KernelNattyVersionAndFlavours

Differences between revisions 1 and 9 (spanning 8 versions)
⇤ ← Revision 1 as of 2010-09-21 06:46:31 →
Size: 2280
Editor: 210-242-151-101
Comment:
← Revision 9 as of 2010-10-26 16:35:57 → ⇥
Size: 4279
Editor: host194
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
 * '''Launchpad Entry''': UbuntuSpec:kernel-natty-version-and-flavours  * '''Launchpad Entry''': UbuntuSpec:hardware-kernel-n-version-and-flavours
Line 10: Line 10:
Discuss the mainline baseline version for Natty. Also discuss the current kernel flavours for each architecture. We will also discuss the source branch for these flavours. Finally we will touch on the ports architectures.
Line 12: Line 14:
This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.) None.
Line 14: Line 16:
It is mandatory. == Kernel Version ==
Line 16: Line 18:
== Rationale == Discussions on which mainline kernel base is appropriate for Natty. As Natty is not an LTS we do not require a specific version for alignment upstream. Therefore we will be using the latest version released at kernel freeze.
Line 18: Line 20:
== User stories == == Flavours ==
Line 20: Line 22:
== Assumptions == Are we carrying the appropriate flavours?
Line 22: Line 24:
== Design == === Current Flavours ===
Line 24: Line 26:
You can have subsections that better describe specific parts of the issue. ==== Distro ====
||'''Architecture'''||'''Flavour'''||'''Description'''||
|| i386 || generic || kernel for desktop machines with less than 4GB of ram ||
|| i386 || generic-pae || kernel for desktop machines with more than 4GB of ram ||
|| i386 || virtual || kernel for virtual machine use (KVM/EC2) ||
|| amd64 || generic || kernel for desktop machines ||
|| amd64 || server || kernel for server machines ||
|| amd64 || virtual || kernel for virtual machine use (KVM/EC2) ||
|| armel || versatile || kernel for ARM versatile (QEMU) ||
|| armel || omap || kernel for ARM OMAP-3 hardware ||
Line 26: Line 37:
== Implementation == ==== Ports ====
||'''Architecture'''||'''Flavour'''||'''Description'''||
|| powerpc || powerpc || PowerPC ||
|| powerpc || powerpc-smp || PowerPC with SMP support ||
|| powerpc || powerpc64-smp || PowerPC64 with SMP support ||
Line 28: Line 43:
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:
Line 30: Line 44:
=== UI Changes === == New Flavours ==
Line 32: Line 46:
Should cover changes required to the UI, or specific UI that is required to implement this === 64bit kernels on 32bit userspace (amd64 on i386) ===
Line 34: Line 48:
=== Code Changes === We have had a number of requests for a 64 bit kernel (amd64) for 32 bit (i386) installs. This gives the user the advantages of running 64 bit in terms of kernel memory handling improvements while maintaining the 32 bit userspace which remains more compatible with 3rd party applications.
Line 36: Line 50:
Code changes should include an overview of what needs to change, and in some cases even the specific details. rtg - I suspect there will be some caveats to this combination. For example, VmWare may not work, nor will other virtualization programs. 64 bit chroots will likely also not be possible because of packaging resaons, despite the 64 bit kernel.
Line 38: Line 52:
=== Migration === === Low-latency kernel ===
Line 40: Line 54:
Include:
 * data migration, if any
 * redirects from old URLs to new ones, if any
 * how users will be pointed to the new way of doing things, if necessary.		 With nobody committed to maintain a kernel with Ingo's RT patches in, is a kernel with config changes to prefer low latency over e g power consumption the next best thing we can give e g ubuntu-studio users? Are Alessio's lowlatency suggestions a good base for such a flavour?
