This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus: Tuning runtime behaviour with environment variables.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Andreas Jaeger <aj at suse dot com>, "Ryan S. Arnold" <ryan dot arnold at gmail dot com>, Andi Kleen <andi at firstfloor dot org>, David Miller <davem at davemloft dot net>, Siddhesh Poyarekar <siddhesh at redhat dot com>, Andreas Schwab <schwab at suse dot de>
- Date: Wed, 29 May 2013 11:16:38 -0400
- Subject: Re: Consensus: Tuning runtime behaviour with environment variables.
- References: <51A58A92 dot 4050508 at redhat dot com> <20130529053454 dot GB20323 at brightrain dot aerifal dot cx>
On 05/29/2013 01:34 AM, Rich Felker wrote:
> On Wed, May 29, 2013 at 12:56:50AM -0400, Carlos O'Donell wrote:
>> Community,
>>
>> I'd like to drive some consensus around the idea of using
>> environment variables to tune runtime behaviour in glibc.
>
> Like Roland, I'm largely opposed to environment variables or any means
> of tuning the library behavior for an already-built/installed
> application. However, if the community deems them desirable, my hope
> would be that, at the very least:
Rich, thank you for expression your opinion. I'm noting that you
are largely opposed to env vars for tuning library behaviour.
> - Aside from a few existing grandfathered-in ones, environment
> variables or other tunables should merely transform the library from
> one conforming implementation to a different conforming
> implementation. No settings should make it non-conforming.
Fully agreed.
> - Any settings which could cause a conforming application which works
> correctly with the default settings to stop working correctly should
> be ignored completely when the program is suid or AT_SECURE is set
> in the aux vector.
Fully agreed.
> - The namespace for glibc tuning variables should be clearly defined
> in such a way that they can be mechanically removed from the
> environment without having to worry that future additions will be
> missed by the stripping code.
Fully agreed. It is lamentable that previous env vars weren't expored
in some sensible namespace. All future tunables will inhabit a fixed
namespace e.g. GLIBC_*, such that you can remove them easily.
I have added all three of these to the documentation for tuning here:
http://sourceware.org/glibc/wiki/TuningLibraryRuntimeBehavior
Cheers,
Carlos.