On 03/29/2012 01:42 PM, Luiz Capitulino wrote:
On Thu, 29 Mar 2012 13:26:34 -0500
Anthony Liguori<aligu...@us.ibm.com> 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<lcapitul...@redhat.com>
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
