Maintaining a net driver in my day job, plus core networking
and PCI code as necessary
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...
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 (1)
The old model:
Each stable release had even second component. Bug fixes and
minor features in stable releases with third component
incremented (e.g. 2.4.27)
Major development done separately, resulting in series of
unstable releases with odd second component (e.g. 2.5.50)
After a year or two, development resulted in a new stable
release
Problem: users waited years for new features, and then got many
more changes all at once. Particularly bad in the 2.4-2.6
transition.
Linux release model (2)
The new model:
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 release has stable update branch; releases
numbered 2.6.x.y
Usually closed shortly after next stable release, but may
continue as a 'longterm' branch (e.g. 2.6.32.y)
Linux 3.0 doesn't change this, except that x is now
the second component and y is the third
Debian kernel team (1)
Who are we?
Currently 5 general maintainers: Maximilian Attems, Bastian
Blank, dann frazier, Moritz Muehlenhoff and me
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-2.6
(still!). 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-tools-upstream, etc.
linux-support-upstream-abi -
scripts and metadata to support linux-latest-2.6
Official Linux kernel packages (2)
The linux-latest-2.6 source package builds meta-packages
to support automatic upgrades between binaries built
from linux-2.6.
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-kbuild-2.6 builds
linux-kbuild-upstream -
kernel build system and tools for building OOT modules
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 - mostly reimplemented with cgroups and
namespaces
Xen - now upstream; Linux 3.0 is a useful dom0 kernel!
aufs - needed for Debian Live
PREEMPT_RT - gradually being merged upstream; new option in
amd64 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 myself