[oe] Building a kernel with builtin initramfs

Richard Purdie rpurdie at rpsys.net
Fri Feb 15 11:58:15 UTC 2008


Sorry, I am aware of the thread but I haven't had time to respond
much :(.

On Fri, 2008-02-15 at 13:32 +0200, Paul Sokolovsky wrote:
> 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 ;-((.

This is deliberate. Its so if you have "deb" packaging enabled and then
switch to "ipk", everything just works since bitbake realises which
stamps are missing and builds the missing parts.

> 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.

I'm not sure this recursive bitbake calling is something we want to
encourage as its going to cause massive support nightmares and just
confuse people. What I'd prefer to see is a sequence like:

bitbake initramfs-image
bitbake initramfs-kernel

The initramfs-kernel recipe complains if it can't find a compatible
initramfs image and provides instructions on what you need to do to
create one.

Whilst this means the user has to run two commands, it also means they
see and understand what is going on.

Cheers,

Richard






More information about the Openembedded-devel mailing list