Re: Bug#607368: Please decide how kernel ABI should be managed
On Tue, 04 Jan 2011, Julien BLACHE wrote:
> Don Armstrong <don@debian.org> wrote:
> > Julien: Are you currently shipping a kernel in production which
> > would be affected by this change if we don't change the ABI
> > number? Or does this only affect cases where you are testing
> > squeeze? Could it be
>
> I have 30 beta-testers that are affected by this issue on the
> workstations they have started using for their everyday work.
> Although it's still a beta phase, at this point, these workstations
> are to be considered "in production" given the users have basically
> made the switch now.
Ok. My main concern here is what exactly would happen if we were to
ignore the ABI change for this particular issue, and then put in place
some kind of a process where the kernel team could be informed of
downstream users of the ABI.
From my current understanding, the ABI number is only meant to cover
some of the symbols which can be used externally, not all of them.
[Specifically, those that the kernel team are aware of being used
externally.]
> Full deployment involves over a thousand workstations.
But presumably they're not running a testing version affected by this.
> > worked around by using DKMS or similar with prebuilt binaries and
> > requiring exact kernel version dependencies?
>
> DKMS is useless if the ABI number doesn't change, in its current
> form. If DKMS was changed to rebuild all modules when the kernel
> package is upgraded, we'd still have issues with on-disk modules not
> matching the running kernel ABI until the machine is rebooted. This
> can sometimes take two or three weeks if a long-running computation
> is running on the machine.
Presumably this wouldn't be much of an issue, unless users are going
to be newly loading these modules. [Which I would hope wouldn't be the
case if you were running a long-running computation.]
> As to using strict dependencies... it makes all of the above even
> worse.
Certainly; there's a cost to be born on both sides. The most important
thing to avoid from my perspective is a kernel which when booted has
modules that cannot be loaded.
> And I'll ask again: what's the point of the kernel ABI number if we
> have to use strict dependencies?
Some modules may need strict dependencies if they are using symbols
not covered by the ABI; this is one possible way that we can resolve
this issue.
> Seriously?
Lets restrict ourselves to discussing the technical issues and
possible solutions instead of rhetorical flourishes.
Don Armstrong
--
The computer allows you to make mistakes faster than any other
invention, with the possible exception of handguns and tequila
-- Mitch Ratcliffe
http://www.donarmstrong.com http://rzlab.ucr.edu
Reply to: