Re: [Qemu-devel] How to introduce bs->node_name ?

[Eric Blake]

On 10/30/2013 07:49 AM, Markus Armbruster wrote:

> 
> The first proposal is to add another parameter, say "id".  Users can
> then refer either to an arbitrary BDS by "id", or (for backward
> compatibility) to the root BDS by "device".  When the code sees
> "device", it'll look up the BB, then fetch its root BDS.
> 
> CON: Existing parameter "device" becomes compatibility cruft.
> 
> PRO: Clean and obvious semantics (in my opinion).

I like this one as well.

> 
> The second proposal is to press the existing parameter "device" into
> service for referring to BDS node_name.
> 
> To keep backward compatibility, we obviously need to ensure that
> whenever the old code accepts a value of "device", the new code accepts
> it as well, and both resolve it to the same BDS.
> 
> What about situations where the old code rejects a value of "device"?
> The new code may resolve it to a non-root BDS that happens to have that
> ID...
> 
> What about dynamic reconfiguration changing the root?  Example: a
> synchronous snapshot splices in a QCOW2, which becomes the new root.  In
> the current code, device_name refers to the new root.  Wouldn't that
> require the BDS ID of the old root moves to the new root?  But that
> would mean BDS IDs change!

Having device_name tied to the BB, and ID tied to each BDS, seems much
more workable in the long run.

>> My personnal suggestion would be that non specified node-name would be set to
>> "undefined" meaning that no operation could occur on this bs.
> 
> Yes, that's how IDs work elsewhere.

Agreed.

> [QMP and HMP code using bdrv_find() snipped]
> 
> I think we should review with the QMP schema first, code second.

Yes, get the interface right, and then it's easier to review the code
that implements the interface.

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

signature.asc
Description: OpenPGP digital signature