qemu-devel
[Top][All Lists]
Advanced

[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: Fri, 09 Dec 2011 08:25:12 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

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
runtime?

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.

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.

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.

Regards,

Anthony Liguori


Kevin





reply via email to

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