[OE-core] [PATCH 2/7] kernel: fix out of tree module builds

[Bruce Ashfield]

On Tue, Dec 23, 2014 at 6:51 AM, Enrico Scholz
<enrico.scholz at sigma-chemnitz.de> wrote:
> Richard Purdie <richard.purdie at linuxfoundation.org> writes:
>
>>> > In summary, basically, yes. The kernel source is huge and we were
>>> > compressing/decompressing it in several places on the critical
>>> > path.  People were struggling to develop kernels using the system
>>> > due to the overhead.
>>>
>>> I do not see how the new system makes it easier to "develop kernels".
>>
>> One of the complaints I keep hearing is how long the populate_sysroot
>> and package tasks take. I also get complaints about the sstate footprint
>> of those tasks.
>
> Perhaps, it should be possible to disable sstate'ing for certain recipes?
> In case of the new kernel build system, you swap the expensive sstate'ing
> with an expensive unpacking.
>
>
>> Imagine you're doing a "bitbake virtual/kernel -c compile -f", hacking
>> on a module, you then package and install it onto the target to test.
>
> 1. Are there really people who are doing such things?  There are much
>    more effective ways to do kernel development with OE (you have the
>    overhead from bitbake reading its database; do_compile() does not
>    deploy images on TFTP server nor the modules in the NFS sysroot).

There are definitely people doing this. And if the build system wouldn't
get in the way .. more definitely could.

>
> 2. This usecase is not supported by the current classes:
>
>    1. the 'bitbake virtual/kernel -c compile -f' removes .config and
>       System.map from the kernel sources (else, do_compile() will fail)

This one is going to be fixed with the follow up patches I mentioned
in another email, since we can maintain the output artifacts separate
from ${B} and build against them, that keeps us working with rm_work
and keeps things light.

>
>    2. trying to build the module (with 'M=...')will fail because .config
>       + System.map are missing in the source

#2 shouldn't happen if the module depends on the kernel's do_install
(as we intended), since that puts the external module build artifacts
back in place.

>
>
>>> to polluting sources with .config and related files, KBUILD_OUTPUT/VPATH
>>> builds are not possible from this tree.
>>
>> Agreed and I'm actually not happy about this. I think going forward
>> we'll need a second directory for these so we do keep the output
>> separate and can recompile against it.
>
> 'cp -al' a template kernel and .config etc. into ${WORKDIR} should be
> pretty fast.

With a split source and build configuration .. this shouldn't be needed.
If we start copying these things back into WORKDIR .. then something
is wrong.

Bruce

>
>
> Enrico
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"