Please decide how kernel ABI should be managed
reopen 607368
tags 607368 - wontfix
reassign 607368 tech-ctte
retitle 607368 Please decide how kernel ABI should be managed
thanks
Hi,
I am hereby asking the tech-ctte to decide how the kernel ABI should be
managed.
Case in point: the kernel team decided to ignore changes to the smp_ops
symbol in 2.6.32-28 which broke external modules (vmware) without any
prior warning.
I am worried that this is going to happen again during the lifetime of
Squeeze, silently breaking working setups upon reboot after a kernel
update, even though the new kernel carries the same ABI number as the
previous one.
I do agree that it is fine to ignore changes to symbols that are only
exported and used inside a self-contained group of modules to which no
additional modules will ever need to be added.
I disagree with the kernel team's take that it is OK for them to ignore
symbol changes in all other cases, especially for symbols exported by
the core kernel (like smp_ops).
This kind of silent breakage is a nightmare from an ops standpoint and
it does have a cost for our users. The ABI number should guarantee that
upgrading from a revision of linux-image to another carrying the same
ABI number will not cause any breakage with external modules built for
this ABI.
As the kernel team made it clear that they make their decision partly
based on symbol usage, I'd like to highlight once again, for the
specific case of smp_ops, that VMware modules aren't exactly pet modules
that only a few of our users care about. There is ample proof of this on
several web forums and mailing-lists dedicated to either VMware or
Debian.
I am seeking a generic ruling by the tech-ctte to ensure that the kernel
ABI number remains meaningful and dependable.
I think it would be best if this matter would be decided upon before the
release of Squeeze, or not too long after it, so as to avoid further
breakages in early kernel updates for Squeeze.
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: