Date: Wed, 18 Oct 1995 14:45:44 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: wollman@lcs.mit.edu (Garrett A. Wollman) Cc: terry@lambert.org, bde@zeta.org.au, bakul@netcom.com, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? Message-ID: <199510182145.OAA01079@phaeton.artisoft.com> In-Reply-To: <9510182102.AA05903@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Oct 18, 95 05:02:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > ] #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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510182145.OAA01079>