From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:54172)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1XTS7v-0001Dm-FC
	for qemu-devel@nongnu.org; Mon, 15 Sep 2014 04:59:21 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1XTS7p-0005QV-AB
	for qemu-devel@nongnu.org; Mon, 15 Sep 2014 04:59:15 -0400
Received: from mx1.redhat.com ([209.132.183.28]:9542)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1XTS7p-0005Oo-2B
	for qemu-devel@nongnu.org; Mon, 15 Sep 2014 04:59:09 -0400
Date: Mon, 15 Sep 2014 10:59:01 +0200
From: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20140915085901.GA5236@noname.str.redhat.com>
References: <8738bvv4dm.fsf@blackfin.pond.sub.org>
	<20140915013158.GA2639@fam-t430.nay.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140915013158.GA2639@fam-t430.nay.redhat.com>
Subject: Re: [Qemu-devel] BB name vs. BDS name in the QAPI schema
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Fam Zheng <famz@redhat.com>
Cc: qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>, Luiz Capitulino <lcapitulino@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, =?iso-8859-1?Q?Beno=EEt?= Canet <benoit.canet@nodalink.com>

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.

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.

Kevin