On Tue, May 31, 2016 at 8:31 AM, Ian Geiser wrote: > ---- On Wed, 25 May 2016 16:04:50 -0400 Christopher Larson < > clarson@kergoth.com> wrote ---- > > > > On Wed, May 25, 2016 at 4:35 AM, Ed Bartosh > 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. > I'd agree with that, yes, it's the specific plugins that are bound to bsp, and a number of the defaults are clearly for specific use cases by specific bsps, which of course is why the wks is machine specific and in the bsp's realm of responsibility. > > 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. > I'd agree with that to a certain extent. Many of the current plugins encode a lot of hardcoded logic and configuration and aren't very flexible. More small plugins that we can mix and match with more options to configure them would be nicer, but I'm assuming we just haven't had a lot of people contributing to wic in that way yet. There aren't currently many ways for the distro or image to affect what wic does, right now. Ed wants the image recipe to be responsible for breaking up the rootfs or otherwise prepping the partition input for use by wic, but if we do that, we're injecting machine-specific logic into the image recipe. I think it should either be done by a wic plugin or plugins (either in the wic core, or as you suggest, new plugins in the bsp), not the image recipe, or the image/rootfs classes and python package need more hooks for the machine/distro configuration to opt-in to that sort of preparation without hardcoding it into the image recipe itself. I don't feel too strongly either way, I just want to make sure we follow the project philosophy and don't tightly intertwine the distro, machine, and image recipe. 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? > It depends on context, actually, which gives the term some ambiguity. The image *recipe* is of course a yocto construct, and its output might be just hte rootfs or might be a disk image, depending on the configuration of IMAGE_FSTYPES. It's this recipe notion of an image that needs the orthogonality -- no machine or distro specifics in the image recipe. On the other hand, wic's output is an image, that being a disk image which gets flashed to media using the rootfs and other files as input. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics