>> I remember what great fun it was debugging bidirectional modem ports
>> under Xenix/286.  Uugetty sometimes decided that modem responses was
>> someone trying to log in, and would continue to chat until I
>> recognized the problem.
>
>IMHO, it's an order of magnitude easier to debug such problems in
>user-space than in kernel/device space!  Having "locks" in kernel space
>means it's usually very very difficult to discover the exact state of
>the system from user-space, and/or to forcefully change the state of the
>system (i.e. much harder than simply removing a lock file).  Fixing a
>modem configuration is also usually easier than fixing a device driver,
>at least for most folks.

While I would normally agree with Greg, I have found that the callout device
solution works better (for me) than the uugetty approach.  I'm not sure why,
but I really think it does (and I gather that I'm not alone).

>Also IMHO, such things a ignoring modem control, or flow control, on a
>port are hardware problems and should be fixed with appropriate hardware
>solutions (i.e. jumpers in the connector!).

Ugh.  Only a solution if you have a breakout box or a cable-making kit.  If
you're stuck at home with just a set of cables that have molded connectors, the
software approach is the only answer (I'd hate to tell people that the answer
to getting their terminal working is to buy a breakout box or make their own
magic cable).

--Ken