[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: qmp-shell for GSoC/Outreachy?
From: |
Dr. David Alan Gilbert |
Subject: |
Re: qmp-shell for GSoC/Outreachy? |
Date: |
Thu, 6 Feb 2020 18:18:36 +0000 |
User-agent: |
Mutt/1.13.3 (2020-01-12) |
* Markus Armbruster (address@hidden) wrote:
That I wrote:
> >
> > I believe it should be a python shell with added commands.
> >
> > Simple things should be simple.
> > e.g. adding a disk from a local file should be trivial.
> >
> > Complex things can be complex - but it would be better if they were
> > simple.
> >
> > It's OK if the worst case of a blockdev is a bit hairy, but
> > watch out for cases where the hairyness creeps in unnecessarily.
>
> Designing interfaces to complex machinery is hard. Experience tells
> that we do okay when we focus on the building blocks first. That's
> -blockdev. When we start with trying to make simple things simple, we
> end in swamps. That's -drive.
>
> Focus on building blocks is of course no excuse for unnecessary
> hairiness.
>
> It's also no reason not to build more convenient things on top of the
> building blocks. I doubt they should go into QMP, though.
I see where you're coming from, but I like -drive - it's simple for
simple things; maybe it's a nightmare for some others, but if I just
want a VM with a disk on virtio, it's easy.
But I agree if you have good building blocks and they're easy to
understand and easy to represent, it's not a bad start.
> > If the user screwsup, it should give an error that prompts the user
> > to the parameter they got wrong.
> >
> > Output from commands should normally be pretty formatted (with an option
> > to display raw json for those needing it).
> > e.g. that 'query-version' should give either just the package
> > version (as info version currently does) or:
> > 4.2.50 Package: v4.2.0-1188-gd95a3885a9
> >
> > We shouldn't lose any HMP commands that some people find useful
> > Ditching HMP isn't an option until we've got almost all of it
> > covered.
>
> In particular, we currently use HMP for debugging and monitoring
> purposes, where we don't need or want QMP's rigor, neither its rigorous
> interface stability, nor its structured I/O. We want the "whipuptitude"
> we get from monitor_printf(). This is actually a point David has made
> several times.
>
> To have a qmp-shell replace HMP, I think it needs to be able to
>
> * Go beyond 1:1
>
> We tried a 1:1 mapping between HMP and QMP commands, and it didn't
> work out. HMP's replacement should let us build convenient commands
> from QMP building blocks.
>
> We tried a 1:1 mapping between HMP and QMP command arguments, guided
> by @args_type. Worked out for simple cases, but was too constricting.
Yes, it works for some things.
> * Preserve "whipuptitude" [David]
>
> I figure that means allowing some in QMP. Without compromising its
> core mission, of course.
>
> * As discoverable as HMP is now [Kevin]
>
> * Help, completion and such at least on par with what HMP provides now
>
> Highly desirable:
>
> * Support transitioning to the machine interface [John]
>
> Let humans start playing with the human interface, and when they feel
> the need to automate, help them transition to QMP.
>
> Back to John's question on qmp-shell syntax, which hasn't been answered
> so far.
>
> JSON is a data-interchange format. It doesn't try to be a configuration
> format or programming language syntax for human use. It gets pressed
> into these roles with entirely predictable poor results.
>
> Pain points of JSON include having to count parenthesises and having to
> quote so bloody much. Additional QMP pain points include long names and
> excessive nesting.
Some other pet hates:
a) Number formats are awful for our uses
b) Lack of room for comments
> For the configuration format role, more usable alternatives exist. YAML
> is a popular one.
>
> qmp-shell is a REPL. It needs a REPL-friendly syntax. I doubt YAML is
> or even tries to be REPL-friendly. I'd love to be wrong; the first rule
> of language design is "don't".
>
> Other language suggestions?
While I hate XML, there's a certain niceness in using the same thing as
libvirt for places that mean the same thing; but that would have the bad
requirement that things meant *exactly* the same thing.
But, for machine representations, I'm not sure moving away from JSON is
a requirement.
Dave
> On making JSON suck less in this role:
>
> LISP REPLs demonstrate that computers can assist effectively with
> counting parenthesises, and with completing long names.
>
> We could make quoting optional for sufficiently nice object member
> names. QAPI naming rules ensure niceness, actually.
>
> We could make quoting optional for certain string literals. Simple
> enough for literals that can only be a string, like abc. For literals
> that could be something else like 123 or true, omitting quotes creates
> ambiguity. When the schema accepts only one of the possible types, the
> ambiguity goes away. Complexity stays, however.
>
> Excessive nesting should ideally be attacked in QMP itself, but backward
> compatibility makes that hard.
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK
- Re: qmp-shell for GSoC/Outreachy?, (continued)
- Re: qmp-shell for GSoC/Outreachy?, Kevin Wolf, 2020/02/06
- Re: qmp-shell for GSoC/Outreachy?, Dr. David Alan Gilbert, 2020/02/06
- Re: qmp-shell for GSoC/Outreachy?, Kevin Wolf, 2020/02/07
- Re: qmp-shell for GSoC/Outreachy?, John Snow, 2020/02/07
- Re: qmp-shell for GSoC/Outreachy?, Markus Armbruster, 2020/02/08
- Re: qmp-shell for GSoC/Outreachy?, Kevin Wolf, 2020/02/10
- Re: qmp-shell for GSoC/Outreachy?, Kevin Wolf, 2020/02/10
- Re: qmp-shell for GSoC/Outreachy?,
Dr. David Alan Gilbert <=
- Re: qmp-shell for GSoC/Outreachy?, Markus Armbruster, 2020/02/07
- Re: qmp-shell for GSoC/Outreachy?, Eric Blake, 2020/02/07
- Re: qmp-shell for GSoC/Outreachy?, Markus Armbruster, 2020/02/08
- Re: qmp-shell for GSoC/Outreachy?, John Snow, 2020/02/07
- Re: qmp-shell for GSoC/Outreachy?, John Snow, 2020/02/07