Re: [Qemu-devel] [PATCH RFC 1/7] qom: allow properties to be registered against classes

["Andreas Färber" <afaerber@suse.de>]

Am 03.09.2015 um 19:09 schrieb Daniel P. Berrange:
> On Thu, Sep 03, 2015 at 07:02:25PM +0200, Markus Armbruster wrote:
>> Andreas Färber <afaerber@suse.de> writes:
>>
>>> Am 03.09.2015 um 18:37 schrieb Markus Armbruster:
>>>> "Daniel P. Berrange" <berrange@redhat.com> writes:
>>>>> On Wed, Sep 02, 2015 at 06:18:28PM +0200, Andreas Färber wrote:
>>>>>> I had suggested exactly this looong time ago, but Anthony opposed it. I
>>>>>> don't quite remember why...
>>>>>
>>>>> It is a while back now so I don't remember all aspects of the discussion
>>>>> either. The main thing I remember is that we could not simply use the
>>>>> existing GObject model from glib, since that exclusively records properties
>>>>> against the object class. In some cases, particularly the relationships
>>>>> between objects, QEMU needed to be able to define properties on the fly
>>>>> against object instances.
>>>>
>>>> I remember Anthony's assertion that this is the case, but I don't
>>>> remember the actual problems where this is actually the case.
>>>>
>>>> What properties do we currently define that could not be defined against
>>>> the class?
>>>
>>> All child<> properties and everything on Container objects.
>>
>> Apologies if you had to explain this a dozen times already, but here
>> goes my ignorant question anyway: why can't these properties be defined
>> against the class?
> 
> IIUC, you can have zero or more "child<N>" properties registered.
> You only know how many such properties to register at runtime,
> and the count can vary per object instance. So you have to
> register "child<1>", "child<2>", etc properties on objects.
> 
> If we wanted to register these against the class, we could
> introduce an "array of objects" property type. So we would
> just register a "children" array property against the class,
> which can be populated with arbitrary number of objects at
> runtime.  If we did this though, we'd probably need to setup
> some backwards compat support so that any code (or external
> user of QEMU) that tries to use "child<1>" would get transparently
> forwarded to "children" property, element 1.

For that array concept I reserved literal "[*]" recently (patches welcome!),

> I think it could be worth exploring this idea,

but here child<...> is the type. Properties can have arbitrary names, in
some cases (containers) varying from instance to instance, thus are
dynamic. E.g., -device => /machine/peripheral-anon/device[n].

The peculiarity of child<> properties is that the property itself
contains the value pointer, rather than its parent object instance.
Therefore we'll need both class and object level properties, as I
thought you had done in your patch.

Markus, if we need an in-depth discussion, please put it on the agenda
for Tuesday. :)

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)