All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Chris Wright <chrisw@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Adam Litke <agl@us.ibm.com>,
	Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Re: [RFC] QCFG: a new mechanism to replace QemuOpts and option handling
Date: Tue, 15 Mar 2011 14:51:47 +0100	[thread overview]
Message-ID: <4D7F6EF3.2010504@redhat.com> (raw)
In-Reply-To: <4D7F6BAB.8040709@codemonkey.ws>

Am 15.03.2011 14:37, schrieb Anthony Liguori:
> On 03/15/2011 06:21 AM, Kevin Wolf wrote:
>> Am 14.03.2011 18:48, schrieb Anthony Liguori:
>>> I've got a spec written up at http://wiki.qemu.org/Features/QCFG.
>>> Initial code is in my QAPI tree.
>> One question about a small detail on this wiki page:
>>
>>> typedef struct BlockdevConfig {
>>>      char * file;
>>>      struct BlockdevConfig * backing_file;
>>>
>>>      struct BlockdevConfig * next;
>>> } BlockdevConfig;
>> What is the 'next' pointer used for,
> 
> This is a standard part of QAPI.  All types get a next pointer added 
> such that we can support lists of complex types.

Only a single list for each object.

>>   are you going to store a list of
>> all -blockdev options used? And why isn't it a QLIST or something?
> 
> Two reasons.  QLIST requires another type for the head of the list which 
> would complicate things overall.  Second is that these types are part of 
> the libqmp interface and I didn't want to force qemu-queue on any 
> consumer of libqmp.

And now you force existing qemu code to go back to open coded lists,
which is arguably a step backwards. I don't think this is any better
than forcing the (non-existent) users of libqmp to include one
additional header file.

Kevin

  reply	other threads:[~2011-03-15 13:49 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
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 [this message]
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=4D7F6EF3.2010504@redhat.com \
    --to=kwolf@redhat.com \
    --cc=agl@us.ibm.com \
    --cc=anthony@codemonkey.ws \
    --cc=armbru@redhat.com \
    --cc=chrisw@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@linux.vnet.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.