Maintaining a net driver in my day job, plus core networking
and PCI code as necessary
Maintaining Linux 3.2.y stable update series on
kernel.org
Debian kernel contributor since 2008; uploader since 2009
Initially trying to deal with the non-free firmware issue
Moved on to triaging bugs, fixing bugs, backporting
features, updating packaging...
Maximilian Attems
Theoretical Physicist
Postdoc of Frankfurt Institute of Advanced Studies
Numerical simulations of Yang-Mills theory on TOP 500 clusters
Linux Contributor since 2004
Linux janitor Maintainer late 2.5 early 2.6, 2.6.32.X stable series
klibc Co-Maintainer
make deb-pkg
Debian Linux Contributor since 2005
Early userspace
x86
Linux kernel
Started by Linus Torvalds in 1991 as a kernel for i386
PCs: just a hobby, won't be big and professional like gnu
Adopted as the kernel of the Debian system in 1993
After 20 years' development, supports more hardware
architectures and devices than anything else
Hardware vendors must provide Linux drivers because
their customers demand it
Still the default kernel for the Debian system
Linux release model
Since ~2004:
Development results in a new stable(-ish) release every 2-3
months
git (and previously BitKeeper) made distributed development
and testing a lot easier
Each 2.6.x and 3.x release has a stable
update branch; releases numbered 2.6.x.y
and 3.x.y
Usually closed shortly after next stable release, but may
continue as a 'longterm' branch (e.g. 2.6.32.y)
Debian kernel team (1)
Who are we?
Currently 5 general maintainers: Maximilian Attems, Bastian
Blank, dann frazier, Ben Hutchings, Moritz Muehlenhoff
Many more specialised contributors:
Specific architectures
Specific features (e.g. Xen)
Bug triage
Would appreciate more help, particularly with bug triage and
PowerPC
Debian kernel team (2)
What do we do?
Bug triage - takes a huge amount of time
Backport bug fixes and features - particularly new hardware
support for stable
...while trying not to change kernel ABI in stable
Update build configurations for each new upstream release -
e.g. to enable new drivers
Try to ensure smooth upgrades when there are major
implementation changes - e.g. KMS, switch to libata drivers
Integrate some features not accepted upstream
Official Linux kernel packages (1)
Main source package is linux. Most
binary package names change regularly.
linux-image-upstream-abi-flavour
- compiled kernel and modules
linux-headers-upstream-abi-flavour
(and others) - development package for OOT modules
linux-libc-dev - headers for userland
linux-source-upstream -
for custom kernels
linux-doc-upstream,
linux-manual-upstream, etc.
linux-support-upstream-abi -
scripts and metadata to support linux-latest
Official Linux kernel packages (2)
The linux-latest source package builds meta-packages
to support automatic upgrades between binaries built
from linux.
linux-image-flavour
linux-headers-flavour
linux-source,
linux-doc,
linux-tools, etc.
The installer will normally install
linux-image-flavour (for
some appropriate flavour).
Official Linux kernel packages (3)
firmware-free - separate 'firmware'
compliant with DFSG
linux-base - base package for
images and tools
linux-tools builds
linux-kbuild-upstream -
kernel build system and tools for building OOT modules
linux-tools-upstream
- perf tool
usbip - usbip configuration
tools
Official early userspace
Main source package is initramfs-tools.
Co-developed with Ubuntu and hence sharing all the pain^Wfun of the
software and that special relation.
In any case a huge step forward after the very special initrd-tools.
initramfs-tools paved the way for pluggable initramfs generators.
But, early userspace shouldn't be visible to users.
Todays dev sits in dracut. With better maintenance inside the team
very likely candidate for Debian 8.0.
Upcoming challenge: secureboot.
Custom Linux kernel builds
The official packages work for most users, but not all:
Different ARM platforms need incompatible configurations,
and we cannot build them all
New features are not enabled immediately if we are worried
about potential regressions
Using either upstream source or Debian linux-source package:
make && make install
make deb-pkg - build packages
make-kpkg - build packages with
more customisation; requires
kernel-package
Extra features
Always aim to get patches merged upstream. But many big features
that users want added are not merged upstream for a long
time. Kernel team expects features to be upstream first, then
backported.
But there have been exceptions:
OpenVZ and VServer - being reimplemented upstream with cgroups
and namespaces
Xen - now upstream
aufs - needed for Debian Live
PREEMPT_RT - gradually being merged upstream; new option in
amd64 and i386 packages
Out-of-tree modules
The kernel team does not encourage the use of out-of-tree modules.
However, we support them by providing development packages and by
avoiding ABI changes during a stable release.
Debian has two packages to aid in building out-of-tree modules:
dkms - builds and installs modules
automatically. Can build packages for installation on other
systems. Also supported by Ubuntu and SUSE.
module-assistant - builds packages
as directed. Uses a separate package name for each kernel ABI.
Firmware files
Most peripherals have microcontroller running non-free
firmware; some require host to load it
Several drivers used to include firmware, making kernel
non-free. Fudged with GRs for a while; finally fixed in squeeze
Users with these devices - almost any wifi card, some network
controllers and Radeon GPUs - will still need the firmware
files installed
Kernel team maintains
firmware-nonfree source package
covering most firmware files that are clearly redistributable
Also collected in linux-firmware.git repository maintained by
David Woodhouse and Ben Hutchings