Kevin Wolf <kw...@redhat.com> 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?