Re: Call for GSoC internship project ideas

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Jan 22, 2026 at 02:22:28PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Thu, Jan 22, 2026 at 2:14 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > 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.
> 
> 
> That's right, the goal here is not to cover all possible images though.
> 
> I picked Fedora here as an example, because it is the best supported
> distribution in mkosi.

IMHO to be worth the effort of integrating mkosi *and* maintaining its
use in QEMU long term, it has to address a broad set of problems that
we face in the functional tests.

IMHO the inherant dependency on distros is the underlying problem
we have, as we try to achieve testing coverage across all the
machine types in QEMU.  It leads us to having a random selection
of different approaches, and mkosi does not look like it will
reduce that problem, or help us fill in the gaps we have.

> > 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.
> 
> mkosi can produce initrd images, which can be small enough and
> customizable. Although I lack the details of what is possible, this is
> part of the project research.
> 
> Imho, building all images from scratch cannot be sustainable.

I'd say the opposite - relying on distros, whether using mkosi
or not, is not sustainable.

Once we have written some scripts that can build gcc, binutils, linux,
busybox we've opened the door to be able to support every machine type
on every target, provided there has been a gcc/binutils/linux port at
some time (which covers practically everything). Adding new machines
becomes cheap then - just a matter of identifying the Linux Kconfig
settings, and everything else stays the same. Adding new targets means
adding a new binutils build target, which should again we relatively
cheap, and also infrequent. This has potential to be massively more
sustainable than a reliance on distros, and should put us on a pathway
that would let us cover almost everything we ship.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|