qemu-devel
[Top][All Lists]
Advanced

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

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


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH RFC 1/7] qom: allow properties to be registered against classes
Date: Thu, 3 Sep 2015 18:25:08 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Thu, Sep 03, 2015 at 07:21:07PM +0200, Andreas Färber wrote:
> 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 <address@hidden> writes:
> >>
> >>> Am 03.09.2015 um 18:37 schrieb Markus Armbruster:
> >>>> "Daniel P. Berrange" <address@hidden> 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].

Good point, I had forgotten that.

> The peculiarity of child<> properties is that the property itself
> contains the value pointer, rather than its parent object instance.

Yep, that confused me for a while !

> Therefore we'll need both class and object level properties, as I
> thought you had done in your patch.

Yes, that's what this proposed patch series does.

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

Personally I'd prefer to see us focus on just solving the simple
cases first, so we don't end up stuck arguing over the hard
cases and holding up potential quick wins !

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



reply via email to

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