This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Env var to tunable mapping?
- From: Stan Shebs <stanshebs at google dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Tue, 8 Sep 2015 17:32:21 -0500
- Subject: Re: Env var to tunable mapping?
- Authentication-results: sourceware.org; auth=none
- References: <55D358D8 dot 7020303 at linux dot vnet dot ibm dot com> <55D3615F dot 1020300 at linaro dot org> <55D3AA72 dot 7000901 at linux dot vnet dot ibm dot com> <55D48F62 dot 6010902 at linaro dot org> <55D4ADC7 dot 3050008 at linux dot vnet dot ibm dot com> <20150819174147 dot GO2415 at spoyarek dot pnq dot redhat dot com> <55E732E1 dot 1070106 at redhat dot com>
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