[oe] Building a kernel with builtin initramfs
pHilipp Zabel
philipp.zabel at gmail.com
Thu Feb 14 10:55:28 UTC 2008
On Thu, Feb 14, 2008 at 3:54 AM, Paul Sokolovsky <pmiscml at gmail.com> wrote:
> Hello,
>
> Sometimes, it may be necessary to have a kernel with builtin initramfs.
> Initramfs commonly kernel modules, so we have kernel build recursion.
> Standard way to break this loop is to split procedure causing recursion
> into independent steps, so we'd first build kernel modules, then build
> initramfs, then build a kernel image.
>
> The question, is how to express this with bitbake and OE. Skipping
> various ideas, here's the one which promise viability:
>
> 1. Have a kernel-modules.bb, which will execute bitbake recursively to
> build a PREFERRED_PROVIDER_virtual/kernel, and will pass a special flag
> variable.
>
> 2. Detecting that flag, kernel.bbclass will build/package only modules.
>
> 3. Then, have a kernel-initramfs.bb (DEPENDS=kernel-modules) which will
> take a variable defining which initramfs image to build, if any, and
> execute bitbake recursively with IMAGE_FSTYPES=cpio.gz on that.
>
> 4. Make a task in kernel.bbclass depend on kernel-initramfs.bb (build
> task of it).
>
>
> Again, that appears to be something working, at least from 1st look.
> However, it introduces new trick - recursive execution of bitbake,
> what, as far as I know, never happened so far. Well, for "make" such
> usage is commodity, and the fact that it is required 2 times in the
> above scenario show that it is useful ;-).
>
>
> Other ideas?
Split the module generation out of the main compile/install/package
tasks in kernel.bbclass and have kernel-initrmfs.bb's do_initramfs
depend on that.
Can we have conditional inter-task dependencies in bitbake recipes?
regards
Philipp
More information about the Openembedded-devel
mailing list