Date: Sun, 2 Nov 2003 03:20:19 -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: <200311021120.hA2BKJf4060442@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: bde@zeta.org.au
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: kern/58803: kern.argmax isn't changeable even at boot [PATCH]
Date: Sun, 2 Nov 2003 12:12:08 +0100 (CET)
Bruce Evans <bde@zeta.org.au> wrote:
>
>On Sat, 1 Nov 2003, Per Hedeland wrote:
>
>> Garrett Wollman <wollman@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.
Many thanks for your detailed explanation, and my apologies to Garrett
Wollman for jumping to conclusions based on the existing FreeBSD code
and the assumption that adhering to POSIX wouldn't break existing code
(I didn't have the spec at hand).
>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.
Yes, though from a pragmatic point of view I would still think that as
long as this doesn't cause malfunction, it would be preferable to
breaking existing code that would still function with a constant but
incorrect definition.
I realize that at least in the case of ARG_MAX, a program could expect
that all its arguments and environment strings would fit in an array of
size ARG_MAX and thus break badly if this wasn't the case. However I
would expect that "typical" usage would be for sizing an array for
arguments given to a forked/executed program, which wouldn't break as
long as the constant is lower than the actual value.
>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.
OK - removing the use of ARG_MAX without a guarding #ifdef in the source
tree of the base system seems to be pretty trivial, but of course it has
the same problem (unfixable IMHO) visavi the ports. So what is the
conclusion of this? Can we never make ARG_MAX a tunable, or should we
take the same pragmatic but non-POSIX-compliant approach as is
effectively done for OPEN_MAX?
>> 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.
So, would the patch be acceptable if it also
a) Fixed the usage of ARG_MAX in the source tree
b) Made the constant definition be equal to _POSIX_ARG_MAX
c) Prevented setting the tunable lower than _POSIX_ARG_MAX
? Removing the definition altogether would of course be just as simple
as b), I just feel that it would cause unnecessary breakage. And, what
about NCARGS?
Thanks
--Per Hedeland
per@hedeland.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311021120.hA2BKJf4060442>