Re: [Qemu-devel] BB name vs. BDS name in the QAPI schema

[Fam Zheng]

On Mon, 09/15 10:59, Kevin Wolf wrote:
> Am 15.09.2014 um 03:31 hat Fam Zheng geschrieben:
> > On Sat, 09/13 19:04, Markus Armbruster wrote:
> > > 
> > > I actually like having separate parameters for separate kinds of names.  
> > > 
> > > However, BlockdevRef appears to tie our hand: it's an anonymous union,
> > > which means only the value is on the wire, and the receiving end uses
> > > its type to determine which union member it is.  Both kinds of names are
> > > strings, so we can't have separate union members for them.
> > > 
> > > Opinions?
> > 
> > Why wouldn't it work without distinguishing it in the QAPI side?
> 
> BlockRef takes either a string referring to an existing BDS (using
> device_name or node-name) or a dict of options for creating a new one.
> 
> > I remember at the time of introducing node-name, it was in a separate
> > namespace, but now it's not. Then why should the user care *whether* a name 
> > is
> > "device" or "node-name"?
> 
> When you reconfigure the graph (e.g. by taking a live snapshot), the BB
> name always stays at the root (i.e. points to the new BDS), whereas the
> node-name always stays at the same node (which was at the root, but
> isn't any more), that's probably important for the user. Maybe a bit
> like branches and tags in git.

Yes, good point! We shouldn't complicate the interface in terms of specifying
the operation object, but this device name behavior consistency should be well
documented independently.

Thanks for explaining!

> 
> So yes, they are somewhat different, but in the end they all resolve to
> a BDS and it makes sense to allow accessing them in a uniform way (just
> like 'git show <tag-name>' works the same as 'git show <branch-name>').
> 
> Which leads me to this conclusion: One mandatory string argument per
> command is enough, and also results in a cleaner interface than having
> two optional arguments that aren't truly optional because you need to
> specify the one xor the other.

Yes, I second that.

Fam