dc13 - 1.0
DebConf13
Speakers | |
---|---|
Ben Hutchings |
Schedule | |
---|---|
Day | DebConf day 5 (2013-08-15) |
Room | Second talk room |
Start time | 14:30 |
Duration | 00:45 |
Info | |
ID | 1017 |
Event type | meeting |
Track | |
Language | en |
Feedback | |
---|---|
Did you attend this event? Give Feedback |
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:
- 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.
- 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.
- 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)?