[Top][All Lists]

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

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 07/18] qom: add link properties
Date: Thu, 01 Dec 2011 09:10:49 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

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,


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);


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.


Anthony Liguori

reply via email to

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