Ben Hutchings <b...@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 <jbla...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
