[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#607368: Please decide how kernel ABI should be managed



Don Armstrong <don@debian.org> wrote:

Hi,

> 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.

The harm is done now, reverting or bumping the ABI at this point only
makes things worse.

>> Full deployment involves over a thousand workstations.
>
> But presumably they're not running a testing version affected by this.

At this time I have no assurance that this issue or a similar issue with
another symbol won't happen again during the Squeeze lifetime, so they
are potentially affected until proven otherwise as far as I'm concerned.

To the thousand machines given above, you can add several hundred
machines part of several HPC clusters; the nodes use external InfiniBand
drivers from ofa-kernel 1.5.2 in the pkg-ofed repository. Having the
cluster fail to come online after a kernel upgrade would be interesting.

We also have servers using the Brocade FC HBA/CNA drivers from Brocade,
due to the 2.6.32 drivers being way out of date (2.6.32->2.6.37 is
ca. 100 commits and needs new firmware files with new names, if anyone
is interested).

>> 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.]

Modules get loaded automatically pretty much all the time on a
workstation: filesystem modules for a USB key or when upgrading grub,
drivers for USB devices, you name it.

>> 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.

The issue I have with that, other than the fact that it is just plain
wrong, is that all the module packaging tools were built on the premise
that changes to the kernel ABI are reflected by the ABI number. None of
the tools work if that premise doesn't hold true.

JB.

-- 
 Julien BLACHE <jblache@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 



Reply to: