Re: [PATCH 2/7] kernel: fix out of tree module builds

[Enrico Scholz <enrico.scholz@sigma-chemnitz.de>]

Richard Purdie <richard.purdie@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).

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)

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


>> 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.


Enrico