[Top][All Lists]

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

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM
Date: Fri, 16 Sep 2011 21:29:53 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

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


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.


Anthony Liguori

reply via email to

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