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

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

Don Armstrong <don@debian.org> writes:

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

I feel like I should note here that I've been maintaining a complex
out-of-tree kernel module for Debian for many years now (openafs) and am
also involved in maintaining the non-free NVIDIA modules, and I can't
remember ever having the kernel ABI break for those modules without the
ABI number changing.  It's probably happened and I just don't remember it,
but certainly not enough to be memorable.

*Upstream* has caused us all sorts of problems from time to time because
of taking public symbols and making them GPL-only (OpenAFS predates Linux
and the core of the source is licensed under a free but GPL-incompatible
license, which also affects the kernel module), but the Debian kernel
maintainers have always done a great job at maintaining ABI guarantees,
insofar as my packages are affected.  The only problem that I recall with
the ABI numbering was the unfortunate use of -trunk as an ABI version
during the squeeze development cycle, and there mostly because -trunk
sorted inappropriately after regular ABI numbers were introduced, not
because of an inherent problem with the use of that technique in unstable.

So while I do recognize that there was a problem with an out-of-tree
module that brought this particular bug to the technical committee, I have
to say that with my out-of-tree module maintainer hat on the kernel team
seems to, by and large, be doing a good job of maintaining the kernel ABI
already.  That inclines me against supporting any major change in how this
is handled.

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: