|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH v2] qom: Introduce object_realize_nofail() |
Date: | Thu, 12 Apr 2012 11:33:29 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 |
On 04/12/2012 11:09 AM, Peter Maydell wrote:
On 12 April 2012 17:02, Anthony Liguori<address@hidden> 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=tapIsn'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
[Prev in Thread] | Current Thread | [Next in Thread] |