On Wed, 2022-11-02 at 17:23 -0700, Paul Eggleton wrote:
> From: Paul Eggleton <paul.eggle...@microsoft.com>
>
> We have a usecase where our initramfs changes on every build (since it
> contains a version number which is based on the date), and we're
> incorporating that into a fitImage. Most of the time our builds are done
> from shared state and we want them to be as efficient as possible.
> Currently, when the initramfs signature is different this setup requires
> the kernel to be recompiled on every build, which is not ideal. I've
> come up with the following rough patch to address this, which does the
> following:
>
> * Avoid the dependency of do_bundle_initramfs on ${INITRAMFS_IMAGE} if
> we are going to be building that for the fit image later anyway
> * Add a do_preserve_kernel_build task to preserve the files needed to
> re-run do_assemble_fitimage_initramfs in a separate location from
> ${B}, which can be saved to sstate
> * Add a do_deploy_fitimage task to deploy just the files written out by
> do_assemble_fitimage_initramfs to ${DEPLOY_DIR_IMAGE}; this allows us
> to preserve less in sstate than we would have to if we allowed
> do_deploy to rerun. Of course the downside is we then need to add a
> dependency from the image's do_build on the kernel's
> do_deploy_fitimage, and I had to introduce a variable to control that
> which is a bit awkward.
>
> This patch is quite rough and I'd like to take suggestions on how to
> improve it. One of my challenges is I don't have a complete grasp of all
> the usage modes supported by this code so I'd appreciate folks who do
> taking a look.
I don't have good answers unfortunately.
We have tried really hard to avoid putting all of the kernel build
output into sstate. The main reason for that was that recompiling the
kernel from source took around the same amount of time as compressing
it and moving it around in sstate, it was huge.
If we're going to start putting all the kernel bits into sstate, we
would probably rethink kernel-devsrc and a few other pieces too. I'm
not sure we should do that but they're all connected. Perhaps we do
give in and do that but I doubt people will like the build times or
sstate size increases :(.
I'd also observe that we don't have good tests for a lot of these
different use cases. The code has slowly been turning into an if/else
labyrinth and it is very unclear which usecases are being used by
people. We have seen a rise in test cases and I have pushed for them
where I can but the situation isn't great and is a big worry whenever
we make changes in here.
Adding in yet further if/else paths with magic variables to control
them isn't filling me with confidence.
The recent work Sean Anderson did on fitimage with u-boot looked like a
promising de-cluttering of some of the maze.
I added Bruce to Cc:.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173061):
https://lists.openembedded.org/g/openembedded-core/message/173061
Mute This Topic: https://lists.openembedded.org/mt/94747626/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
