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

[Markus Armbruster]

Roman Penyaev <r.peniaev@gmail.com> writes:

> 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()?

Three, to be honest:

* QemuOpts, commonly with qemu_opts_parse_noisily()

* QAPI, commonly with qobject_input_visitor_new_str()

* Ad hoc parsers (you don't wan't to know more)

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

It's not easy.

The main difficulty is assessing compatibility breaks, and whether they
matter.

>                                                          I can,
> of course, be wrong, but if I understand correctly, util/keyval.c
> does not work with QemuOpts,

Correct.

>                              and the entire char/* is very much
> tied to this classic way of getting arguments.

In the beginning, there was the command line (CLI), and then the human
monitor (HMP).

As CLI options and HMP commands were implemented with QemuOpts, the
underlying internal interfaces tended to be adjusted to take QemuOpts
arguments.

Then there was QMP, and then there was QAPI.  As QMP commands were
implemented with QAPI, the underlying internal interfaces tended to be
adjusted to take generated QAPI type arguments.

This got us two internal interfaces doing the same thing.  To not have
two implementations, one interface needs to wrap around the other.
Wrapping the QemuOpts one around the QAPI one is more sane.

Have a look at qmp_chardev_add() and hmp_chardev_add().

qmp_chardev_add() wraps around chardev_new(), which takes QAPI type
ChardevBackend.

hmp_chardev_add() wraps around qemu_chr_new_from_opts(), which wraps
around do_qemu_chr_new_from_opts(), which wraps around
qemu_chardev_new(), which wraps around chardev_new().  CLI -chardev
works the same way.

So...  Yes, at some point the entire chardev/ was very much tied to
QemuOpts.  By now, its core *should* be untied from it.  There *may* be
remnants of the old way that still need to be untied.

>                                                Is there a
> transitional way to parse the arguments? Use the modern way, but
> still represent the arguments as QemuOpts?

You could convert manually from QAPI to QemuOpts, but that would be a
mistake.  We know, because we made the mistake with device_add and
netdev_add.  Fixing the mistake for netdev_add was painful (see commit
db2a380c84574d8c76d7193b8af8535234fe5156 (net: Complete qapi-fication of
netdev_add)).  device_add remains unfixed, which has been a source of
trouble.