Subject: Re: uugetty for NetBSD
To: Charles M. Hannum <mycroft@mit.edu>
From: Curt Sampson <cjs@portal.ca>
List: current-users
Date: 11/09/1996 13:14:47
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.
Me too. And I'll be happy to do all the work necessary, since
someone's interested in committing 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:
1. If we include the functionality of open(2), we also have to pass
all of the parameters for that syscall as well.
2. With opentty(), we can't differentiate between errors relating
to the lockfile and errors relating to the device itself. For
example if a program running under the uucp ID has access to the
device itself, but someone has gone and changed the ownership of
/var/spool/lock to root, we won't be able to return to the program
exactly what's wrong.
3. Some programs might not wish actually to open the tty after
they've done a lock. An example would be a program that just stops
all modem activity for a brief period of time (so that you could
make sure your line is free for a a voice call, for example).
What are the advantages of opentty() over uucplock()?
Another advantage to uucplock, of course, is that it's basically
written. :-) I specifically did not look at any other source when
I wrote the locking function for getty, so I'd want someone to have
a look at some other implementations of this (say, from Taylor UUCP
and mgetty) and tell me if there's anything silly I've missed.
One thing I'd like to see uucplock() return is the PID of the
process that has the lock, if the tty is already locked. But this
leaves open the question of what one returns when successful at
locking, and what one returns when a failure of some other kind
has occurred. Perhaps the current PID and zero, respectively?
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.