Subject: Re: Formal getty replacement yet?
To: None <current-users@NetBSD.ORG>
From: Ken Hornstein <firstname.lastname@example.org>
Date: 12/19/1994 14:53:14
>> 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