Re: Env var to tunable mapping?

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

On 09/08/2015 06:32 PM, Stan Shebs wrote:
> On Wed, Sep 2, 2015 at 12:33 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> 
>> [...]
>> 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.
> 
> I think one can make an objective case for going either way, but it
> strikes me as
> simpler in the long run to do separate environment variables.  Special syntax
> always tends to seem plenty powerful in the beginning, then a couple years later
> it's "who thought this made sense??", and then after that, someone comes
> up with a use case for which the special syntax does not work well, and then
> you're roped into lots of syntax-grafting hackery.
> 
> With multiple env vars, the fancy new tunable of 2020 can have its own
> distinctive
> syntax if necessary, no trying to fit into what seemed clever in 2015.

Stan, Thanks for that insight. I had no considered it that far ahead,
but yes, we'd need some syntax to split the single env var, and if we
instead had one env var per variable it would be simpler for each to have
a syntax that suited the purpose.

Cheers,
Carlos.