• Launchpad Entry: kernel-karmic-flavours

X86 Issues

Many users and some OEMs are requesting the addition of a 32 bit PAE enabled kernel. Their reasons are thus:

• Almost all newer laptops can be purchased or upgraded to have more then 3GB of RAM.
• Many users prefer 32 bit user space in order to more easily use proprietary applications such as Skype and Flash.
• Existing 32 bit users want a 32 bit upgrade option.

The proposed kernel flavours for Karmic are as follows:

• i386-generic (no substantial change from Jaunty)
  • Should the minimum supported instruction set be CONFIG_M686=y? VIA C3, Transmeta Crusoe, and Geode LX are the most common non-Intel embedded x86 CPUs. All support the i686 instruction set (MMX, CMOV). Are there toolset issues with i586 and lower?
• i386-generic-pae (generic with PAE enabled)
• amd64-generic (no substantial change from Jaunty)
  • Is there enough reasons to continue to carry a separate flavour for the server? The process and I/O scheduler can be set at run-time. The biggest compile time option difference is CONFIG_PREEMPT_VOLUNTARY.
• lpia-lpia (no substantial change from Jaunty).
  • Need to think about the impact of true Moorestown support v.s. the i386/Atom approach that we've previously adopted for LPIA. Are there upgrade issues?

Note that the i386-server flavour is being dropped. I can think of no good reason to continue to support a 32 bit server. The 32 bit -generic kernel ought to suffice for those headless implementations that have used the -server flavour in the past, such as home gateways. All of the -server unique settings can be made at runtime to a -generic{-pae} kernel, the most important of which are I/O and process scheduler settings.

A related Blueprint can be found at: https://blueprints.edge.launchpad.net/ubuntu/+spec/use-pae-when-possible

ARM Issues

• armel-armv7 - compiling for v7 may force a number of the ARM SOCs to be dropped.
  • Is it still armel ?

Unsupported Architectures

It has been pointed out that having a separate community maintained kernel tree for unsupported architectures (PPC, HPPA, IA64, SPARC) is causing some package name confusion as well as extra administrative overhead. The proposal is to fold support for those architectures back into the main kernel repository. Given my experience with Hardy I foresee the following issues (with respect to unsupported architectures) :

• An architecture specific patch can cause an ABI change. The current policy is that any interface ABI change requires an ABI bump for all architectures. (I am not inclined to change that policy).
• There is incremental effort required to manage configurations.
• There is incremental effort required to accept, review, and apply patches from the community.

• There will be Launchpad bugs filed against the linux package that are architecture specific.

• If unsupported architecture builds fail, releasing linux-meta for supported architectures will cause linux-meta update warnings for the FTBS architectures.

I would like to hear from archive administrators about the extra overhead imposed by having a ports kernel (and related ABI dependent packages) so that we can make a somewhat subjective judgement.

One positive benefit to folding these unsupported architectures is if we make the decision to backport modern kernels to LTS releases. Hardy does have official support for PPC, HPPA, IA64, and SPARC. See https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-karmic-new-kernel-on-lts

Other Considerations

We already have issues with upgrading old dapper -> hardy -> intrepid leaving the user who has a modern CPU using the unsupported ports 386 kernel instead of the main kernels. We should ensure the kernel selection for Karmic will fix those: https://bugs.edge.launchpad.net/ubuntu/+bug/353534