Re: [PATCH v4 6/8] chardev/char-mux: implement backend chardev multiplexing

[Kevin Wolf]

Am 17.12.2024 um 11:32 hat Roman Penyaev geschrieben:
> Hi Markus,
> 
> Thanks for the explicit info. But I have a lot to ask :)
> Do I understand correctly that there are two ways to parse
> arguments: classic, via qemu_opts_parse_noisily() and modern, via
> qobject_input_visitor_new_str()? (for example, I look in
> net/net.c, netdev_parse_modern()). My goal is not to create a
> completely new option, but to add (extend) parameters for
> chardev, namely to add a new type of backend device. This
> complicates everything, since chardev uses
> qemu_opts_parse_noisily() for parsing and bypasses the modern
> way (I hope I'm not mistaken, maybe Marc can comment). And I'm
> not sure that it's easy to replace the classic way of parsing
> arguments with the modern way without breaking anything.

A few years ago, I tried to unify the QMP and CLI code paths for
creating chardevs and this involved using QAPI for everything. As far as
I can remember, chardevs don't use any of the QemuOpts features that
don't exist in they keyval parser, so it's easy from that angle.

What makes it more complicated is that CLI and QMP options have diverged
quite a bit, and while generally the same functionality is available, it
sometimes uses different names or is negated in one compared to the
other etc.

So I ended up writing compatibility code that translated legacy CLI
options into QAPI-compatible ones, and then I could use the exising QAPI
types. Part of it made use of aliases, which would have been a new
feature in QAPI, but Markus didn't like them in the end. They could have
been replaced by manual conversion code, but I didn't have time (nor, to
be honest, motivation) to work it any more when Markus had finally made
that decision. It shouldn't actually be very hard.

Anyway, if it's of any use for you, feel free to resurrect parts of it:

https://repo.or.cz/qemu/kevin.git/shortlog/refs/tags/qapi-alias-chardev-v4

(Or maybe I will eventually...)

Whatever you choose to do, my one request for you would be that you
really make sure that CLI and QMP are structured and behave exactly the
same with your new option, to avoid making the problem worse than it
already is.

Kevin