Re: Changing external kernel module results in rebuild of whole kernel

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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.

Cheers,

Richard