Re: Consensus: Tuning runtime behaviour with environment variables.

["Carlos O'Donell" <carlos at redhat dot com>]

On 06/20/2013 04:09 PM, Mike Frysinger wrote:
> On Wednesday 29 May 2013 00:56:50 Carlos O'Donell wrote:
>> I'd like to drive some consensus around the idea of using
>> environment variables to tune runtime behaviour in glibc.
> 
> i probably missed the boat on this, but the way i generally see things:

No boat was missed. This is an ongoing discussion about the
design and use env vars to change runtime behaviour.

>  - env vars that affect global runtime-immutable things are fine (e.g. every 
> LD_* var we have today ?), assuming of course we have documentation in place 
> (i believe some of the malloc ones were added w/out any documentation which 
> meant they rarely got used even though they were super useful).

Looking at the existing env vars is part of this work and we'll
see how they fit into the new policy (Joseph's request).

As you note there are already env vars to change the behaviour
of many facts of glibc, say ~20-30 actually do really drastic
things to the runtime. We need to get a handle on this before
it gets out of control, and that's part of what this discussion
is about.
 
>  - i'm not a big fan of env vars that affect default settings when a C API 
> (whether it be _np namespaced or whatever) is better off.  that said, i don't 
> really have an answer that satisfies the proposed constraints other than using 
> env vars (changing behavior of programs where recompiling isn't an option).

One option is to preload a library that interacts with the glibc tunables
C API and sets the defaults. You'd need one such library for each set of
tunables you have for each application you want to tune. That also won't
work if you need to set a tunable early, say before ifunc relocations
are handled, before elision is enabled, before stacks are setup, etc. etc.

This notion of a preloaded DSO that sets defaults isn't entirely a
foreign concept. It's a "runtime customization plugin" :-) However, the
use of env vars is easier and faster for developers and admins and
doesn't preclude the latter.

> if the namespace was clearly defined (e.g. using GLIBC_XXX), and we documented 
> things, and we restrict their use to init time (rather than the code always 
> doing getenv() as then people may abuse it at runtime), then i could stomach 
> it.

That's exactly the kind of thing we're aiming for.

Cheers,
Carlos.