This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Tunable elision patch for siddhesh/tunables
- From: Siddhesh Poyarekar <sid at reserved-bit dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, murphyp at linux dot vnet dot ibm dot com, Steve Munroe <sjmunroe at us dot ibm dot com>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, andi at firstfloor dot org
- Date: Tue, 6 Oct 2015 19:47:42 +0530
- Subject: Re: [RFC] Tunable elision patch for siddhesh/tunables
- Authentication-results: sourceware.org; auth=none
- References: <5612A237 dot 7040409 at linux dot vnet dot ibm dot com> <561392C9 dot 2030804 at reserved-bit dot com> <5613D61E dot 70406 at linux dot vnet dot ibm dot com>
On Tuesday 06 October 2015 07:39 PM, Paul E. Murphy wrote:
> My interpretation is that COMPAT_TUNABLE_* macros should only be used
> for porting existing tunables with an existing env var.
Ugh, sorry, I misread the code and thought you were introducing an
environment variable. I see now that you're only introducing a new envp
parameter to tunable_register. The WITH_ENV is fine for now. If we go
the environment variable route, we can use that by default since we
always want envp to be available by some means or the other.
> I agree. The intent of these patches is to validate your existing
> work with tunables by using something clearly demanded by the glibc
> users.
>
> What work remains on this branch before you open it for debate?
I need to split the patches into two sets, one that simply adds an
abstract framework without doing any work and another that opens up the
discussion about what the tunable interface should look like, i.e. one
envvar per variable, one envvar for all, some file, auxval passed by the
kernel, etc.
Siddhesh