Date: Fri, 17 Nov 1995 11:48:19 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: grog@lemis.de Cc: hackers@FreeBSD.ORG Subject: Re: elm problem - "solved" Message-ID: <199511171848.LAA05946@phaeton.artisoft.com> In-Reply-To: <199511171732.SAA26447@allegro.lemis.de> from "Greg Lehey" at Nov 17, 95 06:32:43 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
> 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.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511171848.LAA05946>