From: Markus Armbruster <armbru@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Denis V. Lunev" <den@virtuozzo.com>,
"Cleber Rosa" <cleber@redhat.com>,
"Stefan Hajnoczi" <stefanha@gmail.com>,
qemu-devel <qemu-devel@nongnu.org>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Dominik Csapak" <d.csapak@proxmox.com>,
"Eduardo Habkost" <ehabkost@redhat.com>
Subject: Re: Making QEMU easier for management tools and applications
Date: Tue, 28 Jan 2020 11:16:16 +0100 [thread overview]
Message-ID: <87y2trdgy7.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <bd4a2839-69d6-697b-dc07-567ba08ce044@redhat.com> (John Snow's message of "Mon, 27 Jan 2020 15:59:14 -0500")
John Snow <jsnow@redhat.com> writes:
> On 1/27/20 9:35 AM, Kevin Wolf wrote:
>> Am 24.01.2020 um 10:50 hat Daniel P. Berrangé geschrieben:
>>> On Thu, Jan 23, 2020 at 04:07:09PM -0500, John Snow wrote:
>>>> Well, sure. The context of this email was qmp-shell though, which is
>>>> meant to help facilitate the entry of JSON commands so that you *can*
>>>> indeed just forego the CLI/HMP entirely.
>>>>
>>>> If you are of the opinion that every user of QEMU should be copy/pasting
>>>> JSON straight into a socket and we should delete qmp-shell, that's
>>>> certainly a fine opinion.
>>>
>>> I think part of the pain of qmp-shell comes from the very fact that
>>> it is trying to be an interactive shell. This points people towards
>>> interactively typing in the commands, which is horrific when you get
>>> anywhere near the JSON, or even dot-notation traditional commands.
>>>
>>> If it was just a qmp-client that was single shot, we'd encourage
>>> people to create the JSON in a sensible way - vim/emacs/whatever.
>>
>> I don't see how this is sensible. QMP commands are something that I
>> reuse even less than VM configurations, so creating a one-off file for
>> each would take me a lot more time and I would still have to type the
>> same JSON code that I have to type with -qmp stdio.
>>
>> The reason it is and should be an interactive shell is that I'm
>> interacting with it. Switching back and forth between a text editor and
>> a shell to actually send the command to QEMU would make things only even
>> more cumbersome than they already are.
>>
>>> Bash/dash/zsh/$whatever is their interactive shell, with massively
>>> more features than qmp-shell. You have command history, autocomplete,
>>> conditional and looping constructs, and everything a normal shell
>>> offers.
>>
>> If I wanted to program a QMP client, I would use Python. For me,
>> conditionals and loops are completely out of scope for a QMP shell. I
>> just want an easy way to tell QEMU to do something specific.
>>
>> A command history already exists for qmp-shell. It's better than bash
>> because it doesn't mix QMP history with whatever else I do on my
>> computer.
>>
>> Autocomplete in qmp-shell doesn't exist, as far as I know, but if
>> implemented, it could be a lot more useful than bash completion because
>> it could offer key completion based on the QMP schema.
>>
>
> It does have tab completion for command names, but it does not know
> about or remember argument fields. It does not have autocomplete or
> typing hints like FiSH or bash ^r.
>
> I would like to change this, actually, by making the docstrings in QAPI
> schema a first class citizen of the spec and allowing them to be
> introspectable via the socket directly.
>
> (I.e., you can get the list of arguments and the docstrings that
> accompany them over the wire so you can display it in the client.)
You need doc strings for help, but not for completion.
query-qmp-schema's reply is already rather big: 130KiB.
The size of docs in an JSON encoding useful to qmp-shell we can only
estimate. Plain text docs/interop/qemu-qmp-ref.txt is 505KiB.
I guess we'd make the doc strings optional.
> Problem I'm having with qmp-shell is, like Kevin says below ...
>
>> This is in fact a big part of the problem that qmp-shell really needs to
>> solve before it can replace HMP: How to make writing commands at least
>> almost as simple as with HMP. If I can just press tab a few times to
>> cycle through the available options for the command, that would already
>> be a massive improvement over writing JSON manually (which you would
>> still have to do with your text-file based approach, without any
>> QMP-specific support).
>>
>
> ... I can't figure out how to make writing commands simple.
>
> When you have a "simple" command, the abstraction works OK; you can type
> key=val pairs and go about your way.
qmp-shell tries to improve on the JSON syntax by inventing its own,
but...
> As soon as you have anything nested, the gossamer-thin illusion is
> destroyed.
... it does a halfhearted job.
I'm deeply skeptical of any solution that starts with inventing a
new language. Start with examining existing ones instead.
> I investigated making this a little easier by adding a parser
> that could read directly from stdin and would allow multi-line JSON
> inputs as arguments.
>
> (Like the python shell does it, for example: When you have a dictionary
> opening brace, it lets you continue to the next line.)
>
> I was a little disheartened that most JSON parsers in python expect to
> consume buffered objects and generally consume the entire buffer -- it
> didn't seem to play nice with the idea of wanting to parse from STDIN
> directly.
>
>
> So:
>
> - I think qmp-shell is worth having, especially if polished
> (autocomplete, docstrings, argument hints, etc).
>
> - Kevin mentioned getting this into the GTK shell. I think that would be
> great, as a step to help phase out HMP.
>
> - I think getting rid of HMP is good because I don't care for the idea
> of supporting two monitor protocols. One schema, one parser, one truth.
>
> - I do, however, like the idea of having a non-rigorous monitor that
> lets us get away with murder when we need to. HMP is useful for
> debugging, prototypes and other things where the rigor and permanence of
> a QAPI schema feels too burdensome.
We discussed relaxing the rules for such QMP commands. In particular,
they could return just a string. Fine with me as long as we make
perfectly clear these commands are not stable interfaces.
> - So: maybe a turbocharged qmp-shell can offer some similar kinds of
> convenience commands that are build on top of real QMP. Sugar logic and
> other fanciful things could be implemented there in qmp-shell as
> extensions. You'd get a stock pile of them with your QEMU install that
> help you do certain tasks quickly and trivially.
>
> - Given all the above, I am willing to try to save, polish, or re-design
> qmp-shell; but am a bit starved for ideas on the syntax... This is why I
> was spending a bit of time talking about our flattening to dot syntax,
> and other projects related to representing hierarchical data.
>
> Would really love to hear ideas on what a good interactive shell syntax
> for a JSON-fueled schema would look like.
We can't possibly be the first ones asking this question.
> Any prior art, other projects, and reading anyone can recommend would be
> nice.
[...]
next prev parent reply other threads:[~2020-01-28 10:17 UTC|newest]
Thread overview: 183+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-20 16:13 Making QEMU easier for management tools and applications Stefan Hajnoczi
2019-12-20 21:07 ` Richard W.M. Jones
2020-01-02 11:26 ` Stefan Hajnoczi
2019-12-21 9:02 ` Markus Armbruster
2019-12-23 15:04 ` Michal Prívozník
2020-01-07 9:36 ` Kevin Wolf
2020-01-07 10:55 ` Michal Privoznik
2020-01-07 12:57 ` Kevin Wolf
2020-01-07 17:53 ` Christophe de Dinechin
2019-12-24 13:41 ` Daniel P. Berrangé
2020-01-22 22:28 ` John Snow
2020-01-23 7:19 ` Markus Armbruster
2020-01-23 17:58 ` John Snow
2020-01-23 19:01 ` Daniel P. Berrangé
2020-01-23 21:07 ` John Snow
2020-01-24 7:59 ` Markus Armbruster
2020-01-24 10:27 ` Daniel P. Berrangé
2020-01-24 14:38 ` Kevin Wolf
2020-01-24 18:23 ` John Snow
2020-01-24 18:30 ` Dr. David Alan Gilbert
2020-01-24 18:48 ` John Snow
2020-01-24 18:52 ` Dr. David Alan Gilbert
2020-01-24 18:58 ` John Snow
2020-01-25 10:18 ` Markus Armbruster
2020-01-27 10:18 ` Daniel P. Berrangé
2020-01-27 12:48 ` Markus Armbruster
2020-01-27 11:56 ` Kevin Wolf
2020-01-27 12:04 ` Peter Maydell
2020-01-27 20:11 ` John Snow
2020-01-27 22:38 ` Paolo Bonzini
2020-01-28 0:37 ` John Snow
2020-01-28 10:16 ` Daniel P. Berrangé
2020-01-28 10:39 ` Kevin Wolf
2020-01-28 15:36 ` Markus Armbruster
2020-01-31 12:25 ` Eric Blake
2020-01-28 10:28 ` Kevin Wolf
2020-01-28 12:36 ` Markus Armbruster
2020-01-28 12:54 ` Kevin Wolf
2020-01-28 13:45 ` Gerd Hoffmann
2020-01-31 6:50 ` Markus Armbruster
2020-01-31 7:48 ` Paolo Bonzini
2020-01-31 8:09 ` Markus Armbruster
2020-02-03 20:07 ` Andrea Bolognani
2020-02-04 9:58 ` Markus Armbruster
2020-01-31 12:27 ` Eric Blake
2020-02-02 9:21 ` Kevin Wolf
2020-02-02 10:44 ` Paolo Bonzini
2020-02-03 6:20 ` Markus Armbruster
2020-02-03 8:48 ` Markus Armbruster
2020-01-27 20:12 ` Dr. David Alan Gilbert
2020-01-24 20:34 ` John Snow
2020-01-27 8:35 ` Gerd Hoffmann
2020-01-27 12:13 ` Kevin Wolf
2020-01-27 16:18 ` Gerd Hoffmann
2020-01-24 9:50 ` Daniel P. Berrangé
2020-01-25 11:52 ` Paolo Bonzini
2020-01-27 10:05 ` Daniel P. Berrangé
2020-01-27 8:25 ` Tooling to help humans use JSON (was: Making QEMU easier for management tools and applications) Markus Armbruster
2020-01-27 9:06 ` Making QEMU easier for management tools and applications Markus Armbruster
2020-01-27 10:00 ` Daniel P. Berrangé
2020-01-27 14:35 ` Kevin Wolf
2020-01-27 20:29 ` Dr. David Alan Gilbert
2020-01-28 10:59 ` Kevin Wolf
2020-02-05 13:09 ` Kevin Wolf
2020-02-05 19:09 ` qmp-shell for GSoC/Outreachy? (Was: Re: Making QEMU easier for management tools and applications) John Snow
2020-02-05 19:49 ` Dr. David Alan Gilbert
2020-02-06 9:40 ` qmp-shell for GSoC/Outreachy? Markus Armbruster
2020-02-06 10:09 ` Daniel P. Berrangé
2020-02-06 12:11 ` Markus Armbruster
2020-02-06 12:15 ` Daniel P. Berrangé
2020-02-06 18:02 ` Dr. David Alan Gilbert
2020-02-07 21:03 ` John Snow
2020-02-08 7:17 ` Markus Armbruster
2020-02-06 14:21 ` Kevin Wolf
2020-02-06 18:26 ` Dr. David Alan Gilbert
2020-02-07 10:49 ` Kevin Wolf
2020-02-07 21:23 ` John Snow
2020-02-08 7:25 ` Markus Armbruster
2020-02-10 11:59 ` Kevin Wolf
2020-02-10 12:26 ` Kevin Wolf
2020-02-06 18:18 ` Dr. David Alan Gilbert
2020-02-07 7:47 ` Markus Armbruster
2020-02-07 21:31 ` Eric Blake
2020-02-08 7:34 ` Markus Armbruster
2020-02-07 21:56 ` John Snow
2020-02-07 20:56 ` John Snow
2020-01-27 20:59 ` Making QEMU easier for management tools and applications John Snow
2020-01-28 10:16 ` Markus Armbruster [this message]
2020-01-28 19:21 ` John Snow
2020-01-24 6:38 ` Markus Armbruster
2020-01-25 22:34 ` Christophe de Dinechin
2020-01-25 11:55 ` Paolo Bonzini
2020-01-02 14:47 ` Stefan Hajnoczi
2020-01-16 11:03 ` Kashyap Chamarthy
2020-01-20 9:55 ` Stefan Hajnoczi
2020-01-20 13:57 ` Kashyap Chamarthy
2020-01-25 11:41 ` Paolo Bonzini
2020-01-27 19:41 ` John Snow
2020-01-02 15:05 ` Dr. David Alan Gilbert
2020-01-13 13:44 ` Markus Armbruster
2019-12-24 13:00 ` Daniel P. Berrangé
2020-01-02 14:22 ` Stefan Hajnoczi
2020-01-22 22:42 ` John Snow
2020-01-23 7:21 ` Markus Armbruster
2020-01-23 10:27 ` Daniel P. Berrangé
2020-01-23 18:13 ` John Snow
2020-01-23 19:12 ` Daniel P. Berrangé
2020-01-02 15:10 ` Dr. David Alan Gilbert
2020-01-07 17:11 ` Christophe de Dinechin
2020-01-08 10:43 ` Kevin Wolf
2020-01-08 11:40 ` Christophe de Dinechin
2020-01-08 13:38 ` Kevin Wolf
2020-01-14 13:04 ` Markus Armbruster
2020-01-14 17:31 ` Christophe de Dinechin
2020-01-15 9:20 ` Markus Armbruster
2020-01-15 9:34 ` Christophe de Dinechin
2020-01-15 12:15 ` Markus Armbruster
2020-01-15 12:19 ` Daniel P. Berrangé
2020-01-15 14:02 ` Markus Armbruster
2020-01-30 21:09 ` Improving QOM documentation [Was: Re: Making QEMU easier for management tools and applications] Kashyap Chamarthy
2020-01-31 6:11 ` Markus Armbruster
2020-01-31 7:46 ` Paolo Bonzini
2020-01-31 15:37 ` Christophe de Dinechin
2020-01-31 16:28 ` Paolo Bonzini
2020-01-31 9:50 ` Kashyap Chamarthy
2020-01-31 10:35 ` Peter Maydell
2020-01-31 11:02 ` Paolo Bonzini
2020-01-31 15:22 ` Kashyap Chamarthy
2020-01-31 17:23 ` Markus Armbruster
2020-02-03 8:56 ` Paolo Bonzini
2020-02-03 9:54 ` Markus Armbruster
2020-02-03 15:21 ` Paolo Bonzini
2020-02-04 8:42 ` Markus Armbruster
2020-01-31 16:39 ` Markus Armbruster
2020-01-20 10:08 ` Making QEMU easier for management tools and applications Stefan Hajnoczi
2020-01-21 5:42 ` Markus Armbruster
2020-01-21 11:32 ` Stefan Hajnoczi
2020-01-21 12:03 ` Marc-André Lureau
2020-01-21 13:36 ` Integrating QOM into QAPI (was: Making QEMU easier for management tools and applications) Markus Armbruster
2020-01-21 14:36 ` Daniel P. Berrangé
2020-01-21 15:01 ` Integrating QOM into QAPI Markus Armbruster
2020-01-21 15:11 ` Marc-André Lureau
2020-01-21 16:21 ` Peter Maydell
2020-01-22 5:16 ` Getting whole-tree patches reviewed and merged (was: Integrating QOM into QAPI) Markus Armbruster
2020-02-07 21:53 ` Getting whole-tree patches reviewed and merged Eric Blake
2020-02-10 11:26 ` Paolo Bonzini
2020-02-10 16:04 ` Markus Armbruster
2020-02-10 16:12 ` Peter Maydell
2020-01-22 10:50 ` Integrating QOM into QAPI Alex Bennée
2020-01-22 12:24 ` Markus Armbruster
2020-01-22 12:42 ` Marc-André Lureau
2020-01-22 13:28 ` Peter Maydell
2020-01-22 13:32 ` Marc-André Lureau
2020-01-23 7:37 ` Markus Armbruster
2020-01-24 18:32 ` Paolo Bonzini
2020-01-25 4:44 ` Marc-André Lureau
2020-01-25 9:28 ` Paolo Bonzini
2020-01-25 21:25 ` Peter Maydell
2020-01-26 8:09 ` Christophe de Dinechin
2020-01-26 9:11 ` Marc-André Lureau
2020-01-26 16:47 ` Paolo Bonzini
2020-01-27 19:05 ` Christophe de Dinechin
2020-01-27 19:05 ` Christophe de Dinechin
2020-01-26 15:04 ` Peter Maydell
2020-01-27 19:05 ` Christophe de Dinechin
2020-01-28 8:00 ` Markus Armbruster
2020-01-28 10:03 ` Daniel P. Berrangé
2020-01-29 12:42 ` Christophe de Dinechin
2020-01-15 9:35 ` Making QEMU easier for management tools and applications Marc-André Lureau
2020-01-15 12:25 ` Markus Armbruster
2020-01-25 17:18 ` Paolo Bonzini
2020-01-27 9:30 ` Markus Armbruster
2020-01-13 16:30 ` Stefan Hajnoczi
2020-02-04 15:54 ` Summary of " Markus Armbruster
2020-02-05 6:38 ` Markus Armbruster
2020-02-10 10:56 ` Stefan Hajnoczi
2020-02-10 11:01 ` Peter Maydell
2020-02-10 11:08 ` Daniel P. Berrangé
2020-02-10 11:29 ` Peter Maydell
2020-02-10 11:04 ` Paolo Bonzini
2020-02-10 16:43 ` Markus Armbruster
2020-02-12 13:54 ` Stefan Hajnoczi
2020-02-12 14:03 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y2trdgy7.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=cleber@redhat.com \
--cc=d.csapak@proxmox.com \
--cc=den@virtuozzo.com \
--cc=ehabkost@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).