czw., 19 mar 2020 o 18:13 Richard Purdie <[email protected]> napisał(a): > > On Thu, 2020-03-19 at 17:44 +0100, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski <[email protected]> > > > > 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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
