Subject: Re: uugetty for NetBSD
To: Perry E. Metzger <email@example.com>
From: Curt Sampson <firstname.lastname@example.org>
Date: 11/11/1996 10:39:01
On Mon, 11 Nov 1996, Perry E. Metzger wrote:
> > Yes. Flock doesn't work on character devices.
> Why don't we just fix that?
>From my quick reading of the source: flock() just calls lockf()
with a start of zero and a range of the length of the file. (Lockf
is in the VFS layer.) Currently there is no lockf for device-type
If you want to create one, the semantics get interesting. Obviously,
it's possible to lock range 512-1023 on /dev/rds0c. However, what
if someone wants to lock the range 600-800? Or what if they want
to lock any range at all on /dev/ttya?
This is definitely an interesting thought, though, and might be
worth some discussion on tech-kern (to which I've cc'd this message).
Oh, and the other reason? Most every program in the world that uses
serial ports uses LCK..ttyXX locking. Thus, getty really should be
able to do this so that uucp, mgetty, ixocico, kermit, tip, etc.
all don't have to be changed just to accommodate NetBSD. Since
it's used in several programs, it might as well go into libutil
where it can be shared, and where it's handy for anyone else who
needs to lock a TTY using the standard locking mechanism.
Also, it's one of the most (if not *the* most) portable locking
mechanisms out there, so if someone's writing a portable program
they can just rip out this code and compile it on other systems
that don't have this is a library already.
Curt Sampson email@example.com Info at http://www.portal.ca/
Internet Portal Services, Inc.
Vancouver, BC (604) 257-9400 De gustibus, aut bene aut nihil.