pt., 20 mar 2020 o 00:38 Richard Purdie <[email protected]> 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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
