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

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



On Mon, 27 Dec 2010, Ben Hutchings wrote:
> On Sun, 2010-12-26 at 15:55 -0800, Don Armstrong wrote:
> > 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.

So in this case, if it was clear that the change would have broken an
OOT module, the kernel team would normally either postpone the change,
or change the ABI number.

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

Ok. For some reason, I hadn't originally noticed that this was
concerning an OOT module which Debian itself didn't actually
distribute. [Julien: I'm correct in that, right?] But that's probably
fine.
 
> > How are the symbols that those OOT modules use communicated to the
> > kernel team?
> 
> They aren't.

Would putting the onus on OOT maintainers to maintain such a list be
of benefit to the kernel maintainer team?

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

Makes sense. What about this case? What should Julien do?

Julien: Are you currently shipping a kernel in production which would
be affected by this change if we don't change the ABI number? Or does
this only affect cases where you are testing squeeze? Could it be
worked around by using DKMS or similar with prebuilt binaries and
requiring exact kernel version dependencies?


Don Armstrong

-- 
I don't care how poor and inefficient a little country is; they like
to run their own business.  I know men that would make my wife a
better husband than I am; but, darn it, I'm not going to give her to
'em.
 -- The Best of Will Rogers

http://www.donarmstrong.com              http://rzlab.ucr.edu


Reply to: