UDS Intrepid Kernel Team Report
Plans for 8.10
- Linux 2.6.26 Kernel
- Daily kernel builds from git
- Switch to AUFS for unionfs on LiveCD
- Easy install and setup of crashdump infrastructure
- Usage of Grub2
- Compressed swap for low memory LiveCD and LTSP installs
- Kernel ABI policy
- nVidia and ATI drivers split out of LRM and DKMS enabled
- Ability to boot the last successfully booted kernel
- Cleanup of old kernels
- linux source stripped to just i386 and amd64 architectures
- Only building generic and server flavors out of main tree
Note, the kernel track was somewhat ad-hoc because of missing team lead at UDS.
Kernel Bug Migration
Intrepid Kernel Features and Flavors
- Kernel version for Interpid will be 2.6.26
- Improve ABI checking
- Better handling of updateconfigs
- Remove unsupported architectures
- Remove custom-binary flavors
- Trim configs to just generic and server
- Review configs for consistency
Device Driver 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)
Switch to AUFS
- 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
- 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-ID's without updating kernel
- Adds yet another way to identify devices
- gonna ignore it for now.
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.
- Not usable yet in Hardy, needs modifications to grub conf, adding packages, etc.
- amit is gonna do it.
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.
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
- 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.
X Wishlist for the Kernel
List has to be reviewed. No decisions made yet: X/KernelWishlist
- 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).
- 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
- 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.
- 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.
- 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.