On Sat, 9 Nov 1996, Don Lewis wrote:

> It'll be pretty rare, but there are times when I don't like gambling.

Unfortunately, that gamble is still there; if your process wedges,
you're stuck. I can't see why wedged proceses woudl be any less
common than processes leaving locks around that then get maintained
because a long-lived process just happened to land on that same
PID, and was created in an small hole so that the watchdog didn't
catch it.

> But you may still have to reboot if the process is keeping DTR up...

You may. However, there's a reasonable chance that calls will
continue to work, so long as you're lucky with people at the remote
end hanging up properly (which you often are). And also, if you're
on a machine with a few dozen active serial ports on it, it would
be much nicer to be able to cu to the port, busy out the modem,
and schedule a reboot later than to have to have an unscheduled
reboot, or an answering modem that otherwise doesn't work.

> I had the source ;-)  The solution to both problems (not quite, getty is
> still susceptible to a brief burst of CD) is to increase the time that
> DTR is held low by pointing adb at a handy kernel variable, though I'd
> prefer a better (per device) interface.

Well, sticking things like per-device DTR drop times in the kernel
is one of the things that puts me off this idea. It just doesn't
seem very clean to imply that changing a modem could require a
kernel recompile. I suppose we could add a stack of sysconf parameters
for this, too, but still....

The other thing, of course, is that LCK..ttyXX locking is pretty
much universial in communications programs. Taylor UUCP uses it.
mgetty uses it. ixopage uses it. All of these programs, and more,
would suddenly become incompatable with NetBSD (except for Taylor
UUCP, presumably, since that's in our source tree) and would need
to be modified by anyone wanting to use them in a dial-in/dial-out
situation.

So for this reason too I don't think it's practical to not to
support UUCP lockfiles. I don't have as much of an objection as
Charles Hannum does to supporting both, but as he points out, it
is bound to create confusion.

cjs

Curt Sampson    cjs@portal.ca		Info at http://www.portal.ca/
Internet Portal Services, Inc.	
Vancouver, BC   (604) 257-9400		De gustibus, aut bene aut nihil.