Re: [PATCH 00/13] boot: Make fit_image_load() easier to maintain

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2067 bytes --]

On Wed, Mar 25, 2026 at 10:54:09AM -0600, Simon Glass wrote:

> Before fit_image_load() was created, the code to load kernels, ramdisks
> and devicetrees from a FIT was spread around many functions. By
> combining most of the code in one place, it became possible to add more
> features in a consistent way. The 'loadables' feature was much easier to
> plumb in, for example.
> 
> While fit_image_load() was a substantial advance, it has never been a
> svelte function and the passing years have not been entirely kind. With
> a few new features on the horizon, this is a good time to improve the
> implementation.
> 
> This series splits much of the code from fit_image_load() into a number
> of smaller functions. Most of the changes are fairly mechanical, with
> just a few renames and tweaks here and there.
> 
> This should make the function much easier to maintain. It may also
> encourage someone to take a look at its callers, which could also use
> some attention.
> 
> Code-size impact: about +8 bytes on aarch64 and +24-40 bytes on arm, due
> to the compiler's register allocation across the new helper functions.
> 
> 
> Simon Glass (13):
>   boot: Split out the first part of fit_image_load()
>   boot: Move call to fit_image_select() and rename it
>   boot: Tidy up setting of the OS arch on host builds
>   boot: Move type and OS checking into a new function
>   boot: Move handling of the load_op into a separate function
>   boot: Move obtaining data from a FIT image into a function
>   boot: Check the image is allowed before setting os.arch
>   boot: Move the architecture check into check_allowed()
>   boot: Move image-decompression into a separate function
>   boot: Move decomp_image() into handle_load_op()
>   boot: Move setting the OS arch into check_allowed()
>   boot: Drop unnecessary data variable
>   boot: Tidy local variables in fit_image_load()

I've reviewed through 5, and I assume 6-13 have similar issues as the
rest. Please think about that before submitting a v2, thanks.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]