qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH] pc: change default machine model and versio


From: Andreas Färber
Subject: Re: [Qemu-devel] [RFC PATCH] pc: change default machine model and versions
Date: Tue, 10 Apr 2012 12:30:00 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0

Am 03.04.2012 21:38, schrieb Anthony Liguori:
> Right now, '-M pc' is the default and, in general, this machine type has guest
> visible ABI changes in each version of QEMU.  At some point in each release,
> we create a '-M pc-X.Y' corresponding to the last release and attempt to make
> that look like the previous QEMU version's machine.
> 
> We've accumulated a bunch of '-M pc-X.Y's at this point and if we move to a
> three month release process, the problem will get much worse.
> 
> This is a proposal to change the way we do things in order to simplify
> compatibility and present a very clear statement of what we support.
> 
> With this patch, we will not introduce any more '-M pc-1.x' beyond 'pc-1.0'.
> We will not introduce a new 'pc-X.Y' until the QEMU 2.0 release (1Q 2014).
> Instead, we will introduce a 'pc-next' machine type that is *not* the default
> machine type.  If you omit a '-M' option, you will get '-M pc-1.0'.  However,
> if you want to test the latest and greatest, you will need to use an explicit
> '-M pc-next'.

Independent of what frequency of machine versions we offer, I think
defaulting to pc-1.0 is a bad idea. The people fiddling with QEMU
command lines are mostly developers, others can be expected to use a
more convenient frontend, such as libvirt or oVirt. I would hope that
updating any of these frontends to supply a -M pc-1.0 argument would be
possible without much effort. Expecting developers to type -M pc-next
again and again will result in pc-next not being tested as much and thus
broken quickly.

Therefore I would suggest to make pc-next the default machine but to
alias pc-1.0 as "pc", if we want to split off pc-next from pc-x.y.

Being the one who commented on the shortened release cycle causing new
machines to emerge each release, I was rather thinking of widening the
release cycle again. But rather than talking about time periods, maybe
we should compile a time table of when distributions actually choose a
new QEMU version?

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]