Re: [Qemu-devel] release retrospective, next release timing, numbering

[Daniel P . Berrangé]

On Fri, Apr 27, 2018 at 06:42:07PM +0200, Thomas Huth wrote:
> On 27.04.2018 18:24, Peter Maydell wrote:
> > On 27 April 2018 at 17:17, Thomas Huth <address@hidden> wrote:
> >> By the way, just another crazy idea for v3.0 (i.e. feel free to turn it
> >> down immediately ;-)): Since compilation and testing time for QEMU is
> >> really huge, what do you think if we got rid of some QEMU binaries?
> >> qemu-system-aarch64 is a superset of qemu-system-arm, qemu-system-x86_64
> >> is a superset of qemu-system-i386 and qemu-system-ppc64 is a superset of
> >> qemu-system-ppc (and qemu-system-ppcemb). Would be feasible to get rid
> >> of the subset binaries with some work? (I think they were especially
> >> useful on 32-bit machines in the past, but most people are using 64-bit
> >> machines nowadays, aren't they?).
> > 
> > I think Markus' backward-compatibility rubber chicken may prevent
> > us from removing those executables...
> 
> Markus seems currently to be in the mood to cut down the testing time
> (see the current qom-test mail thread), so maybe we can convince him ... ;-)
> 
> > (In the utopian far future I'd like us to have just one QEMU
> > executable that could handle all architectures at once :-))
> 
> Yes, that would be great ... but that's really distant future, I guess.

I'm curious what is the compelling benefit of having a single fat QEMU
binary that included all archiectures at once ?

>From a security POV I find it desirable for us to go in the other direction
away from monolithic binaries that include everything. We've started that
work with turning various pieces of QEMU into loadable modules. In the future
we might see some pieces being moved into completely separate binaries. eg we
could have a core QEMU binary and separate binaries for GTK, SPICE, VNC, etc
frontends.

If each target architecture could be a loadable module, it might be
acceptable, but I wouldn't much like the idea of having every architecture
compiled into a single binary. Distros like to build every QEMU feature,
but users reasonably don't want to expand their attack surface by having
all features installed, so being able to install packages for each target
arch separately is a compelling benefit of current set of QEMU per-target
binaries that I wouldn't want to loose.

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