qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC] QCFG: a new mechanism to replace QemuOpts and option handling
Date: Mon, 14 Mar 2011 15:04:49 -0500	[thread overview]
Message-ID: <4D7E74E1.30408@codemonkey.ws> (raw)
In-Reply-To: <878vwhwkcq.fsf@ginnungagap.bsc.es>

On 03/14/2011 02:52 PM, Lluís wrote:
> Anthony Liguori writes:
>
>> I've got a spec written up at http://wiki.qemu.org/Features/QCFG.  Initial code
>> is in my QAPI tree.
> What about moving the documentation to a 'doc' attribute?
>
> Thus, instead of the example vnconfig:
>
> { 'type': 'VncConfig',
>    'doc': 'Configuration options for the built-in VNC server.',
>    'data': {'address': 'str',
>             ...} }
>
> Still, it's not clear to me how attribute documentation shoul dbe
> provided:
>
>    'data': {'address': {'type': 'str',
>                         'doc': 'The hostname to bind the VNC server to...'},
>              ...
>            }
>
> Or maybe:
>
>    'data': {'address': 'str',
>             'address.doc': 'The hostname to bind the VNC server to...'},
>              ...
>            }
>
> But as I suppose these documentation comments are automatically
> processes, this might just prove too verbose for no benefit at all, as
> introspecting down to the documentation might be already doable with the
> format on the example.

Exactly.  This is the intention--to have the documentation be just as 
well structured as the JSON.

> You could also have a 'since' attribute, in case dynamic interface
> checks are necessary (e.g., the "Since: 0.14.0" in the example).

Indeed.

Regards,

Anthony Liguori

> Lluis
>
> --
>   "And it's much the same thing with knowledge, for whenever you learn
>   something new, the whole world becomes that much richer."
>   -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
>   Tollbooth
>

  reply	other threads:[~2011-03-14 20:06 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-14 17:48 [Qemu-devel] [RFC] QCFG: a new mechanism to replace QemuOpts and option handling Anthony Liguori
2011-03-14 19:52 ` Lluís
2011-03-14 20:04   ` Anthony Liguori [this message]
2011-03-15 10:09 ` Kevin Wolf
2011-03-15 13:27   ` Anthony Liguori
2011-03-15 13:45     ` Kevin Wolf
2011-03-15 13:56       ` Anthony Liguori
2011-03-18 18:12     ` Stefan Hajnoczi
2011-03-15 11:21 ` [Qemu-devel] " Kevin Wolf
2011-03-15 13:37   ` Anthony Liguori
2011-03-15 13:51     ` Kevin Wolf
2011-03-17 15:26       ` Markus Armbruster
2011-03-18  4:12         ` Anthony Liguori
2011-03-18 13:07           ` Markus Armbruster
2011-03-17 15:22 ` [Qemu-devel] " Markus Armbruster
2011-03-17 18:28   ` Anthony Liguori
2011-03-18  9:44     ` Kevin Wolf
2011-03-18 14:04     ` Markus Armbruster
2011-03-18 22:39       ` Anthony Liguori
2011-03-22 13:01         ` Markus Armbruster
2011-03-22 15:49           ` Anthony Liguori
2011-03-24  8:32             ` Markus Armbruster

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=4D7E74E1.30408@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --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).