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