Re: [RFC PATCH v2 15/17] xenconsoled: add support for non-pty output

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2015 bytes --]

On Thu, Nov 01, 2018 at 05:35:04PM +0000, Ian Jackson wrote:
> Marek Marczykowski-Górecki writes ("[RFC PATCH v2 15/17] xenconsoled: add support for non-pty output"):
> > Handle 'output' xenstore entry, as qemu does. Right now support only few
> > simple options:
> >  - "pty" (unchanged)
> >  - "file:path" (overwrite file)
> >  - "pipe:path" (read-write file/pipe)
> >  - "null"
> 
> I have always thought the qemu set of console things very awkward to
> deal with.  pipe, in particular, is very awkward to use because pipes
> have poor semantics for this.

In fact libxl usage of "pipe" isn't about pipe at all. It's about
reading from normal file. This rely on a qemu fallback "pipe" handling -
first it looks for two pipes: path.in and path.out (for in- and
out-bound data). When it doesn't find them, it fallback to just "path"
opened for read and write.
And libxl use that fallback only. With normal file (see below).

> Would it be useful if I implemented a facility for xenconsoled to make
> an AF_UNIX listening socket for each console it handles ?  People who
> wanted to talk to the console would connect() to it.

This is meant to be compatible with other console backend(s) - namely
qemu-xen and qemu-xen-traditional. If xenconsoled backend for N>1
consoles would behave differently (in a way not supported by qemu one),
each place would need additional handling for that...
There are not many places though: "file:" is used to write qemu-dm (in
stubdomain) state to a file and "pipe:" is used to read it from that
file.

Note that real pipes are not used here at all. This is just awkward
naming for "read from this file".

> Multiple connections would be supported a la screen or tmux, although
> of course for your application you'd use a lock to prevent multiple
> access.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel