On 10 Nov 1996, Charles M. Hannum wrote:

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

Could we not achieve the same thing by replacing uucplock() in the
shared library with a function that always returns success, thereby
relying entirely on the kernel locking presumably added to open()?

Another possibility would be to have uucplock check the kernel to
see if it supports kernel tty locking, and just return success if
it does. Though this is starting to smack of feeping creaturism.

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

I'll write up a manual page for it, then, and post it here for
perusal.

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.