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 our usecase we build usually two kernels: a full featured one for
>> the main system and a minimal, initramfs based for a rescue system.
>> 
>> With this change and building both kernels, it is ambiguous which
>> System.map is used.
>
> Regardless of how you do this, if you build two kernels, you still need
> to choose one to build the main set of modules against. I'm therefore
> not sure how this change makes anything particularly worst than what
> existed before?

A I see... previously I did

| do_install[noexec] = "1"

in the rescue kernel and only the main kernel's System.map, .config... were
staged into the sysroot.  This can be done now too, but building secondary
kernels fails with

| .../usr/src/kernel is not clean, please run 'make mrproper'


> Building two kernels is currently fraught with difficulty anyway,

It was not so difficulty... Removing the "virtual/kernel" provider and
changing names of deployed files should do it with the old classes.


> to the point of not being a currently well supported use case and the
> classes would probably need to be refactored to allow such things to
> be well supported. These changes do bring significant benefit

Does some lowered i/o really provide such a benefit?  With the new
system you are bypassing the excellent staging system (which would
detect e g ".config" or "System.map" file conflicts). Afais, it breaks
with "rm_work" too (I guess, kernel:fetch stamp is removed when kernel
build finishes and packages which inherit "kernelsrc" fetch the kernel
sources (without .config and System.map) again).



Enrico