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