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

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

On Sun, 2010-12-26 at 15:55 -0800, Don Armstrong wrote:
> On Sun, 26 Dec 2010, Ben Hutchings wrote:
> > On Sun, 2010-12-26 at 12:23 -0800, Don Armstrong wrote:
> > > 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.
> > 
> > No. Firstly, if we know that an ABI change would break an OOT module
> > then we try to avoid making that change.
> Ok. And am I correct in assuming that if the ABI change would break an
> OOT module, you would normally change the ABI number?

In the time I've been involved in the kernel team, I haven't yet seen a
case where a bug fix required an ABI change that I knew would break an
OOT module.

I understand that in the past the kernel team has deferred such bug
fixes and eventually applied such deferred changes as a batch while
changing the ABI number, after coordinating with affected people (such
as the d-i and CD teams).

> Which OOT modules are important enough to result in ABI number
> changes?

We don't have a formal policy but I think we consider OOT modules that
(1) appear to be used in production and (2) have published source code
for at least the part that directly uses kernel symbols.

Anything distributed by Debian should meet those qualifications, but
users such as Julien also care about modules from other sources.  I
normally use Google Code Search to check for OOT modules using symbols
that have changed ABI and which I think might be ignorable.

> How are the symbols that those OOT modules use communicated to the
> kernel team?

They aren't.

> What does the kernel maintainer team feel should be done by the
> maintainer in this case to ensure continuity of upgrades and rebuilds
> of the OOT modules?

We recommend that OOT module package makes use of DKMS.  DKMS includes
hook scripts to trigger rebuilding OOT modules automatically for each
new kernel ABI version, if the end user or administrator installs the
module source and the appropriate linux-headers package.  In a more
tightly controlled environment where such packages should not be
installed on production servers, the administrator must rebuild modules
elsewhere and deploy them along with the kernel upgrade.  DKMS provides
various means for this.


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: