Re: [PATCH] mips: work-around R10k ll/sc errata

[Matt Turner <mattst88 at gmail dot com>]

On Wed, Jun 29, 2011 at 3:34 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Wed, 29 Jun 2011, Ralf Baechle wrote:
>
>> > I didn't get any sense of consensus in the previous discussion (which
>> > extended to at least Jan 2009) and several people there are rather more
>> > expert in the MIPS variants than me. ?Perhaps someone would care to put
>> > together a compilation of all the points raised and explain how the patch
>> > addresses them or at least leaves things no worse off - in particular
>> > detailing the circumstances (compiler options) under which the patch
>> > results in any change to the code in glibc.
>>
>> Do you have a pointer to that old discussion?
>
> http://sourceware.org/ml/libc-ports/2008-10/msg00010.html
> http://sourceware.org/ml/libc-ports/2008-11/subjects.html#00000
> http://sourceware.org/ml/libc-ports/2009-01/subjects.html#00036
>
>> To summarize, I think the patch should be applied but the mentioned issues
>> may deserve documentation.
>
> Thanks. ?Maciej, do you have any comments on this latest patch?
>
>> As more of a general question, Is there a point in eventually moving this
>> sort of stuff into a VDSO? ?It would allow the kernel to provide suitable
>> definitions of common LL/SC constructs without having to modify glibc.
>
> I don't think it's easy for GCC to generate calls to a vDSO directly from
> __sync_* intrinsics, and __sync_* intrinsics (or in future an
> implementation of the C1X and C++0X atomics functionality using new
> versions of those intrinsics) are what we want code to use.

I don't mean to speak for Maciej, but in the last email link you
provided, both he and Daniel Jacobowitz seem to be in favor of a patch
that only affected the code when specifically requested.

> Please don't activate this workaround on builds that won't run on an R10K

Matt