Re: [Qemu-devel] [RFC PATCH 11/11] [WIP] block: Implement 'blockdev-add' QMP command

[Eric Blake]

On 07/12/2013 03:40 AM, Kevin Wolf wrote:

>>> +
>>> +{ 'command': 'blockdev-add', 'data': { 'options': 'BlockOptions' } }
>>
>> Sounds nice - and seems like it should be easy enough to extend BlockRef
>> and/or BlockOptions to have a way to pass an fd even for backing files,
>> getting to (my) end goal of using fd passing to get SELinux labeling for
>> NFS files out of the box from libvirt.
> 
> In fact, I think it might be a schema-only patch at this point. :-)
> 
>> Should this command return anything?  For example, returning a
>> BlockDeviceInfo (with its recursive listing of the entire backing chain)
>> might be useful to check that qemu's view of the world matches what the
>> caller passed in.  Particularly important if we are able to let the user
>> choose whether to pass the full chain or to just pass the top-most image
>> and let qemu chase down the metadata in that image to open additional
>> files for the rest of the chain.
> 
> Does it matter for you to have this immediately as a return value from
> blockdev-add, or wouldn't a following query-block on this device achieve
> the same?

Yeah, that will probably work.  We have a couple *-add that return
useful values, but that was so we didn't have to introduce a separate
query at the time.  But here, we already have the query, and for a
deeply nested struct, that's a lot of information to generate for
callers that don't care, and callers that do care can do a double call.

> 
> I'm not against adding a return value when it's useful, but I don't think
> we should just return arbitrary query-* results if we can't think of
> anything else to return.

It should always be possible to upgrade from {} to actual struct
contents in a later release, should the need arise.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature