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