qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH V4 4/7] qmp: Allow to change password on names b


From: Kevin Wolf
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
User-agent: Mutt/1.5.21 (2010-09-15)

Am 09.12.2013 um 17:41 hat Luiz Capitulino geschrieben:
> On Mon, 9 Dec 2013 17:23:09 +0100
> Kevin Wolf <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]