>[ On Sun, November  3, 1996 at 19:13:38 (-0500), der Mouse wrote: ]
>> Subject: Re: uugetty for NetBSD

>> Speaking personally, I would say it didn't do it because it shouldn't
>> do it.  If you really must use the same hardware for dialin and
>> dialout, you should be running getty on the dialin device and uucp on
>> the dialout device, and let the kernel do the interlocking _right_,
>> instead of half-baked userland schemes that can go wrong in far too
>> many ways.

>Speaking from hard-won experience, I can very strongly say the *many*
>of us would prefer to keep such locks out in user-land.  I've yet to see
>a kernel that can properly handle all the stupidities various kinds of
>hardware (i.e. modems and UARTS, etc.) can throw at it.  The day async
>driver writers can manage to write a truely robust state machine that
>both properly implements RS-232 (or whatever) state transitions, *and*
>can handle all the illegal transitions that might possibly hget thrown
>at it, then and only then will I trust such things in the kernel.  I do
>not ever want to have to contemplate rebooting just because some stray
>signal threw the tty driver into a fit.

Alternatively, it would be cool if there were a tool (something like
sysctl) that could simple "reset" a serial port in the kernel, and
free any processes blocked on it, that would be Really Cool.  After
all, it's just software.

Maybe this as part of a general tool that is capable of setting
various tty and/or serial port properties (like a souped-up ttyflags).

>At least when user-land locking schemes go wrong, or are not quite
>robust in the face of un-expected events, they can quickly and quietly
>be fixed without interfering with any other current activities on the
>system.

Yes, _something_ that can quickly and easily free the breakage without
rebooting is The Right Thing To Do.

-----------------------------------------------------------------------------
  Michael L. VanLoon                           michaelv@MindBender.serv.net
        --<  Free your mind and your machine -- NetBSD free un*x  >--
    NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3,
        Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32...
    NetBSD ports in progress: PICA, others...
-----------------------------------------------------------------------------