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. -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
