I know everyone must be tired after the effort of getting NetBSD-1.0
out.   Its a great system and I want to switch to it asap...
But first I need to get my mail/news happening....

Following on from my blathering the other day, I had a look at hacking
fcntl() to support 32bit off_t's as well as 64bit and while F_SETLK
could probably be made to work I'm not so sure about F_GETLK.

SETLK could handle it in the unknown l_type case, by loading an
flock32 struct (flock with off_t replaced by long) with the data, and
checking if l_type is suddenly known, and if so, re-load the flock
struct with the now correct data (casting the long's in flock32 to
off_t).

I'm not sure that the same trick can be used when reading a lock, as
the kernel will see everything happily as flock structs and has no way
of checking that the user's struct is actually an flock32 struct, in
which case we will either overwrite part of the users data space that
we should not - or we get a fault of some kind.

Sooo, I seem to be stuck with implementing old.fcntl().  Or should it
simply use ibcs2_fcntl() ?

I was thinking that old.fcntl() could simply call fcntl() for all but
the F_*LK cases.  A quick grep of /usr/src shows that only a few progs
(files listed below) shipped with NetBSD actually use F_*LK, so only
these would need to be re-compiled after old.fcntl is installed.

lib/libpthread/pthreads/fd.c:541:/*		case F_SETLKW: */
lib/libpthread/pthreads/fd.c:546:/*		case F_SETLK: */
lib/libpthread/pthreads/fd.c:547:/*		case F_GETLK: 
usr.bin/vi/common/exf.c:819:	if (!fcntl(fd, F_SETLK, &arg))
usr.bin/at/at.c:205:	fcntl(lockdes, F_SETLKW, &lock);
usr.bin/at/at.c:262:	fcntl(lockdes, F_SETLKW, &lock);
usr.sbin/sendmail/src/conf.c:1890:		action = F_SETLK;
usr.sbin/sendmail/src/conf.c:1892:		action = F_SETLKW;
usr.sbin/amd/config/mtab_file.c:94:	rc = fcntl(fd, F_SETLKW, (caddr_t) &lk);

So, if I implement this, do the core team want it?  Anybody?
Is the i386 the only arch that has binaries that cannot be re-compiled
(because they come from commercial vendors?) should this be
implemented as an i386 specific feature?

--sjg