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

[Michal Suchánek]

On Fri, 27 Apr 2018 17:24:38 +0100
Peter Maydell <address@hidden> wrote:

> On 27 April 2018 at 17:17, Thomas Huth <address@hidden> wrote:
> > On 27.04.2018 17:51, Peter Maydell wrote:  
> >> Hi; I usually let people forget about releases for a month or
> >> so before bringing this topic up, but:
> >>
> >> (1) do we want to call the next release 2.13, or something else?
> >> There's no particular reason to bump to 3.0 except some
> >> combination of
> >>  * if we keep going like this we'll get up to 2.42, which starts to
> >>    get silly
> >>  * Linus-style "avoid being too predictable"
> >>  * triskaidekaphobia  
> >
> > and maybe:
> >
> >  * Celebrate 15 years of QEMU  
> 
> Oh, hey, I hadn't noticed that. That's as good a reason as
> any other!
> 
> > 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...

At least the PPC vs PPC64 default to different BIOS, machine type, etc.

That could be achieved by a wrapper script around the 64bit binary I
suppose.

Is there any reason why the 64bit emulator would not run on 32bit
system? The emulated 64bit system is .. emulated after all.

Thanks

Michal