[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Making QEMU easier for management tools and applications
Re: Making QEMU easier for management tools and applications
Tue, 28 Jan 2020 11:16:16 +0100
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
John Snow <address@hidden> 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
>> 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
>> 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,
> As soon as you have anything nested, the gossamer-thin illusion is
... 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
> - 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
Re: Making QEMU easier for management tools and applications, John Snow, 2020/01/22
Re: Making QEMU easier for management tools and applications, Paolo Bonzini, 2020/01/25
- Re: Making QEMU easier for management tools and applications, (continued)
- Tooling to help humans use JSON (was: Making QEMU easier for management tools and applications), Markus Armbruster, 2020/01/27
- Re: Making QEMU easier for management tools and applications, Markus Armbruster, 2020/01/27
- Re: Making QEMU easier for management tools and applications, Daniel P . Berrangé, 2020/01/27
- Re: Making QEMU easier for management tools and applications, Kevin Wolf, 2020/01/27
- Re: Making QEMU easier for management tools and applications, Dr. David Alan Gilbert, 2020/01/27
- Re: Making QEMU easier for management tools and applications, Kevin Wolf, 2020/01/28
- Re: Making QEMU easier for management tools and applications, John Snow, 2020/01/27
- Re: Making QEMU easier for management tools and applications,
Markus Armbruster <=
- Re: Making QEMU easier for management tools and applications, John Snow, 2020/01/28
- Re: Making QEMU easier for management tools and applications, Markus Armbruster, 2020/01/24
- Re: Making QEMU easier for management tools and applications, Christophe de Dinechin, 2020/01/25