qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Lin Ma <lma@suse.com>,
	pbonzini@redhat.com, afaerber@suse.de, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] 答复: Re: [PATCH v2] object: Add 'help' option for all available backends and properties
Date: Thu, 22 Sep 2016 09:54:35 +0100	[thread overview]
Message-ID: <20160922085435.GH352@redhat.com> (raw)
In-Reply-To: <87shssnxeq.fsf@dusky.pond.sub.org>

On Thu, Sep 22, 2016 at 10:36:45AM +0200, Markus Armbruster wrote:
> Don't make up a description in user_creatable_help_func(), improve the
> description infrastructure and its use so you get more useful ones
> there.
> 
> The existing description infrastructure is just Property member
> description and object_property_set_description().  Rarely used, so
> description is generally null.
> 
> Calling object_property_set_description() more often could be helpful,
> but to come up with a sensible description string, you need to know what
> the property does.  Needs to be left to people actually familiar with
> the objects.
> 
> Aside: historically, we add properties to *instances*.  All the property
> meta-data gets duplicated for every instance, including property
> descriptions.  This is more flexible than adding the meta-data to the
> class.  The flexibility is rarely needed, but the price in wasted memory
> is always paid.  Only since commit 16bf7f5, we can add it to classes.
> Adding lots of helpful property descriptions would increase the cost of
> instance properties further.

FWIW, we could easily optimize handling of description strings by
applying the same trick that GLib has done for GObject property
descriptions.

Almost certainly every call to object_property_set_description is
going to be passing a string literal, not a dynamically allocated
string. So we take advantage of that and in fact mandate that it
is a string literal, and thus avoid the strdup() of description.

We can place a fun game to enforce this at compile time thus:

 - Rename object_property_set_description() to
   object_property_set_description_internal()

 - Add the macro

  #define  object_property_set_description(obj, name, desc, errp) \
     object_property_set_description_internal(obj, name, "" desc "", errp)


None the less, we really should make an effort to switch things
over to use class properties instead of instance properties, as
its going to save us allocating a 64 byte struct per property
per instance


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	other threads:[~2016-09-22  8:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-11  5:53 [Qemu-devel] [PATCH v2] object: Add 'help' option for all available backends and properties Lin Ma
2016-09-12 15:42 ` Markus Armbruster
2016-09-17 12:15   ` [Qemu-devel] 答复: " Lin Ma
2016-09-19 11:58     ` Markus Armbruster
2016-09-19 15:56       ` Andreas Färber
2016-09-19 17:13         ` Markus Armbruster
2016-09-21 15:56           ` Lin Ma
2016-09-22  8:36             ` Markus Armbruster
2016-09-22  8:54               ` Daniel P. Berrange [this message]
2016-09-22 11:12                 ` Markus Armbruster
2016-09-22 11:28                   ` Daniel P. Berrange
2016-09-22 12:03                     ` Markus Armbruster
2016-09-22 13:48                       ` Daniel P. Berrange
2016-09-22 13:01               ` Daniel P. Berrange
2016-09-12 15:56 ` [Qemu-devel] " Daniel P. Berrange
2016-09-17 12:15   ` [Qemu-devel] 答复: " Lin Ma

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=20160922085435.GH352@redhat.com \
    --to=berrange@redhat.com \
    --cc=afaerber@suse.de \
    --cc=armbru@redhat.com \
    --cc=lma@suse.com \
    --cc=pbonzini@redhat.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).