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

[Per Hedeland]

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

From: Per Hedeland <per at hedeland.org>
To: wollman at khavrinen.lcs.mit.edu
Cc: FreeBSD-gnats-submit at freebsd.org
Subject: Re: kern/58803: kern.argmax isn't changeable even at boot [PATCH]
Date: Sat, 1 Nov 2003 21:13:18 +0100 (CET)

 Garrett Wollman <wollman at khavrinen.lcs.mit.edu> wrote:
 >
 ><<On Sat, 1 Nov 2003 13:36:47 +0100 (CET), Per Hedeland <per at hedeland.org> said:
 >
 >> 	The trivial patch enclosed seems to fix the problem.
 >
 >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. 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 */
 
 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.
 
 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.
 
 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.
 
 A more interesting question to my mind would be whether the patch breaks
 anything in the kernel due to assumptions of ARG_MAX being a constant.
 
 --Per Hedeland
 per at hedeland.org