Bug#607368: Kernel ABI management
Ben Hutchings <ben@decadent.org.uk> wrote:
Hi,
> Some distributions provide a list all exported symbols which can be
> depended on not to change. We haven't done that but we do consider
What you're saying here is very important: you haven't done that yet,
which implies that all symbols are covered by the ABI.
This is reinforced by reading the packaging scripts and realizing they
check the whole ABI, prior to -28.
> where symbols are used before deciding a change can be ignored.
I can perfectly imagine that you weren't aware of VMware's reliance upon
this symbol before, but you are now.
No need to tell you that quite a few of our users out there will use
VMware on Squeeze and be impacted by this change.
> (As an example, there are several sets of drivers for related hardware
> in which one core module exports symbols to the specific driver modules.
> Those exports should in no way be depended on by OOT modules.)
As smp_ops is exported by the core kernel and not by the common core of
a self-contained set of drivers, I don't think this argument holds here.
Reviewing the kernel revision history, smp_ops was indeed exported to
allow building KVM as a module. The commit message certainly doesn't
claim that KVM should be the sole user of this exported symbol.
I fail to see a reason why VMware or anybody else should refrain from
using smp_ops if they need it.
>> We would not accept that behaviour from a shared library, I don't see
>> any reason why we would accept it from the kernel.
>
> This is not true; for example, the interface between libc and NSS is not
> stable.
And it's been widely recognized as a design flaw and a royal pain in the
ass for, like, forever. Not exactly an example you want to follow.
> If someone claims to certify something about future Debian kernels
> without talking to the kernel team, they are a fraud.
See the top of this mail where you state that no list of symbols covered
by the ABI was ever published for Debian kernels. It isn't unreasonable
under these circumstances to assume that all symbols are covered.
>> Out of tree modules exist and you can't just ignore them; in some
>> environments they are necessary to make things work and you won't have a
>> way around that.
>
> Example?
VMware, nVidia, various drivers and infrastructure for communications
hardware (been there, done that), ...
JB.
--
Julien BLACHE <jblache@debian.org> | Debian, because code matters more
Debian & GNU/Linux Developer | <http://www.debian.org>
Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
Reply to: