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

[Markus Armbruster]

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.