qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] KVM call agenda for Tuesday 7


From: Anthony Liguori
Subject: Re: [Qemu-devel] KVM call agenda for Tuesday 7
Date: Tue, 07 Feb 2012 10:24:19 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

On 02/07/2012 09:21 AM, Paolo Bonzini wrote:
On 02/07/2012 03:56 PM, Anthony Liguori wrote:
Another related question is, should the 4th QOM series present a full
composition tree based on the legacy qdev bus concept?

Composition, no. The legacy qbus concept doesn't model composition
because it puts children created by composition (like the Cirrus VGA
adapter) in the same context as a device created by a user (like an
e1000 network card).

Currently it doesn't, but
if not, why not? That would help _a lot_ with removing PROP_PTR.

One thing that we could do, is modify qdev_create() like:

DeviceState *qdev_create_with_name(BusState *bus, const char *typename,
const char *name)
{
// ...
object_property_add_child(legacy_machine_root(), name, OBJECT(dev), &err);
// assert if err due to conflicting property names
}

DeviceState *qdev_create(BusState *bus, const char *typename)
{
return qdev_create_with_name(bus, typename, typename);
}

Most devices only have a single instance. In the cases where there are
multiple instances, we'll have to fix it up manually but that really
shouldn't be all that hard.

I'm wary of all plans that require to go through all the code once. What about
simply /devices/default/child[...] or something like that?

The paths would be unstable, but maybe that's okay. I'd suggest doing child[rand()] to avoid the appearance that these paths are in any way shape or form stable.

BTW, I would like to change /i440fx to /devices/i440fx, so that we will have
clean namespaces:

/block
...
/chardev
...
/clocks
...
/devices
/peripheral
... # named devices created with -device
/peripheral-anon
/child[...] # unnamed devices created with -device
/default
/child[...] # created with qdev_create

Yeah, this makes sense. By clocks, you mean things like rtc_clock, vm_clock, etc? Not the omap clocks which happen to live in /clocks in your series?

Regards,

Anthony Liguori


Paolo





reply via email to

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