Re: [OE-core] [PATCH 2/2] uki.bbclass: add class for building Unified Kernel Images (UKI)

[Mikko Rapeli <mikko.rapeli@linaro.org>]

Adding Alexandre and Kristian since they contributed the uki support,

On Wed, Sep 04, 2024 at 11:17:29AM +0200, Alexander Kanavin wrote:
> On Wed, 4 Sept 2024 at 09:56, Mikko Rapeli <mikko.rapeli@linaro.org> wrote:
> > > Not rejected per se; I would suggest that the existing wic
> > > implementation is rewritten to use the class (and hopefully becomes
> > > radically simpler and shorter)!
> > >
> > > It's fine to not be entirely backwards compatible; this is master, and
> > > we can break things.
> >
> > Does the implementation have to be a wic plugin?
> >
> > wic is another wrapper over bitbake and I'd need to teach openssl native
> > and python3native things to it which seems a bit too much. uki.bbclass
> > is much simpler and wic can process the produced .efi file when creating
> > the ESP boot partition. I can try to fix the tests to work with uki.bbclass.
> 
> No, implementation can stay in the bbclass. But I don't exactly
> remember how the whole thing fits together, and whether you can keep
> what the bbclass functionality in the bbclass and have wic call into
> it (perhaps indirectly) or vice versa.

Current uki support implementation is in a wic plugin,
scripts/lib/wic/plugins/source/bootimg-efi.py. It can't call into bbclass'es.
It can run binaries from recipe sysroot but re-implements the bitbake recipe
runtime environment via scripts/lib/wic/misc.py function exec_native_cmd().
It doesn't support running python3 or openssl binaries, currently, so it
doesn't work with systemd ukify script. Adding that support is possible
but feels like duplicating the bitbake environment in wic.

I can understand the plugin based design if wic is meant to also run outside of
bitbake build environment, but for non-trivial tools like in ukify, python3,
openssl etc this can't easily be done. ukify tool only runs well in the bitbake
build environment with specific versions of those tools and their dependencies.

I would prefer to keep the uki generation in a bbclass where all runtime
dependencies can be managed with bitbake, and use wic for baking
the uki .efi binaries into partitions and images.

Alexandre and Kristian, do you have preferences about uki generation
via bbclass vs wic plugins? Do you expect to run wic outside of bitbake?
If you've added secure boot signing, how did you add that with wic plugin
based uki generation?

> I just would like to avoid the situation where there are two entirely
> different implementations of the same thing in core, and only one of
> them gets tested. If wic can work together with the bbclass, then the
> existing wic selftests will test the bbclass as well.

Understood. I can convert the existing wic plugin code and tests to work
with uki.bbclass generated .efi file and use wic to generate the partitions
and image files only. There's been some adaptation work in the uki generation
due to systemd/systemd-boot implementation and uki specification changes so I
think using the systemd side implementation would be more future proof, though
of course APIs can change there too.

Cheers,

-Mikko