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 <afaer...@suse.de> writes: >> >>> Am 03.09.2015 um 18:37 schrieb Markus Armbruster: >>>> "Daniel P. Berrange" <berra...@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)