This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add GLIBC_PTHREAD_ELISION_ENABLE tunable
- From: Andi Kleen <andi at firstfloor dot org>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Siddhesh Poyarekar <sid at reserved-bit dot com>, munroesj at linux dot vnet dot ibm dot com, "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>, "libc-alpha\ at sourceware dot org" <libc-alpha at sourceware dot org>, Carlos O'Donell <carlos at redhat 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>, stli at linux dot vnet dot ibm dot com, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Siddhesh Poyarekar <siddhesh at redhat dot com>, vapier at gentoo dot org
- Date: Thu, 17 Sep 2015 13:32:04 -0700
- Subject: Re: [PATCH] Add GLIBC_PTHREAD_ELISION_ENABLE 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> <1442513371 dot 10636 dot 2 dot camel at oc7878010663> <20150917181945 dot E92852C3B40 at topped-with-meat dot com> <1442514665 dot 2348 dot 38 dot camel at reserved-bit dot com> <20150917194823 dot D23452C3B40 at topped-with-meat dot com>
Roland McGrath <roland@hack.frob.com> writes:
Roland,
>
> The main point is to separate the internal API infrastructure that will be
> used pervasively across the source tree and set the terms for how we
> describe a tunable (i.e. naming, types, et al) from the "back end"
> implementation of any particular scheme for getting values into the
> system.
I don't see how such a complicated procedure is needed to add simple
tunables. It seems just an elaborate way to say "I can't make up my mind"?
> What we agreed on was that we could relatively easily reach consensus on
> this internal API. We explicitly deferred specific discussion on what I'm
> calling "back end" issues until after the API is in place.
Please make a decision. This whole train wreck is going on for far too
long now. And tunables are badly needed.
An "internal API" doesn't help any user. If some plugin scheme is done
the first usable version of it will be just the defacto implementation.
I thought we had a consensus earlier when I was told to implement
environment variables with opt-in config file. Is that now already
forgotten?
> I stand by my core positions.
Nobody can figure out what your core positions are, they don't
actually describe any way to solve the problem.
-Andi