From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45198) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqK5n-0002oP-N2 for qemu-devel@nongnu.org; Tue, 10 Dec 2013 04:59:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VqK5h-00023L-IG for qemu-devel@nongnu.org; Tue, 10 Dec 2013 04:59:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37580) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqK5h-00023F-94 for qemu-devel@nongnu.org; Tue, 10 Dec 2013 04:58:57 -0500 Date: Tue, 10 Dec 2013 10:57:50 +0100 From: Kevin Wolf Message-ID: <20131210095750.GC3656@dhcp-200-207.str.redhat.com> References: <1386263703-19292-1-git-send-email-benoit@irqsave.net> <1386263703-19292-5-git-send-email-benoit@irqsave.net> <20131206092703.5d60345a@redhat.com> <52A1EC31.7000709@redhat.com> <20131206115215.0427a956@redhat.com> <20131209162309.GJ3549@dhcp-200-207.str.redhat.com> <20131209114109.1c4a8d5f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20131209114109.1c4a8d5f@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH V4 4/7] qmp: Allow to change password on names block driver states. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: famz@redhat.com, =?iso-8859-1?Q?Beno=EEt?= Canet , jcody@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com Am 09.12.2013 um 17:41 hat Luiz Capitulino geschrieben: > On Mon, 9 Dec 2013 17:23:09 +0100 > Kevin Wolf wrote: >=20 > > > > I'm leaning slightly towards the approach that Beno=EEt 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 t= he > > > > naming). But I can live with either approach, if anyone else has= a > > > > strong opinion. > > >=20 > > > Well, we can pick up any descriptive name 'treat-device-as-a-node', > > > 'device-is-a-graph-node'... > >=20 > > 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 i= t > > wasn't meant for. >=20 > 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=EEt 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