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

[Anthony Liguori <anthony@codemonkey.ws>]

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