On 04/12/2012 11:09 AM, Peter Maydell wrote:
On 12 April 2012 17:02, Anthony Liguori<anth...@codemonkey.ws> wrote:
On 04/12/2012 10:52 AM, Peter Maydell wrote:
Why would you design an infrastructure that lets you coherently bundle
together a collection of devices and have configurable properties on
that bundle as well as on the devices, and then *not* use it for machines?
The machine concept in QEMU is "broken" IMHO. If we want to maintain
compatibility (and we do), we need to let machines act as a bridge.
Here's how I expect the PC to work:
qemu --no-machine -readconfig my-system.cfg
[device "root"]
driver=i440fx
cpu[0]=cpu0
slot[3]=e1000
memory=2G
biosname=bios.bin
[device "cpu0"]
driver=qemu64
[device "e1000"]
bus=/i440fx
netdev=eth0
[netdev "eth0"]
type=tap
Isn't this just defining a machine in a config file without
naming it?
Yup.
And what we think of as "machines' should basically just be doing the same thing
a config file does. It doesn't need to be part of the object model.
There is no real need to have a '-machine' option and no need to model a
machine.
This doesn't make sense to me. We need a -machine option because it's
the major way for the user to say what kind of model they want. We need
to model machines because without that we just have a pile of useless
devices.
Machine wouldn't go away. The point I'm making is that -machine doesn't have to
be an alias of a single -device option.
Regards,
Anthony Liguori
-M pc ends up being a compatibility bridge which takes a bunch of options
that really do lots of different things (like choosing network device
models). I see machines as a function that takes a QemuOpts and then does
the equivalent of the above.
-- PMM
