[OE-core] Wic and "live" images

[Christopher Larson]

On Tue, May 31, 2016 at 8:31 AM, Ian Geiser <geiseri at geekcentral.pub> wrote:

>  ---- On Wed, 25 May 2016 16:04:50 -0400 Christopher Larson <
> clarson at kergoth.com> wrote ----
>  >
>  > On Wed, May 25, 2016 at 4:35 AM, Ed Bartosh <ed.bartosh at 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.
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160531/ee7e6e85/attachment-0002.html>