Path: utzoo!utgpu!water!watmath!onfcanim!dave
From: dave@onfcanim.UUCP (Dave Martindale)
Newsgroups: comp.dcom.modems
Subject: Re: Solution to Problems with UUCP/modems.
Keywords: modems ACU driver
Message-ID: <16147@onfcanim.UUCP>
Date: 15 Sep 88 20:18:23 GMT
References: <14170@comp.vuw.ac.nz> <323@uncle.UUCP> <37899@pyramid.pyramid.com> <1260@moscom.UUCP> <13564@mimsy.UUCP>
Reply-To: dave@onfcanim.UUCP (Dave Martindale)
Organization: National Film Board / Office national du film, Montreal
Lines: 28

In article <13564@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>
>People claim that it is `inelegant' to put this in the kernel.  `Why,'
>they cry, `should we do it here when we can do it in user mode?'

It's worth noting that the Berkely "acucntrl" runs in user mode in
name only - it goes poking around in /dev/kmem to do its work.

>Indeed, the very reason that the file system is in the kernel is the
>same reason that tty multiplexing should be (and, in other cases,
>already is) also in the kernel.  (One can argue that services such as
>these should be moved back out into separate processes, a la Mach;
>nonetheless, the multiplexing should be centrally sited.)

Also, if it really was centrally sited, it would work properly for
all devices all the time.  Acucntrl certainly doesn't work properly
all the time.  I've lost count of how often I've dialed up a modem
on onfcanim, got carrier, and then got hung up on because uucico also
wanted to use the line and I wasn't logged in yet.  A kernel-based
interlock would just look at the carrier detect bit - if it was up,
uucico's open would fail.

This still leaves a window of a second or two where I can call into a
modem which uucico has already allocated for dailout, but it's much
smaller.  And even that could be narrowed by kernel fixes - by not
raising DTR to an answer modem until the kernel sees RING asserted.

	Dave Martindale