Line 45: Line 56:
== Test/Demo Plan == == Flavour Source Disposition ==
Line 47: Line 58:
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage. In Maverick the master branch produced two ARM flavours, versatile and OMAP3. With Linaro also producing OMAP3 kernels it may be appropriate to switch the source of these kernels over to that kernel; even if we do not it may be appropriate to pull out this into its own branch.
Line 49: Line 60:
This need not be added or completed until the specification is nearing beta. rtg - Given how well the Linaro arm flavour is doing, I'm of the opinion that the only armel flavour that should be produced by the master branch is versatile (for qemu). There is currently a lot of unnecessary duplication between Maverick master(omap3)/ti-omap4/mvl-dove and the linux-linaro kernel package produced by John Rigby.
Line 51: Line 62:
== Unresolved issues == == Ports Architectures ==
Line 53: Line 64:
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. As ia64 and sparc are now officially dead we are only carrying powerpc as a ports architecute. As the source is now carried primarily on the master branch is there any longer any value in treating this differently. Specifically should we be pulling back the ports meta package into the main one to simplify maintenance.
Line 57: Line 68:
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.  * Kernel Version
 * Flavours
   * review of the current flavours distro and ports
 * Proposed new Flavours
   * 64bit kernel for 32bit userspace (amd64 kernel on i386)
   * lowlatency
 * Flavour source disposition
   * OMAP3 should this be split out from the master branch
    * can we pull this from linaro instead
 * PORTS architectures
   * should we pull powerpc meta package back into the master repos

== Decisions ==

Summary

Discuss the mainline baseline version for Natty. Also discuss the current kernel flavours for each architecture. We will also discuss the source branch for these flavours. Finally we will touch on the ports architectures.

Release Note

None.

Kernel Version

Discussions on which mainline kernel base is appropriate for Natty. As Natty is not an LTS we do not require a specific version for alignment upstream. Therefore we will be using the latest version released at kernel freeze.

Flavours

Are we carrying the appropriate flavours?

Current Flavours

Distro

Architecture

Flavour

Description

i386

generic

kernel for desktop machines with less than 4GB of ram

i386

generic-pae

kernel for desktop machines with more than 4GB of ram

i386

virtual

kernel for virtual machine use (KVM/EC2)

amd64

generic

kernel for desktop machines

amd64

server

kernel for server machines

amd64

virtual

kernel for virtual machine use (KVM/EC2)

armel

versatile

kernel for ARM versatile (QEMU)

armel

omap

kernel for ARM OMAP-3 hardware

Ports

Architecture

Flavour

Description

powerpc

powerpc

PowerPC

powerpc

powerpc-smp

PowerPC with SMP support

powerpc

powerpc64-smp

PowerPC64 with SMP support

New Flavours

64bit kernels on 32bit userspace (amd64 on i386)

We have had a number of requests for a 64 bit kernel (amd64) for 32 bit (i386) installs. This gives the user the advantages of running 64 bit in terms of kernel memory handling improvements while maintaining the 32 bit userspace which remains more compatible with 3rd party applications.

rtg - I suspect there will be some caveats to this combination. For example, VmWare may not work, nor will other virtualization programs. 64 bit chroots will likely also not be possible because of packaging resaons, despite the 64 bit kernel.

Low-latency kernel

With nobody committed to maintain a kernel with Ingo's RT patches in, is a kernel with config changes to prefer low latency over e g power consumption the next best thing we can give e g ubuntu-studio users? Are Alessio's lowlatency suggestions a good base for such a flavour?

Flavour Source Disposition

In Maverick the master branch produced two ARM flavours, versatile and OMAP3. With Linaro also producing OMAP3 kernels it may be appropriate to switch the source of these kernels over to that kernel; even if we do not it may be appropriate to pull out this into its own branch.

rtg - Given how well the Linaro arm flavour is doing, I'm of the opinion that the only armel flavour that should be produced by the master branch is versatile (for qemu). There is currently a lot of unnecessary duplication between Maverick master(omap3)/ti-omap4/mvl-dove and the linux-linaro kernel package produced by John Rigby.

Ports Architectures

As ia64 and sparc are now officially dead we are only carrying powerpc as a ports architecute. As the source is now carried primarily on the master branch is there any longer any value in treating this differently. Specifically should we be pulling back the ports meta package into the main one to simplify maintenance.

BoF agenda and discussion

  • Kernel Version
  • Flavours
    • review of the current flavours distro and ports
  • Proposed new Flavours
    • 64bit kernel for 32bit userspace (amd64 kernel on i386)
    • lowlatency
  • Flavour source disposition
    • OMAP3 should this be split out from the master branch
      • can we pull this from linaro instead
  • PORTS architectures
    • should we pull powerpc meta package back into the master repos

Decisions

CategorySpec

KernelTeam/Specs/KernelNattyVersionAndFlavours (last edited 2010-12-08 14:42:07 by 212-139-219-66)