[OE-core] [PATCH] kernel.bbclass: Tolerate empty INITRAMFS_IMAGE when INITRAMFS_TASK is set

[Phil Blundell]

On Fri, 2013-11-15 at 11:26 -0200, Otavio Salvador wrote:
> Hello Phil,
> 
> On Fri, Nov 15, 2013 at 11:05 AM, Phil Blundell <pb at pbcl.net> wrote:
> > The idiomatic way to reinstate the old-style initramfs handling appears to be to
> > set:
> >
> > INITRAMFS_TASK = "${INITRAMFS_IMAGE}:do_rootfs"
> 
> What problems are you having with the 'new-style'?

Good question.  When I first merged the version of kernel.bbclass that
implemented the "new-style" system I was having a bunch of problems
which seemed to be due to the new code.  However, after a bit of further
debugging it now appears that most of them are issues with the
implementation rather than with the concept and selecting INITRAMFS_TASK
doesn't actually help very much because the code that was causing my
problems is shared between the two paths.

The main difficulty I was having was that kernel.bbclass was looking for
the initramfs image with slightly the wrong filename.  After a certain
amount of sleuthing and some clues from Andrea it eventually became
apparent that kernel.bbclass relies on the initramfs image recipe
leaving ${IMAGE_LINK_NAME} at its default value and will fail if it's
set to anything else.  This seems slightly fragile and it seems as
though it would be better for kernel.bbclass to look for the initramfs
image at its primary location rather than relying on the symlink.

I also discovered that the new code in kernel.bbclass uncompresses the
initramfs image before embedding it in the kernel.  I can guess why this
seemed like a good plan, but it's slightly surprising behaviour and it
seems like anybody who wanted to embed the initramfs in uncompressed
form would just select IMAGE_TYPE = "cpio" for it in the first place.
Also, Andrea reports that he does actually get worse compression overall
with this approach in at least some circumstances.

Anyway, with those things fixed I can now at least build images again
and it's entirely possible that the "new style" system would also work
for me.  However, it doesn't seem as though the new technology would
bring me any particular benefits, and as far as I can tell it would
introduce an extra kernel compile step that I don't particularly want,
so I am inclined to stick with INITRAMFS_TASK for the moment.

Right now I'm trying to debug a slightly obscure problem where, under
circumstances that aren't entirely clear to me, bitbake ends up running
linux:do_compile, linux:do_bundle_initramfs and then
linux:do_populate_sysroot but somehow overlooking do_install.  This
causes sysroot_stage_all() to blow up because the directory it's trying
to copy from doesn't exist.  I'm not entirely sure whether this is
related to the initramfs code or not, though it does only seem to affect
kernel recipes.

p.