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

[Anthony Liguori]

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
> > > 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.
>
> 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
/pc
  /i440fx
  /ide
    /ide1
      /drive[0]
  /net[0]
  /serial[0]

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

Regards,

Anthony Liguori

> Kevin