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-kw...@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 :|
