On Sat, 2010-12-18 at 16:20 +0100, Julien BLACHE wrote: > 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.
This is not correct. We have ignored many changes since 2.6.32-12 when the ABI number was bumped to 5. In 2.6.32-27 the symbol version files were refreshed and the ignore list was reset. > > 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. The upstream policy is that symbol exports may be removed when there are no in-tree users. So that export could even be made conditional on CONFIG_KVM_MODULE (or whatever it's called). > I fail to see a reason why VMware or anybody else should refrain from > using smp_ops if they need it. Because it's a low-level implementation detail. Maybe I should find a way to limit that export so OOT users won't make this mistake. > >> 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. It is extremely stupid. > >> 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), ... VMware - use KVM. nvidia - use nouveau, report a bug if it doesn't work. random drivers - send them to the maintainer of crap (Greg K-H, for the staging tree). Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
signature.asc
Description: This is a digitally signed message part
