qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: "Marc-André Lureau" <marcandre.lureau@gmail.com>,
	QEMU <qemu-devel@nongnu.org>,
	"Markus Armbruster" <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC 1/7] qom: allow properties to be registered against classes
Date: Mon, 7 Sep 2015 15:11:56 +0200	[thread overview]
Message-ID: <55ED8D1C.6020404@suse.de> (raw)
In-Reply-To: <20150907084604.GA29882@redhat.com>

Am 07.09.2015 um 10:46 schrieb Daniel P. Berrange:
> On Fri, Sep 04, 2015 at 11:38:06PM +0200, Marc-André Lureau wrote:
>> On Wed, Aug 26, 2015 at 2:03 PM, Daniel P. Berrange <berrange@redhat.com> wrote:
>>> +ObjectProperty *
>>> +object_class_property_add(ObjectClass *klass,
>>> +                          const char *name,
>>> +                          const char *type,
>>> +                          ObjectPropertyAccessor *get,
>>> +                          ObjectPropertyAccessor *set,
>>> +                          ObjectPropertyRelease *release,
>>> +                          void *opaque,
>>> +                          Error **errp)
>>> +{
>>> +    ObjectProperty *prop;
>>> +    size_t name_len = strlen(name);
>>> +
>>> +    if (name_len >= 3 && !memcmp(name + name_len - 3, "[*]", 4)) {
>>> +        int i;
>>> +        ObjectProperty *ret;
>>> +        char *name_no_array = g_strdup(name);
>>> +
>>
>> I question the need for dynamic/array property name registered in
>> classes. What would be more useful is an array property instead. It
>> would help to introspect classes for dynamic "children[*]" case.
>> object_property_add_child() could verify/check against the class
>> declaration, and grow the instance properties list (like it does now,
>> but it would be only for instances of children[] items). On
>> introspection of classes, the class "children[*]" property would be
>> visible, but would be hidden when introspecting the instance, and you
>> wouldn't be able to lookup that "array" property.
>>
>> It seems relatively straightforward to deal with the link<> case, by
>> storing the offset of the "child" pointer. This seems fine if limited
>> to a single link<> (it should probably check the prop is not of the
>> name[*] style already), ex:
>> https://gist.github.com/elmarco/905241b683fb9c5f2a08
>>
>> Your patches looks good  to me in general but object_property_del()
>> should be fixed, since the prop find may belong to the class.
> 
> Actually I skipped object_property_del() intentionally. Classes should
> be immutable once defined, so deleting a property from a class would
> not be appropriate.

Agreed, I don't see a use case either.

Can you propose a sentence to amend the commit message with? Then I
would apply this patch to my upcoming qom-next pull, then the unreviewed
rest could go through their respective maintainers.

Regards,
Andreas

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

  reply	other threads:[~2015-09-07 13:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-26 12:03 [Qemu-devel] [PATCH RFC 0/7] Making QOM introspectable Daniel P. Berrange
2015-08-26 12:03 ` [Qemu-devel] [PATCH RFC 1/7] qom: allow properties to be registered against classes Daniel P. Berrange
2015-09-02 16:18   ` Andreas Färber
2015-09-03 15:49     ` Daniel P. Berrange
2015-09-03 16:37       ` Markus Armbruster
2015-09-03 16:41         ` Andreas Färber
2015-09-03 17:02           ` Markus Armbruster
2015-09-03 17:09             ` Daniel P. Berrange
2015-09-03 17:21               ` Andreas Färber
2015-09-03 17:25                 ` Daniel P. Berrange
2015-09-04  6:56                   ` Markus Armbruster
2015-09-07 12:54                     ` Paolo Bonzini
2015-09-11 16:09     ` Daniel P. Berrange
2015-09-04 21:38   ` Marc-André Lureau
2015-09-07  8:46     ` Daniel P. Berrange
2015-09-07 13:11       ` Andreas Färber [this message]
2015-09-07 13:17         ` Daniel P. Berrange
2015-08-26 12:03 ` [Qemu-devel] [PATCH RFC 2/7] hostmem: register properties against the class instead of object Daniel P. Berrange
2015-08-26 12:03 ` [Qemu-devel] [PATCH RFC 3/7] rng: " Daniel P. Berrange
2015-08-26 12:03 ` [Qemu-devel] [PATCH RFC 4/7] tpm: " Daniel P. Berrange
2015-08-26 12:03 ` [Qemu-devel] [PATCH RFC 5/7] cpu: avoid using object instance state in property getter Daniel P. Berrange
2015-08-26 12:03 ` [Qemu-devel] [PATCH RFC 6/7] x86-cpu: register properties against the class instead of object Daniel P. Berrange
2015-08-26 12:03 ` [Qemu-devel] [PATCH RFC 7/7] machine: " Daniel P. Berrange
2015-09-02  9:05 ` [Qemu-devel] [PATCH RFC 0/7] Making QOM introspectable Daniel P. Berrange
2015-09-02 11:14   ` Markus Armbruster
2015-09-02 16:16   ` Andreas Färber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55ED8D1C.6020404@suse.de \
    --to=afaerber@suse.de \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=marcandre.lureau@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).