Kernel ABI breakage

Tim Gardner tim.gardner at
Tue Mar 4 19:16:45 UTC 2008

Tim Gardner wrote:
> Fabio M. Di Nitto wrote:
>> On Wed, 20 Feb 2008, Tim Gardner wrote:
>>> Fabio M. Di Nitto wrote:
>>>> Hi guys,
>>>> I spoke to Tim on IRC a few days back about problems introduced by some
>>>> recent updates in LUM and he suggested to take it to a wider audiance.
>>>> I filed a bug to keep track of the issue: #192559
>>>> but is the general approach of upgrading entire subsystems in LUM (or
>>>> any
>>>> other package for the matter) that needs to be reviewed.
>>>> So far i don't recall this problem happening before, but now it's clear
>>>> out of a default install.
>>>> Fabio
>>>> PS CC me on reply. I am not subbed to this mailing list.
>>>> -- 
>>>> I'm going to make him an offer he can't refuse.
>>> After some experimentation I think can propose at least one short term
>>> solution.
>>> 1) Disable CONFIG_SOUND in the kernel.
>>> 2) Commit duplicated (and modified) headers from LUM ALSA into the
>>> kernel tree. Remove LUM versions of the duplicate headers to enforce
>>> correct compilation.
>>> 3) Port CONFIG_SND/CONFIG_ALSA dependent drivers from the kernel to LUM
>>> (cx88 and saa7134).
>> there are more drivers..
>>> Assuming the LUM ALSA header modifications do not cause compilation
>>> errors, this will at least allow external subsystems to compile against
>>> the kernel and generate the correct ABI.
>>> While this solution works for ALSA, its not particularly elegant. If we
>>> take on more duplicate subsystems like this in LUM, then we'll have to
>>> design something better.
>> No i think we need to find the right solution immediatly.
>> The problems here are:
>> - linux-kernel-headers generated by the kernel contains old headers and a
>>   Modules.versions that does not reflect what is loaded at runtime.
>> - lum: introduces a kernel ABI breakage
>> - lbm: could do the same as lum at some point in time.
>> The only way we have to detect that there is an ABI change is by
>> comparing the different Modules.versions and the real one is not
>> available anywhere due to the build-dep chain.
>> The only really clean solution i can think of is to step back from this
>> approach of splitting stuff into 3 different sources and collapse them
>> again.
>> The only reason i can recall of why they were splitted was to avoid to
>> rebuild the world for an ubuntu module update and not to contaminate the
>> kernel tree with tons of extra patches.
>> Here we are at the point were we basically need to jump back a few years
>> when we had debian/patches to apply every single change to the source tree.
>> Unless we can find a very elegant and working solution immediatly, this
>> is virtually the only approach that works. A kernel that breaks in time
>> with updates is not a viable solution for hardy.
>> Fabio
>> -- 
>> I'm going to make him an offer he can't refuse.
> I've developed the basic infrastructure in kernel/lum/lbm to mitigate
> ABI issues according to the Sprint notes we developed in
> I've tested it to the extent that I'm reasonably sure I have not busted
> the core builds. However, I've not tested any third party external builds.
> Also, I have not implemented BuildConflicts in lum because I'm not
> convinced that its the right thing to do.
> The remaining work to be done is
> 1) disable CONFIG_SND in the kernel
> 2) port CONFIG_ALSA and CONFIG_SND dependent kernel modules into lum.
> 3) Generate meta packages for linux-headers-{lum,lbm}.
> rtg

I've disabled CONFIG_SND in i386/{386,generic,server} and
amd64/{generic,server} and added the $flavour.ignore.modules files.

All other arches have CONFIG_SND (and ALSA) enabled in the kernel and
_not_ in LUM, so they are of no interest with regard to ABI breakage.

The next step is to filter the $flavour.ignore.modules against the list
of modules that are built by LUM ALSA and port from the kernel tree to
LUM those modules that have gone missing.

Since I'm now officially on leave, someone else gets to do this.

Tim Gardner tim.gardner at

More information about the kernel-team mailing list