qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [RFC] QMP design: Fixing query-block and f


From: John Snow
Subject: Re: [Qemu-block] [Qemu-devel] [RFC] QMP design: Fixing query-block and friends
Date: Wed, 28 Jun 2017 12:00:49 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0


On 06/28/2017 03:15 AM, Markus Armbruster wrote:
> John Snow <address@hidden> writes:
> 
>> On 06/27/2017 12:31 PM, Kevin Wolf wrote:
>>> Hi,
>>>
>>> I haven't really liked query-block for a long time, but now that
>>> blockdev-add and -blockdev have settled, it might finally be the time to
>>> actually do something about it. In fact, if used together with these
>>> modern interfaces, our query commands are simply broken, so we have to
>>> fix something.
>>>
>>
>> [...words...]
>>
>>>
>>> So how do we go forward from here?
>>>
>>> I guess we could add a few hacks o fix the really urgent things, and
>>> just adding more information is always possible (at the cost of even
>>> more duplication).
>>>
>>
>> I think you've included this suggestion so that you can summarily
>> dismiss it as foolish.
>>
>>> However, it appears to me that I dislike so many thing about our current
>>> query commands that I'm tempted to say: Throw it all away and start
>>> over.
>>>
>>
>> Inclined to agree. The structure of the block layer has changed so much
>> in the past few years and this is easily seen by the gap you've outlined
>> here.
>>
>> We have to keep the old query commands around for a while as Eric says,
>> but I worry that they are so wrong and misleading as to be actively harmful.
>>
>> Maybe there's some hair trigger somewhere that if $NEW_FEATURE_X is used
>> to configure QEMU in some way, that the old commands can be deprecated
>> at runtime, such that we can more aggressively force their retirement.
> 
> We warn on use of deprecated command line and HMP features.  I think we
> want the same for QMP, within QMP.
> 
> [...]
> 

I was thinking of something even stronger than a warning in this case.
Warn if you use it anyway, but if you use $SOME_2.10_FEATURE, it
actually disables it.

"Hi, I know that you have seen the 2.10 API. I'm removing access to this
feature, because you REALLY ought not use it."

Could be as simple as actually disabling the old query command if the
new query command is utilized.

--js



reply via email to

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