> Wiadomość napisana przez Paul Vixie <p...@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 _______________________________________________ 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"
