On Sun, 2010-12-26 at 12:23 -0800, Don Armstrong wrote: > On Sun, 26 Dec 2010, Ben Hutchings wrote: > > On Thu, 2010-12-23 at 12:08 -0800, Don Armstrong wrote: > > > On Sun, 19 Dec 2010, Julien BLACHE wrote: > > > > 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. > > > > > > I have a couple of (possibly naïve) questions that would help me > > > understand the space of solutions here. > > > > > > 1) What is the kernel ABI currently used to indicate? > > > > The ABI *number* indicates a range of versions within which newer > > versions are likely to remain compatible with modules built for an > > older version. > > So currently there is no guarantee that a specific ABI maintains any > kind of compatibility for out of tree modules; it is a best effort > based on the kernel maintainer's understanding of what symbols have > changed and what out of tree (or even in-tree) modules are affected. > > Do the kernel maintainers currently track compatibility of in-tree > modules for modules which may reasonably be loaded during the lifetime > of the install? [I'm thinking of removable device drivers, things like > KVM, etc.] Not specifically. *Most* modules will remain compatible, but we expect users to reboot shortly after a kernel upgrade. [...] > What I think is missing now, is a discussion of which cases where > changing the ABI number is necessary for proper functioning, and which > cases of malfunction we feel are acceptable, and which are not. > > For in tree modules, all of the problems that would occur from > upgrading a kernel where the ABI had changed (but not the number) can > be resolved by rebooting. I'm personally a bit concerned that these > errors may be a bit disconcerting to our users, but that may be > something we decide to live with and document. > > For out of tree modules, these problems can either be resolved by > changing the ABI number, Yes. > or possibly by using Breaks: for all of the > affected out-of-tree modules where the change wasn't wide-spread > enough to bump the ABI number. No. Firstly, if we know that an ABI change would break an OOT module then we try to avoid making that change. Therefore, if an ABI change does break an OOT module then we would not know that we should add the Breaks relation. Also, we now recommend that OOT module sources are packaged using dkms, which means the module binaries are *not* packaged and no such relation can be declared. > A slightly wilder alternative, is to > Provides: linux-kernel-abi-2.6.32-vmware-5 or something for > out-of-tree modules which aren't going to be covered by the main ABI, > but are important enough to require compatibility. [...] I refuse to support any specific OOT module in this way unless paid to do so. I expect that other kernel team members will tell you the same. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part