Abstract - What Needs to Be Done

Currently, some ports to non-PC architectures are quite good maintained and useable out of the box with currently released upstream kernels. At least, this seems to count for Alpha, StrongARM, SuperH and UltraSparc. Mainstream PPC hardware also seems to be well-supported.

Some other ports don't have a lot of outstanding patches, but there's little development at all which makes it quite hard (if possible at all) to get a current 2.4.x or 2.5.x kernel running on those machines. This is notably true for Sparc (SparcStations) and some M68k variants (Atari).

Some other ports do have own source code repositories with a large number of outstanding patches. Additionally, these architectures oftenly can use common (eg. ISA or PCI) drivers, but need to tweak them a little (which means that there are arch-dependant patches to arch-independant drivers which are hard/not-nice to merge, especially if no communication to the initial author fires up to really resolve those problems). At least, PA-RISC, PA-RISC64 and all MIPS incarnations belong to this category.

Then, there are some other architectures which do have a really small user base. Problem here is that these ports are not really well-tested and there's little known about them at all. Some of them seem to die at some time, while some other are just starting (small user base because hardware isn't yet commonly available). This includes cris, m68k, m68knommu, v850 on the one hand and ia64, s390(x), um and x86_64 on the other hand...

The Goals to Reach

The core goal of this project is to ease usage of Linux on non-Intel compatible computers. Installation itself is more or less self-containent and I don't plan doing anything there. But from my today's view, an average-experienced non-Intel user (which is, most of the time, a Linux power user) expects some things from Linux:

