Re: Bug#607368: Please decide how kernel ABI should be managed
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.GD29698@doc.ic.ac.uk
http://www.donarmstrong.com http://rzlab.ucr.edu
Reply to: