Date: Sat, 1 Nov 2003 12:20:22 -0800 (PST) From: Per Hedeland <per@hedeland.org> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/58803: kern.argmax isn't changeable even at boot [PATCH] Message-ID: <200311012020.hA1KKM22038982@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/58803; it has been noted by GNATS. From: Per Hedeland <per@hedeland.org> To: wollman@khavrinen.lcs.mit.edu Cc: FreeBSD-gnats-submit@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@khavrinen.lcs.mit.edu> wrote: > ><<On Sat, 1 Nov 2003 13:36:47 +0100 (CET), Per Hedeland <per@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@hedeland.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311012020.hA1KKM22038982>