From owner-freebsd-current  Wed Oct 18 14:52:31 1995
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id OAA24217
          for current-outgoing; Wed, 18 Oct 1995 14:52:31 -0700
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 OAA24198
          ; Wed, 18 Oct 1995 14:52:16 -0700
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA01079; Wed, 18 Oct 1995 14:45:44 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199510182145.OAA01079@phaeton.artisoft.com>
Subject: Re: getdtablesize() broken?
To: wollman@lcs.mit.edu (Garrett A. Wollman)
Date: Wed, 18 Oct 1995 14:45:44 -0700 (MST)
Cc: terry@lambert.org, bde@zeta.org.au, bakul@netcom.com,
        current@freefall.freebsd.org, hackers@freefall.freebsd.org
In-Reply-To: <9510182102.AA05903@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Oct 18, 95 05:02:03 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2693      
Sender: owner-current@FreeBSD.org
Precedence: bulk

> > ] #define ARG_MAX		65536	/* max bytes for an exec function */
> 
> > Type:		Bogus.
> 
> Type:		POSIX.
> 
> > Required by:	The process environment being in the user's address
> > 		space instead of attached to the proc structure and
> > 		accessed through system calls.
> 
> BZZZZT!  Wrong, but thanks for playing.  You can ask David or John
> about the memory-fragmentation issues which mandate the use of a
> separate VM submap to hold this data while it is being staged between
> the old process and the new process.

BZZZZT!  Replace the enviornment with logical names and hang the logical
name table off the proc struct instead of copying it like this and it
won't *need* to be staged.  Bye bye, staging area.  Mark the environment
as a shared copy-on-modification structure.

> > ] #define CHILD_MAX		   40	/* max simultaneous processes */
> 
> > Type:		Administrative (compile time override)
> 
> Type:		Bogus but POSIX.
> 
> > Required by:	The ability for a user program to fork(2) the system to
> > 		death.
> 
> BZZZZT!  This value should be modifiable at run time.  (It isn't yet.)

Posix?  You mean by way of the limits code retrieving it?

I never said that it shouldn't be modifiable at runtime, but "unlimited"
is a valid value in POSIX.

> > ] #define LINK_MAX		32767	/* max file link count */
> > Type:		Pragmatic
> Type:		POSIX.

Uh... where?  Limits retrieval?

> > ] #define MAX_CANON		  255	/* max bytes in term canon input line */
> > Type:		Bogus
> Type:		POSIX.

Uh... where?  POSIX doesn't mandate implementation.

> > ] #define NGROUPS_MAX	   16	/* max supplemental group id's */
> > Type:		Standard (Interoperability, Legacy)
> > Required by:	NFS, YP
> > Reason:		Excess groups are truncated by the NFS external ID
> > 		representation mechanism.  In point of fact, this
> > 		limit should be 8 to ensure interoperability with
> > 		older SVR3/SVR4 systems.
> 
> No, the NFS and RPC code have their own kluges to deal with broken
> systems.

You mean that they should.  Try mounting an SVR4.0.2 NFS volume from a
BSD system, and then accessing it from a credential with > 8 groups.

> > ] #define OPEN_MAX		   64	/* max open files per process */
> > Type:		Bogus
> Type:		POSIX.

Uh... where?  Limits retrieval?

> > ] #define PIPE_BUF		  512	/* max bytes for atomic pipe writes */
> > Type:		Bogus
> Type:		POSIX.

???

[ ... BC_ * ... ]

> > Type:		Bogus
> 
> Type:		POSIX.
> 
> > Required by:	A user space program
> 
> Required by:	IEEE-CS technical committee P1003.1.
> 
> Any user-space program that executes `bc' to do arithmetic, or uses
> the LC_COLLATE localization support, or executes `expr' to do
> arithmetic.

Yetch.

Revised-Type:	Gross, but POSIX