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

[Anthony Liguori]

On 02/07/2012 07:52 AM, Paolo Bonzini wrote:
> On 02/07/2012 02:45 PM, Andreas Färber wrote:
> > Another topic that can be answered by email is what the time planning
> > for the 4th QOM series looks like.

qom-upstream.16 is pretty close to ready to be sent out for v1.  It's fairly 
tricky getting these things into a bisectable state.  I think I've got about a 
days worth of work left so hopefully in terms of calendar time, probably this 
friday.

In terms of merging, once it's gotten the appropriate reviews.  This won't be a 
rebase-pain so we'll just treat it like a normal series.

> > Are there things that developers of
> > new devices should keep in mind / start doing differently wrt SysBus?

It's probably a good time to read object.h if you haven't already.  In terms of 
deprecating things, I'd prefer to deprecate by removing which basically means 
we'd only deprecate SysBus after converting all of the current users.

A big consideration at this point is compatibility.  It's not clear to me what 
interfaces we really have to maintain compatibility for.

For instance, the 4th series breaks setting -global properties based on bus 
name.  But this is 1) not used by libvirt 2) not actually documented anywhere 
and 3) such a subtle implementation detail that I don't think more than a few 
people even know it's possible.

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

That gives us composition paths and a clear goal for removing the legacy paths 
(we'd want to work toward eliminating /legacy-machine).

device_add doesn't use qdev_create() and neither would properly refactored 
devices (they'd use object_init).

Regards.

Anthony Liguori

> Paolo