Env var to tunable mapping?

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

On 08/19/2015 01:41 PM, Siddhesh Poyarekar wrote:
> On Wed, Aug 19, 2015 at 11:24:39AM -0500, Paul E. Murphy wrote:
>> As Siddhesh notes, there are already quite a few env variables which alter
>> the behavior of libc and company. He does a good job of describing
>> the requirements of such a framework. I see no reason why it can't
>> be approached incrementally.
> 
> It will in fact be approached incrementally.  I have patches on the
> siddhesh/tunables branch that I need to fix up following our
> discussion at the GNU Tools Cauldron and post on the list.  I hope to
> be able to do it before the end of the week.
> 
>> Adding to the requirements, would a common syntax for tunable environment
>> variables be desirable?
> 
> The namespace requirements are frozen, but the open question currently
> is how we read values for those tunable names.  My initial draft made
> environment variables out of those names, but the consensus in the
> room last week leaned towards an alternate expression, perhaps a
> single environment variable with a string value that is parsed to get
> all tunable values.  There could be other ideas, I'll think about it
> once I get the initial framework in.

To be clear it was Roland McGrath who supported the position that we have
a single env var for all tunables. I heard no other opinions for this case.

I do not support that position. I posit we should have one tunable per env
var, and that we should follow namespace rules for those env vars e.g.
always start with GLIBC_*. There is precedent for this, the Gnome xdg-app
framework is already exporting XDG_* env vars in a sensible namespace, and
as a framework just above us, they already have to deal with this kind of
pseudo-API.

You can argue that unsetting all tunables is harder. It is.

Instead of:
unset GLIBC_TUNABLES

You have to:
env | while read env; do if [[ $env == GLIBC* ]]; then unset $env; fi; done;

But what's the more probable case? I would argue it's more probably that you
want to set or unset just one tunable. Having them all in one string is therefore
more complicated and requires special shell set and unset functions to assist.

If we start off on the right foot, and document that all GLIBC_* env vars need
to be unset if you want default behaviour, then people will listen, and they
will follow. Better yet we talk to Michael Kerrisk and get it documented in
the man pages early how to set or unset the tunables.

More people have to speak up about which interface they would like to see.

Cheers,
Carlos.