From owner-freebsd-hackers  Sat Nov 18 00:22:07 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id AAA02612
          for hackers-outgoing; Sat, 18 Nov 1995 00:22:07 -0800
Received: from cls.net (freeside.cls.de [192.129.50.1])
          by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id AAA02605
          for <hackers@freebsd.org>; Sat, 18 Nov 1995 00:22:02 -0800
Received: by mail.cls.net (Smail3.1.29.1)
	  from allegro.lemis.de (192.109.197.134) with smtp
	  id <m0tGiXP-0011jIC@cls.net>; Sat, 18 Nov 95 08:22 GMT
From: grog@lemis.de (Greg Lehey)
Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany
Phone: +49-6637-919123
Fax:   +49-6637-919122
Reply-To: grog@lemis.de (Greg Lehey)
Received: (grog@localhost) by allegro.lemis.de (8.6.9/8.6.9) 
	id JAA16684; Sat, 18 Nov 1995 09:00:08 +0100
Message-Id: <199511180800.JAA16684@allegro.lemis.de>
Subject: Re: elm problem - "solved"
To: terry@lambert.org (Terry Lambert)
Date: Sat, 18 Nov 1995 09:00:08 +0100 (MET)
Cc: hackers@freebsd.org (FreeBSD Hackers)
In-Reply-To: <199511171848.LAA05946@phaeton.artisoft.com> from "Terry Lambert" at Nov 17, 95 11:48:19 am
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 2373      
Sender: owner-hackers@freebsd.org
Precedence: bulk

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