> Wiadomość napisana przez Paul Vixie <p...@redbarn.org> w dniu 12.07.2016, o
> godz. 02:39:
> Jakub Klama wrote:
>> It doesn't speak any protocol. virtio-console is a pipe. it pushes
>> bytes back and forth. Name is indeed unfortunate, it should have
>> been called virtio-pipe, but virtio-console is how the virtio
>> specification calls it.
> 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. 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.
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?
* It doesn't necessarily need to be connected to bhyve process stdin/stdout
* If bhyve opens pty(s), how would it communicate ptsname() back to the user?
> please explain how your proposed addition to bhyve handles resize events but
> is not actually related to tty use by either the guest or host.
It doesn't, that's just not supported yet :)
>> If we were to use virtio-console as a system console, then using a
>> pseudo tty and forwarding pty resize notifications as resize control
>> events to the guest is totally fine and desired (at least as one of
>> the options). However, as I said, unix domain socket is perfect fit
>> for using is at a regular bidirectional pipe.
> 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
> please explain more about your use case. what will this device look like to
> the guest, and what application do you expect to have running on the host to
> talk to this unix domain socket?
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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to