dc13 - 1.0


Ben Hutchings
Day DebConf day 5 (2013-08-15)
Room Second talk room
Start time 14:30
Duration 00:45
ID 1017
Event type meeting
Language en

Destabilising the Linux kernel module ABI

The Linux kernel developers do not attempt to provide a stable ABI to kernel modules. In Debian stable releases we do attempt to maintain a stable ABI, for good reasons, but that itself causes several problems. Can we do better with an unstable ABI?

Maintaining a stable kernel module ABI causes these problems:

  1. Upstream bug fixes that need to be backported in a stable release will often include an ABI change, and it can require extreme efforts to avoid the ABI change in the backported version.
  2. Kernel package names must reflect their ABI, similarly to shared library packages. But using the same package name throughout a stable release means there is no easy way to recover from a kernel upgrade that causes failure to boot.
  3. We must treat additions to the ABI, either for bug fixes or to support backported drivers, as backward-compatible and acceptable. But between a package upgrade and the following reboot, new modules may fail to load against the old kernel. This has sometimes caused problems for update-grub and os-prober.

So what stops us from making each stable update generate new binary packages with a new ABI? I see at least two blockers:

a. Upgrades that change the package name will use substantially more disk space on /boot and /, as the old packages remain installed indefinitely. APT even blacklists kernel packages from 'autoremove'! b. Out-of-tree modules need to be rebuilt for each new ABI. This makes upgrades harder for people using them, unless they are willing to install the appropriate linux-headers package and the toolchain it depends on, on each production machine,

What can we do to solve either set of problems (or others I forgot to mention)?