Re: [Qemu-devel] [PATCH 07/18] qom: add link properties

[Anthony Liguori]

On 12/01/2011 09:00 AM, Avi Kivity wrote:
> On 12/01/2011 04:53 PM, Anthony Liguori wrote:
> > >   What does the client code looks like for link<PCIDevice>?
> >
> > I'm not sure what you mean by client code,
>
> This:
>
> > but consider a device called UsbController that looks like:
> >
> > struct UsbController
> > {
> >      DeviceState parent;
> >
> >      UsbDevice *slave; // link property
> > };
> >
> > To add this as a link, somewhere in the init function you would do:
> >
> >
> > static void usb_controller_initfn(UsbController *dev)
> > {
> >     ...
> >     qdev_property_add_link(DEVICE(dev), "slave", "UsbDevice",
> >                            (DeviceState **)&dev->slave, NULL);
> > }
>
> Issues:

I have thought about all of these and have solutions but we have to take it one 
step at a time.

> - this is an object property, not a class property, so to get a list of
> properties we need to instantiate an object.

Yes, but it will be safe to instantiate an object as object instantiation is 
side-effect free.  Recall, QOM does not have constructor properties and 
construction is delayed to realize.

In addition, we'll be moving all structures into header files and I imagine 
we'll have a doc syntax so that we can place documentation about the properties 
in the headers and exact it appropriately.

> - "UsbDevice" as the type is not type safe at compile time

It will become TYPE_USB_DEVICE once we get the next stage in.  See some of my 
earlier QOM posts for examples.

> - ditto for the cast

The cast is unfortunate.  I can't really figure a good solution to this.  I 
could implement a macro to eliminate the cast but since this may be a NULL 
pointer when this function is called, I can't find a way to make this safer.

> > If you want to set the property explicitly, you would just do:
> >
> >    dev->slave = some_other_device
> >
> > You don't need to use any special function to manipulate the link.
> > Stylistically, I'd prefer that all devices exposed accessor functions
> > and that you did these things through accessors so that we had clear
> > rules about what's public and private.
>
> Also, so we can have observers that trigger on changes.

Exactly.  I don't think it's a hard requirement right now for any type of 
property.  I think avoiding boiler plate is more important at the moment.

Regards,

Anthony Liguori