> 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 separately. > 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. Jakub _______________________________________________ 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"
