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

[Roman Penyaev]

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. I can,
of course, be wrong, but if I understand correctly, util/keyval.c
does not work with QemuOpts, and the entire char/* is very much
tied to this classic way of getting arguments. Is there a
transitional way to parse the arguments? Use the modern way, but
still represent the arguments as QemuOpts?

--
Roman

On Wed, Dec 11, 2024 at 10:42 AM Markus Armbruster <armbru@redhat.com> wrote:
>
> I'm awfully, awfully late.  My apologies!
> Marc-André Lureau <marcandre.lureau@gmail.com> writes:
>
> > Hi
> >
> > On Wed, Oct 16, 2024 at 2:29 PM Roman Penyaev <r.peniaev@gmail.com> wrote:
> >
> >> This patch implements multiplexing capability of several backend
> >> devices, which opens up an opportunity to use a single frontend
> >> device on the guest, which can be manipulated from several
> >> backend devices.
> >>
> >> The idea of the change is trivial: keep list of backend devices
> >> (up to 4), init them on demand and forward data buffer back and
> >> forth.
> >>
> >> Patch implements another multiplexer type `mux-be`. The following
> >> is QEMU command line example:
> >>
> >>    -chardev mux-be,id=mux0 \
> >>    -chardev 
> >> socket,path=/tmp/sock,server=on,wait=off,id=sock0,mux-be-id=mux0 \
> >>    -chardev vc,id=vc0,mux-be-id=mux0 \
> >>
> >
> > I am not sure about adding "mux-be-id" to all chardev. It avoids the issue
> > of expressing a list of ids in mux-be though (while it may have potential
> > loop!)
> >
> > Markus, do you have a suggestion to take an array of chardev ids as a CLI
> > option? It looks like we could require QAPIfy -chardev from Kevin here..
>
> We've developed a number of ways of array-shaped configuration bits.
> The most recent one relies on QAPI.  To not get bogged down in
> compatibility considerations, let me show a new option first.
>
> Create a QAPI type FooOptions for the option's argument, say
>
>     { 'struct': 'FooOptions',
>       'data': { 'ids': ['str'] } }
>
> Create the new option -foo, and use qobject_input_visitor_new_str() and
> visit_type_T() to parse its argument into a T.
>
> The new option now supports both JSON and dotted keys syntax for its
> argument.
>
> JSON example:
>
>     -foo '{"ids": ["eins", "zwei", "drei"]}'
>
> Same in dotted keys:
>
>     -foo ids.0=eins,ids.1=zwei,ids.2=drei
>
> Note: dotted keys are slightly less expressive than JSON.  For instance,
> they can't do empty arrays.  Users need to fall back to JSON then.
> Peruse the big comment in util/keyval.c if you're curious.
>
> Things can get messy when QAPIfying an existing option argument.  Dotted
> keys are designed to be close to QemuOpts, but they're not identical.
> If existing usage of the option argument relies on funky QemuOpts
> features dotted keys don't replicate, we have a compatibility problem.
> For complicated arguments, we may not know whether we have a
> compatibility problem.
>
> We can sacrifice dotted key syntax to avoid compatibility problems: if
> the argument isn't JSON, fall back to the old option parsing code
> instead.  Ugly, because we then have effectively two interfaces instead
> of a single interface with a choice of syntax.
>
> Hope this still helps at least some.
>