Re: [RFC] Rebuild external kernel modules on kernel change

[Koen Kooi <k.kooi@student.utwente.nl>]

On 06-04-09 00:43, Richard Purdie wrote:
> On Sat, 2009-04-04 at 15:31 +0200, Koen Kooi wrote:
>> 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:
>
> The thing is if we start doing this for kernels, we'll probably end up
> having to do it for other things and the end result will be a mess.
>
> A better fix for this is BB_STAMP_POLICY = "whitelist" which will at
> least cause the right things to rebuild.
>
> No, this doesn't bump the PR when packages change but I'd actually like
> to see some new code to fix this problem and several others once and for
> all. The idea would be to "compare" the current build with any previous
> ones and error if bad differences are detected. In this case if PR = X
> had already built that would be an "error" which the system may work
> around by using PR = "X-Z1" in the output packages. You could teach that
> code interesting (even distribution specific) logic e.g. to ignore
> changes in system libraries like libc.
>
> This would imply this comparison data would have to come from a shared
> source for multiple build machines for a distribution like Angstrom.
>
> No, this solution isn't simple but hacking around the problem just
> builds a house on top of quicksand ;-).

The problems with a default OE/angstrom setup are:

1) No automatic rebuild of dependant packages
  - Already solved with BB_STAMP_POLICY = "whitelist"

2) No automatic way to increase PR of dependant packages

3) No distributed way to record increase of PR of dependant packages

4) No way to inject kernelversion and PR into external modules
  - Can be solved with code similar to debian.bbclass

if someone can tackle 4) we're further along with making things saner.


regards,

Koen