> 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.

freebsd-virtualization@freebsd.org mailing list
To unsubscribe, send any mail to 

Reply via email to