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: Mon, 9 Dec 2013 17:23:09 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Am 06.12.2013 um 17:52 hat Luiz Capitulino geschrieben:
> On Fri, 06 Dec 2013 08:24:33 -0700
> Eric Blake <address@hidden> wrote:
> 
> > On 12/06/2013 07:27 AM, Luiz Capitulino wrote:
> > > On Thu,  5 Dec 2013 18:15:00 +0100
> > > Benoît Canet <address@hidden> wrote:
> > 
> > >> -{ 'command': 'block_passwd', 'data': {'device': 'str', 'password': 
> > >> 'str'} }
> > >> +{ 'command': 'block_passwd', 'data': {'*device': 'str',
> > >> +                                      '*node-name': 'str', 'password': 
> > >> 'str'} }
> > > 
> > > What about:
> > > 
> > > { 'command': 'block_passwd', 'data': {'device': 'str',
> > >                                       '*device-is-node': 'bool', 
> > > 'password': 'str'} }
> > 
> > That would also work; the naming is a bit more awkward, but then you
> > don't have the issue of mutually-exclusive optional arguments where
> > exactly one of the two arguments is required.
> 
> Yes, and I dislike that very much.
> 
> Btw, can anyone remind me why we can't have new commands instead?

Because having to maintain two commands for the same functionality is
bad.

> > 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.

Kevin



reply via email to

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