[OE-core] Changing external kernel module results in rebuild of whole kernel

[Bruce Ashfield]

On 2015-05-13 11:44 AM, Richard Purdie wrote:
> On Wed, 2015-05-13 at 11:33 +0100, Richard Purdie wrote:
>> On Tue, 2015-05-12 at 08:01 +0200, Mike Looijmans wrote:
>>> As things are now, I'd much prefer the "taring up and then extracting a large
>>> (GB) sized sstate object" option, since that at least worked correctly.
>>
>> Sorry for the delayed reply, I didn't understand exactly what was
>> happening without looking at a build. By far the easiest "fix" right now
>> is:
>>
>> RM_WORK_EXCLUDE += "<my kernel recipe PN>"
>>
>> This won't cost that much diskspace and should avoid the problem you're
>> seeing.
>>
>> The problem is module.bbclass has a DEPENDS on virtual/kernel which
>> means it depends on <kernel>:do_populate_sysroot. As well as triggering
>> the unpack to repopulate the shared work area for the kernel, this means
>> it will cause the thing to effectively repackage.
>>
>> There are various ideas coming to mind:
>>
>> * We could drop virtual/kernel from DEPENDS which would shorten the
>> kernel dependency chain by removing populate_sysroot from the equation.
>>
>> * We could change the task dependencies of populate_sysroot in
>> kernel.bbclass so that it doesn't depend on do_install (it doesn't
>> handle files any more now anyway).
>>
>> * We could figure out why populate_sysroot from sstate isn't good enough
>> for bitbake and change the sstate code to use sstate more heavily. If I
>> remember rightly, we currently rerun all a task's tasks rather than pull
>> it half from sstate and half not.
>>
>> None of these jumps out at me as an easy or necessarily desirable fix.
>
> I do have some patches:
>
> https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=c4aed2ba7ae74e54a4ae8ac7aeda291704bde82a
> https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=7a20f175c0a1cdec208471e5f7ff5f560f0b609e
> https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=c5f3cdca3e16d90c4e5bbb3abe5e136b8025f1a4
>
> What I've noticed is that rm_work does not remove the data from
> shared-work. What it does do is remove the stamp file which causes all
> the tasks to rerun even if the data was there. The above patches make
> "do_shared_work" a semi sstate task, one which is never generated into
> the sstate feed but does have the right stamp functionality. This
> basically stops kernel modules from rerunning kernel tasks even with
> rm_work.
>
> Whether these patches are a good idea, I'm less sure.
>
> Bruce: You might want to look at the module.bbclass changes in the first
> patch. I think there is some duplication between module and module-base
> I need to remove.


I looked at the series, and it looks sane to me. Nice to move that
dependency to a common location, rather than requiring and end module
recipe (like lttng to get it correct).

For the overlap, I assume you were talking about them both now
having the do_configure[depends] += "virtual/kernel:do_shared_workdir" ?

Since module inherits module base, looks like that can be shuffled down
to the lowest class. It's also a bit odd (to my eyes) that module.bbclass
has the do_make_scripts dependency, while module-base.bbclass has the
actual routines ..

Definitely from sorting out that looks to be in order.

Bruce


>
> Cheers,
>
> Richard
>
>
>