[oe] [RFC] Rebuild external kernel modules on kernel change

[Tom Rini]

On Mon, Jun 01, 2009 at 07:25:11PM +0200, Koen Kooi wrote:
> On 01-06-09 18:58, Tom Rini wrote:
>> On Sat, Apr 04, 2009 at 03:31:25PM +0200, Koen Kooi wrote:
>>
>>> Hi,
>>>
>>> For beagleboard I have a few things I need to rebuild everytime the
>>> kernel changes:
>>>
>>> * powervr kerneldrivers
>>> * sdma kernel module
>>> * dmai kernel module
>>> * codec-engine
>>>
>>> And I have roughly two kinds of kernel changes:
>>>
>>> 1) version upgrade (e.g. 2.6.29 ->  2.6.29)
>>
>> Based on the rest of the email, I assume you mean 2.6.28 ->  2.6.29
>
> right.
>
>>> 2) config changes (e.g. enable ethernet bridging)
>>
>> So, by coincidence I had this thread around still.  For (1), you already
>> have kernel-abiversion, but maybe we need some helpers to make this more
>> useful?  For (2) that's not true unless you're changing one of the
>> variables that actually changes the running kernel abi (which isn't
>> caught in kernel-abiversion file).  This shouldn't be a frequent
>> operation.
>
> 2) is *very* hard to track down, e.g. people don't expect that enabling  
> netfilter as modules breaks external wifi drivers since struct sk_buff  
> will change (ask nokia 770 tablet users).
> I bet there are a lot more cases where kernel runtime abi changes, so  
> every kernel PR bump will trigger a rebuild *and* (here's comes the most  
> important bit) an automatic PR bump for recipes using module*.bbclass.

So we need people to have a better understanding of the kernel, true.  I
think we've all been there at some point.  IIRC, netfilter is the
exception, not the rule.

> So far I've only seen suggestions that will trigger a rebuild of recipes  
> using module*bbclass, but no solutions for automagic version changes so  
> that the package manager will pick it up as well.

I think the problem is we're making an automatic hammer for a manual
screwdriver task, in 2/3. (1) does need better handling but we have that
information around already, in kernel-abiversion, we just need to export
that out.

-- 
Tom Rini