From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2949D3644B6 for ; Thu, 22 Jan 2026 11:40:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769082057; cv=none; b=UVkppPVcZz6e4VKCrssqcbpW18MWfC0WKhycmbbM0MA+wZ5RKttZcPeDAPeVVXTfdUAAIEe209PysN0QqyfcFnJzrnKuWLkyPQWPRM83tWYav33CUD66opE+HsUGyrxUaOJJjcekN4v3qwgj6UrRjWHLlWHAbLcBYlnV0Am7gG8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769082057; c=relaxed/simple; bh=/zdRymQH34oxbl15maoMWJwXy0/5cVI/nlD6Mmh2YiM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Hl2e59Kps5uJTRv2fussQGJ0/F2EwZmKBtUnCXcTxurcsGuCW205YLFeBjooM//Ik+mmAn45bvdniWn39b4fxpVFLeM03XD0zuOsK9NxwmPSqEY9yD9KTxk4TS8LEcsDm5BbG4scA25TfgF6nR+spGRmlE7qr2dleiR+LsRSbYM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=PAgGleAW; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="PAgGleAW" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1769082055; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=roXvgU1UIoaVctduRVEdG1PB3IOZIIwfmIIScyiFIcU=; b=PAgGleAWpkQZC/sVkLrh+7kHhgV+nvjB1wd6Pob5Lsr44IkSzNPxnAznEMBZsglJ3z1ZCJ ur1US09HXQY35agTERXYDU/Cl92E3QE4YH4/TJW/y6kzwNBHPesH0BEISOQ9C4Gnc3OYWm OJ9o7nxJLyFvCILYJftbDgluL2+zjG0= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-550-vuGKawt_M2GB_JhHx6spZA-1; Thu, 22 Jan 2026 06:40:50 -0500 X-MC-Unique: vuGKawt_M2GB_JhHx6spZA-1 X-Mimecast-MFC-AGG-ID: vuGKawt_M2GB_JhHx6spZA_1769082049 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 512ED18FF885; Thu, 22 Jan 2026 11:40:44 +0000 (UTC) Received: from redhat.com (unknown [10.42.28.63]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id CD7B630002D8; Thu, 22 Jan 2026 11:40:36 +0000 (UTC) Date: Thu, 22 Jan 2026 11:40:33 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Cc: Peter Maydell , Stefan Hajnoczi , Thomas Huth , qemu-devel , kvm , Helge Deller , Oliver Steffen , Stefano Garzarella , Matias Ezequiel Vara Larsen , Kevin Wolf , German Maglione , Hanna Reitz , Paolo Bonzini , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Mark Cave-Ayland , Alex Bennee , Pierrick Bouvier , John Levon , Thanos Makatos , =?utf-8?Q?C=C3=A9dric?= Le Goater Subject: Re: Call for GSoC internship project ideas Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.2.14 (2025-02-20) X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 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é 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é 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 :|