lkml.org 
[lkml]   [2015]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Question about barriers for ARM on tools/perf/
Em Fri, May 08, 2015 at 05:45:35PM +0100, Will Deacon escreveu:
> On Fri, May 08, 2015 at 04:27:59PM +0100, Peter Zijlstra wrote:
> > On Fri, May 08, 2015 at 11:57:01AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Fri, May 08, 2015 at 03:48:20PM +0100, Will Deacon escreveu:

> > > > Do you know what the objection to the intrinsics was? I believe that
> > > > the __sync versions are deprecated in favour of the C11-like __atomic
> > > > flavours, so if that was all the objection was about then we could use
> > > > one or the other depending on what the compiler supports.

> > > Peter? Ingo?

> > I cannot remember, the __sync things should mostly work I suppose, and
> > if you wrap then in the normal atomic interface we don't have to learn
> > yet another API.

> Yeah, I think that's a good idea.

I'll use what I have, that is what I posted, i.e. something that was
tested. As we test it further, then we can either lift more stuff from
the kernel or add more compiler-foo.h stuff like we have in the kernel.

> > That said, I've successfully lifted this kernel code into userspace in
> > the past.
>
> Lifting a copy isn't too bad, it's using the same file that worries me.

So that is how I'll proceed, lifting a copy of just what I need, lifting
more as the need arises, and fallbacking to gcc intrinsics for
architectures where the implementations drag too much stuff.

Over time, as the need arises, maybe to support some older compiler or
some problematic toolchain, lifting more from the kernel may be desired
and should be considered.

- Arnaldo


\
 
 \ /
  Last update: 2015-05-08 20:41    [W:0.046 / U:45.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site