This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/9] Add vectorized getenv for glibc use
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org, Andi Kleen <ak at linux dot intel dot com>
- Date: Tue, 28 May 2013 15:49:20 -0700 (PDT)
- Subject: Re: [PATCH 1/9] Add vectorized getenv for glibc use
- References: <1368225725-14283-1-git-send-email-andi at firstfloor dot org> <1368225725-14283-2-git-send-email-andi at firstfloor dot org> <5191DFB8 dot 4030709 at redhat 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