This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: How are we doing with our blockers for 2.18?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Ryan S Arnold <rsa at linux dot vnet dot ibm dot com>
- Cc: "Ryan S. Arnold" <ryan dot arnold at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh at redhat dot com>, Andi Kleen <andi at firstfloor dot org>, Ryan Arnold <rsa at us dot ibm dot com>
- Date: Mon, 17 Jun 2013 16:09:37 -0400
- Subject: Re: How are we doing with our blockers for 2.18?
- References: <51BB768B dot 8010204 at redhat dot com> <CAAKybw_nEWwod5-aP7UvmXQc4A-Pe_nKhyBOkuFydQLzbOx=zg at mail dot gmail dot com> <51BF53EB dot 1010004 at redhat dot com> <1371496726 dot 1716 dot 51 dot camel at localhost dot localdomain>
On 06/17/2013 03:18 PM, Ryan S Arnold wrote:
> On Mon, 2013-06-17 at 14:22 -0400, Carlos O'Donell wrote:
>> On 06/14/2013 05:39 PM, Ryan S. Arnold wrote:
>>> On Fri, Jun 14, 2013 at 3:01 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>>> Community,
>>>>
>>>> How are we doing with our 2.18 blockers?
>>>
>>> The Power8 patches depends on AT_HWCAP2 as is, but I suppose I could
>>> separate the platform enablement from the power8 hwcap bits. That
>>> would still get the power8 arch stuff in place by Monday. in the
>>> meantime I'll look at the implications of AT_HWCAP w/rt the
>>> pseudo-hwcap bits.
>>
>> Monday is an arbitrary day for the freeze.
>>
>> What really matters is that we as a community talk about what
>> features we want in 2.18, abide by that, and then work to review
>> and close out those issues as immediately as possible.
>>
>> What is required to get the Power8 and AT_HWCAP2 patches into
>> master right now?
Are there any Power8 patches that should go in right now?
Even if you can't get AT_HWCAP2 in?
> I need to remove the TLS artifacts from the dl_hwcap.
Not impossible.
The TLS pseudo-hwcap bit is only used if you install a new
glibc into an ancient distro where the libraries are all in
the tls/ subdirectory. However, installing such a glibc
into an old distribution, with the TLS bit removed, would simply
fallback to using non-TLS libraries. It wouldn't technically break
anything AFAIK, and it's a valid thing to do.
You also need to look at the VDSO pseudo-hwcap bit mechanism that
allows VDSO's to register bits beyond _DL_FIRST_EXTRA, like the
bit for 'nosegneg' on x86*. Those bits will get in the way of AT_HWCAP2
bits. There is already precedent in the kernel that says any
number of bits can be registered this way and they map to beyond
_DL_FIRST_EXTRA in the 64-bit hwcap in ld.so.
The nosegneg bit is the only user of the above VDSO pseudo-hwcap
mechanism. Not having this set only results in less than optimal
behaviour for Xen hosts.
The TLS, VDSO pseudo-hwcap, and platform pseudo-hwcaps should
probably have their own 64-bit pseudo hw-cap field that uniquely
puts them into their own grouping with AT_HWCAP* in the original
64-bit field. It will slowdown startup slightly.
> I need to figure out what to do with the platform bits which may be
> saved in the high bits of the hwcap since these will now collide with
> the AT_HWCAP2 usage in PowerPC (since they marked the bits from high to
> low).
Problematic and requires discussion (as I note above).
> Roland wants a clear policy on how AT_HwCAP2 will be used by the kernel
> in the future, which means negotiating this with the kernel.
A very good idea, the best way to do this is get a Documentation/
patch in place upstream that describes AT_HWCAP2.
> Also, based on what's negotiated I need to perform sanity enforcement.
>
>>
>> If you can split the patches and that makes review easier then
>> please do so immediately
>
> So with that in mind I don't see how AT_HwCAP2 can make 2.18 unless
> someone has an immediate solution to these problems identified.
No, I also don't see how we can get AT_HWCAP2 into 2.18.
Cheers,
Carlos.