[prev in list] [next in list] [prev in thread] [next in thread]
List: openembedded-core
Subject: Re: [OE-core] Wic and "live" images
From: Christopher Larson <clarson () kergoth ! com>
Date: 2016-05-31 16:13:37
Message-ID: CABcZANmGsEQG5_=BtY3o1OJYqT5AxFagJ3Qfgeo3zjQjm7nBWA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, May 31, 2016 at 8:31 AM, Ian Geiser <geiseri@geekcentral.pub> 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 <ed.bartosh@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
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 31, \
2016 at 8:31 AM, Ian Geiser <span dir="ltr"><<a \
href="mailto:geiseri@geekcentral.pub" \
target="_blank">geiseri@geekcentral.pub</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div id=":2wa" class="a3s aXjCH m15507717d4cddcc0"> ---- On \
Wed, 25 May 2016 16:04:50 -0400 Christopher Larson <<a \
href="mailto:clarson@kergoth.com">clarson@kergoth.com</a>> wrote ----<br> <span \
class=""> ><br> > On Wed, May 25, 2016 at 4:35 AM, Ed Bartosh <<a \
href="mailto:ed.bartosh@linux.intel.com">ed.bartosh@linux.intel.com</a>> \
wrote:<br> ><br>
</span><span class=""> > 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.<br> <br>
</span>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.<br></div></blockquote><div><br></div><div>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.</div><div> \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div id=":2wa" class="a3s aXjCH m15507717d4cddcc0"><span \
class=""> > 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.<br> <br>
</span>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.<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2wa" class="a3s aXjCH \
m15507717d4cddcc0"> 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?</div></blockquote></div><br>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.</div><div \
class="gmail_extra"><br></div><div class="gmail_extra">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.<br>-- <br><div class="gmail_signature" \
data-smartmail="gmail_signature">Christopher Larson<br>clarson at kergoth dot \
com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior \
Software Engineer, Mentor Graphics</div> </div></div>
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic