[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 11/11] [WIP] block: Implement 'blockdev-add'
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [RFC PATCH 11/11] [WIP] block: Implement 'blockdev-add' QMP command |
Date: |
Fri, 12 Jul 2013 08:27:09 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 |
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
Re: [Qemu-devel] [RFC PATCH 00/11] qapi changes in preparation for blockdev-add, Laszlo Ersek, 2013/07/12