Re: QAPI sync meeting

[Kevin Wolf <kwolf@redhat.com>]

Am 07.10.2021 um 12:23 hat Paolo Bonzini geschrieben:
> On 07/10/21 12:01, Kevin Wolf wrote:
> > 
> >    * -chardev: I have patches that QAPIfy the option based on aliases,
> >      getting rid of the old handwritten parser that is inconsistent with
> >      QMP in non-obvious ways and replacing it with translation to QMP
> >      (both using aliases and a little C code) that makes the differences
> >      obvious.
> > 
> >      First posted in November 2020, more details in the cover letter:
> >      https://patchew.org/QEMU/20201112175905.404472-1-kwolf@redhat.com/
> > 
> >      Later versions (not yet posted as a series because I'm waiting for
> >      aliases) also make -chardev accept JSON syntax, which is what
> >      libvirt really wants to use.
> 
> I'm still not sure about this...  It's an awful lot of code if the aliases
> are only used by -chardev, and I'd rather use -object/object-add for
> chardevs if that's at all possible.

The important part for me there is getting rid of the second parser that
is inconsistent with QAPI - and people add to it without fully realising
that it's a separate implementation, so they test -chardev and leave
chardev-add behind broken.

My approach keeps the existing command line syntax and still makes sure
that inputs from both the CLI and QMP go through a single code path,
making sure that they are consistent.

Aliases are a helpful tool to achieve this, but the series can be
rewritten a bit if people are fundamentally against having aliases.
Aliases do nothing that C code can't do.

I don't think that aliases are a lot of code, or even complicated code.
Current v4 looks like a lot of lines of code because Markus made me add
big comments everywhere and tons of tests. The actual code additions are
rather small. But I also notice that there is resistance against having
multiple ways to specify the same thing (which is the essence of
aliases), so if people hate them, let's throw them away. The only part I
really dislike with this scenario is that I could have been told almost
a year ago...

Anyway, your approach provides a different solution to the goal of
getting rid of the second parser if you extend it: Add -object support
to all chardev backends, then deprecate -chardev wholesale and drop it
two releases later. This feels contentious, but I'm not opposed.

Timeline: My series could be done for 6.2. Yours could have the
replacement in 6.2 the earliest if we start working on it right now,
then libvirt starts using it, deprecation in 7.0 or 7.1, then drop the
old interface two releases later, i.e.  December next year or March
2023.

Kevin