Hi Richard
On Thursday, 10 November 2022 11:14:24 NZDT Richard Purdie wrote:
> 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 :(.
Right, and I had avoided putting too much into sstate with this patch -
basically just vmlinux and the contents of arch/${ARCH}/boot (via the perhaps
a bit broadly named KERNEL_OUTPUT_DIR) - possibly even that could be trimmed a
bit. For our case building the kernel takes a significant time because (long
story short) there are actually two kernels building (debug and regular
flavours) and there are a number of items that depend upon them -> they also
get rebuilt if we don't untangle this a little bit.
I'm now wondering if part of the solution here would be to move some of the fit
image + initramfs assembly to the initramfs image context. That would mean
that do_deploy would need to save away everything necessary to do that, but
that shouldn't be a huge amount of data.
> 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.
I'm all for adding additional tests, certainly, and I'm happy to at least some
of that work. I'd need to get a better understanding of some of the other use
cases though.
> Adding in yet further if/else paths with magic variables to control
> them isn't filling me with confidence.
I understand that. I was hoping to figure out a way to avoid adding significant
extra complexity.
> The recent work Sean Anderson did on fitimage with u-boot looked like a
> promising de-cluttering of some of the maze.
Indeed.
Paul
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173104):
https://lists.openembedded.org/g/openembedded-core/message/173104
Mute This Topic: https://lists.openembedded.org/mt/94747626/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
