Overview

• Abstract - What Needs to Be Done
• The Goals to Reach
  • One Stable Kernel Source Tree
  • Easily Buildable Cross-Toolchain
• What Ports are Out There?
• Proceedings
  • Step 1: Complete Data by asking Port Maintainers
  • Step 2: Sort out what actually needs to be done
  • Step 3: Offering help - Scenarious
• What Port Maintainers Can Do
• Additional Informations
• Responses

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:

• http://www.kegel.com/crosstool/ and http://www.kegel.com/crosstool/ crosstool-howto.html
• http://www.objsw.com/CrossGCC/
• ftp://ftp.foobazco.org/pub/people/wesolows/mips-linux/crossdev/
• http://www.blandsite.org/unixce/docs/HOWTO-Linux-Build-Kernel-SH.txt
• http://billgatliff.com/twiki/bin/view/Crossgcc/ and http://crossgcc.billgatliff.com/index.html
• http://www.ltc.com/~brad/mips/mips-cross-toolchain.html
• http://www.linux4.be/hackers/toolchain.php
• http://www.cse.unsw.edu.au/~cgray/crossdev/x86-alpha-xcc.html
• http://bytesex.org/cross-compiler.html
• http://www.strusel007.de/fun-with-stupid-filters/cross-compiler.html

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?

Proceedings

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:

• Please have a look at the table (above) and drop me a note if you feel anything about it wrong, esp. with your port's/board's entry.
• What source code management tool do you use?
• If you cannot manage to timely sync up your new patches with Linus, do you at least keep them publically accessible? If so, where can I find them?
• Suppose I'd take your latest patches and I'd import them into the most recent Linus kernel release/snapshot, would you assist in digging for bugs there?
• Suppose wo would have achieved to port your patches to 2.[45].current, would you do your best to always import Linus' latest kernel snapshot to reduce future conflicts?
• Suppose I'd had some scripts telling me when code gets changed that you previously changed (only common code, not your port's private code), would you care to look at it after getting notified by me? This is to reduce the risk that others nullify your fixes.

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:

• Ports whose patches are religiously pushed upstream to Linus.
• Ports that don't constantly push their patches (and thus having large amounts of them outstanding) as well as those ports which don't at least always pull Linus' latest sources into their trees.

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:

• Rediffing available (older) patches against most current versions of Linus' kernel releases.
• Importing Linus' kernel releases into some port's repositories.
• Sending patches upstream.
• Notify if workarounds/fixes to common code are getting dropped.
• Maintain an own Linux tree (2.5.x-portn) which could eg. be feeded through CVS/bk/... log emails with containing patches/patchsets). I think this will only really work for 2.5.x (and upcoming 2.7.x) because I think it's basically too late to get 2.4.x to sync up with all port's trees...

What Port Maintainers Can Do

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

• Strongly thinking about starting an own Linux tree for Linux ports (whose first rule will be to keep up with current development kernels), it will help me to have fast and inexpensive read-only access to your CVS/BK/whatever SCM trees. For me, it seems quite practical to use rsync to have your whole CVS repository mirrored to my home machine. There, I can use 100MBit/sec without paying high carrier fees:) If there's any way, please install a rsync server to distribute your CVS repository.
• As I'm not going to start any work based on 2.4.x, you should most probably spend more time on 2.5.x if you really aim at syncing up with Linus at some time. On i386, 2.5.x is quite useable right now and I expect other architectures to follow soon:) So if you've got some time, please try to update your trees from time to time with Linus' current 2.5.x patches. You know, it's easier to merge two things which are mostly identical than to merge patches for 2.5.23 into 2.5.70...
• After I've started my porting tree, it would of course help if you could try to also use this tree. Real usage is the best way to test it. Additionally, I'm thinking about how to properly implement triggers to show when a Linus patch possibly breaks patches intruduced while working on a port.

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:

• http://perso.wanadoo.es/xose/linux/linux_ports.html
• http://www.itp.uni-hannover.de/~kreutzm/de/lin_plattforms.html

Responses

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