Richard Purdie <[email protected]> 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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
