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

[Andrea Adami]

On Tue, Nov 19, 2013 at 12:26 AM, Andrea Adami <andrea.adami at gmail.com> wrote:
> On Mon, Nov 18, 2013 at 1:26 PM, Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
>> 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 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.
>>
>> 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.
>>
>
>
> This decompression is apparently what makes my kernel unbootable.
> We purposedly specify options for the XZ compressor (for machines with
> 32MB ram) and if the cpio is uncompressed before these preferences are
> lost.
>
> Andrea
>
>

So, can we change it? I'd say if one bothers to specify compression
for the cpio then respect that...
If on the other hand one needs to do dirty things within the cpio,
then don't compress it as first: the compression options can be
specified in the kernel recipe/config so the artifact is compressed
afterwards.

Cheers

Andrea

>
>> Cheers,
>>
>> Richard
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core