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
