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

[Bartosz Golaszewski]

pt., 20 mar 2020 o 00:38 Richard Purdie
<richard.purdie at linuxfoundation.org> napisał(a):
>
> On Thu, 2020-03-19 at 19:20 +0100, Bartosz Golaszewski wrote:
> > 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.
>
> Going back in time I'm the person who split the image pieces off from
> do_rootfs and split the different image commands into different tasks.
> I did this for several reasons but one was we were developing new task
> dependency code inside the image construction which was just crazy.
>
> I was wondering about the option of having the image task deploy the
> image earlier. I think that could be made to work. I think conceptually
> it makes more sense architecturally than adding in arbitrary new task
> levels to the existing structure.
>
> > 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.
>
> I often think things like that but then new use cases come along...
>
> > 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.
>
> I do understand there is a problem. We also have problems with people
> not understanding the code as it works today. Your proposal adds
> something else with is hard to explain to users ("Is my image simple or
> composed?") and whilst we can and do add complexity where we need to,
> I'm not yet convinced this change makes enough sense to have it.
>
> Changing the way image deployment works would in many ways be much
> easier for people to understand and makes the system more flexible
> without adding problematic terminology.
>
> > 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.
>
> We have piles of "get the job done" and also need to sometimes take a
> step back and see if we can do something better. Right now I think your
> proposal makes things worse and will be hard to explain to people. My
> instinct is we can do better here.
>

Fair enough. I don't quite agree and I'd like to hear other voices too
but I also don't want to waste time arguing either.

As I'm afraid that if I don't follow up on this myself, it will simply
be forgotten, I'm offering to spend some time figuring out per-task
deployment.

I started looking into it and figured that ideally we could have each
image task use a separate local-deploy directory and make them all
part of  SSTATETASKS. Unfortunately a lot of places reference the
IMGDEPLOYDIR variable so it probably has to stay in some form. I
couldn't find any info on that - does bitbake offer anything like
"per-task variables"? Variables that expand to different values
depending on the task that calls them? Otherwise we could replace
IMGDEPLOYDIR calls with some helper function that would return a
different value depending on BB_CURRENTTASK?

Any advice on technicalities is welcome.

Bart