We *do* know for sure that the relationship has always been there. At
least in Linux, and I bet in 99% of all other Unixes too. The arguments
simply have traditionally been counted as part of the stack size.
Or did you mean the latter part?
The fact is, we *also* know for sure that anybody that depends on
_SC_ARG_MAX being exact has always - and will continue to be - broken.
Again, because of not only older kernels but also because even with the
patch in question, we don't count argument sizes exactly.
I do agree that we should at least make the "MAX(stacksize/4, 128k)"
change for backwards compatibility. That is actually a potential
regression, but it has nothing to do with a new _SC_ARG_SIZE, because
quite frankly, it's a regression *regardless* of whether we'd expose a new
rlimit or not!
And one of the reasons I'm so down on new resource limits is that nobody
then has the code to actually update them. You won't see it in "ulimit -a"
until you have a newly compiled bash that cares etc etc, so as far as I'm
concerned, I see hat RLIMIT_ARG_MAX as nothing but a pain. It actually
makes the code more complex, makes it work less like we and others have
*always* worked, and doesn't even help users - quite the reverse.
I don't like unnecessary complexity. If the RLIMGI_STACK/4 check is truly
so troublesome, let's just *remove* it, rather than add more crap and
complexity on top of it!
Problem solved.
Linus
--
