On Nov 9,  7:01pm, Curt Sampson wrote:
} Subject: Re: serial line ideas
} On Sat, 9 Nov 1996, Don Lewis wrote:
} 
} > I worry about things like putting the pid in the lock file for such
} > purposes.  What if the process holding the lock dies without removing
} > the lock file, and when you get around to checking on who is holding the
} > lock, the process ids have wrapped around and some innocent process now
} > has that pid?
} 
} Well, it looks as if it's locked when it's not. It could be a
} problem for production systems, if a long-lived process somehow
} gets that same PID. This is, however, not going to be a terribly
} common occurance, and is easily fixed by hand.

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

} Also, a watchdog
} for this is not hard to write if this is a serious concern.

I think you'll run into a race condition.  What if the process holding the
lock does so for just a little under the time it takes the pids to cycle
once.

} > With kernal locks, the lock has to be held by a process that has the
} > device open.  If the process dies, the lock is unlocked.  You can find
} > out what process(es) have the device open (thus locking it) with fstat.
} 
} True enough. On the other hand, if a processes wedges (gets stuck
} in a non-interuptable state, such as waiting for disk I/O), that
} device now remains locked forever and you have to reboot your system
} before you can have access to it.

But you may still have to reboot if the process is keeping DTR up, unless
you go to a scheme where DTR is totally manually controlled independent
of whether the device is open or not (well, you could drop it on close,
but all processes would have to assume that it is in an unknown state when
the open the device and wiggle it accordingly).

} Another thing you can't do with kernel locks is to lock the port
} without bringing up DTR, which you might want to do if you wanted
} to await an incoming call that you don't want your modem to answer,
} for example.

Communications by Morse code by by watching RI?

} (Actually, come to think of it, you'd need some special hacks in
} the kernel to deal with DTR, too, otherwise incoming and outgoing
} calls wouldn't be compatable. When getty does its open, DTR must
} come up so that the modem will answer a ring. However, at this
} point getty cannot have the port locked, because that would prevent
} uucico from dialing out. So uucico does a dialout, does its thing,
} and then closes the port, which is supposed to drop DTR and hang
} up. The kernel at this point has to have some code that will bring
} down the DTR for a certain length of time, and then bring it back
} up again, despite the fact that getty is still hanging in that very
} same blocking open that brought up DTR that was called before the
} uucico session. This isn't terribly pretty.)

This is pretty much how SunOS 4.x does it.  The only two problems I've
run into were related to the time DTR is held low.  If the interval
is too short, some Telebits don't really get fully reset.  Also, they
may not have cleared CD by the time DTR comes back, and getty's open()
unblocks when it does.  For some reason getty wants to do a second
open() on the device, doesn't check for failure (which occurs in this
case because CD has dropped in the meantime), and it then proceeds to
go off into the weeds.  The latter is a userland problem -- if only
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.

			---  Truck