Re: [Qemu-devel] [RFC] Plan for moving forward with QOM

[Anthony Liguori <anthony@codemonkey.ws>]

On 09/16/2011 09:17 PM, Anthony Liguori wrote:
> On 09/16/2011 07:48 PM, Edgar E. Iglesias wrote:
>> QEMU should allow us to model devices in a a bus agnostic way.
>
> And this is the problem to fix in qdev. We need to kill buses in qdev. The
> approach really boils down to:
>
> 1) Add unique names to devices (this is needed because buses must have names
> because they must be addressable).
>
> 2) Eliminate any device that has two bus instances in it. I'm pretty sure IDE is
> the only example of this.
>
> 3) Move all BusState functionality to DeviceState and eliminate buses. This is a
> compatibility breaker but a critical change.
>
> Along the way, we also need to refactor properties to support getters/setters

If someone wants to jump in and help, this is a good spot to start as its pretty 
much orthogonal to the bits I'm working on.  Today we define properties like:

    .props = (Property[]){
       DEFINE_PROP_UINT8("port", PCIESlot, port.port, 0),
       ..
    }.

Property looks like:

struct PropertyInfo {
     const char *name;
     size_t size;
     enum PropertyType type;
     int (*parse)(DeviceState *dev, Property *prop, const char *str);
     int (*print)(DeviceState *dev, Property *prop, char *dest, size_t len);
     void (*free)(DeviceState *dev, Property *prop);
};

struct Property {
     const char   *name;
     PropertyInfo *info;
     int          offset;
     int          bitnr;
     void         *defval;
};

This forces a model where all properties are members of the state structure with 
simple copy semantics.  We want Property to look like this:

struct NewProperty {
     const char *name;
     const char *type;
     void (*set)(DeviceState *dev, const char *prop, Visitor *v,
                 void *opaque, Error **errp);
     void (*get)(DeviceState *dev, const char *prop, Visitor *v,
                 void *opaque, Error **errp);
     void *opaque;
};

Which lets the device model implement arbitrarily complex properties and 
implement behavior both on setting and getting of properties.  That means we can 
have truly synthetic properties.

The trick we can do is redefine DEFINE_PROP as:

-#define DEFINE_PROP(_name, _state, _field, _prop, _type) { \
-        .name      = (_name),                                    \
-        .info      = &(_prop),                                   \
-        .offset    = offsetof(_state, _field)                    \
-            + type_check(_type,typeof_field(_state, _field)),    \
-        }
+#define DEFINE_PROP(_name, _state, _field, _prop, _type) {        \
+        .name      = (_name),                                     \
+        .set       = qdev_prop_set_legacy,                        \
+        .get       = qdev_prop_get_legacy,                        \
+        .opaque    = (void *)&(Property){                         \
+            .name      = (_name),                                 \
+            .info      = &(_prop),                                \
+            .offset    = offsetof(_state, _field)                 \
+                + type_check(_type,typeof_field(_state, _field)), \
+        },                                                        \
+}

And then implement qdev_prop_set_legacy/qdev_prop_get_legacy to simply call the 
old style property parse/print functions.  That means that all of the existing 
qdev properties will be treated as strings as far as the Visitor is concerned 
but since that's how it works today, it's not all that bad.

Once this is in place, a link<> and child<> property type could be added to 
automate support of composition and linking which would let us start 
constructing graphs (solving a number of practical problems).

Regards,

Anthony Liguori

> and add composition properties and link properties. At some point, we need to
> introduce the QOM type system to get the full benefits of all of this but that
> can probably be mechanical once we've completed the above.

>
> I think this is all well within the scope of 1.1 and can be done without a
> tremendous amount of churn in the tree.
>
> Regards,
>
> Anthony Liguori