[ On Sat, November 9, 1996 at 18:25:49 (-0800), Don Lewis wrote: ]
> Subject: Re: serial line ideas
>
> 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?

Hopefully the process doing the killing is running as "uucp" or
something similar and can't kill your average innocent process.

>  Then there's the problem of someone manually clearing the
> lock by removing the lock while some process is still talking to the device.
> How do you recover from that?

Generally nasty things happen and both the old and new processes fail,
leaving the field clear for subsequent processes.

> 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.

You must trust state-driven device drivers a whole lot more than I do.

Remember that not only must the state machine implemented by the driver
be done carefully and properly, it must also be robust enough to
withstand the barrage of stupid events slightly brain-dead hardware
might deliver to it.  I've yet to see one that won't hang in some
situation or another.  I have seen one or two that can be reset if a
carefully applied sequence of signals are sent to the hardware again,
but I don't think I've ever seen one that can 100% reliably be restarted
from the software side.

Which reminds me.  I wonder if a serial driver with locks, written as an
LKM, could be successfully reset by dumping and re-loading it....

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>