[OE-core] RFC: Split do_rootfs into image specific tasks?

[Patrick Ohly]

On Mon, 2015-12-28 at 13:00 +0000, Richard Purdie wrote:
> I've heard complaints from people trying to create more interesting
> image types about how hard it is to understand the rootfs/image
> generation code and that its a pain to develop/test/debug.
[...]
> I guess the real question is whether people like this direction and how
> much should we change the API in order to improve things? Could we
> afford a pretty heavy rewrite in this area to give a good end result?

I think it is indeed a step in the right direction. Having to re-create
the rootfs directory each time one makes a change to an image creation
class or image configuration made experimenting with such changes
awkward and slow.

However, the question remains how far this rewrite should go. The
current semantic model of an "image" is essentially "rootfs + boot
loader + kernel", and the current "image" recipes define both the
content of the rootfs and additional parameter for turning that one
rootfs into an image.

That's arguably the most common scenario, but it is only a special case.
Other image layouts may have multiple partitions, each with certain
files. For example, there might be a read-only rootfs, an overlay
partition for the rootfs and a data partition for user files (for the
sake of the argument, assume that it needs to be pre-populated with
certain files).

In my opinion, the proposed changes allow implementing a more general
image class. Such a class would have to create additional tasks (like
do_overlayfs and do_userfs where it installs files based on some
additional recipe variables), then in do_image_foobar combine these
additional directories into the full disk image.

This can be done without using any existing code, but probably there are
overlaps in functionality and opportunities for code reuse. For example,
converting a directory into a ext2/ext3/ext4/btrfs file system is a
common problem. Having that in a Python utility method would be useful
(but not needed immediately).

The "populate rootfs" code may also be a candidate for moving into an
utility method, although it may be harder to determine exactly which
variables it depends on and might not even be needed.

So, bottom line, I think it makes sense to move ahead as proposed and
refine later in cooperation with distros trying to implement their own
special disk layout.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.