Intrepid Kernel UDS Planning
These are the kernel track titles and a rough outline of the topics that I think need to be covered during each track.
2008-05-19
11:00 Building Upstream Kernels
- Decided to use kernel-ppa
- Once ubuntu kernel freezes it will begin to diverge from upstream. Maintaining the upstream kernel and the intrepid kernel in the same ppa will be problematic (until private ppa's are available via launchpad 2.0 - July 2008?). Until private ppa's are available, a kernel team policy decision was made that after the ubuntu kernel freezes the kernel-ppa will no longer provide the upstream bleeding edge kernel.
- kernel-ppa will be sync'd with upstream on an ad-hoc basis (typically weekly or when upstream -rc releases)
- Bug triagers to warn users of lum/lrm/lbm abi skew - make sure they are using a version of lum/lrm/lbm built after the kernel they will be using
- update-manager should automatically pick up any updates since the ubuntu package version is updated
[Resolved by rebase to current "Y" stream.]
12:00 Kernel Bug Migration
- See htps://wiki.ubuntu.com/QATeam/KernelBugMigration
[In Progress]
16:15 Intrepid Kernel Features and Flavours
- Kernel for Interpid
- version (most likely 2.6.26) [DONE]
- Custom-Binary flavours
- Should we keep them? [Need community member to step up to complete]
- ABI check for custom-binary flavours [DONE]
- splitconfig for custom-binary [DONE]
- incorporate custom binaries into updateconfigs check (a frequent cause of FTBS) [DONE]
- ia64, hppa, sparc, powerpc fate - These arches will be maintained by the community in a main package. [DONE]
- lpia might become a regular flavour instead of custom-binary. [DONE]
- One of the issues discussed at the Feb/08 Lexington Sprint with lpia developers was that since lpia maintains out-of-tree patches, they are not always prepared for a kernel upload. However, lpia image creation is based on the latest kernel in the lpia archive (not always the right choice). It is possible for the uploaded kernel to be based on older lpia code then is in the lpia PPA archive because it is still undergoing development. It may make sense to decouple the lpia build cycle from the distro kernels.
- Consider a 'debug' flavour for i386/amd64, possibly use the kernel PPA to generate the debug flavour. [REJECTED in favor of crashdump]
- Disable debug mechanisms in main flavours, enable in debug flavour
- Check into using current debug image
- default enable latencytop in the debug flavour
Discussion results:
* All custom binaries (xen, rt, openvz, lpia) will get their own universe package as long as there is a maintainer to take maintenance responsibilities. lpia is a special case since the Mobile team will own and maintain it. [DONE]
* Kernel version is most likely to be 2.6.26. [DONE]
* All non-x86 arches will be in one universe package to be community maintained, based on 2.6.25. This package will also support the -386 flavour.
* Debug kernel - this still requires some thought as it is going to add to kernel team maintenance overhead. It also begs the question of for which flavour do we enable debug? All of them? latencytop would be part of the debug flavour. [REJECTED see above]
* x86/x86_64 flavours are -generic, -server, -virtual. [All are there except virt]
* Dan Shearer mentioned that 64 bit lguest may have stability issues.
2008-05-20
09:50 Review Unfulfilled specs from Hardy
driver-device-manager [Deferred in favor of Jocky's roadmap]
livecd-unionfs-alternatives [Complete using AUFS]
grub2 [Deferred grub2 still not ready]
kernel-build-system-feature-requests [Spec page is up to date]
new-pci-ids [Rejected]
daily-kernel-builds [Complete won't be daily most likely weekly]
linux-kernel-crash-dump [Done]
Discussion results:
* Device Manager
- This spec makes much more sense for the platform team.
- There is nothing on the kernel side that needs to be implemented still.
- This would be a distro-agnostic program
DeviceKit might be a good choice (instead of HAL)
* aufs support
- aufs is now implemented in LUM.
- We should pull an update for aufs though, as there was a new update on 2008-05-19
- If the desktop/platform folks would like to use it, they can
* Grub 2
- grub2 can replace isolinux
- can replace gfxsplash?
- supports usb keyboards?
- more modular
- better filesystem support
- still under development
- not so good at supporting buggy bioses than isolinux
- Dell interested for localization support
- China requirements for localized menus
- Debian proposal to switch to grub2 instead:
- Colin King is going to create a livecd with grub2 to start playing with it
* New PCI ids without updating kernel
https://blueprints.edge.launchpad.net/ubuntu/+spec/new-pci-ids
- Adds yet another way to identify devices
- gonna ignore it for now.
* Daily kernel builds
https://blueprints.edge.launchpad.net/ubuntu/+spec/daily-kernel-builds
- 'Daily' doesn't make sense
- new modules need intervention
- tree isn't always in a build-able state
- ABI skew will cause problems with LUM, LRM, LBM
- Currently done manually using debian/scripts/misc/prepare-ppa
- The kernel is uploaded to the kernel-ppa account on launchpad
- Tim is going to clean up the script and DOCUMENT it.
* Kernel crash dump
- Not usable yet in Hardy, needs modifications to grub conf, adding packages, etc.
- amit is gonna do it.
2008-05-21
09:50 Live CD memory requirements: compcache
Our target is to reduce Kernel RAM requirements for the distro. This will help on Subnotebooks, LiveCDs, and Thin Clients. We are reviewing the compcache kernel module for achieving this.
Compcache was developed as a Google SoC project and is already used in distros like altlinux in their LTSP kernel flavour with success. http://code.google.com/p/compcache/
There is a bug open on launchpad with prepared diffs to the 2.6.24 kernel image as well as prebuilt Live isos.
We will enable it in intrepid in linux-ubuntu-modules to get proper testing during the release cycle and to work out a proper userspace integration with udev etc. If feasable a Hardy backport might be considered.
Related Bugs
Add compcache modules, allowing ubiquity installs on 256MB machines: https://bugs.launchpad.net/ubuntu/+bug/200765
Xubuntu requires more than 128mb of ram to install via LiveCD: https://bugs.edge.launchpad.net/ubuntu/+source/xubuntu-meta/+bug/70561
Outstanding Issues
* CPU usage has to be reviewed
- - Works on the principle of swap replay; swap in/out events are relayed to userspace, where it is compressed
* a cleaner way than the included initscripts should be found and integration
- with udev for the device creation is needed
* what is the impact on suspend/hibernate/resume ?
Apparently there are some known problems http://code.google.com/p/compcache/issues/detail?id=2 talking about freezes on ARM architecture. Since ARM does suspend completely different (the clock is separated from the CPU, so ARM shuts down completely while x86 CPUs have an internal clock and never power down completely on suspend) it might not be an issue at all on x86 based CPUs.
15:00 X Wishlist for the Kernel
2008-05-22
15:00 Kernel Process Issues
- Process issues
Devise a way to notify ISV a bit in advance of kernel ABI changes(or whomever whould like to). See https://wiki.ubuntu.com/Ubiquity/DriverUpdates which started this discussion in MountainView.
- Evaluate bug handling
15:15 LRM Reorganization
- Restructure LRM similar to LUM/LBM.
- Put LRM under version control.
- Does it really need to be?
- Think about splitting out fglrx and nvidia into DKMS packages (envyng?)
- Get rid of unneeded drivers from lrm (cleanup).
- fritz?
- ltmodem?
- Do we really need lrm for non-x86 (ports)?
- Only things that really get built now are: madwifi and fritz
- Do we even care of madwifi is supported here?
- Should we leave it to the ports teams to worry about this?
- Likely applies to lum/lbm too. No need to build that on non-x86
Discussion Results:
- Move video drivers into DKMS packages in an experiment to see how well it works to build these on the desktop. The fallback is to build binary debs as part of the build. Mario Limoncello and Alberto Milone to be the graphics drivers package maintainers.
- Put LRM packaging under git control, but place the binaries in a publicly accessible location such as people.ubuntu.com. Add a debian/rules target to populate the appropriate binaries, e.g., make the binaries a make dependency.
- No action on fritz, ltmodem, or madwifi (unless ath5k proves to be mature enough)
- Only build LRM for x86/X86_64, but build for all flavors.
2008-05-23
15:00 WLAN mesh networking support
Miscellaneous
Left over topics that were resolved (or not) in hallway discussions:
- Driver work
- Make broken-bios kernel messages more visible to user (without being annoying)
- ath5k help - rtg to test on Atheros HW
- fritz/fritz64/ltmodem: Look into free alternatives, check for new versions, evaluate if they even need to be in lrm anymore - maybe just boot them out of LRM and see who complains. Is anyone still using it?
- Cleanup lum drivers - Colin to look at build warnings and other noise.
- Look at how other distros are handling alsa outside the kernel tree - Is building ALSA in LUM really the best way? It almost works for Hardy, but there are some gotchas for the inexperienced.
- Look into dkms for out-of-tree kernel modules (lum/lbm/lrm) - we should gain experience with this method after splitting out the ATI/nVidia graphics drivers from LRM.
- Tainting for non-ubuntu modules
- Fix LIRC build warnings
- incorporate loopback patches to support Wubi dirty buffer writebacks - Colin K. to look into this.
http://wireless.kernel.org/en/users/Download for Gutsy/Hardy LBM - look at backporting the compat wireless tree.
- Bookkeeping (packaging details)
- Create a debian/rules target that sets up an external build directory for mucking with configs so as to not taint sources - the prepare target already does this.
- Re-use config answers during updateconfigs - perhaps more difficult then you might think, and not always the right thing to do. With the reduction in CPU arches and flavours I don't think this is as much of an issue.
- Miscellaneous
- Look into boot time speedups - Amit to investigate prefetch SoC patch along with keybuk.
- Look into kerneloops.org usage (sync from Debian)
- Look at new scheduler configs - CONFIG_CGROUP_SCHED, CONFIG_SCHED_HRTICK, CONFIG_SCHED_DEBUG, et al.