Date: Fri, 4 Aug 2000 15:20:35 +0100
From: Roger Gammans <roger@computer-surgery.co.uk>
The card has auto support in hardware for those options, outside of
the uart. Options 2/3 you can obviously implement this way with
ioctl( TIOCMBIS/TIOCMBIC and friends) but in this card you need to
enable that option first anyway.
This mean we have three options as I see it.
1) Chose one, and that what linux supports,
then do ostrich impression
2) (1a really) Chose one mode as default make userspace
bang the h/w directly to change it.
3) Add a (new?) ioctl to change it. Define a default.
Does this explain it better?
The problem with half-duplex support is that *everyone* seems to do it
different. Some use RTS high, some use RTS low, some use DSR/DTR/CD,
etc., etc. etc. Some require that you wait some minimum amount of time
after the transmitting to flip the control line, some require that you
flip the control line after not more than some time period, etc., etc.
So as a result, my bias has been to leave out any kind of half-duplex
support, since there's no standard, and so trading off the limited
interest with the inevitable software bloat that this would cause has
caused me to be very suspicious of supporting this, especially since
there is the userpsace TIOCMBIS/TIOCMBIC option.
I'm willing to be convinced, if someone can come up with some official
RS-232 standard indicating this *is* how you support half-duplex, and
some kind of proof that the standard is even vaguely universally obeyed.
>From what I've seen of the people requested half-duplex support, though,
that hasn't been my impression about the state of affairs. (It's even
worse than the nonsense of using DTR/DSR for hardware handshaking ---
which I'll consider adding *after* 2.5 ships. :-)
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:16 EST