Re: [PATCH 1/9] Add vectorized getenv for glibc use

[Roland McGrath <roland at hack dot frob dot com>]

> I think this can go in as long as Roland has no objections. Roland has
> expressed some concerns with using environment variables to expose glibc
> tunables to users. If I understand correctly I think Roland's concerns
> were around performance, and control (user vs. system admin). I'll
> let Roland speak for himself though.

I had expected that any sensible implementation would look at the
environment only once per program invocation, so performance was never
my chief concern.  What concerns me is the complexity of the system
and the subtle security implications of obeying new environment
variables.  

I explained this before in the context of Siddhesh's proposal for an
environment variable affecting pthread stack size.  For that case, we
are starting with an API to change the default from inside the program
and this is sufficient for now and can be built on to prototype future
possibilities.

Those concerns remain about all new environment variables and I
certainly don't think we should be introducing any new magic
environment variables at this point in the cycle.  Perhaps in the long
run environment variables will in some fashion be part of the
interface for tunables.  But we need to have a thorough contemplation
of the whole area of tunables before we add anything to any part of
the libc interface.  Special new magic interpretation of user-fungible
bits like the environment is among the most dangerous approaches and
we must be extremely circumspect.

If there is in future some need to look at more environment variables,
then this implementation of doing that efficiently seems fine enough.


Thanks,
Roland