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?
signature.asc
Description: PGP signature
_______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
