This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: A single environment variable for tunables vs a variable per tunable
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Siddhesh Poyarekar <sid at reserved-bit dot com>, Roland McGrath <roland at hack dot frob dot com>, "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Steve Munroe <sjmunroe at us dot ibm dot com>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, stli at linux dot vnet dot ibm dot com, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, vapier at gentoo dot org
- Date: Fri, 18 Sep 2015 00:19:13 -0400
- Subject: Re: A single environment variable for tunables vs a variable per tunable
- Authentication-results: sourceware.org; auth=none
- References: <55F33220 dot 8050105 at linux dot vnet dot ibm dot com> <20150917043712 dot GA6834 at vapier dot lan> <55FACCF4 dot 1050200 at linux dot vnet dot ibm dot com> <20150917175102 dot 39DD32C3B22 at topped-with-meat dot com> <1442512762 dot 2348 dot 31 dot camel at reserved-bit dot com>
On 09/17/2015 01:59 PM, Siddhesh Poyarekar wrote:
> On Thu, 2015-09-17 at 10:51 -0700, Roland McGrath wrote:
>> There should be no explicit code using new environment variables at
>> all.
>> It should all go through the tunables framework so policy and
>> knowledge
>> about use of environment variables is centralized.
>
> I pushed some code to the siddhesh/tunables branch last week that reads
> just one magic environment variable and parses the string to initialize
> all tunables at once. This gives a definite path to deprecate the
> existing arbitrary environment variables in future as well since it
> clearly separates those bits from the core framework. So now y'all
> have both approaches to try out while I cool my heels off for a bit - I
> hope to be back hacking soon.
>
> We have talked about both approaches for a bit in different threads and
> I continue to have a slight preference for the single environment
> variable for the sheer ease of initialization and the possibility of
> doing it really early once I figure out how to get the code included
> into the dynamic linker without dropping it into the elf directory.
> All other differences seem cosmetic to me.
Given that we can change our mind on a release-by-release basis I'm also
happy with just one env var... given that you implemented it :-)
c.