On Tue, 17 Sept 2024 at 13:32, Marc-André Lureau
<marcandre.lur...@redhat.com> wrote:
>
> Hi Roman
>
> On Fri, Sep 13, 2024 at 8:37 PM Roman Penyaev <r.peni...@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.
> >
> > The following is QEMU command line example:
> >
> >   -chardev socket,path=/tmp/sock,server=on,wait=off,id=sock0 \
> >   -chardev vc,id=vc0 \
> >   -chardev mux,id=mux0,chardev=vc0,,sock0 \
> >   -device virtconsole,chardev=mux0 \
> >   -vnc 0.0.0.0:0
> >
> > Which creates 2 backend devices: text virtual console (`vc0`)
> > and a socket (`sock0`) connected to the single virtio hvc
> > console with the multiplexer (`mux0`) help. `vc0` renders
> > text to an image, which can be shared over the VNC protocol.
> > `sock0` is a socket backend which provides biderectional
> > communication to the virtio hvc console.
>
> I think I would rather implement a new mux for this purpose, like
> "mux-be" perhaps?
>
> "mux" has been a bit hidden (behind mux=on) for various reasons, and
> is probably not at production quality level.

You get a mux by default (for serial vs HMP monitor), so
I think it's pretty heavily used and tested in that sense...

-- PMM

Reply via email to