qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: famz@redhat.com, "Benoît Canet" <benoit@irqsave.net>,
	jcody@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org,
	stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH V4 4/7] qmp: Allow to change password on names block driver states.
Date: Tue, 10 Dec 2013 10:57:50 +0100	[thread overview]
Message-ID: <20131210095750.GC3656@dhcp-200-207.str.redhat.com> (raw)
In-Reply-To: <20131209114109.1c4a8d5f@redhat.com>

Am 09.12.2013 um 17:41 hat Luiz Capitulino geschrieben:
> On Mon, 9 Dec 2013 17:23:09 +0100
> Kevin Wolf <kwolf@redhat.com> wrote:
> 
> > > > I'm leaning slightly towards the approach that Benoît took, if only for
> > > > the naming aspect (that is, I also thought of the idea of a bool flag,
> > > > but didn't suggest it because I didn't like the implications on the
> > > > naming).  But I can live with either approach, if anyone else has a
> > > > strong opinion.
> > > 
> > > Well, we can pick up any descriptive name 'treat-device-as-a-node',
> > > 'device-is-a-graph-node'...
> > 
> > All devices are represented by nodes, so that doesn't make sense.
> > If anything, 'interpret-device-name-as-node-name', which at the same
> > time makes it pretty clear that we're abusing a field for something it
> > wasn't meant for.
> 
> Having two optionals where they can't be specified at the same time
> and can't be left off at the same time is a clear abuse as well.

Is it? If you wanted to express this in the schema, we'd need to extend
the QAPI generator, but until now we never have. I don't think this is
the first time that optional fields are not completely independent, but
may be required/forbidden based on values of other fields. Documenting
it should be enough, in my opinion.

> The truth is, both proposals are bad. This makes me think that maybe
> we should introduce a block API 2.0 and deprecate the current one
> (partly or completely).

Nice try, but of course this is equivalent to the "new command"
solution.  Deprecating the old version doesn't get you rid of it, you
still need to support it for compatibility. And then you're back to
square one.

For what it's worth, I think what Benoît implemented is the outcome of
discussions of the Block BOF on KVM Forum that included both block layer
developers and API users (i.e. libvirt), after considering and
dismissing other options (which, of course, included separate commands).

Kevin

  parent reply	other threads:[~2013-12-10  9:59 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-05 17:14 [Qemu-devel] [PATCH V4 0/7] Giving names to BlockDriverState graph nodes Benoît Canet
2013-12-05 17:14 ` [Qemu-devel] [PATCH V4 1/7] block: Add bs->node_name to hold the name of a bs node of the bs graph Benoît Canet
2013-12-09 16:04   ` Kevin Wolf
2013-12-09 16:11   ` Kevin Wolf
2013-12-05 17:14 ` [Qemu-devel] [PATCH V4 2/7] block: Allow the user to define "node-name" option Benoît Canet
2013-12-06 15:35   ` Eric Blake
2013-12-09 16:15   ` Kevin Wolf
2013-12-11 14:42     ` Benoît Canet
2013-12-05 17:14 ` [Qemu-devel] [PATCH V4 3/7] qmp: Add a command to list the named BlockDriverState nodes Benoît Canet
2013-12-06 15:59   ` Eric Blake
2013-12-09 15:46     ` Benoît Canet
2013-12-10 15:22       ` Eric Blake
2013-12-05 17:15 ` [Qemu-devel] [PATCH V4 4/7] qmp: Allow to change password on names block driver states Benoît Canet
2013-12-06 14:27   ` Luiz Capitulino
2013-12-06 15:24     ` Eric Blake
2013-12-06 16:52       ` Luiz Capitulino
2013-12-09 13:35         ` Benoît Canet
2013-12-09 16:23         ` Kevin Wolf
2013-12-09 16:41           ` Luiz Capitulino
2013-12-09 16:48             ` Benoît Canet
2013-12-09 17:03               ` Luiz Capitulino
2013-12-09 17:16                 ` Benoît Canet
2013-12-10  9:57             ` Kevin Wolf [this message]
2013-12-10 14:06               ` Luiz Capitulino
2013-12-10 14:25                 ` Kevin Wolf
2013-12-10 15:16                   ` Luiz Capitulino
2013-12-10 15:54                     ` Kevin Wolf
2013-12-10 16:15                     ` Eric Blake
2013-12-11  3:52                     ` Fam Zheng
2013-12-11 13:20                       ` Luiz Capitulino
2013-12-05 17:15 ` [Qemu-devel] [PATCH V4 5/7] qmp: Allow block_resize to manipulate bs graph nodes Benoît Canet
2013-12-09 16:24   ` Kevin Wolf
2013-12-09 16:41     ` Benoît Canet
2013-12-10  9:59       ` Kevin Wolf
2013-12-05 17:15 ` [Qemu-devel] [PATCH V4 6/7] block: Create authorizations mechanism for external snapshots Benoît Canet
2013-12-05 17:15 ` [Qemu-devel] [PATCH V4 7/7] qmp: Allow to take external snapshots on bs graphs node Benoît Canet
2013-12-09 15:32 ` [Qemu-devel] [PATCH V4 0/7] Giving names to BlockDriverState graph nodes Kevin Wolf
2013-12-09 15:52   ` Benoît Canet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131210095750.GC3656@dhcp-200-207.str.redhat.com \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=benoit@irqsave.net \
    --cc=famz@redhat.com \
    --cc=jcody@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).