Re: [OE-core] [RFC] [PATCH] Allow fitimage + initramfs rebuild to be accelerated

[Paul Eggleton <bluelightning@bluelightning.org>]

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