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: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH RFC 1/7] qom: allow properties to be registered against classes
Date: Fri, 04 Sep 2015 08:56:41 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

"Daniel P. Berrange" <address@hidden> writes:

> 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 !

That's a sensible approach when the solutions to the simple cases are
likely to stand regardless of whether and how we later crack the hard
cases.  I guess it's sensible here.  Let me explain.

I prefer defining properties in static data rather than code, because
reasoning over static data is so much easier.  If we can find a way to
do that even for the hard cases, lovely.  If we can't, then I'd still
prefer the softer cases done in data.  Two mechanisms instead of one
(bad), but the vast majority of cases becomes simpler (good).

So, if there's rough consensus Dan's RFC is worth pursuing, we can and
should defer the in-depth discussion of hard cases until we get around
to them.

Makes sense?



reply via email to

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