qemu-devel
[Top][All Lists]
Advanced

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

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] [Qemu-block] [RFC] QMP design: Fixing query-block and friends
Date: Thu, 29 Jun 2017 09:23:36 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

John Snow <address@hidden> writes:

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

Such spontaneous API change is bad magic, I'm afraid.  It also sabotages
the value of query-qmp-schema.

What we could do is enrich query-qmp-schema with deprecation
information, and let clients request a compatibility level.  Requesting
a level we no longer provide fails.  Default is the oldest level we
provide.  Clients relying on a stable interface would be well adviced to
request the one they need.



reply via email to

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