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

[Koen Kooi]

On 04-04-09 17:51, Frans Meulenbroeks wrote:
> Hm,
>
> I don't like that one needs to touch conf/machine/beagleboard.conf
> each time the kernel is updated.
> This is likely to be forgotten at some time.
> Can't we use something in the linux-omap-*.bb file ?

You can't set global vars in recipes.

regards,

Koen


> Btw, I always bump PR if I change something in the config.
>
> Isn't it possible to add rebuilding those modules to e.g.. virtual/kernel?
>
> Frans
>
> 2009/4/4 Koen Kooi<k.kooi at student.utwente.nl>:
>> 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)
>> 2) config changes (e.g. enable ethernet bridging)
>>
>> The first type of change could be solved by putting KERNEL_VERSION in PV or
>> PR, but that needs a non-trivial amount of python since the information
>> isn't available at parsing time (exactly like debian.bbclass).
>> The second kind of change is a lot harder to detect, unless we start storing
>> md5sums for kernel defconfigs.
>>
>> I have a lowtech proposal for this:
>>
>> -----
>>
>> conf/bitbake.conf:
>> # Define a PR for kernels that machines can override so things like
>> # modules get rebuilt
>> MACHINE_KERNEL_PR ?= "r0"
>>
>> conf/machine/beagleboard.conf:
>> # Increase this everytime the kernel changes
>> MACHINE_KERNEL_PR = "r39"
>>
>> classes/kernel.bbclass:
>> # A machine.conf or local.conf can increase MACHINE_KERNEL_PR to force
>> # rebuilds for kernel and external modules
>> PR = "${MACHINE_KERNEL_PR}"
>>
>> class/module-base.bbclass:
>> # A machine.conf or local.conf can increase MACHINE_KERNEL_PR to force
>> # rebuilds for kernel and external modules
>> PR = "${MACHINE_KERNEL_PR}"
>>
>> -----
>>
>> I don't really like this method, but I'm having a hard time coming up with a
>> decent solution that:
>>
>> a) works
>> b) requires less or equal manual work
>> c) keeps PR in sync between different buildhosts
>>
>> regards,
>>
>> Koen
>>
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>