> From: Peter Hurley [mailto:peter@xxxxxxxxxxxxxxxxxx] > On Thu, 2013-03-21 at 20:38 +0000, Grant Edwards wrote: > > On 2013-03-21, Craig McQueen <craig.mcqueen@xxxxxxxxxxxxxxxxxxxxxx> > wrote: > > > > > I'm interested in having support for hardware handshaking lines for > > > both pseudo-tty (Unix 98 style) and USB serial gadget drivers. > > > Unless I've missed something, it looks as though they don't support > > > the hardware handshaking lines. > > > > > > Has anyone worked on this already, for either pseudo-tty or USB > > > serial gadget? > > > > For years, I've wanted to be able to implement serial-ports in > > user-space, but the pseudo-tty implments too small a subset of the > tty > > API to make it usable for that. In addition to the TIOCMSET/TIOCMGET > > support, it would need to support all the other standard serial-port > > configuration options (character len, parity, baud rate, RTS/CTS flow > > control, etc.). > > > > I asked several years ago if such enhancements to the pseudo-tty > > driver would be accepted, but I never got any response, so I took > that > > as a "no". > > Anything tacked onto the pty driver is a non-starter because any app > that mis-handles termios for a pty will be in for a shock. There's a > lot of weird legacy behavior that must continue to work. I understand that could be a concern. How about we add the functionality to the pty driver, but it's disabled by default, and applications that want it can turn it on with an ioctl call? > > > It sounds as though people have done pseudo-ttys with HW > handshaking > > > support--eg tty0tty project. However I'd rather implement this > > > function in the kernel pseudo-terminal driver itself. Is there any > > > reason not to do that? > > > > No reason other than you and I are the only two people who care about > > it. :) > > Assuming you're leaning toward an in-kernel solution, why not just > implement a new tty driver that behaves like a local serial port? The pseudo-tty already provides most of the functionality I want, so I don't want to reinvent the wheel. I want to use it to simulate a modem device. Various other programs could benefit from an enhanced pseudo-tty, so they also don't have to implement their own kernel drivers--e.g.: * interceptty could be enhanced if the pseudo-tty could handle hardware handshaking as well as setting port speed etc. * Serial-over-Ethernet (RFC-2217) client drivers could use a pseudo-tty to implement the virtual tty device, including hardware handshaking and setting port speed etc. > For the firewire-over-serial staging driver, I did a software-only > loopback driver that does all that (simulate MCTRL, etc.) as a way to > test and isolate firewire/dma problems from data handling and tty > driver problems. > > > > I was wondering how to handle the HW lines on the master side of > the > > > pseudo-tty, and on the USB gadget device. It's the opposite way to > a > > > regular serial port (DCE rather than DTE), so you _write_ DSR, CTS, > > > DCD and RING, and _read_ DTR and RTS. There could be two ways to do > > > this: > > > > > > 1) Reverse normal operations, so do TIOCMSET of TIOCM_DSR, TIOCM_CD > > > etc. > > > > That's what I'd vote for. > > > > > 2) Act like a normal port, and "cross-over" signals. So do > > > > > > TIOCMSET of TIOCM_DTR, which changes DSR on the slave; TIOCMGET of > > > TIOCM_DSR to read the state of DTR set by the slave. Etc. What > about > > > setting the slave's DCD and RING? Maybe do TIOCMSET of TIOCM_OUT1 > > > and > > > TIOCM_OUT2 on the master. > > This is the approach I took for simulating HW flow control over > firewire. Software null-modem cable. Perhaps there are pros and cons for both options. If we can't get a clear consensus, could we make this configurable with an ioctl call? Regards, Craig McQueen ��.n��������+%������w��{.n�����{��ǫ����{ay� ʇڙ���f���h������_�(�階�ݢj"��������G����?���&��
