Date: Sat, 18 Nov 1995 09:00:08 +0100 (MET) From: grog@lemis.de (Greg Lehey) To: terry@lambert.org (Terry Lambert) Cc: hackers@freebsd.org (FreeBSD Hackers) Subject: Re: elm problem - "solved" Message-ID: <199511180800.JAA16684@allegro.lemis.de> In-Reply-To: <199511171848.LAA05946@phaeton.artisoft.com> from "Terry Lambert" at Nov 17, 95 11:48:19 am
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes:
>
> > Well, we found the problem. lock_info is of type struct flock. In
> > BSD systems derived from Net/2, and also in Linux, SunOS 4, System
> > V.3, struct flock is defined as
> >
> > /*
> > * Advisory file segment locking data type -
> > * information passed to system by user
> > */
> > struct flock {
> > short l_type; /* lock type: read/write, etc. */
> > short l_whence; /* type of l_start */
> > off_t l_start; /* starting offset */
> > off_t l_len; /* len = 0 means until end of file */
> > pid_t l_pid; /* lock owner */
> > };
>
> BZZZT. SunOS4 has the syspid as well. It's necessary for NFS locking,
> which is why my NFS locking kernel support patches had it as well.
OK, here's the extract from my SunOS 4.1.3_U1B man page:
The record to be locked or unlocked is described by the
flock structure defined in <fcntl.h> as follows:
struct flock {
short l_type; /* F_RDLCK, F_WRLCK, or F_UNLCK */
short l_whence; /* flag to choose starting offset */
long l_start; /* relative offset, in bytes */
long l_len; /* length, in bytes; 0 means lock to EOF */
pid_t l_pid; /* returned with F_GETLK */
};
In <sys/fcntlcom.h>, the definition is:
/* file segment locking set data type - information passed to system by user */
struct flock {
short l_type; /* F_RDLCK, F_WRLCK, or F_UNLCK */
short l_whence; /* flag to choose starting offset */
long l_start; /* relative offset, in bytes */
long l_len; /* length, in bytes; 0 means lock to EOF */
short l_pid; /* returned with F_GETLK */
short l_xxx; /* reserved for future use */
};
So yes, maybe l_xxx is used as a syspid. But I don't think so, and
it's certainly not documented.
> > I really have great difficulty understanding why this change was made.
> > It means that old FreeBSD and BSD/386 binaries won't work correctly
> > under FreeBSD or BSD/OS Versions 2. I can't see any advantage at all
> > in this change. Grrrr.
>
> Think packing on RISC systems. You put the largest followed by the
> smallest to reduce the copyin overhead.
Think reality. short=2 bytes. long=4 bytes for all the systems we're
talking about. The only 8-byte constraint in most RISC systems is for
doubles on the Sparc architecture--I don't know for sure for other
RISCs. Can you point to more restrictive constraints?
Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511180800.JAA16684>