Re: Making QEMU easier for management tools and applications

[Markus Armbruster]

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.

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?