Date: Mon, 11 Jul 2016 14:53:54 -0700 From: Paul Vixie <paul@redbarn.org> To: Jakub Klama <jakub.klama@uj.edu.pl> Cc: freebsd-virtualization@freebsd.org Subject: Re: [Differential] D7185: Add virtio-console support to bhyve Message-ID: <57841572.7060903@redbarn.org> In-Reply-To: <6B5AEBF8-98B0-4031-A3E3-A1EBC8B4B763@uj.edu.pl> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
>> 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 what's supposed to happen is that a window size event is propagated
through a tty-like device (nmdm, pty, pts) by setting the new window
size with TIOCSWINSZ and then causing the process group of the control
tty to receive a SIGWINCH, which receives the new window size with
TIOCGWINSZ. this works on pty and pts, because the software that
connects the master and slave sides of those pseudo terminal devices is
window size aware. in sys/kern/tty_pts.c we see the following:
/* Just redirect this ioctl to the slave device. */
tty_lock(tp);
error = tty_ioctl(tp, cmd, data, fp->f_flag, td);
tty_unlock(tp);
if (error == ENOIOCTL)
error = ENOTTY;
this is after a switch statement that fails to enumerate TIOCSWINSZ, so
it falls through to this code in sys/kern/tty.c:
case TIOCGWINSZ:
/* Obtain window size. */
*(struct winsize*)data = tp->t_winsize;
return (0);
case TIOCSWINSZ:
/* Set window size. */
tty_set_winsize(tp, data);
return (0);
ssh (slogin), rlogin, telnet, but sadly not rtty, all catch SIGWINCH,
then they do TIOCGWINSZ to retrieve the kernel's idea of new window
size, then they propagate this to their other-side (sshd, rlogind,
telnetd) using a control-packet that's unique to each protocol. the
other-side hears the control message and calls TIOCSWINSZ to tell the
other-side kernel about the new window size. when this happens, the code
shown above for TIOCSWINSZ that calls tty_set_winsize() causes the
SIGWINCH to be sent to the process group of the tty:
void
tty_set_winsize(struct tty *tp, const struct winsize *wsz)
{
if (memcmp(&tp->t_winsize, wsz, sizeof(*wsz)) == 0)
return;
tp->t_winsize = *wsz;
tty_signal_pgrp(tp, SIGWINCH);
}
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.
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.
--
P Vixie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57841572.7060903>