[oe] Building a kernel with builtin initramfs

[Paul Sokolovsky]

Hello,

On Fri, 15 Feb 2008 10:41:01 +0100
"pHilipp Zabel" <philipp.zabel at gmail.com> wrote:

> On Fri, Feb 15, 2008 at 10:02 AM, Paul Sokolovsky <pmiscml at gmail.com>
> wrote:
> > Hello,
> >
> >  On Thu, 14 Feb 2008 11:55:28 +0100
> >  "pHilipp Zabel" <philipp.zabel at gmail.com> wrote:
> >
> >  > 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.
> >
> >  Ok, this is not going to work due to timestamps.
> 
> The problem is that this whole kernel/module issue is more like two
> intertwined recipes. We'd need separate timestamps for modules and
> kernel image. I'd prefer using the task dependency system to solve
> this.
> 
> >  > >  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.
> >
> >  Well, that's of course how I started. So, in kernel.bbclass I have
> >
> >  do_compile_modules ()
> >  addtask compile_modules after do_patch
> >
> >  do_install_modules()
> >  addtask install_modules after do_compile_modules
> 
> Ok, that's what I was thinking about.
> 
> >  That works, but that's where I stopped: how to package just
> > modules - fork whole packaging class(es) like compile/install tasks
> > forked above?
> 
> We could make the ${WORKDIR}/install and ${WORKDIR}/image directories
> configurable and then call the original tasks from wrapper tasks
> setting those variables.
> 
> do_package() {
>     PACKAGE_INSTALL_DIR=${WORKDIR}/install-kernel
>     PACKAGE_IMAGE_DIR=${WORKDIR}/image-kernel
>     package_do_package
> }
> 
> do_package_modules() {
>     PACKAGE_INSTALL_DIR=${WORKDIR}/install-modules
>     PACKAGE_IMAGE_DIR=${WORKDIR}/image-modules
>     package_do_package
> }
> 
> Could something like this work?

python package_do_package () {
[]
}
do_package[dirs] = "${D}"

Note sure how such declarative stuff can be converted to imperative
style like above. Also, do_package is only part of the picture.
Important thing is package_write. And the way it is implemented now,
do_package_write is just a dummy anchor task. Subclasses do not
implement it, but instead anchor using it in task sequence:

addtask package_write_ipk before do_package_write after do_package

This is weird. Richard, was it done this way? It makes impossible to
imperatively call package writeout task ;-((.


Otherwise, regarding producing initramfs'ed kernel, I switched to the
solution a-la initramfs-image-ipk - instead of trying to plug into
existing kernel.bbclass task sequence, I made a separate task which
builds kernel with initramfs included. Of course, that's not ideal -
package with non-initramfsed kernel already written by that time, so
new package would need to overwrite it ;-\. If package writing were
possible at all, but it's not due to the above.

My current idea is to write package in separate recipe at all, stealing
PV from the file.


[]

-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com