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. > Where do we specify what it guarantees? We don't. > 2) What are all of the options for handling this situation? > Specifically, how should a package maintainer who is maintaining a > out-of-tree module which uses symbols from the kernel handle them > through an upgrade which changes the symbols? If the symbols need to > be covered by the ABI, how can the maintainer get them covered by ABI? > What should they do in cases when they are not covered by the ABI? > > My main concern is that there seems to be no way for oot modules like > the vmware modules to sanely keep in step with the kernel ABI. While > this may not be a concern for kernel upstream, it's something that we > would ideally deal with to avoid issues for our users on upgrades. 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. 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. The result of these competing pressures is that we have to fudge ABI changes. Where possible, we adjust upstream fixes to remain backward-compatible. In other cases we revert fixes or ignore the ABI changes, based on our judgement of the costs and benefits. --- If people don't like this compromise, then I think the only reasonable alternative is to do what most other distributions do: set the kernel version (as shown by uname -r) to the package version. This means that each new upload will have new package names (and will require an upload of linux-latest-2.6). APT should also be fixed to allow auto-removal of old kernel images. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part