Re: [PATCH] kernel.bbclass: Tolerate empty INITRAMFS_IMAGE when INITRAMFS_TASK is set

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Sat, 2013-11-16 at 18:09 +0000, Phil Blundell wrote:
> 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@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.

FWIW I would *love* to simplify this code and have one good/efficient
codepath everyone uses. The initramfs decompression code looks nasty to
me for example and I agree with your thoughts on that.

Cheers,

Richard