Re: Making QEMU easier for management tools and applications

[Kevin Wolf]

Am 28.01.2020 um 13:36 hat Markus Armbruster geschrieben:
> Kevin Wolf <address@hidden> writes:
> 
> > Am 27.01.2020 um 21:11 hat John Snow geschrieben:
> [...]
> >> (The argument here is: It's a little harder and a little longer to type,
> >> but the benefits from the schema organization may improve productivity
> >> of using QEMU directly instead of harming it.)
> >
> > I think this is a false dichotomy.
> >
> > You can have everything defined by the schema and properly documented
> > and still have a non-JSON command line. Translating the QAPI schema to
> > a command line option is a solved problem, this is exactly how
> > -blockdev works.
> >
> > The unsolved part is how to compatibly convert the existing options. If
> > you're willing to sacrifice compatibility, great. Then we can just
> > define stuff in the QAPI schema and still keep a command line syntax
> > that is usable for humans. The code for mapping a QAPI type to the
> > argument of an option is basically already there.
> 
> Correct.
> 
> Solving that problem took time, but that's sunk cost now.
> 
> > The only question is "is compatibility important"? If the answer is no,
> > then we'll be there in no time.
> 
> I doubt we'll be there in no time, but certainly much sooner than if we
> have to grapple with compatibility to a byzantine CLI nobody truly
> understands.
> 
> There's one known issue caused by having "a non-JSON command line"
> (actually: dotted keys as sugar for JSON): pressure to reduce nesting.
> 
> Consider chardev-add.  Example:
> 
>     {"execute": "chardev-add",
>      "arguments": {"id": "bar",
>                    "backend": {"type": "file",
>                                "data": {"out": "/tmp/bar.log"}}}}
> 
> The arguments as dotted keys:
> 
>     id=bar,backend.type=file,backend.data.out=/tmp/bar.log
> 
> Observe there's quite some of nesting.  While that's somewhat cumbersome
> in JSON, it's a lot worse with dotted keys, because there nesting means
> repeated key prefixes.  I could give much worse examples, actually.

This is true, but even without the repeated keys (e.g. in a syntax that
would use brackets), it would still be unnecessarily verbose and
probably hard to remember:

    id=bar,backend={type=file,data={out=/tmp/bar.log}}

> We'd rather have something like
> 
>     id=bar,type=file,out=/tmp/bar.log
> 
> Back to JSON:
> 
>     "arguments": {"id": "bar", "type": "file", "out": "/tmp/bar.log"}
> 
> QAPI can do this, but it uses feature that predate chardev-add.
> 
> We don't want to duplicate the chardev-add schema in modern, flattened
> form for the CLI.
> 
> So the compatibility problem actually shifts to QMP: can we evolve the
> existing QMP command compatibly at a reasonable cost in design, coding
> and complexity to support flat arguments?

Well, first of all: Do we need compatibility? If we don't, then we can
just make the change.

Much of this threads plays with the though that maybe we don't need any
compatibility and make the radical conclusion that we don't need any
human-friendly interface at all. Keeping full compatibility is the other
extreme.

There might be some middle ground where we break compatibility where the
old way can't easily be maintained with the new infrastructure, but
don't give up on the idea of being used by humans.

Kevin