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

[Daniel P . Berrangé]

On Thu, Jan 09, 2025 at 01:56:40PM +0100, Roman Penyaev wrote:
> Hi,
> 
> On Tue, Jan 7, 2025 at 3:57 PM Marc-André Lureau
> <marcandre.lureau@redhat.com> wrote:
> > Whether we talk about multiplexing front-end or back-end, the issues
> > are similar. In general, mixing input will create issues. Teeing
> > output is less problematic, except to handle the buffering...
> 
> I understand your concerns. What exact issues do you have in mind?
> Are these issues related to the input buffer handling, so technical issues?
> Or issues with usability?

While the design / impl technically allows for concurrent input to be
sent to the frontend, from multiple backends, in practice I don't think
we need to be particularly concerned about it.

I don't see this as being a way for multiple different users to interact
concurrently. Rather I'd see 1 user of the VM just deciding to switch
from one backend to the other on the fly. IOW, although technically
possible, the user will only be leveraging one at a time to send input.

We very definitely do need all backends to receive output from the guest
concurrently too, as you'd want the historical output context to be
visible on whatever backend you choose to use at any given point in time.

If a user decides to be crazy and send input from multiple backends
concurrently, then they get to keep the mess.

> > > Do you think we need to artificially introduce multiplexing logic to be 
> > > fully
> > > compliant with multiplexer naming? It's not hard to do, repeating
> > > `mux_proc_byte()` from `mux-fe`. In my use-case, I'll still need to 
> > > disable
> > > multiplexing in favor of 'mixing', for example with the 'mixer=on' option,
> > > i.e. '-chardev mux-be,mixer=on,...`. Or do you think it should be some
> > > completely different beast, something like mixer chardev?
> >
> > I think it would be saner to have the muxer be selectors: only work
> > with one selected be or fe. Otherwise, we can run into various issues.
> 
> In multiplexing (not mixing) for the use-case that I am describing, there is 
> one
> serious drawback: as soon as you switch the "focus" to another input device
> (for example from vnc to socket chardev), you will not be able to s]witch back
> from the same input console - the input now works on another device. This 
> looks
> strange and does not add convenience to the final user. Perhaps, for a case
> other than console, this would be reasonable, but for console input -
> I would like
> to keep the mixer option: the front-end receives input from both back-ends.

Agreed, I think this is desirable. If you did the exclusive access mode,
it'd complicate things as you now need a way to switch between active
backends, while also reducing the usefulness of it.

The main thing I'm not a fan of here is the naming 'mux-fe', as I think we
should have something distinct from current 'mux', to reduce confusion
when we're talking about it.

How about 'overlay' or 'replicator' ? 

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|