On 14 Sep 2010 at 14:16, Roland McGrath wrote: > > obviously an AT_ARGMAX computed at execve time would be based on the rlimits > > as well and if later userland changed the rlimits, it'd be userland's problem, > > not that of the kernel (or the kernel could refuse a change that would violate > > its earlier promise). > > This would thoroughly defeat the purpose of adding the thing. The > only reason to have a new thing is so that userland does not have to > mirror the kernel's policy (as it attempts to do now, with the 1/4 > calculation). If the new thing is not something that userland can > use consistently so as not to have to know what the kernel's actual > policy is, then I don't see the point of it at all. userland could never rely on the kernel's policy at all since get_arg_page could have failed for more reasons than overstepping the currently hardcoded ARG_MAX check in there. so what AT_ARGMAX would buy us is to allow the kernel policy to change over time, but it's never been about guarantees, whether POSIX wants such a thing or not. > > > auxv is only appropriate for things that > > > are known at the time of the exec and won't change thereafter. > > > > you mean stuff like AT_EUID et al.? ;) > > The information that these give is about the conditions at startup. > That's what they mean to userland, and userland only uses them to know > the situation before it has made any calls. The definition of AT_EUID > is "effective user ID at program startup", and that fact does not > change. just for my own curiosity, where does this definition come from? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
