[Differential] D7185: Add virtio-console support to bhyve

[Jakub Klama]

> Wiadomość napisana przez Paul Vixie <paul at redbarn.org> w dniu 11.07.2016, o godz. 23:53:
> 
> 
> 
> Jakub Klama wrote:
>> nmdm(4) emulates a serial port. how could one pass ioctls and signals via serial port?
> 
> i think if bhyve arranged for its virtio_console device to be its control terminal, it would receive SIGWINCH from the host kernel, which it could propagate to the guest's /dev/console, after first doing a TIOCGWINSZ to find the new size and making that available to the guest's /dev/console driver's TIOCGWINSZ.
> 
> rtty would have to do the same.

That's the plan, but obviously it won't work with nmdm(4). bhyve could also allocate a pty/pts, retrieve it's name using ptsname() and report that back to the user.

> 
>>> yikes. so you've got to reinvent what TIOCPKT does, but differently?
>> 
>> how could one pass ioctls via unix domain socket?
> 
> you can't. that's why i'm saying "but differently".
> 
> [...]
> so in the bhyve case, the bhyve process and its console driver is acting as both a tty client (because it connects to one in the host) and as a tty server (because it offers one in the guest), and it is therefore in the role that rlogin+rlogind, or telnet+telnetd, or ssh+sshd, would be in. and in that role, you hear SIGWINCH, you ask for TIOCGWINSZ, you propagate this value in an implementation-dependent way, and you perform the effect of TIOCSWINSZ to your guest.
> 

Host-side handling of window size change is pretty much straightforward, so there's nothing to discuss here. Propagating the window size values to the guest happens via resize event defined in virtio-console specification. Guest kernel and guest virtio-console driver performs whatever is necessary to handle that event.

> so, i still don't understand why you created a vertio_console driver that opens a socket in the host file system and speaks a new protocol over that. you can, from within bhyve, do what rlogin+rlogind, or ssh+sshd, or telnet+telnetd do. if nmdm isn't propagating window size changes yet, either you or i can fix that. and i can fix rtty. inventing a new data path with a new (and as-yet-undefined) protocol should be a last resort. we're no where near last-resort yet.

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

Jakub