[I've had to guess at the cc list for this, because we no longer have mail archives that preserve them.] On Fri, 2016-11-25 at 10:01 -0800, Linus Torvalds wrote: > On Thu, Nov 24, 2016 at 4:40 PM, Nicholas Piggin <npiggin@xxxxxxxxx> wrote: > > > > > > Yes, manual "marking" is never going to be a viable solution. > > > > I guess it really depends on how exactly you want to use it. For distros > > that do stable ABI but rarely may have to break something for security > > reasons, it should work and give exact control. This is roughly how Debian handles the kernel module ABI during a stable release. > No. Because nobody else will care, so unless it's like a single symbol > or something, it will just be a maintenance nightmare. I agree with this. We can explicitly "version" individual symbols anyway by doing something like: -int foo(void); +#define foo foo_2 +int foo_2(int); > > What else do people *actually* use it for? Preventing mismatched modules > > when .git version is not attached and release version of the kernel has > > not been bumped. Is that it? > > It used to be very useful for avoiding loading stale modules and then > wasting days on debugging something that wasn't the case when you had > forgotten to do "make modules_install". Change some subtle internal > ABI issue (add/remove a parameter, whatever) and it would really help. > > These days, for me, LOCALVERSION_AUTO and module signing are what I > personally tend to use. > > The modversions stuff may just be too painful to bother with. Very few > people probably use it, and the ones that do likely don't have any > overriding reason why. [...] Debian has some strong reasons: 1. Changing the release string requires any out-of-tree modules to be upgraded (at least rebuilt) on end-user systems. So we try to avoid doing that during the lifetime of a stable release, i.e. we don't let the release string change. Also, the release string is reflected in package names (e.g. linux-image-4.8.0-1-amd64), and introducing new package names requires manual approval by the Debian archive team. 2. We want to allow ABI breaks for "internal" symbols used only by in- tree modules, as those breaks will be resolved by rebooting to complete the upgrade. But we need a run-time check to prevent loading an incompatible module before the reboot. 3. So far as I can see, module signing doesn't work for a distribution kernel with out-of-tree modules as there has to be a trust path from a built-in certificate to the module signing certificate. So signature enforcement will have to be disabled on systems that use out-of-tree modules, thus it's not a substitute for modversions. We expect Linux 4.9 to be the basis for a longterm stable branch and on that basis intend to include it in the next Debian stable release. Even if the decision is to get rid of modversions, it would be very helpful if they could be revived for 4.9 so that we have some time to adapt our packaging practices to work without them in future. Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice. - John Levine, moderator of comp.compilers
Attachment:
signature.asc
Description: This is a digitally signed message part
