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! > 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 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? 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. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203688): https://lists.openembedded.org/g/openembedded-core/message/203688 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]] -=-=-=-=-=-=-=-=-=-=-=-
