Date: Tue, 12 Jul 2016 00:17:11 +0200 From: Jakub Klama <jakub.klama@uj.edu.pl> To: Paul Vixie <paul@redbarn.org> Cc: freebsd-virtualization@freebsd.org Subject: Re: [Differential] D7185: Add virtio-console support to bhyve Message-ID: <577FFDDF-7EC5-4143-AA1B-858BA8C3287F@uj.edu.pl> In-Reply-To: <57841572.7060903@redbarn.org> References: <differential-rev-PHID-DREV-h346qsj6dfo524z3qnfy-req@FreeBSD.org> <5783D6FF.7010107@redbarn.org> <FCF5C7E6-2BCF-4729-BC2B-788E1FE74BCE@uj.edu.pl> <5783E2FE.1040309@redbarn.org> <EDFB1E4C-755F-4D2F-808C-E45A31C3EE2C@uj.edu.pl> <5783E64B.9010608@redbarn.org> <6B5AEBF8-98B0-4031-A3E3-A1EBC8B4B763@uj.edu.pl> <57841572.7060903@redbarn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Wiadomo=C5=9B=C4=87 napisana przez Paul Vixie <paul@redbarn.org> w = dniu 11.07.2016, o godz. 23:53: >=20 >=20 >=20 > Jakub Klama wrote: >> nmdm(4) emulates a serial port. how could one pass ioctls and signals = via serial port? >=20 > 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. >=20 > 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. >=20 >>> yikes. so you've got to reinvent what TIOCPKT does, but differently? >>=20 >> how could one pass ioctls via unix domain socket? >=20 > you can't. that's why i'm saying "but differently". >=20 > [...] > 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. >=20 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?577FFDDF-7EC5-4143-AA1B-858BA8C3287F>