One stable kernel source tree.
Non-Intel users expect to have one kernel source tree that is known to work, which I think is a worthwhile goal. Currently, most architectures do maintain their own trees. This is why I think about starting an own Linux tree which contains all the ports. After everything is merged (and somewhat working), I will kindly ask arch maintainers to start feeding patches to Linus (or to get permission to do that myself - I'll not send any patches on my own).
Easily buildable cross-toolchains.
Some of those architectures are not the fastest ones. Distributions are expected to provide userland binaries (for most archs, Debian's ports will be the way to go - no other distribution supports that many systems. The second part of a running system is the kernel itself. Most users (out of the expected user base) will try to build their own kernel images. As many supported boxes are not the fastest, cross-compiling (eg. building the Linux kernel on a 3GHz Intel box for an old little Sparc machine) will be the way to go. However, building a cross-compiler isn't exactly known to be easy so we need some proper documentation and some scripts here. Best I've found so far are:

After these two main goals are done, the highest hurdles for upgrowind non-Intel kernel hackers and power users are taken:)

What ports are out there?

CPU Board 2.4.x 2.5.x Maintainers / Important Contributors Web Site Mailing Lists
Alpha all Up to date Up to date Richard Henderson <rth@twiddle.net>
Ivan Kokshaysky <ink@jurassic.park.msu.ru>
3000 TurboChannel Not yet supported Not yet supported George Armhold <armhold@cs.rutgers.edu>
Craig P. Prescott <prescott@phys.ufl.edu>
Cris all Unknown Unknown Bjorn Wesen <bjornw@axis.com> http://developer.axis.com/ dev-etrax@axis.com
H8300 all Unknown Unknown Yoshinori Sato <ysato@users.sourceforge.jp>    
i386 all Up to date Up to date Linus Benedict Torvalds <torvalds@transmeta.com> http://www.kernel.org/ linux-kernel@vger.kernel.org
visws Unknown Unknown Andrey Panin <pazke@donpac.ru> http://linux-visws.sf.net/ linux-visws@lists.sf.net
PC9800 Unknown Unknown Osamu Tomita <tomita@cinet.co.jp> http://www.kmc.gr.jp/proj/linux98/index-english.html  
IA64 all Unknown Unknown David Mosberger-Tang <davidm@hpl.hp.com> http://www.linuxia64.org/ linux-ia64@linuxia64.org
m68k all 2.4.x mostly works, Atari might suffer from bit rotting (better try 2.2.x). Amiga (no SCSI) and Q40/Q60) should work, other boards need work. Jes Sorensen <jes@trained-monkey.org> is port maintainer, Geert Uytterhoeven <geert@linux-m68k.org> and Roman Zippel <zippel@linux-m68k.org> are keeping CVS (http://linux-m68k-cvs.apia.dhs.org/) up to date. http://www.linux-m68k.org/
amiga Should work. Currently no SCSI, needs little work Geert Uytterhoeven <geert@linux-m68k.org>    
apollo Unknown Unknown      
atari Probably broken, 2.2.x should work. Most probably broken.      
mac 2.2.x in CVS at http://linux-mac68k.sourceforge.net/ is th is the last known-good kernel for m68k-MACs. 2.4.x is most probably broken at the moment. 2.5.x is most probably broken at the moment. Joshua Thompson <funaho@jurai.org>
Ray Knight <audilvr@speakeasy.org>
http://www.mac.linux-m68k.org/ linux-mac68k@mac.linux-m68k.org
HP9000/300 Unknown Unknown Philip Blundell <philb@gnu.org> http://www.tazenda.demon.co.uk/phil/linux-hp/  
q40/q60 Seems to have little aged, outstanding patches Unknown Richard Zidlickyrz <rz@linux-m68k.org> http://linux-q40.sourceforge.net/  
sun3 Unknown Unknown Sam Creasey <sammy@sammy.net> http://sammy.net/sun3/ sun3-list@redhat.com
sun3x Unknown Unknown Sam Creasey <sammy@sammy.net> http://sammy.net/sun3/ sun3-list@redhat.com
VME Unknown Unknown Richard Hirst <richard.hirst@gpt.co.uk>    
m68knommu all Unknown Unknown Greg Ungerer <gerg@snapgear.com>
David McCullough <davidm@snapgear.com>
http://www.uclinux.org/ jeff@uclinux.org
MIPS all Nearly up to date, many patches need to go upstream After a killer import, 2.5.x is at a current state and some surgery is done to make it run again. A ton of patches went upstream after 2.5.73, more is to follow. Ralf Bächle <ralf@linux-mips.org> http://www.linux-mips.org/ linux-mips@linux-mips.org
DECstation Nearly up to date, many patches need to go upstream After a killer import, 2.5.x is at a current state and some surgery is done to make it run again. Maciej W. Rozycki <macro@ds2.pg.gda.pl> http://www.linux-mips.org/
Misc. Boards Nearly up to date, many patches need to go upstream After a killer import, 2.5.x is at a current state and some surgery is done to make it run again.    
PA-RISC all Up to date, patches need to go upstream Up to date, patches need to go upstream Matthew Wilcox <matthew@wil.cx>
Grant Grundler <grundler@parisc-linux.org>
http://www.parisc-linux.org/ parisc-linux@parisc-linux.org
PPC all Unknown Unknown Benjamin Herrenschmidt <benh@kernel.crashing.org>
Roman Zippel <zippel@linux-m68k.org>
IBM RS6000 (PREP) 2.4.x seems to work out of the box Unknown http://penguinppc.org/
NuBus-based PPC-MACs (61xx, 7100, 8100, 62xx and 52xx systems) BK-tree at http://nubus-pmac.bkbits.net/ is somewhat working Unknown Etsushi Kato <ekato@ees.hokudai.ac.jp>
Ray Knight <audilvr@speakeasy.org>
Pre-compiled kernels are available at ftp://ppc.linux.or.jp/pub/users/ekato/nubus-pmac/current/ "linuxppc-nubus"-list at http://lists.linuxppc.org
PPC64 all Unknown Unknown David Engebretsen <engebret@us.ibm.com> http://linuxppc64.org/  
S/390 all Unknown Unknown Martin Schwidefsky <schwidefsky@de.ibm.com> http://oss.software.ibm.com/developerworks/opensource/linux390/ linux-390@vm.marist.edu
Sparc all Mostly up to date, but some issues... Mostly up to date, but some (more?) issues... Pete Zaitcev <zaitcev@redhat.com>
Dave S. Miller <davem@redhat.com>
http://osinvestor.com/sparc/ sparclinux@vger.kernel.org
sun4 Unknown Unknown   http://osinvestor.com/sparc/ sparclinux@vger.kernel.org
sun4c Unknown Unknown   http://osinvestor.com/sparc/ sparclinux@vger.kernel.org
sun4d Unknown Unknown   http://osinvestor.com/sparc/ sparclinux@vger.kernel.org
sun4m Unknown Unknown   http://osinvestor.com/sparc/ sparclinux@vger.kernel.org
Sparc64 sun4u Mostly up to date Mostly up to date Dave S. Miller <davem@redhat.com> http://www.ultralinux.org/ ultralinux@vger.kernel.org
StrongARM all Unknown Unknown Russell King <rmk@arm.linux.org.uk> http://www.arm.linux.org.uk/ linux-arm-kernel@lists.arm.linux.org.uk
pt Unknown Unknown Stefan Eletzhofer <stefan.eletzhofer@eletztrick.de>
shark Unknown Unknown Alexander Schulz <alex@shark-linux.de> http://www.shark-linux.de/shark.html  
SuperH all Unknown Unknown Niibe Yutaka <gniibe@m17n.org> http://linuxsh.sourceforge.net/ linux-sh@m17n.org
UM all Unknown Unknown Jeff Dike <jdike@karaya.com> http://user-mode-linux.sourceforge.net/ user-mode-linux-devel@lists.sourceforge.net
VAX all Experimental port with mostly statically linked userland, no glibc support yet.   http://linux-vax.sourceforge.net/index.html  
V850 all Unknown Unknown Miles Bader <miles@lsi.nec.co.jp> http://www.ee.nec.de/uclinux/  
X86_64 all Unknown Unknown Andi Kleen <ak@suse.de> http://www.x86-64.org/ discuss@x86-64.org


Step 1: Complete Data by asking Port Maintainers

To complete needed date (we at least need to know what at all needs to be done:) I'm planing to send an email to all port and board maintainers asking them:

Step 2: Sort out what actually needs to be done

After inquiring latest data on all those ports, we will separate them into two groups:

I'll simply forget about the first group because we cannot do anything for them:) However, the second group of ports need help. For these ports, we've got to choose the best method of resyncing them with Linus. Additionally, I'll pay attention that their 2.5.x files are kept up to date. I'm sure that it would be nice to have a fully working 2.4.x, but I suspect there's so much code outstanding that there's no way in syncing that. This way, I'll mostly try to get 2.5.x (and later development releases) fully synced to achieve future value. Having 2.4.x fine and all might be nice, but it's worthless if you die in 2.5.x..

Step 3: Offering help - Scenarious

This is what I can offer:

What Port Maintainers Can Do

As a port maintainer, you can do quite a lot to improve current situation:

Additional Informations

All informations presented on this web page are seamlessly stolen from different web sites all over the world. Most of them came from port specific home sites.

Additionally, some good hints and lots of corrections had been sent to me by email from various volunteering persons, especially from quite some port maintainers. After all, their help and knowledge is what is needed here! Thanks a lot!

Further more, I already looked at these pages (or I need to) to compile the table above:


I already contacted some port maintainers and here's what they told me. Note that this is only a collection of results, emails, IRC chats and so on. It's far from being complete...

Dave S. Miller (Sparc and Sparc64)
Dave always tries to get his patches upstream as fast as possible. That way, Sparc and Sparc64 are basically up-to-date all the time. Despite that, Sparc still needs hackers because Dave is only collecting patches for these machines (and no longer actively developing on these boxes).
Geert Uytterhoeven (m68k)
m68k seems to really suffer from it's too small user base. Geert is doing a great job in keeping it alive, but some machines really need some polish again to come back to live.
Ralf Bächle (MIPS and MIPS64)
Ralf did import tons of 2.5.x patches into the MIPS CVS repository recently within really short time and he's now working on making it really useable again. He also sent some hugh patches to Linus recently.

Please send hints, additions, comments, patches and corrections to Jan-Benedict Glaw <jbglaw@lug-owl.de>. Flames and insults will be silently ignored.

Last changed: Tue, 09 Sep 2003 21:27:56 +0200