From owner-freebsd-hackers Sat Nov 18 13:29:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA18609 for hackers-outgoing; Sat, 18 Nov 1995 13:29:03 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA18597 for ; Sat, 18 Nov 1995 13:28:54 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA09612; Sat, 18 Nov 1995 14:26:30 -0700 From: Terry Lambert Message-Id: <199511182126.OAA09612@phaeton.artisoft.com> Subject: Re: elm problem - "solved" To: grog@lemis.de Date: Sat, 18 Nov 1995 14:26:30 -0700 (MST) Cc: terry@lambert.org, hackers@freebsd.org In-Reply-To: <199511180800.JAA16684@allegro.lemis.de> from "Greg Lehey" at Nov 18, 95 09:00:08 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4653 Sender: owner-hackers@freebsd.org Precedence: bulk > > > /* > > > * 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 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 , 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 */ > }; #ifndef _POSIX_SOURCE /* extended file segment locking set data type */ struct eflock { 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 */ long l_rpid; /* Remote process id wanting this lock */ long l_rsys; /* Remote system id wanting this lock */ }; #endif /* !_POSIX_SOURCE */ I have access to a SunOS 4.1.3 box as well. 8-). > So yes, maybe l_xxx is used as a syspid. But I don't think so, and > it's certainly not documented. Yeah. NFS locking isn't documented. So? Here's some "close" doc: % man fcntl [ ... ] F_RSETLK F_RSETLKW F_RGETLK Are used by the network lock daemon, lockd(8C), to communicate with the NFS server kernel to handle locks on the NFS files. [ ... ] Also not documented: F_CNVT Convert an NFS file handle to an fd for the rpc.lockd process. F_UNLKSYS Remove all locks by remote system id (l_rsys). The kernel code for NFS locking is actually pretty damn obvious, with the exception of function callback registration in the NFS init code to let F_CNVT work when NFS is an LKM. 8-). > > > 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? >From stdio.h: ========================================================================== /* * This is fairly grotesque, but pure ANSI code must not inspect the * innards of an fpos_t anyway. The library internally uses off_t, * which we assume is exactly as big as eight chars. (When we switch * to gcc 2.4 we will use __attribute__ here.) * * WARNING: the alignment constraints on an off_t and the struct below * differ on (e.g.) the SPARC. Hence, the placement of an fpos_t object * in a structure will change if fpos_t's are not aligned on 8-byte * boundaries. THIS IS A CROCK, but for now there is no way around it. */ ========================================================================== (BTW: we're after gcc 2.4: where is __attribute__? 8-)). off_t is 8 bytes. It's a quad. Check the GCC configuration file for "quad" and/or "long long". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.