On Wed, Nov 23, 2016 at 2:22 PM, Ed Bartosh <ed.bart...@linux.intel.com> wrote: > On Wed, Nov 23, 2016 at 02:08:28PM +0100, Kristian Amlie wrote: >> On 23/11/16 13:08, Ed Bartosh wrote: >> > On Tue, Nov 22, 2016 at 12:54:52PM +0100, Kristian Amlie wrote: >> >> On 22/11/16 12:10, Patrick Ohly wrote: >> >>>> ... >> >>> >> >>> All of these introduce some special mechanism. Let me propose something >> >>> that might integrate better with the existing tooling: >> >>> >> >>> The "rootfs" directory gets redefined as representing the entire virtual >> >>> file system. When creating a disk image, it gets split up into different >> >>> partitions based on the image configuration. >> >>> >> >>> For example, the /home or /data directories in the rootfs could hold the >> >>> content that in some image configurations goes into separate partitions. >> >>> >> >>> The advantage of this approach is that the tooling for staging content >> >>> for image creation does not need to be changed. The same staged content >> >>> then can be used to create different images, potentially even using >> >>> different partition layouts. >> >> >> >> That's a very good idea. I think it beats all of my suggestions! >> >> >> >>> To implement this approach with wic, wic needs to be taught how to >> >>> exclude directories from the main rootfs. Ideally, the mkfs.* tools >> >>> should also support that without having to make an intermediate copy of >> >>> the files for a certain partition, but initially wic could create >> >>> temporary directory trees. >> >> >> >> Yes, some work would be needed here, but ultimately it would be contained >> >> within wic and related tools, which is a good thing. >> >> >> > >> > I support the idea. Let's discuss the details of implementation and >> > create a bug in bugzilla to track the development >> >> Do you want me to create the ticket? (it'll be my first, so apologies in >> advance if I omit something important) >> >> > This can be done by extending existing rootfs plugin. It should be able >> > to do 2 things: >> > >> > - populate content of one rootfs directory to the partition. We can >> > extend syntax of --rootfs-dir parameter to specify optional directory >> > path to use >> > >> > - exclude rootfs directories when populating partitions. I'd propose to >> > introduce --exclude-dirs wks parser option to handle this. >> > >> > Example of wks file with proposed new options: >> > part / --source rootfs --rootfs-dir=core-image-minimal --ondisk >> > sda --fstype=ext4 --label root --align 1024 --exclude-dirs data >> > --exclude-dirs home >> > part /data --source rootfs --rootfs-dir=core-image-minimal:/home --ondisk >> > sda --fstype=ext4 --label data --align 1024 >> > part /home --source rootfs --rootfs-dir=core-image-minimal:/data --ondisk >> > sda --fstype=ext4 --label data --align 1024 >> > >> > Does this make sense? >> >> Looks good. The only thing I would question is that, in the interest of >> reducing redundancy, maybe we should omit --exclude-dirs and have wic >> figure this out by combining all the entries, since "--exclude-dirs >> <dir>" and the corresponding "part <dir>" will almost always come in >> pairs. Possibly we could mark the "/" partition with one single >> --no-overlapping-dirs to force wic to make this consideration. Or do you >> think that's too magical? >> > Tt's quite implicit from my point of view. However, if people like it we > can implement it this way. > >> (I haven't checked how feasible this is in the code btw) > > I think it would be much easier to implement --exclude-dirs. > > BTW, it will also allow to exclude directories from any partition, not just > from > root, e.g. to use --exclude dirs this way: > part /data --source rootfs --rootfs-dir=core-image-minimal:/home --ondisk sda > --fstype=ext4 --label data --align 1024 --exclude-dirs cache --exclude-dirs > tmp
Just to be sure, --exclude-dirs means that the contents of the directory are skipped, not the directory itself? Given your example, /home/tmp, /home/cache will be included in /data, but /home/{cache,tmp}/* not. Is this correct? Regards, -- Maciej Borzecki RnDity -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core