Add hardware handshaking to pseudo-tty and USB serial gadget

Add hardware handshaking to pseudo-tty and USB serial gadget

[Craig McQueen]

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?

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?


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.

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.

Same question for the USB serial gadget.

So which of those choices would be better? I think I prefer (2) because the user code stays more the same whether it's talking to a master device or slave device.

Regards,
Craig McQueen

Re: Add hardware handshaking to pseudo-tty and USB serial gadget

[Grant Edwards]

On 2013-03-21, Craig McQueen <craig.mcqueen@beamcommunications.com> 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".

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

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

I think that would make code on the master side confusing. If I want
to set CD from the master side, I'd rather do ioctl(TIOCMSET,TIOCM_CD)
than ioctl(TIOCMSET,TIOCMOUT1).

> Same question for the USB serial gadget.

I'm afraid I don't know anything about USB serial gadgets.

> So which of those choices would be better? I think I prefer (2)
> because the user code stays more the same whether it's talking to a
> master device or slave device.

It depends on what you want to do with the resulting device-pair.  If
you want a peer-to-peer software "null-modem" cable to hook together
two applications that both expect to talk to serial ports via the
existing API, then (2) is definitely the way to go, but you've got do
decide how to wire the null-modem.  In real null-modem cables, it's
usually done something like this:

     DTR  ---+-- DSR
             |   
             +-- CD

     RTS  ---+-- CTS
             |
             +-- RI  (RI is sometimes left disconnected).

If you want to end up with something that's going to work with
existing apps, you should probably stick to the above and forget about
OUT1 and OUT2.
             
But, a virtual null-modem cable betwen two applications is not what
I've wanted to do in the past.  I've wanted to impliment a pseudo
serial port in user-space using code that, for example, communicates
with the read serial port hardware via Ethernet.  For that application,
I think (1) is better.

If you go with (1), then it's pretty simple to write a small app that
hooks together the master sides of two pairs to provide a virtual
null-modem cable (and it's easier to change the wiring of the
null-modem cable depending on the situation).

-- 
Grant Edwards               grant.b.edwards        Yow! All right, you
                                  at               degenerates!  I want
                              gmail.com            this place evacuated in
                                                   20 seconds!

Re: Add hardware handshaking to pseudo-tty and USB serial gadget

[Peter Hurley]

On Thu, 2013-03-21 at 20:38 +0000, Grant Edwards wrote:
> On 2013-03-21, Craig McQueen <craig.mcqueen@beamcommunications.com> 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.

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

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.

Regards,
Peter Hurley

RE: Add hardware handshaking to pseudo-tty and USB serial gadget

[Craig McQueen]

> From: Peter Hurley [mailto:peter@hurleysoftware.com]
> On Thu, 2013-03-21 at 20:38 +0000, Grant Edwards wrote:
> > On 2013-03-21, Craig McQueen <craig.mcqueen@beamcommunications.com>
> 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

Re: Add hardware handshaking to pseudo-tty and USB serial gadget

[Peter Hurley]

