Date: Wed, 18 Oct 1995 12:39:49 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: bakul@netcom.com, terry@lambert.org, bde@zeta.org.au, current@freefall.freebsd.org, hackers@freefall.freebsd.org Subject: Re: getdtablesize() broken? Message-ID: <199510181939.MAA00690@phaeton.artisoft.com> In-Reply-To: <199510180704.RAA16305@godzilla.zeta.org.au> from "Bruce Evans" at Oct 18, 95 05:04:23 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >Basically, all of the user space code that uses the standard-since-4.2 > >sys/types.h definitions would need to be rewritten. This is what I > >meant. > > The select() interface has pointers to fd_set's, so it doesn't rule out > using arrays of fd_set's. I think only the FD_ macros and the > documentation would need to be rewritten. OK, I might buy this, though it seems a non-standard way of dealing with the issue. I think the current bit macros would require modification to take address operands, or cast them to long arracys and linearly traverse them in any case. Still, a passed "maxfd" in excess of the array max could have the kernel twiddling the the contents of non-select bit data areas. I think there is no way short of an interface change to cause the user to not have to supply a maxfd <= the actual array length limits, even if you make the kernel not care by breaking the FD_SETSIZE "agreement" between the kernel and the user programs. > >How do I make a program which doesn't guard using FD_SETSIZE the max fd > >it tries to select upon suddenly have a larger statically or stack > >declared bitvector array? > > Don't use the standard FD_ macros. Can't do it without mandating code modifications. If we start down this road, I demand we get rid of tty interfaces other than POSIX termios and just mandate that everyone change their code. Welcome to Plan 9. > Anyway, the kernel needs to handle an arbitrary FD_SETSIZE for > compatibility. There is no reason why the Linux FD_SETSIZE should be as > limited as the FD_SETSIZE that the kernel happened to be compiled with. > Fixed limits defeat binary compatibility. This is particularly annoying > for fixed limits like OPEN_MAX that aren't actually fixed even on the > host OS. See <sys/syslimits.h> for a long list of bogus limits. ??? Let's see: ] #define ARG_MAX 65536 /* max bytes for an exec function */ Type: Bogus. Required by: The process environment being in the user's address space instead of attached to the proc structure and accessed through system calls. Reason: Support of legacy code that directly manipulates the enviroment in violation of the documented interface, preventing those interfaces from moving from section 3 (library) to section 2 (system calls). ] #define CHILD_MAX 40 /* max simultaneous processes */ Type: Administrative (compile time override) Required by: The ability for a user program to fork(2) the system to death. Reason: There exist intentionally and unintentionally disruptive users. ] #define LINK_MAX 32767 /* max file link count */ Type: Pragmatic Required by: There are limitations on the largest number that can be stored in the "link count" field of an on disk inode. Reason: You can't overcome all design limitations and still have reasonable usability. This is one such limit, which is orders of magnitude larger than the highest "reasonable" value. ] #define MAX_CANON 255 /* max bytes in term canon input line */ Type: Bogus Required by: Seperate cannonization buffer. Reason: No one has double-staged tty input for cannonization to cause it to use a queue based buffering mechanism. ] #define MAX_INPUT 255 /* max bytes in terminal input */ Type: Bogus Required by: Seperate cannonization buffer. Reason: No one has double-staged tty input to cause it to use a queue based buffering mechanism. ] #define NAME_MAX 255 /* max bytes in a file name */ Type: Standard Required by: POSIX compliance Reason: The file component name length limit is mandated to be set to 255 characters. ] #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. ] #define OPEN_MAX 64 /* max open files per process */ Type: Bogus Required by: Bash, tcsh Reason: Stupid programmers of shells attempt to split the open file descriptor numeric name space into two components, and to use the upper component to ensure that a collision with the fd for the currently executing script is not stepped on by the script itself. The correct procedure for systems with memory limited open file limits (AIX, BSD, etc.) is to write the programs to use collision detection and move the script fd, using indirect instead of direct reference to the script fd to allow this. The limit also works around a bug in BSD, which is that the open file limit should be bound by a free memory threshold (as should all allocations initiated as a result of a user request) instead of causing a system panic. ] #define PATH_MAX 1024 /* max bytes in pathname */ Type: Standard Required by: POSIX compliance Reason: The path length limit is mandated to be set to 1024 characters. There is in fact a bug in non-terminal symbolic link expansion in vfs_lookup.c that reduces this limit below the mandated 1024 by using coroutine based mutual recursion to avoid increasing stack depth. This is a programatic error, and is thus only tangentially related to this limit. ] #define PIPE_BUF 512 /* max bytes for atomic pipe writes */ Type: Bogus Required by: Implementation Reason: Buffer atomicity is related to the underlying POSIX domain socket based implementation of pipes. This is in fact a limit which must be traded against pipe depth, and is a conceptual limitation on the idea of pipes. ] #define BC_BASE_MAX 99 /* max ibase/obase values in bc(1) */ ] #define BC_DIM_MAX 2048 /* max array elements in bc(1) */ ] #define BC_SCALE_MAX 99 /* max scale value in bc(1) */ ] #define BC_STRING_MAX 1000 /* max const string length in bc(1) */ ] #define COLL_WEIGHTS_MAX 0 /* max weights for order keyword */ ] #define EXPR_NEST_MAX 32 /* max expressions nested in expr(1) */ ] #define LINE_MAX 2048 /* max bytes in an input line */ ] #define RE_DUP_MAX 255 /* max RE's in interval notation */ Type: Bogus Required by: A user space program Reason: The programmer didn't know he could use "" to delimit include files instead of <>? 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?199510181939.MAA00690>