Marc-André Lureau <marcandre.lureau@xxxxxxxxx> writes: > Hi > > On Tue, Mar 17, 2020 at 12:55 PM Markus Armbruster <armbru@xxxxxxxxxx> wrote: >> >> This series extends QMP introspection to cover deprecation. >> Additionally, new option -compat lets you configure what to do when >> deprecated interfaces get used. This is intended for testing users of >> the management interfaces. It is experimental. >> >> -compat deprecated-input=<in-policy> configures what to do when >> deprecated input is received. Available policies: >> >> * accept: Accept deprecated commands and arguments (default) >> * reject: Reject them >> * crash: Crash >> >> -compat deprecated-output=<out-policy> configures what to do when >> deprecated output is sent. Available output policies: >> >> * accept: Emit deprecated command results and events (default) >> * hide: Suppress them >> >> For now, -compat covers only deprecated syntactic aspects of QMP. We >> may want to extend it to cover semantic aspects, CLI, and experimental >> features. > > I suggest to use a qmp- prefix for qmp-related policies. The interface is general. The implemented infrastructure is QAPI-only. Its application is QMP-only. If our CLI was QAPIfied, I'd certainly apply it there, too. I intend to resume exploring CLI QAPIfication "real soon now". Not covering CLI now is a bit like not covering semantic aspects of QMP. Imagine the thing covered CLI. Would we want to have separate -compat deprecated-qmp-input, deprecated-cli-input? I doubt it. I think we want a single policy for all host interfaces. Imagine it covered deprecated semantic aspects of QMP. Would we want to have a separate flag for that? Again, I doubt it. For what it's worth, the interface is documented as experimental.