[ +Jiri Slaby who doesn't read linux-serial ;) ]

On Thu, 2013-03-21 at 23:32 +0000, Craig McQueen wrote:
> 
> > From: Peter Hurley [mailto:peter@hurleysoftware.com]
> > On Thu, 2013-03-21 at 20:38 +0000, Grant Edwards wrote:
> > > On 2013-03-21, Craig McQueen <craig.mcqueen@beamcommunications.com>
> > 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's not my place to say yes or no here.

FWIW the pty driver is still a maintenance burden -- I just fixed 2
problems with open()/close() this release.

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

I should have been more specific: I didn't mean necessarily start from
scratch. As a starting point you could just dup pty.c, rip out the BSD
legacy support, and rename the driver/tty device base names.

Whatever that was would behave just like ptm/pts.

> * 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?

I was just sharing my experience. For this part, "the right way" is
whatever you implement.

Regards,
Peter Hurley

RE: Add hardware handshaking to pseudo-tty and USB serial gadget

[Craig McQueen]

> From: Peter Hurley
> [ +Jiri Slaby who doesn't read linux-serial ;) ]
> 
> On Thu, 2013-03-21 at 23:32 +0000, Craig McQueen wrote:
> >
> > > From: Peter Hurley [mailto:peter@hurleysoftware.com] On Thu,
> > > 2013-03-21 at 20:38 +0000, Grant Edwards wrote:
> > > > On 2013-03-21, Craig McQueen
> > > > <craig.mcqueen@beamcommunications.com>
> > > wrote:
> > > > > 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.:
> 
> I should have been more specific: I didn't mean necessarily start from
> scratch. As a starting point you could just dup pty.c, rip out the BSD
> legacy support, and rename the driver/tty device base names.
> 
> Whatever that was would behave just like ptm/pts.

I'm a little fuzzy about this... If I do this, how would userland programs create pty master/slave device pairs? Could it work with the API of the UNIX 98 style pseudo-tty in 'man 7 pty'? That is:

posix_openpt()
grantpt()
unlockpt()
ptsname()

I see posix_openpt(flags) is essentially equivalent to open("/dev/ptmx", flags), so maybe if I made my own driver, posix_openpt(flags) would be replaced by open("/dev/my-driver-ptmx", flags), and the other function calls could stay the same. Is that right?

Thanks,
Craig McQueen

Re: Add hardware handshaking to pseudo-tty and USB serial gadget

[Peter Hurley]

On Fri, 2013-03-22 at 01:44 +0000, Craig McQueen wrote:
> > From: Peter Hurley
> > [ +Jiri Slaby who doesn't read linux-serial ;) ]
> > 
> > On Thu, 2013-03-21 at 23:32 +0000, Craig McQueen wrote:
> > >
> > > > From: Peter Hurley [mailto:peter@hurleysoftware.com] On Thu,
> > > > 2013-03-21 at 20:38 +0000, Grant Edwards wrote:
> > > > > On 2013-03-21, Craig McQueen
> > > > > <craig.mcqueen@beamcommunications.com>
> > > > wrote:
> > > > > > 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.:
> > 
> > I should have been more specific: I didn't mean necessarily start from
> > scratch. As a starting point you could just dup pty.c, rip out the BSD
> > legacy support, and rename the driver/tty device base names.
> > 
> > Whatever that was would behave just like ptm/pts.
> 
> I'm a little fuzzy about this...If I do this, how would userland
> programs create pty master/slave device pairs? Could it work with the
> API of the UNIX 98 style pseudo-tty in 'man 7 pty'? That is:
>
> posix_openpt()
> grantpt()
> unlockpt()
> ptsname()
>
> I see posix_openpt(flags) is essentially equivalent to
> open("/dev/ptmx", flags), so maybe if I made my own driver,
> posix_openpt(flags) would be replaced by open("/dev/my-driver-ptmx",
> flags), and the other function calls could stay the same. Is that
> right?

I was in the middle of dropping in some simple user-space code that
would do the trick when I remembered that what I suggested wouldn't be
that simple because of the devpts filesystem.

Sorry for the false start.

Regards,
Peter Hurley

Re: Add hardware handshaking to pseudo-tty and USB serial gadget

[Peter Korsgaard]

>>>>> "Craig" == Craig McQueen <craig.mcqueen@beamcommunications.com> writes:

Hi,

 Craig> * interceptty could be enhanced if the pseudo-tty could handle
 Craig> hardware handshaking as well as setting port speed etc.  *
 Craig> Serial-over-Ethernet (RFC-2217) client drivers could use a
 Craig> pseudo-tty to implement the virtual tty device, including
 Craig> hardware handshaking and setting port speed etc.

Indeed, getting RFC2217 stuff to work transparently without a custom
kernel driver would be very nice.

-- 
Bye, Peter Korsgaard

Re: Add hardware handshaking to pseudo-tty and USB serial gadget

[Grant Edwards]

On 2013-03-21, Peter Hurley <peter@hurleysoftware.com> wrote:
> On Thu, 2013-03-21 at 20:38 +0000, Grant Edwards wrote:
>> On 2013-03-21, Craig McQueen <craig.mcqueen@beamcommunications.com> wrote:

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

I've been thinking about trying to do that except making it a
serial_core driver on the slave side rather than a tty driver.  I just
converted a tty driver to the serial-core API and the code-size
dropped by almost 70% (hopefully the undiscovered bug count dropped as
well).  I hadn't decided what to do for a master-side API.  I'd
probably abandon the standard tty API altogether and do something from
scratch as a plain char device driver with custom ioctl calls.

-- 
Grant Edwards               grant.b.edwards        Yow! A dwarf is passing out
                                  at               somewhere in Detroit!
                              gmail.com