[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#607368: Please decide how kernel ABI should be managed

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

> 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

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 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

Reply to: