Re: [v2 PATCH] kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency and bundling

[Andrea Adami <andrea.adami@gmail.com>]

On Fri, Aug 23, 2013 at 2:56 PM, Jason Wessel
<jason.wessel@windriver.com> wrote:
> On 08/23/2013 01:16 AM, Khem Raj wrote:
>> On Thu, Aug 22, 2013 at 4:04 PM, Jason Wessel
>> <jason.wessel@windriver.com> wrote:
>>> This patch aims to fix the following two cases for the INITRAMFS generation.
>>>   1) Allow an image recipe to specify a paired INITRAMFS recipe such
>>>      as core-image-minimal-initramfs.  This allows building a base
>>>      image which always generates the needed initramfs image in one step
>>>   2) Allow building a single binary which contains a kernel and
>>>      the initramfs.
>> I think this could be a bit simpler. Have a full kernel image recipe (
>> kernel + initramfs)
>> separate. It fits into the equation nicely. The final image can bundle
>> initramfs which has modules from practically same kernel build is
>> staged step 1 of kernel build which
>> automatically happens today for any image build.
>
> The changes I put together are work around the circular dependency problem.  Staging and using another recipe is certainly an option.
>
> What I really wanted to do was have just another image type not unlike cpio, ext3, etc...  But this was not possible because there was no way to get back to the point that the kernel could be re-linked and make the call to the kernel methods and get the context correct.   I had tried using the internal method for exec_task from the image recipe context but there appeared to be no direct way to get this to work.
>
>
>
>
>>
>> The new recipe for kernel+initramfs requires the existing kernel
>> recipes and tweaks the .config to enable INITRAMFS_IMAGE
>>
>> You can share the sources for both stages where kernel is built like
>> gcc is putting the sources under work-shared and building all gcc
>> recipes out of this location.
>
>
> Ideally we could use the sysroot to regenerate the combined image, but this was not low hanging fruit.  If we came up with a way to generate the combined kernel+initramfs image directly from the sysroot this could easily be controlled by just having it as an IMAGE_FEATURE as opposed to making distinct image types.
>
>
> Jason.
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


Some more thoughts:

I'd like to point out that we introduced a variable called INITRAMFS_FSTYPES

http://cgit.openembedded.org/openembedded-core/commit/meta/conf/bitbake.conf?id=17f7f3a43e863d9e2a16dd02face5137a4f4b225


and that we have an initial initramfs framework (modular, similar to
the one in oe-classic) :

http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-core/initrdscripts?id=7b69ad2167a1f0e57db82817b98a0cbcb70a0dd3

Maybe this framework could be extended for the typical simple needs (
I know our linux-yocto-tiny-kexecboot is a rather complicated
example).

Cheers

Andrea