John Snow <js...@redhat.com> writes: > A note: > > qmp-shell could offer some sugared versions of things like "query-block" > that do some work understanding the reply from QEMU and printing it in a > nice human format.
This is exactly how HMP commands should work. By moving them to qmp-shell, we get to code them in qmp-shell's language (Python, I guess) rather than C. I think we need to decide what qmp-shell's mission should be: is it a better socat for the QMP monitor, or a replacement for the traditional HMP monitor? You may answer "both". It'll complicate things, though. More on that below. > This is generally what I have in mind for things when it's possible: use > "real" QMP interfaces to do the query, and then use qmp-shell code to > display "pretty" results. > > e.g. > >>> query-block > > might execute the raw QMP command and give you back the giant textwall > of gibberish, but perhaps: > >>> ?info block > > would execute query-block behind the scenes, digest the results, and > pretty-print some results. > > These shell-local commands, denoted by the "?" prefix, could be > user-extensible python extensions that simply react to incoming data, > optionally perform extra work, and display results. As long as we develop qmp-shell and QMP together, we don't *have* to separate name spaces. It could simply be "info block". However, consider chardev-add. Example from char.json: -> { "execute" : "chardev-add", "arguments" : { "id" : "baz", "backend" : { "type" : "pty", "data" : {} } } } <- { "return": { "pty" : "/dev/pty/42" } } Here's the HMP equivalent: (qemu) chardev-add pty,id=baz char device redirected to /dev/pts/16 (label baz) With your proposed "?" prefix, the straightforward way to run chardev-add gives your the (thankfully non-giant) textwall of gibberish. If you stick in a "?" and change the "-" to "_", you get the pretty-printed version. Not exactly the kind of UX we strive for, I'm afraid, even if we fix the '-' vs. '_' nonsense. If qmp-shell aims to be a better socat for the QMP monitor, then "?info block" is out of scope, and so is pretty-printed chardev-add. If qmp-shell aims to replace HMP, then query-block is out of scope, and so is JSON-printing chardev-add. Also, "qmp-shell" is a misnomer. If qmp-shell aims to do both, we need to try harder :) Kevin mentioned another way to provide HMP-like functionality in qmp-shell: "have a QMP mode and an HMP mode and the user can switch between these modes." > Otherwise, for commands where this is too laborious, too intensive, or > just not worth it -- but we cannot be rid of them -- I like Dan's idea > of just offering e.g. > > 'x-debug-foo' and returning big text blobs, so we don't have to waste > any brain-calories on devising a properly structured response. To actually replace HMP, we'll want such commands. > Actually, we can even use the featureflags to tag such commands as e.g. > "human-ui-only" and could conditionally compile them out for enterprise > deployments where poor behavior WRT synchronicity is a security liability. Everybody knows enterprise deployments always work, and always perform perfectly. Commands for debugging and monitoring them are quite superfluous ;-P