qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 4/5] monitor: add object-add (QMP) and object_ad


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 4/5] monitor: add object-add (QMP) and object_add (HMP) command
Date: Tue, 07 Jan 2014 13:51:49 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9

Il 07/01/2014 13:00, Markus Armbruster ha scritto:
>> >
>> > Is dumping static properties based on class name sufficient, or do we
>> > need introspection for dynamic properties as well? (or are those not
>> > exposed outside of qom-set?)
> 
> Can't say whether introspection limited to static properties would be
> useful, because I don't actually know how static and dynamic properties
> are used.

I think right now dynamic properties are used little-to-nothing.

They are used by non-devices such as the RNG backends, and for links
(which should replace PROP_PTR).

> I challenged the need for dynamic properties in the early QOM days,
> because they lead to dynamic schemata and complicate introspection, but
> Anthony assured us we cannot do without them.

Dynamic properties are the basis of the QOM tree *as it is implemented
now*.  Children are simply dynamic properties of type child<SomeType>,
and they must be dynamic since the command-line influences the QOM tree.
 So I agree with Anthony that dynamic properties are fundamental to the
way QOM is implemented.  I'm not sure it is *necessary* for it to be
implemented that way, but I don't have any code to show that another
implementation would be simpler or better or even possible.

I also agree with him that moving the qdev properties code up to Object
is not the right way to proceed in order to have static properties.
That code has support for legacy property types such as hexadecimal,
that we need not have outside -device (i.e. if we can create devices one
day with -object, you'll have to write 0x402 because 402 will always be
interpreted as decimal).  At the same time it does not support neither
links nor the more flexible getters/setters that QOM allows.  We
probably would want this for QOM static properties.

On the other hand I agree with a large subset of your idea, i.e. that
devices should have a known schema for the subset of properties that can
be set at initialization time.  Furthermore, this schema should be
introspectable.

Anyhow, with so little use of dynamic properties (outside children), I
believe no one can argue his position successfully with code rather than
just theories.

> >                              We could maybe introduce a QAPI 'built-in'
> > such as 'ObjectProperties' that automatically does the query based on the
> > now-special 'type' param and handles all the type-checking up-front. This
> > would avoid an open-ended 'dict' type proliferating too much and provide
> > infrastructure for introspection.
> 
> I'm afraid I'm too ignorant to understand what you're proposing.

I don't really understand that either.

Paolo



reply via email to

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