Jakub Klama wrote:
if it's never going to appear as /dev/console or any other
tty-like device to the guest, then i won't care what it looks like
on the host. however, you said it could carry resize events, which
leads me to believe that the name (vertio-console) is not wrong,
and it is a tty to the guest, and in my view that means it should
be a tty to the host.
Well, it *can* be a tty to the host, but doesn't need to be.
that's madness. i'd like bhyve to remain for all time as clean as it is
now. so if you want a flat clean bidirectional channel for your "guest
additions" on the guest to talk to your "middleware" on the host, that's
fine by me, but don't let either end look like a tty to anybody. in
fact, it would be better for bhyve for you to implement both host and
guest drivers for virtio_vsock than to use the non-tty features of
virtio_console.
Driver supports multiple ports, and every port can be marked as a
"console" port. Linux guests create regular character devices for
"normal" virtio-console ports and ttys for "console" ports. My code
doesn't support "console" ports yet at all.
your initial mention of resize events up-thread gets harder and harder
for me to understand as we continue down-thread.
please don't implement "console" ports at all unless the host side of
such a port has to talk to a pts, pty, or nmdm. separately, let's work
together to get TIOC{S|G}WINSZ support working in nmdm. this means,
please don't let a guest tty talk to a host unix-domain socket that has
to have a second control channel for carrying tty events like window
size. just don't do that. make the guest tty talk to a host nmdm, pty,
or pts.
I agree that the console port should be a tty on the host. But there
are some things to consider: * There can be more than one - how do we
receive resize events from every pty? polling? fork per pty?
generally you let all the pts/pty/nmdm devices have the same pgrp and
when you get a SIGWINCH you poll all of your devices with TIOCGWINSZ.
the SIGWINCH event is rare enough and the number of devices is low
enough that this polling is not a performance problem.
* It doesn't necessarily need to be connected to bhyve process
stdin/stdout
bhyve should never connect its stdin/stdout to the guest. that's bad
design. let's work together to stamp it out, starting by never letting
any of your virtio_console ports (should you implement the kind that
appear to the guest as tty devices) to bhyve stdin/stdout.
* If bhyve opens pty(s), how would it communicate ptsname() back to
the user?
that would be a fine thing to send to stdout at bhyve initialization time.
if that pipe has resize events encoded in it, as you said earlier,
then it has to have a protocol, and it is not just a bidirectional
pipe.
Pipe itself doesn't have resize events. Resize events are transmitted
out of band, in a separate control queue. That out of band
communication is not visible to the unix domain socket consumer. It
could be made visible in two ways: a) by implementing multiplexing in
the unix domain socket protocol b) by using pseudo tty, connecting
pty data stream to the pipe and handing resizes separately.
if you say "we will never multiplex the unix domain socket" and you say
"pts, pty, or nmdm" rather than "pseudo tty", then we're in agreement.
We're using it in freenas-vm-tools, a "guest additions" package that
would allow host-guest interactions, such as automatic mounting of
the shared 9P storage when being added in the hypervisor GUI,
synchronizing time, potentially also suspending the I/O while
snapshotting the VM datasets, and so on. In the guest, virtio-console
is visible as a regular character device
(/dev/virtio-ports/org.freenas.vm-tools). On the host side, FreeNAS
10 middleware talks to it.
i would prefer to see this as a virtio_vsock.
thank you for explaining.
--
P Vixie
_______________________________________________
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
