Re: Call for GSoC internship project ideas

["Alex Bennée" <alex.bennee@linaro.org>]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Tue, Jan 20, 2026 at 04:42:38PM -0500, Stefan Hajnoczi wrote:
>> Hi Marc-André,
>> I haven't seen discussion about the project ideas you posted, so I'll
>> try to kick it off here for the mkosi idea here.
>> 
>> Thomas: Would you like to co-mentor the following project with
>> Marc-André? Also, do you have any concerns about the project idea from
>> the maintainer perspective?
>> 
>> === Reproducible Test Image Building with mkosi ===
>
>> This project proposes using mkosi to build minimal, reproducible test
>> images directly from distribution packages. mkosi is a tool for
>> building clean OS images from distribution packages, with excellent
>> support for Fedora and other distributions. It should be able to
>> produces deterministic outputs.
>
> Aside from what I mentioned already, the other issue I anticipate
> with mkosi is the mismatch between what hardware QEMU needs to be
> able to cover, vs what hardware the distros actually support.
>
> Fedora in particular is pretty narrow in its coverage. Debian is
> considerably broader.
>
> Neither will support all the QEMU targets, let alone all the
> machine types within the target.
>
>
> While there is value in testing a full blown OS image, IMHO,
> for most of what we need it is considerable overkill, and
> thus makes functional tests slower than they would otherwise
> need to be.
>
> IMHO, our baseline for functional testing images ought to be
> a Linux Kconfig recipe used to build a dedicate kernel, plus
> a busybox build for the target.
>
> This would let us create either a self contained initrd, or
> a tiny root disk, both of which would reliably boot in a
> barely more than a second or two, even under TCG.

This is why I've been building my iamges with buildroot. It provides for
a lean user-space with exactly what you want and it can create a
software BOM for the whole thing.

But it also allows me to bring in more complex things if I need to like
the vkmark tests for example.

> This would have a number of other benefits
>
>  * Not dependent on distros supporting the given QEMU
>    target and machine type. As long as a Linux port
>    exists and busybox compiles, we can test it
>  
>  * Identical test image functionality for every single
>    target and machine type. No hodge-podge of different
>    3rd party guest OS.
>
>  * Stable forever, with all changes entirely under
>    our own control. No distro changes that arbitrarily
>    break our CI.
>
>  * Easier to debug when it breaks, since there would
>    be a small well defined set of logic running in
>    the guest userspace
>
>  * Fairly easy for QEMU to provide the complete and
>    corresponding source for any binary images, since
>    we've built it all from scratch
>
>  * Tiny & fast downloads of pre-built images.
>
>
> This would not eliminate the need for testing real OS images,
> but would significantly downgrade their importance.
>
> Functional tests could be in three groups - 'quick', as today,
> 'slow' the smoke tests with our miny kernel+busybox, 'thorough'
> the full OS images.
>
>
> With regards,
> Daniel

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro