[lttng-dev] Support for new arch 'ppc64le'

[Mathieu Desnoyers]

----- Original Message -----
> From: "Dimitri John Ledkov" <xnox at ubuntu.com>
> To: lttng-dev at lists.lttng.org
> Cc: ravi at linux.vnet.ibm.com, "mathieu desnoyers" <mathieu.desnoyers at efficios.com>
> Sent: Wednesday, March 12, 2014 7:26:12 AM
> Subject: RE: [lttng-dev] Support for new arch 'ppc64le'
> 
> (sorry for breaking threading, I was not previously subscribed)
> 
> On 03/12/2014 12:58 AM, Mathieu Desnoyers wrote:
> > I see that the patch you propose adds both "powerpc64le" and "aarch64"
> > entries. Why are there two of them?
> 
> Currently there are two fairly recent architectures, which at the
> moment can only be compiled with "gcc atomics" code path.
> The two new architectures are (GNU Types):
> * aarch64-linux-gnu (aka ARMv8, ARM64, AARCH64, etc)
> * powerpc64le-linux-gnu
> 
> Upstream config.guess/config.sub/libtool/kernel/compilers have support
> for these targets and many distributions are bootstrapping/building
> archives for these architectures. Although for complete support,
> ideally one would create tarballs on systems with patched libtool,
> it's not required for distributions since we have support to update
> config.guess/config.sub/libtool at package build time.
> 
> Thus I'd like to only request for aarch64/powerpc64el to be recognized
> as archtypes that use gcc atomics in configure.ac. See attached patch.

OK. My request to you is that there has been some testing (make check,
make regtest and ensuring there is no crash, assertions, or other issues
reported) on each of those architectures with userspace RCU.

> 
> Alternatively, you might want to consider making "gcc" atomics the
> fallback ARCHTYPE, instead of "unknown" such that compilation of this
> package is at least attempted on unexpected architectures.

The reason why we don't have this fallback is because we want to make sure
the implementation of gcc atomics are tested for each architecture before
we allow building userspace RCU for them. You may call us paranoid over
this, but we just don't trust the compiler to always do the right thing.

I'll merge your patch into master. However, since this can be considered
as new features (and not bugfixes), I cannot backport it to the stable
branches of userspace RCU. So it will be in there for the future 0.9
branch.

Thanks,

Mathieu

> 
> --
> Regards,
> 
> Dimitri.
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com