qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 12/13] qapi: support for keyworded variable-leng


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 12/13] qapi: support for keyworded variable-length argument list
Date: Thu, 29 Mar 2012 13:53:45 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0

On 03/29/2012 01:42 PM, Luiz Capitulino wrote:
On Thu, 29 Mar 2012 13:26:34 -0500
Anthony Liguori<address@hidden>  wrote:

On 03/29/2012 12:26 PM, Luiz Capitulino wrote:
This allows for QAPI functions to receive a variable-length argument
list. This is going to be used by device_add and netdev_add commands.

In the schema, the argument list is represented by type name '**',
like this example:

      { 'command': 'foo', 'data': { 'arg-list': '**' } }

Each argument is represented by the KeyValues type and the C
implementation should expect a KeyValuesList, like:

      void qmp_foo(KeyValuesList *values_list, Error **errp);

XXX: This implementation is simple but very hacky. We just iterate
       through all arguments and build the KeyValuesList list to be
       passed to the QAPI function.

       Maybe we could have a kwargs type, that does exactly this but
       through a visitor instead?

Signed-off-by: Luiz Capitulino<address@hidden>

What about just treating '**' as "marshal remaining arguments to a string" and
then pass that string to device_add?  qmp_device_add can then parse that string
with QemuOpts.

If this turns out to be simple enough, I'm fine with it.

I don't love doing this sort of double conversion but it's really the only practical way to do it I think. device_add has a weird semantic where printing/parsing is implied so I think it's unavoidable.

It's a bit ugly, but that's how things worked.  When we introduce qom_add, this
problem goes away because you would make multiple calls to qom_set to set all of
the properties.

Just out of curiosity, is qom_add going to supersede device_add?

Eventually...

I'd like to see qom_add as the low level interface but then I'd like to see nice high level interfaces like 'block_add' which took a parameter of virtio-blk and did all of the magic to create a block device in such a way that's compliant to the current machine type.

Regards,

Anthony Liguori





reply via email to

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