Hi Richard Thank you for the review.
On Fri, 2024-08-23 at 14:00 +0100, Richard Purdie wrote: > I have been struggling to find time to sit and think through the > implications of this. I have finally done that, at least a little and > I > have some questions below. Sorry about the delay in getting to this, > I > keep hoping someone else will help with this kind of review but it is > very time consuming and I suspect nobody has quite the right set of > knowledge to make it easier. > > On Mon, 2024-08-19 at 17:17 +0200, Adrian Freihofer via > lists.openembedded.org wrote: > > From: Adrian Freihofer <[email protected]> > > > > Without this change, the kernel is always rebuilt if something > > changes > > in the initramfs. If the kernel is rebuilt with an empty TMPDIR, > > the > > process starts by fetching the large kernel git repository and > > recompiling it from scratch. This is very inefficient. > > > > This cannot be improved if INITRAMFS_IMAGE_BUNDLE = "1". If the > > kernel > > Makefile is needed to generate the initramfs bundle the kernel > > build > > folder is required. For this cases nothing changes. > > When you say "kernel Makefile", I'm assuming to rebuild the kernel > image, you need much more than just the Makefile but a complete > kernel > build tree? The Makefile is a solvable problem, the tree isn't! Yes, I should have written kernel build tree. > > > But for a build configuration with INITRAMFS_IMAGE_BUNDLE = "" the > > build folder is not needed. Creating the initramfs bundle requires: > > linux.bin, DTBs and the initramfs. These artifacts are all > > available in > > the deploy folder which is also sstate cached. > > > > Therefore do_assemble_fitimage_initramfs gets split into two tasks: > > - do_assemble_fitimage_initramfs creates the bundled fitImage which > > runs > > before do_deploy. This is without sstate and therefore the > > do_deploy > > task still deploys the artifacts generated by this task. > > - do_deploy_fitimage_unbundled creates the fitImage in unbundled > > mode. > > This task runs after do_deploy. It uses the linux.bin artifact > > from > > do_deploy to create the fitImage with initramfs. > > I'm a bit worried about having a second do_deploy_xxx task after > do_deploy. This creates a recipe with two deploy tasks and whilst I > can > understand why you're doing it, I worry this is going to create > confusion down the road. > > The reason I say this is that there are rules for "deploy" tasks, > e.g. > in meta-classes/sstate.bbclass:setscene_depvalid() has: > > # do_package/packagedata/package_qa/deploy don't need > do_populate_sysroot > if taskdependees[task][1] == "do_populate_sysroot" and > taskdependees[dep][1] in ['do_package', 'do_packagedata', > 'do_package_qa', 'do_deploy']: > continue > > do_deploy_fitimage_unbundled isn't listed in SSTATETASKS. Whilst that Thank you for the hint. I don't know how this could have been overlooked until now. > is simple to fix, I'm not sure what side effects that is then going > to > cause. > > Also, there is this to consider: > > meta/classes-global/base.bbclass:do_build[recrdeptask] += "do_deploy" > > which is basically making sure "build" targets (the default) trigger > all artefacts to be deployed. I think this new task will be missed by > global code as it isn't covered there. The intent was to have one > name > which covered all cases, not having recipe specific entries in there. > > I'm starting to wonder if that unbundled case should be handled by a > separate recipe, which can then have its own do_deploy task and > depend > on all the correct pieces. > > > > This task is done with SSTATE_SKIP_CREATION, because this also > > works > > with the eSDK installer (oe-selftest -r esdk is successful). It > > is > > also more effective to quickly create the fit image instead of > > handling it via sstate. > > Skipping sstate creation is a huge red warning sign in my mind. So > far > we've only had images and eSDKs using this option and I never wanted > to > add the option generically in the first place since it was going to > lead to more exceptions like this. > > The implications of not creating the sstate can be problematic, for > example the sstate tests then need to learn that some new subset of > sstate artefacts will never be created. This also complicated the > testing of eSDKs which do a similar verification which will also need > exceptions. I can understand why you've done it but I am worried the > side effects will be left for others (such as myself) to resolve as > fit > images get used in new codepaths :/. > > > Unfortunately, this change is not 100% backward compatible. > > Previously, > > a dependency on do_deploy deployed all types of fit images. With > > this > > change, deploying the unbundled fit image requires a dependency on > > do_deploy_fitimage_unbundled. To address this the image.bbclass > > gets > > improved to handle both cases with the KERNEL_DEPLOY_DEPEND > > variable. > > I think this proves my point about why adding a new deploy task is > potentially problematic. Have you considered using an intermediate > recipe for the unbundled case instead? Yes, I have thought about and tried 3 different implementations: - This one here which is supposed to be backward compatible. - Renaming the sstated kernel do_deploy task to e.g. do_deploy_stage1. Then bring the do_deploy task back as an empty task depending on the do_deploy_stage1. This looks equal to the current implementation but allows to inject the do_deploy_fitimage_unbundled task from the kernel- fitimage.bbclass. However, this has similar side effects. For example the eSDK assumes that the do_deploy task is the last sstated task in the chain which provides the relevant sstate artifact. - Add a separate recipe for the unbundled fitImage. This could simplify the implementation, but is probably somewhat cumbersome from the user's point of view. Bundled fitImage remains in the kernel but unbundled needs dealing with different recipes. > > I wish we could determine how much use the bundled and unbundled > cases > have. I'm also starting to wonder if the two cases should be > separated > apart into two clear workflows rather than the current entwined > situation which is very hard to visualise and understand. Yes, that's probably the conclusion so far. The kernel recipes have reached a very complex state. Especially the implementation of the unbundled fitImage support is a bit strange and adds complexity that could possibly be simplified by splitting it into a separate recipe. I will try to come up with a different implementation where the undbundled fitImage is created by a dedicated recipe. This recipe will basically have the do_deploy_fitimage_unbundled implementation as its do_deploy task which depends on the kernel do_deploy. Not sure if such a recipe could also provide a package for the fitImage kernel. Currently the fitImage is deployed only. Other kernel image types are packaged and deployed. The challenge will then probably be to hide the extra complexity of 2 recipes as good as possible and to refactor the tests accordingly. Kind regards, Adrian > > Cheers, > > Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203695): https://lists.openembedded.org/g/openembedded-core/message/203695 Mute This Topic: https://lists.openembedded.org/mt/107982760/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
