On Sun, 26 Dec 2010, Ben Hutchings wrote: > On Thu, 2010-12-23 at 12:08 -0800, Don Armstrong wrote: > > On Sun, 19 Dec 2010, Julien BLACHE wrote: > > > I think it would be best if this matter would be decided upon before > > > the release of Squeeze, or not too long after it, so as to avoid > > > further breakages in early kernel updates for Squeeze. > > > > I have a couple of (possibly naïve) questions that would help me > > understand the space of solutions here. > > > > 1) What is the kernel ABI currently used to indicate? > > The ABI *number* indicates a range of versions within which newer > versions are likely to remain compatible with modules built for an > older version.
So currently there is no guarantee that a specific ABI maintains any kind of compatibility for out of tree modules; it is a best effort based on the kernel maintainer's understanding of what symbols have changed and what out of tree (or even in-tree) modules are affected. Do the kernel maintainers currently track compatibility of in-tree modules for modules which may reasonably be loaded during the lifetime of the install? [I'm thinking of removable device drivers, things like KVM, etc.] > I think I should explain at this point the trade-off we're trying to > make. > > As you know, the kernel-space ABI is volatile and upstream has no > intention of maintaining it, even within a stable/long-term series. > Build configuration changes may also change the ABI in unexpected > ways. Therefore it is generally not practical to maintain ABI within > a single upstream version. Right. > Changing the ABI number requires (1) changing the package names and > (2) rebuilding out-of-tree modules. (1) means linux-2.6 must go > through the NEW queue and also disrupts d-i development (the latter > problem may be reduced within the wheezy release cycle). It also > requires end users and administrators to explicitly remove old > kernel image packages. (2) should not be a huge burden so long as > the modules are packaged using dkms, but auto- rebuilding relies on > having a toolchain installed. Therefore we do not like to change the > ABI number during a stable release or the preceding freeze. So from what I can see, the ideal situation is to not change the kernel ABI number unless we absolutely have to. What I think is missing now, is a discussion of which cases where changing the ABI number is necessary for proper functioning, and which cases of malfunction we feel are acceptable, and which are not. For in tree modules, all of the problems that would occur from upgrading a kernel where the ABI had changed (but not the number) can be resolved by rebooting. I'm personally a bit concerned that these errors may be a bit disconcerting to our users, but that may be something we decide to live with and document. For out of tree modules, these problems can either be resolved by changing the ABI number, or possibly by using Breaks: for all of the affected out-of-tree modules where the change wasn't wide-spread enough to bump the ABI number. A slightly wilder alternative, is to Provides: linux-kernel-abi-2.6.32-vmware-5 or something for out-of-tree modules which aren't going to be covered by the main ABI, but are important enough to require compatibility. Alternatively, we can ignore them, and require that end-users of these out of tree modules know that they must upgrade their out-of-tree modules in lockstep with the kernel. Which in-tree modules should we change the ABI number for? Which out-of-tree modules? How does an out-of-tree module writer know? How can they promote their module to get a Breaks or Provides or whatever? Don Armstrong -- It has always been Debian's philosophy in the past to stick to what makes sense, regardless of what crack the rest of the universe is smoking. -- Andrew Suffield in 20030403211305.gd29...@doc.ic.ac.uk http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101226202304.gx5...@teltox.donarmstrong.com
