[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.
Re: [Qemu-devel] [Qemu-block] [RFC] QMP design: Fixing query-block and friends, Alberto Garcia, 2017/06/30