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:09:14 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

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.

I think it could be worth exploring this idea, but since it is
a significantly more complex thing I didn't try in this series,
and just ignored the child/container problem.

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]