From owner-freebsd-bugs@FreeBSD.ORG Sat Nov 1 12:20:23 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33F0316A4CE for ; Sat, 1 Nov 2003 12:20:23 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FB0443F85 for ; Sat, 1 Nov 2003 12:20:22 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id hA1KKMFY038983 for ; Sat, 1 Nov 2003 12:20:22 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hA1KKM22038982; Sat, 1 Nov 2003 12:20:22 -0800 (PST) (envelope-from gnats) Date: Sat, 1 Nov 2003 12:20:22 -0800 (PST) Message-Id: <200311012020.hA1KKM22038982@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Per Hedeland Subject: Re: kern/58803: kern.argmax isn't changeable even at boot [PATCH] X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Per Hedeland List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2003 20:20:23 -0000 The following reply was made to PR kern/58803; it has been noted by GNATS. From: Per Hedeland 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 wrote: > >< 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 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, 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 (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