[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Wed, 02 May 2007 22:26:27 +0200
- From: Thomas.Doerfler at imd-systems.de (Thomas Doerfler)
- Subject: termios XON/XOFF
-----BEGIN PGP SIGNED MESSAGE-----
Eric Norum schrieb:
> 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.
This is a good idea. It would hopefully eliminate the performance impact
on most of the applications without throwing the code away. The only
drawback: the code will not get easier to read (at least for humans).
>> A general reconstruction of this module would be nice, with the goals to:
>> - - 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.
I agree that printk should not itself use interrupts and should not
require the heavy weight of termios with its resources. What I do not
like with the current termios and printk implementation is:
For a driver supporting termios/interrupts and printk/polled, we
actually need a whole bunch of routines which do almost the same.
My vision is that printk and termios share the same driver API and are
built in a way that printk can do proper POLLED I/O even with a driver
that is normally used for interrupt-driven I/O.
So printk would not be on top of termios but side by side.
I have no idea now how this could be achieved, but it would be worth
> 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.
This brings up another requirement: to add "select" support to termios.
Porting termios from a UNIX style system might be too heavy-weight for
some systems. I think our requirements would need an own solution.
On the other side, maybe efficent serial line support is no longer SO
> --Eric Norum <norume at aps.anl.gov>
> Advanced Photon Source
> Argonne National Laboratory
> (630) 252-4793
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler Herbststrasse 8
D-82178 Puchheim Germany
email: Thomas.Doerfler at imd-systems.de
PGP public key available at:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----