termios XON/XOFF

[Eric Norum]

On May 2, 2007, at 2:22 PM, Thomas Doerfler wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> although I am not currently using XON/XOFF, I vote against eliminating
> it. In various industrial systems, XON/XOFF is the only option of flow
> control, because it requires only three wires (or two optical fibers)
> for data transmission and flow control.
>
> As far as I can remember, years ago I have implemented the majority of
> XON/XOFF flow control code in termios for a RTEMS-based display  
> system.
> - From today's view, the implementation is not very nice, but I  
> think it
> is functional.
>
> I can't agree with Eric's statement to leave even HW flow control a
> hardware/driver issue. This will leave MANY systems out without any  
> flow
> control functionality (remember that even the QUICC/PowerQUICC family
> has no means to signal, that its receive buffer is nearly overflowing
> because the application reads too slow).

What about making termios software (XON/XOFF or RTS/CTS) flow control  
a configuration option?   In my uses of RTEMS, for example, none of  
the older hardware platforms which lack hardware flow control are  
used in applications where flow control is needed.
The result would be a decrease in both code size and in the number of  
instructions run with interrupts disabled.

>
> IMHO, adding a "flush" functionality to the input direction is not  
> such
> a big benefit for me to sacrifice some of the existing  
> functionality for
> it.
>
> I agree with Eric that termios is too complicated, but I think it  
> is not
> because of the functionality available, but because the functionality
> has been added piece by piece (some of this shame goes to me ).
>
> A general reconstruction of this module would be nice, with the  
> goals to:
>
> - - give the source code a better structure
> - - allow implementation of further features (which ones?)
> - - reduce the overhead
> - - reduce the time interrupts are blocked
> - - improve the interface to the drivers
> - - possibly even add part of the printk support (allowing printk over
> interrupt driver drivers?)

Strong disagreement here.
printk should require neither termios nor interrupts.
- printk is used in systems which may be severely restricted in code  
size.  Bringing in all of termios is almost certainly going to undo  
all Joel's hard work in reducing memory footprint.
- printk should be able to get the 'dying gasp' error message out  
even when interrupts are non functional.

>
> The problem with this approach is, that we might need a modified
> interface to the drivers and that the work to be done should not be
> underestimated.
>
> Once again: I see no particular need to do this urgently, but this  
> might
> become a longer-term project.
>
> what do you all think?

Once upon a time, several years ago, I was working on updating the  
network code to a newer version of BSD.  As part of this work I also  
started bringing the whole BSD termios code to RTEMS (among other  
things this would have added select() support for serial lines).    I  
still have some of the code around somewhere -- one change was to add  
sleep/wakeup scheduling semantics to RTEMS.
I wasn't happy with the non-deterministic scheduler times that  
resulted nor with the code bloat that I encountered.
I ended up mothballing the whole project.

-- 
Eric Norum <norume at aps.anl.gov>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793