Re: QAPI sync meeting

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Oct 07, 2021 at 02:53:19PM +0200, Kevin Wolf wrote:
> 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.

If we were thinking about QEMU from new ignoring existing design,
I could even imagine that all of -chardev, -netdev, -device, etc
would actually be -object. So from my POV I don't think it is
unreasonable to take this direction.

> 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.

Are the two approaches mutually exclusive rather than complementary ?
eg is Kevin's work a worthwhile incremental step forward, even if we
eventually get to replacing -chardev with -object ?

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|