termios XON/XOFF

[Thomas Doerfler]

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

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

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?

wkr,
Thomas.


Eric Norum schrieb:
> On May 2, 2007, at 1:39 PM, Aaron J. Grier wrote:
> 
>> On Wed, May 02, 2007 at 12:01:15PM -0500, Eric Norum wrote:
>>> <Controversial>
>>> My feeling is that the termios code is already too complicated and
>>> that all the code to support XON/XOFF flow control should be optional
>>> or removed.
>>> Does anyone really use this antiquated and unreliable  means of flow
>>> control any more?
>>> I'd be happy with leaving flow control up to the hardware (RTS/CTS)
>>> and dropping all references to flow control from the generic termios
>>> code.
>>> /<Controversial>
>> RTS/CTS is still going to affect termios even if the heavy lifting is
>> being managed in the device driver, and at the very least the knobs  
>> for
>> enabling/disabling it have to be exported.  if RTS/CTS isn't  
>> managed by
>> hardware, that leaves termios to deal with it.
> 
> I see that I wasn't clear enough in my rant above.   I do, in fact,  
> suggest that flow control be limited not only to RTS/CTS, but further  
> to hardware which supports it.  Then the only vestige of flow control  
> support left in the generic termios code is that which passes the  
> enable/disable request down to the individual drivers.
> 
> Like I said, "controversial".
> My guess is that the majority of systems out there support hardware  
> flow control nowadays.
> 
>> termios may not be pretty, but it is at least somewhat standardized.
>> what else is there as far as serial APIs?  the windows world of
>> "everything's a UART" seems incredibly worse.  are there other
>> alternatives?
> 
> I'm not arguing to get rid of termios, just to cut down on its bloat.
> 
>> -- 
>>   Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  aaron at frye.com
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.com
>> http://rtems.rtems.org/mailman/listinfo/rtems-users
> 


- --
- --------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler           Herbststrasse 8
D-82178 Puchheim          Germany
email:    Thomas.Doerfler at imd-systems.de
PGP public key available at:
     http://www.imd-systems.de/pgpkey_en.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGOOTrwHyg4bDtfjQRAlFcAJ9zZvHdcwuoXaNF75+2z9fW2MFcHQCfXlTA
VdNLeSzRmQBOwlTIpsEJ6p0=
=kbVC
-----END PGP SIGNATURE-----