[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] release retrospective, next release timing, numbering
From: |
Daniel P . Berrangé |
Subject: |
Re: [Qemu-devel] release retrospective, next release timing, numbering |
Date: |
Mon, 30 Apr 2018 11:35:06 +0100 |
User-agent: |
Mutt/1.9.2 (2017-12-15) |
On Fri, Apr 27, 2018 at 09:01:20PM +0200, Michal Suchánek wrote:
> 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.
I'm assuming thuat a qemu-system-x86_64 binary cannot use KVM to run
on a 32-bit host kernel, even if it was only running a 32-bit guest ?
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 :|
- [Qemu-devel] release retrospective, next release timing, numbering, Peter Maydell, 2018/04/27
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Thomas Huth, 2018/04/27
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Peter Maydell, 2018/04/27
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Thomas Huth, 2018/04/27
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Paolo Bonzini, 2018/04/30
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Peter Maydell, 2018/04/30
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Michal Suchánek, 2018/04/27
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Richard Henderson, 2018/04/29
- Re: [Qemu-devel] release retrospective, next release timing, numbering,
Daniel P . Berrangé <=
Re: [Qemu-devel] release retrospective, next release timing, numbering, Cornelia Huck, 2018/04/30
Re: [Qemu-devel] release retrospective, next release timing, numbering, Daniel P . Berrangé, 2018/04/30
Re: [Qemu-devel] release retrospective, next release timing, numbering, Greg Kurz, 2018/04/30