The following are my opinions on the state of the Linux kernel for the various architectures that use it, roughly in order from best to worst. My main involvement in non-x86 architectures is trying to deal with build failures and other obvious bugs, which is likely to give me something of a bias against them. So I encourage other kernel team members to correct/counter the following as necessary.
* amd64/i386: If we can't support these then we should give up on the release altogether. :-) * armel/armhf: These have long been problematic due to the diversity of hardware platforms and 'siloed' development by platform vendors. However, vendor participation and coordination has improved greatly and there is also some hope of reducing the number of kernel flavours needed in future. A minor concern I have is that I find it hard to get bug fixes reviewed and applied upstream. In Debian, there are multiple kernel maintainers with ARM expertise, and I have no doubt about our ability to maintain these architectures. * mips/mipsel: This seems to be quite actively developed upstream, with contributions from multiple hardware vendors and others. In Debian, the kernel maintainer is Aurelien Jarno. One concern I have about this architecture is the lack of support for initramfs in some boot loaders. Our MIPS kernel images currently have more code built-in and less support for different boot configurations than most other architectures. I believe Aurelien has been working to resolve this, however. * s390/s390x: Actively supported upstream by IBM. Only runs in virtual machines, so there is relatively little diversity of 'hardware' or need for hardware support. In Debian, the main kernel maintainer is Bastian Blank; Aurelien Jarno is also doing some work on it. * sparc: This is actively maintained upstream by David Miller, but quite reasonably this seems to be a lower priority for him than networking. So far as I know, no hardware vendor supports Linux on SPARC. In Debian, the kernel maintainer is Jurij Smakov, though I don't think he has a lot of time for it. * powerpc: This is quite well supported upstream. For the platforms we support, upstream development is dominated by IBM which is primarily concerned with 64-bit systems. One change made it into the 2.6.32.y-longterm branch without anyone ever testing a 32-bit configuration (where it failed to build). There is no Debian kernel maintainer for powerpc. I also see a problem of hardware availability for prospective maintainers (no new PowerPC Macs since 2006; PS3 'OtherOS' support removed in 2010). I am unsure whether this port should be included in wheezy. * ia64: So far as I can tell, there is no longer any commercial support for Linux on Itanium aside from existing contracts. The upstream maintainer (Tony Luck) does not seem to be able to spend much time on it, and contributions from other developers are mostly just adjustments for kernel-internal API changes (which often result in regressions). For example, a system call added in Linux 2.6.27 and now required by udev was not 'wired up' for ia64 until Linux 3.3 (over 3 years later). This is also one of two architectures where we still have to enable an old-style IDE driver as there is no replacement using libata. (The other is m68k.) Dann Frazier is still listed as the Debian kernel maintainer for ia64, but I'm not sure that he's still able to do this. If not, I don't believe this port should be included in wheezy. Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it.
signature.asc
Description: This is a digitally signed message part
