Re: [Qemu-devel] Re: [RFC] QCFG: a new mechanism to replace QemuOpts and option handling

[Markus Armbruster <armbru@redhat.com>]

Anthony Liguori <anthony@codemonkey.ws> writes:

> On 03/17/2011 10:26 AM, Markus Armbruster wrote:
>> Kevin Wolf<kwolf@redhat.com>  writes:
>>
>>> 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.
>> Don't even think of trees.  Yuck.
>
> Sorry, don't fully understand.  The above data structure is a tree.

The next pointer that is "a standard part of QAPI" provides for a single
list membership, no more.  The criticism isn't that you can't build
trees in QAPI (you can).  It's that there's one special list.  Doesn't
feel right for a general purpose interface.  But it really depends on
how it's used.  Anyway, this belongs into the QAPI thread, not here.

> I haven't looked yet at converting the code generator to use the
> qemu-queue structures.  I'm not sure I agree it's the right thing to
> do but I don't think it's all that hard.

Depends on how the list is used.  If all uses are known (say because
they're all behind the interface), and limited to trivial pointer
chasing, then qemu-queue.h may well be more trouble than it's worth.