Bug#607368: Kernel ABI management
reopen 607368
submitter 607368 !
thanks
Hi,
I am sorry that I have to reopen this bug, but first this is about more
than just smp_ops and second the outcome isn't satisfactory.
Whether a symbol is exported for a specific purpose or for general
usage, whether you like it or not, every symbol that is exported is part
of the ABI. If it changes, the ABI changes and it changes for everybody,
regardless of whether they're supposed to be using that symbol or not.
We would not accept that behaviour from a shared library, I don't see
any reason why we would accept it from the kernel.
As it stands, the kernel ABI number has just been rendered useless; I
can no longer trust it nor rely on it. Every kernel revision will have
to be tested to make sure all modules are still compatible with the new
ABI, given the ABI will change silently without bumping the ABI number.
Unsuspecting users will have their setup break upon reboot after
updating their kernel packages without any obvious clue as to what
caused the breakage.
This is a big deal as it puts a big question mark where the kernel ABI
number used to be. This is a problem for users, admins, ISV, vendors
higher up the chain, everybody. It's no longer possible to offer
certified modules for Debian kernels given the kernel ABI number cannot
be relied upon anymore.
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.
So I am asking you to reconsider your position and go back to strictly
maintaining the kernel ABI number. This situation is a big step backward
for the Debian kernel packages and I hope it'll be fixed soon.
Thanks,
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: