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: Andi Kleen <andi at firstfloor dot org>, Roland McGrath <roland at hack dot frob dot com>, 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>
- Date: Fri, 18 Sep 2015 18:06:48 +0200
- 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> <87twqskcsb dot fsf at tassilo dot jf dot intel dot com> <20150918063251 dot GA2213 at vapier dot lan>
On Fri, Sep 18, 2015 at 02:32:51AM -0400, Mike Frysinger wrote:
> On 17 Sep 2015 13:32, Andi Kleen wrote:
> > Roland McGrath <roland@hack.frob.com> writes:
> > > 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"?
>
> glibc is known for its stability and strong guarantees of not breaking
> ABIs. describing something as simple seems to brush that off -- we don't
> want to introduce knobs hastily that we are going to regret and be stuck
This has been discussed since at least two years now.
There's nothing hasty about the existing procedure. In fact "glacially
slow" would be a more appropiate description.
> with forever. perhaps this particular discussion has been dragging on a
> bit, but glibc isn't really the place for experimentation (which is then
> released directly to users) and for seeing what sticks purely by throwing
> things against the wall. i'd rather we be overly conservative.
Does that argue for never changing anything?
I don't see how you can even test anything without "releasing it to
users".
-Andi