Re: [RFC PATCH 0/2] image.bbclass: support two-stage deployment of image artifacts

[Bartosz Golaszewski <brgl@bgdev.pl>]

czw., 19 mar 2020 o 18:13 Richard Purdie
<richard.purdie@linuxfoundation.org> napisał(a):
>
> On Thu, 2020-03-19 at 17:44 +0100, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > This is a follow-up to the discussion I started on the OE-core
> > mailing
> > list a couple days ago[1]. These patches propose to split the
> > deployment
> > of image artifacts into two stages where the first one includes all
> > "regular" images and takes place before do_image_complete and the
> > second
> > is mostly aimed at wic right now and happens after do_image_complete.
> >
> > These patches work but I'm sending them as RFC mostly to continue the
> > discussion about possible solutions for the circular dependencies
> > between
> > the rootfs and initramfs.
> >
> > [1]
> > http://lists.openembedded.org/pipermail/openembedded-core/2020-March/294094.html
>
> This works fine until we have some new image type which then has to
> depend on happening after wic. We then add a three stage process and so
> on. Basically this feels like we're hardcoding something for one
> specific use case which will later break and not scale to other
> problems/solutions.
>

I understand you see it as controversial but let me try to convince you:

If we'll really get to a point where we need to create a hierarchy of
multiple levels of image deployment, then maybe we should switch to
deploying each image right after it is created in its dedicated
do_image_<type> task, then we could really fine-tune the inter-task
dependencies. But we're not there yet and IMO currently it would be
overkill. The rule of thumb for me is not to add new interfaces nobody
asks for.

The thing with wic is that it's aggregating other deployed images.
What we're dealing with are *two* categories of image artifacts: let's
call them simple and composed types. Obviously composed types may need
to access the simple types and, due to the use-case I described in my
previous thread, it's useful if we can depend on the tasks for simple
and composed images separately. Maybe if I renamed the tasks:
do_image_deploy_simple and do_image_deploy_composed it would look
better than an ambiguous do_image_deploy_late.

This also makes your argument about adding a third category purely
theoretical: I don't see how we would need another category of images
anytime soon. Even if we added another aggregating type (one could
argue that hddimg qualifies as such) it could, with a 99% chance, run
in parallel to wic and thus qualify as a deploy_late/composed image.

> Sorry, I'm not convinced this is the right way to move forward. I will
> try and have a think about what the right way is but sadly I don't get
> much time to spend on specific problems like this :(
>

Please do - I'm open for other ideas. Just please keep in mind:
there's obviously a problem with the current approach. I described it
in detail and it turned out Quentin had encountered it too and dealt
with it using a nasty workaround (fitImage deployed by the image
recipe and not the kernel). I'd like to fix it upstream and proposed a
solution that is IMO not horrible. I'd appreciate if we could reach a
compromise that wouldn't leave us with downstream hacks.

Please also note that sometimes "gets the job done" really is better
than not solving problems. Just look at initcall levels in the linux
kernel - they are similar to what I proposed here and serve as a
surrogate for real dependencies.

Best regards,
Bartosz Golaszewski