Am 10.04.2012 14:10, schrieb Andreas Färber: > Am 10.04.2012 12:32, schrieb Peter Maydell: >> On 10 April 2012 11:30, Andreas Färber <afaer...@suse.de> wrote: >>> 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. >> >> To throw in a tangential non-x86 perspective, I would prefer that >> there be no -M default at all. For ARM at any rate there is no >> machine which is inherently preferable or better than any other; >> the current default is integratorcp simply because it happened to >> be the first one implemented, and this tends to lead to user errors >> where people don't realise that not passing in a -M option results >> in their getting an ancient and barely maintained model... > > I'd be fine with such an explicit choice, too. As a side-effect that > would simplify QOM'ification by not needing to create and iterate O(n) > classes (wasting memory during regular execution) just to find the > default one and then possibly override it with another. > > I could generalize and clarify my goal as avoiding unintentionally using > the "wrong" machine.
Not having a default may be a good choice for ARM, but why can't this be a per-target decision? For x86 you don't really have this problem, and one of qemu's strengths is that it doesn't need much configuration, but even just a 'qemu-system-x86_64 disk.img' can be enough to get something booted. Kevin
