[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v2 15/18] rtc: add a dynamic property for retrie

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH v2 15/18] rtc: add a dynamic property for retrieving the date
Date: Tue, 13 Dec 2011 07:31: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/13/2011 03:27 AM, Kevin Wolf wrote:
Am 09.12.2011 15:25, schrieb Anthony Liguori:
On 12/09/2011 08:04 AM, Kevin Wolf wrote:
Am 09.12.2011 14:08, schrieb Anthony Liguori:
On 12/09/2011 05:26 AM, Kevin Wolf wrote:
Am 02.12.2011 21:20, schrieb Anthony Liguori:
This really shows the power of dynamic object properties compared to qdev
static properties.

This property represents a complex structure who's format is preserved over the
wire.  This is enabled by visitors.

It also shows an entirely synthetic property that is not tied to device state.

Signed-off-by: Anthony Liguori<address@hidden>

There's one thing that I was hoping to find answered when I would have
reviewed the whole series, but it hasn't happened: There is no doubt
that dynamic properties (in the sense of being able to modify them after
constructions) are a useful thing. But you also claim that class-based
properties are not enough for QOM and that we need object-based ones,
which is a requirement not immediately obvious to me.

Can you provide some examples where we would explicitly need
object-based properties?

Sure.  Any property that's dynamic needs to be object based.  A good example
would be PCI slots.

Today, we unconditionally advertise 32 slots in our ACPI tables.  It could be
desirable to eventually make this configurable.  So you can imagine where you
would have an 'slot-count' property and if that was set to 16, it would result
in 'slot[0]..slot[15]' being created.

There are other good examples too.

So is it mostly about variably sized arrays, which just happen to be
considered independent properties in your approach? Or are there cases
where a logically separate property may be there or missing depending on
some condition, or possibly even that a new property is created during

So there are three possibilities for properties:

1) Properties have no per-object state, and exist entirely within the classes.
This is what qdev does today.

Not quite sure what you mean by per-object state. The properties are
fields in the XyzState, so they certainly are per-object?

In qdev today, the objects have no state reflecting properties. They properties refer to object state, but the objects have no knowledge of the properties themselves.

2) Properties are defined in the class, but carry per-object state.

3) Properties are defined in the object and carry per-object state.

We definitely can rule out (1).  Stateful properties are needed to implement
links, composition, and just about anything interesting.

Another way that (3) is useful is that it allows you to create container devices
that more or less model a PCB.  That's how peripheral[-anon] is implemented and
I imagine that it will also be useful for implementing "machine" devices.

What would this look like? The user creates new child/link properties on
the board, and some more automatically created properties somehow
describe the wiring between them?

The way I imagine this all working out is that a user creates does something like this:

(qemu) device_add driver=pc,id=pc
(qemu) qom_list /pc

Of course, you could find a way to special case this with (2) but that's why I
ended up going with (3).  You can avoid having a lot of special cases this way.

I'm not entirely convinced that we really need this, but on the other
hand I don't feel strong enough about it to argue.

Actually I think my real problem isn't about per-object properties
(although they might add unnecessary complexity), but more about going
away from the qdev style of things where you had _one_ struct definition
that nicely described all of the properties in a central place. Instead,
I'm seeing patches that spread property definitions all over the code.

There isn't one struct as bus properties get inherited, but I understand your point. The problem with "legacy" properties isn't how they're express, it's that the mix parsing with the property types. I have no problem with using DEFINE_ style properties and would expect that we would find a way to make the current properties have a string and non-string interface.

Now I understand that for dynamically created properties (like on your
PCB) this is necessary and can't be avoided. For about 99% of the
devices static definition of properties would be enough, though.

So basically what I'm asking for is getting the static structs back for
the 99% and have common code that parses them and calls the appropriate
functions to actually the properties. The remaining 1% that
creates/deletes properties during runtime and isn't covered can directly
call whatever it needs.

If you look at my qom-next branch, the static structs are still there for 99%er devices. I have no immediate plans of removing them.


Anthony Liguori


reply via email to

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