[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: QAPI sync meeting
From: |
Daniel P . Berrangé |
Subject: |
Re: QAPI sync meeting |
Date: |
Thu, 7 Oct 2021 14:02:32 +0100 |
User-agent: |
Mutt/2.0.7 (2021-05-04) |
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 :|