John Snow <js...@redhat.com> writes: > On 06/28/2017 03:15 AM, Markus Armbruster wrote: >> John Snow <js...@redhat.com> 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.
