Kernel ABI breakage

[Tim Gardner]

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
https://wiki.ubuntu.com/KernelTeam/Sprints/Feb2008/HeadersABI.

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
-- 
Tim Gardner tim.gardner at ubuntu.com