Re: Call for GSoC internship project ideas

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

On Thu, Jan 22, 2026 at 03:28:24PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Thu, Jan 22, 2026 at 2:57 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Thu, Jan 22, 2026 at 10:54:42AM +0000, Peter Maydell wrote:
> > > On Thu, 22 Jan 2026 at 10:40, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > > 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.
> > >
> > > Isn't that essentially reimplementing half of buildroot, or the
> > > system image builder that Rob Landley uses to produce toybox
> > > test images ?
> >
> > If we can use existing tools to achieve this, that's fine.
> >
> 
> Imho, both approaches are complementary. Building images from scratch,
> like toybox, to cover esoteric minimal systems. And more complete and
> common OSes with mkosi which allows you to have things like python,
> mesa, networking, systemd, tpm tools, etc for testing.. We don't want
> to build that from scratch, do we?

To some extent they are complementary, but in terms of what we're doing
with functional tests today, IMHO it could be almost entirely done
with buildroot images. Few of our current tests leverage significant
userspace functionality inside the guest. I'd see buildroot as being
able to provide common baseline that we could potentially even declare
to be a pre-requisite for introducing a new machine type to QEMU.

A handful of current things might need a full 3rd party distro image,
but not many, hence IMHO the bigger benefit to QEMU comes from investing
in a buildroot like approach rather than mkosi, at least at the current
time.

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 :|