kern/58803: kern.argmax isn't changeable even at boot [PATCH]

[Bruce Evans]

The following reply was made to PR kern/58803; it has been noted by GNATS.

From: Bruce Evans <bde at zeta.org.au>
To: Per Hedeland <per at hedeland.org>
Cc: freebsd-gnats-submit at freebsd.org
Subject: Re: kern/58803: kern.argmax isn't changeable even at boot [PATCH]
Date: Sun, 2 Nov 2003 18:15:56 +1100 (EST)

 On Sat, 1 Nov 2003, Per Hedeland wrote:
 
 >  Garrett Wollman <wollman at khavrinen.lcs.mit.edu> wrote:
 >  >
 >  >Your patch is incomplete, as it does not remove the definition of
 >  >ARG_MAX from <limits.h> nor fix any programs in the source tree that
 >  >use it.
 >
 >  I find that a rather strange comment, perhaps even indicating a lack of
 >  understanding of the general issues surrounding the replacement of
 >  traditionally hardwired constants with tunables.
 
 wollman is a standards lawyer, so he could have written the following
 clause in POSIX.1-2001-draft7 which requires ARG_MAX to not be defined
 in <limits.h> if it is a tunable:
 
 %%%
 8674               Runtime Invariant Values (Possibly Indeterminate)
 8675               A definition of one of the symbolic names in the following list shall be omitted from <limits.h>
 8676               on specific implementations where the corresponding value is equal to or greater than the stated
 8677               minimum, but is unspecified.
 8678               This indetermination might depend on the amount of available memory space on a specific
 8679               instance of a specific implementation. The actual value supported by a specific instance shall be
 8680               provided by the sysconf( ) function.
 
 Traditionally hardwired constants cannot usefully be replaced by
 tunables without removing the hardwired constants.  Otherwise all the
 users of the hardwired constants get wrong values if the tunables are
 actually used.
 
 >  Removing ARG_MAX would
 >  obviously be quite a broken thing to do. As for the rest, <limits.h>
 >  will bring in e.g.
 >
 >  #define CHILD_MAX                  40   /* max simultaneous processes */
 >  #define OPEN_MAX                   64   /* max open files per process */
 
 These and some of the other definitions in <limits.h> are longstanding bugs
 in <limits.h>.
 
 >  Both of these are tunables of course, run-time tunables even, and the
 >  values given aren't even the defaults. The number of programs in the
 >  source tree that use ARG_MAX seems to be roughly equivalent to the
 >  number that use OPEN_MAX (very few in both cases) - apparently no-one
 >  has seen any reason to fix the latter.
 
 Actually, I fixed all uses of CHILD_MAX and OPEN_MAX in the FreeBSD
 source tree almost 8 years ago.  This wasn't very hard, because CHILD_MAX
 is mostly unused, and most places that want the number of open files
 already used getdtablesize(3).  I removed their definitions from
 <limits.h> at the same time.  Committing this part got sidetracked.
 It is even harder to fix now, since there probably many ports than use
 OPEN_MAX even when it is not defined.  The removal of OPEN_MAX in the
 FreeBSD source tree has only been broken in doscmd.
 
 >  The bottom line is that any program that *really* needs to find the
 >  *correct* value for these has to use sysconf(3) (or possibly sysctl(3))
 >  - and a program that doesn't follow that rule is "broken" regardless of
 >  whether the value is actually tunable or not.
 
 Such programs are only broken on on systems that don't define the
 limits.  Definition of a limit as a constant means that the limit is
 actually constant.  Programs are entitled to expect that the limits
 work as specified if they are defined.
 
 As a practical matter, I would never use the #defined limits except
 for things that are specified to be constant (like INT_MAX), since
 supporting the special cases where the limits happen to be compile-time
 constants mainly just takes more code.  I'm familiar with some POSIX
 conformance tests that take an enormous amount of code to handle all
 the possible cases.
 
 >  It could possibly make sense to disallow the setting of kern.argmax to a
 >  lower value than what is given via <limits.h> (and perhaps have a lower
 >  value than the actual default there, similar to the above) - but I don't
 >  see this being done for other tunables.
 
 POSIX also requires {ARG_MAX} >= _POSIX_ARG_MAX && __POSIX_ARG_MAX == 4096,
 so there must be a lower limit of 4096 on any tunable.  Indeed, this stuff
 is quite broken for other tunables, sysctls and setrlimit() calls that
 can reduce the limits below their POSIX minimums or below ones that work.
 
 Bruce