[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Markus Armbruster
Subject: Re: [Qemu-devel] Re: [RFC] QCFG: a new mechanism to replace QemuOpts and option handling
Date: Thu, 17 Mar 2011 16:26:30 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Kevin Wolf <address@hidden> 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.

>>>   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.

Agree.  Let's not screw up our internal interfaces for the sake of an
external interface that may or may not turn out to be viable.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]