Consensus on allowing tunables to use GLIBC_* namespace env vars.

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

I'm looking for consensus on allowing patches that enable the use
of multiple environment variables starting with GLIBC_* to alter
the behaviour of a program under the rules outlined for tunables [1].

The discussion of using one large GLIBC_* env var, groups of them,
or 1:1 mappings are something we can discuss later. Why? Because there
is no ABI for the env vars other than "valid for one release." If we
decide to aggregate them then the next release we'll clean them all
into one env var. If we decide to split them out, then we'll put them
all into their own env vars the next release.

At Cauldron 2015 Siddhesh presented an internal API to start
aggregating and converting existing env vars into what will eventually
become tunables.

A comment made by Roland at the talk was roughly "It looks good, but
don't emit/accept the new-style tunable GLIBC_* env vars yes", which is
good advice because it complicates accepting the new internal API patches
with this discussion of what should the env vars looks like and if they
should even exist. However, I see a need to have that discussion now,
rather than later.

At the distribution level, for API and ABI reasons, we can't add global
symbols to give users the ability to change the behaviour of the library.
Environment variables however have no ABI guarantee, and we can add them
as we please. Further to that I know of cases, like the backwards-memcpy
case and the default-thread-stack-size case, where Red Hat has had to support
having ways to tune the library to support one behaviour or another.
The easiest way to do this is via environment variables or file presence.
As upstream we can't ignore that there is a need for both upstream, and
distro tunables. The tunables discussions are a direct result of this need.

The obvious precedent is the Linux kernel with the myiad of tunables
values that allow people to achieve highly tuned systems for high
throughput or low latency. That complexity has a cost and some of
that is mitigated through applications like tuned [2].

Therefore one can't just say that env vars are going to get too
complicated for anyone to maintain. We have the Linux kernel as an
example that continues to operate without failing. We have also
reserved the right to change tunables each release with no ABI,
so there is that escape hatch.

In summary:

- Allow patches that control glibc behaviour via environment
  variables, subject to tunables rules, and good design.
  
  - Even though internal tunables API is not yet done.

- Use an env var namespace prefix of GLIBC_* for all tunables.

- Use an env var naamespce prefix of GLIBC_PTHREAD_* for pthread
  tunables, like elision disable.

Thoughts?

Cheers,
Carlos.

[1] https://sourceware.org/glibc/wiki/TuningLibraryRuntimeBehavior#How.3F
[2] http://linux.die.net/man/8/tuned