---- On Wed, 25 May 2016 16:04:50 -0400 Christopher Larson <clar...@kergoth.com> wrote ---- > > On Wed, May 25, 2016 at 4:35 AM, Ed Bartosh <ed.bart...@linux.intel.com> > wrote: > > It's debatable. As long as we keep the logic separated, such that anything > bsp specific is in the machine or bsp layer, so the images are independent > of any bsp, then we're fine. If we need to keep certain aspects of rootfs / > image preparation outside of wic, then we'd need the machines which need > such setup to use a hook to ensure it's applied to all images, i.e. an > IMAGE_POSTPROCESS_COMMAND, and we'd need to document that.
If I follow in wic the logic is in the plugins. So its up to the bsp to implement those. Currently though we have tight coupling with efi and mbr in the oe-core libraries. I guess this leads me into a false sense that wic is machine/bsp specific. > That might be doable, but we definitely need to give careful thought to what > pieces of information about the image creation process come from where. > Certain aspects are clearly distro, i.e. extra image space, and possibly > other partitioning like splitting up the rootfs into multiple partitions, > but others are clearly bsp, i.e. setup of a boot partition if the bootloader > expects it, and image recipes need to work regardless of what distro or > machine are selected. This is what I get at by saying needing a "robust" library of common plugins that can be reused by the bsp authors. I think this would allow the wks files to be more consistent and more reusable. Lastly, in the current vernacular am I confusing the terms "image" and "rootfs"? In my mind "image" is the physical bits that will get burned into ROM/SSD/etc. "rootfs" is the filesystem component that is injected somehow into the image. Is this correct? -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
