"Simon J. Gerraty" <sjg@zen.quick.com.au> writes:

> 
> Curt Sampson <cjs@portal.ca> writes:
> >On 9 Nov 1996, Charles M. Hannum wrote:
> >> I'd like to see this moved into a library (say, libutil), which can be
> >> used by all the programs that need it.
> 
> >> e.g.  One could imagine an
> >> interface like:
> >> 
> >> 	opentty("/dev/ttyNN", {DIALIN,DAILOUT})
> >> 	-> 0 for success
> >> 	   -1 for failure, leaving errno set
> 
> >I'd rather see a separate lock function `int uucplock(char *ttydev)'
> >for a few reasons:
> 
> There is no reason you can't have a uucplock() which is called by
> opentty() if desired.   But yes, I think a separate locking call is
> best.

Unfortunately, that makes it dependent on the particular locking
method.  I was trying to come up with an interface that could be moved
transparently to kernel tty locking, if we were to do that.  (In that
case, it would just munge the name in some fashion and do an open().)

> You can take it a step further, and have uucplock() call a more
> generic locking function which lets you specify the lock dir, lock
> name and content format.  Why?  Because the guts of such a routine is
> very generic and widely useful for portable interlocking b/w
> processes.

Regardless of the above, that seems like a reasonable thing to have.