Re: [patch 3/4] new serial flow control

[Russell King <rmk+lkml@arm.linux.org.uk>]

On Sun, Oct 09, 2005 at 02:21:30AM +0200, Samuel Thibault wrote:
> Russell King, le Sun 09 Oct 2005 01:01:53 +0100, a ?crit :
> > > How could this look like in userspace?
> > 
> > I think they should be termios settings - existing programs know how
> > to handle termios to get what they want. 
> 
> Hence a new field in the termios structure?
> 
> There was a discussion about this back in 2000:
> 
> http://marc.theaimsgroup.com/?t=96514848800003&r=1&w=2
> 
> and more precisely a remind of SVR4's termiox structure with an added
> x_hflag:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=96523146720678&w=2
> 
> I'm not sure about how we'd want to implement that. The SVR4 approach
> (orthogonal input/output flow control selection) doesn't seem right to
> me: there are really peculiar flow controls that involve both ways. A
> mere enumeration of possible methods might be better.

What I was thinking of was to use some of the spare termios cflag bits
to select the flow control.  You'd only want one flow control type at
one time though.  Eg: define two fields, each to select the signal.

0 - RTS
1 - DTR

0 - CTS
1 - DTR
2 - DSR

You still want CRTSCTS to enable hardware flow control though - which
is what programs expect to happen with that flag enabled.  RTS/CTS
flow control would be type 0 above for compatibility with existing
programs.

However, bear in mind that the majority of the more inteligent 8250-
compatible UARTs with large FIFOs only do hardware flow control on
RTS/CTS - attempting to simulate hardware flow control on the other
signals could end up with up to 64 or 128 characters being sent after
the transmit handshake is deasserted.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core