[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Architecture qualification for wheezy - status of Linux kernel

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,

* 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 Hutchings
Design a system any fool can use, and only a fool will want to use it.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: