This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.23 --- Hard freeze starting
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- To: Siddhesh Poyarekar <sid at reserved-bit dot com>
- Cc: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Roland McGrath <roland at hack dot frob dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 21 Jan 2016 11:13:47 -0600
- Subject: Re: glibc 2.23 --- Hard freeze starting
- Authentication-results: sourceware.org; auth=none
- References: <569D4A42 dot 7030006 at linaro dot org> <20160120225625 dot 5CE8E2C3B00 at topped-with-meat dot com> <56A0E3C3 dot 5010704 at linaro dot org> <1453391129 dot 19764 dot 4 dot camel at oc7878010663> <20160121155626 dot GQ3334 at devel dot intra dot reserved-bit dot com>
- Reply-to: munroesj at linux dot vnet dot ibm dot com
On Thu, 2016-01-21 at 21:26 +0530, Siddhesh Poyarekar wrote:
> On Thu, Jan 21, 2016 at 09:45:29AM -0600, Steven Munroe wrote:
> > Because this is the only thing that is prevention powerpc from enabling
> > TLE. And it is important to my platform.
> >
> > So Roland may this is just nice to have but I think it is a blocker.
> >
> > If the tunables framework is just a nice to have then it should not be a
> > prerequisite for enable TLE for power.
> >
> > And should not block the enable of TLE for powerpc on power8 and using
> > some other means to enable/disable.
>
> I don't have the full context here, but I believe you could limit the
> scope of TLE implementation of power to what is being done in x86,
> i.e. only implement enabling/disabling of TLE at glibc configure and
> build time.
>
The full context is that the above is not acceptable to the distros.
They insist on an common and dynamic mechanism to enable/disable.
> We willll need consensus on what the final user interface for tunables
> should look like and it is not reasonable to block on that at this
> stage. The only patch I proposed as a blocker was the first patch to
> ensure that we have the scaffolding in place early; that way we can
> focus on getting consensus on the user interface after 2.23 release.
I fear that this group will not find consensus in the absence of some
forcing issue. Otherwise the discussion (with lack of consensus) and
associate delays will go on indefinitely.
This has been delayed too long. It is time to end the debate.