This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How are we doing with our blockers for 2.18?


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]