Cleanup: Re-organise source dir Re-organise the sources, add a top level "src" and "include" dir and move relevant files. Disable autotools automated includes and define them manually. This fixes problems with collision of header names with system headers. Include the autoconf config.h in the default includes and remove it where it's explicitely included. Remove _GNU_SOURCE defines since it's detected at configure for platforms that requires it and added to the config.h. Signed-off-by: Michael Jeanson <mjeanson@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Support for NIOS2 architecture Add support for the Altera NIOS2 CPU archirecture. The atomic operations are handled by the GCC. The memory barriers on this systems are entirely trivial too, since the CPU does not support SMP at all. Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
tile: allocate membarrier system call number Now that the membarrier system call is allocated on tile, allocate its number in our architecture header if the system headers don't allocate it. This allows using the membarrier system call as soon as implemented in the kernel, even if the distribution has old kernel headers. Do so by creating headers specifically for tile, which rely on the gcc atomic and memory barrier builtins. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
ia64: allocate membarrier system call number Now that the membarrier system call is allocated on ia64, allocate its number in our architecture header if the system headers don't allocate it. This allows using the membarrier system call as soon as implemented in the kernel, even if the distribution has old kernel headers. Do so by creating headers specifically for ia64, which rely on the gcc atomic and memory barrier builtins. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
aarch64: allocate membarrier system call number Now that the membarrier system call is allocated on aarch64, allocate its number in our architecture header if the system headers don't allocate it. This allows using the membarrier system call as soon as implemented in the kernel, even if the distribution has old kernel headers. Do so by creating headers specifically for aarch64, which rely on the gcc atomic and memory barrier builtins. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
uatomic: Specify complete types for atomic function calls This was unearthed by clang compiler where it complained about parameter mismatch, gcc doesnt notice this urcu/uatomic/generic.h:190:10: error: address argument to atomic builtin must be a pointer to integer or pointer ('void *' invalid) return __sync_add_and_fetch_4(addr, val); Fixed all instances thusly. [ Edit by Mathieu: use stdint.h types. ] Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Add support for hppa/PA-RISC architecture Add the missing architecture specific functions to provide support for the hppa/PA-RISC architecture: - the processor internal time stamp counter (Control Register CR16) is used to get high-performance/low-latency cycle counts - gcc provides the necessary built-in atomic functions on hppa (which in turn uses the light-weigth atomic locking syscall-interface of the Linux kernel) Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix configure checks for Tile The previous method of checking whether the architecture is TileGx or not was buggy. urcu/arch/tile.h included urcu/arch/gcc.h, which was not installed on the system, causing a configure error. I am not sure why it worked when I tested commit 1000f1f4204e5fbb337f4ea911f1e29f67df79aa, maybe some previous partial install or something. The check is now done earlier, during the configure step and should not cause any trouble. Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Add compilation support for the TileGX architecture This patch adds compilation support for the TileGx architecture. Since the tests were not ran on other architectures of the Tile family (Tile64, TIlepro), errors are triggered during compilation if the architecture is another Tile arch. Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Add MIPS support [ Edit by Mathieu Desnoyers: add explanations about supported MIPS architectures, extracted from conversation with Ralf Baechle: * Supported architectures Ralf Baechle (edited by Mathieu Desnoyers): This code works on all MIPS architecture variants. The memory barrier instruction, SYNC, was introduced for MIPS II. The original MIPS I instruction set doesn't have SYNC nor SMP support in the processor architecture itself so SMP required horrible kludges in the system hardware. I think it's safe to say that Linux/MIPS will never support any of these MIPS I SMP systems. In the unlikely case this happens anyway, we have a (Linux) kernel emulation of the SYNC instruction. Voila - full binary compatibility across all MIPS processors and the oldest hardware pays the performance penalty. * Choice of barrier for cmm_mb()/cmm_rmb()/cmm_wmb() Ralf Baechle: "RMI (aka Netlogic and now Broadcom) XLR processor cores can be configured to permit LD-LD, LD-ST, ST-LD and ST-ST reordering; default is only ST-ST reordering. To allow Linux to eventually enable full reordering cmm_mb(), cmm_rmb() and cmm_wmb() all should perform SYNC and a compiler barrier." * No-op choice for cmm_read_barrier_depends(): Ralf Baechle: "Technically there is nothing in the MIPS architecture spec that would keep a MIPS implementation from reordering as freely as an Alpha or even more liberally. In practice most do strong ordering. However there is no MIPS implementation that makes full use of all the rope provided. So in theory a paranoid implementation of cmm_read_barrier_depends() for MIPS should perform a SYNC. In reality it's not necessary and no sane MIPS core designer would implement something that would design a core that need a non-empty cmm_read_barrier_depends(). The reason why my patch had an empty one is that I was using the Alpha code as a template." Mathieu Desnoyers: Moreover, the Linux kernel chooses a no-op for MIPS read_barrier_depends() implementation, so any MIPS architecture that would be as weak as Alpha would break the Linux kernel before breaking the userspace RCU library. * No need to put ".set noreorder" in cmm_mb() inline assembly: Ralf Baechle: "Certain instructions such as SYNC won't get reordered." ] Signed-off-by: Ralf Baechle <ralf@linux-mips.org> CC: Paul McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Update return value of "set" operations To follow the way the Linux kernel implements atomic_set(), we change some API functions so they don't return any value anymore. This is now the case for: uatomic_set() rcu_set_pointer() rcu_assign_pointer() This API change is very minor. In all instances of the Linux kernel using rcu_assign_pointer(), none currently care about its return value. However, we keep ABI compatibility: rcu_set_pointer_sym() still returns the "v" value, even though it is not used by its wrapper macro anymore. Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
uatomic: add memory barrier API for and/or/add/sub/inc/sub Implement: cmm_smp_mb__before_and, cmm_smp_mb__after_and cmm_smp_mb__before_or, cmm_smp_mb__after_or cmm_smp_mb__before_add, cmm_smp_mb__after_add cmm_smp_mb__before_sub, cmm_smp_mb__after_sub cmm_smp_mb__before_inc, cmm_smp_mb__after_inc cmm_smp_mb__before_dec, cmm_smp_mb__after_dec For generic and x86. These currently translate into simple compiler barriers on all architectures, but the and/or/add/sub/inc/dec uatomics do not provide memory ordering guarantees (only uatomic_add_return, uatomic_sub_return, uatomic_xchg, and uatomic_cmpxchg provides full memory barrier guarantees before and after the atomic operations). Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix uatomic sign cast Passing an unsigned int to uatomic_sub does not honor sign extend to long, as we should be allowed by assume. Fix this by introducing caa_cast_long_keep_sign(), which casts either to long or unsigned long depending on the signedness of the argument received. It is used in uatomic_sub before applying the "-" operator, since this operator needs to operate on the "long" type size (since sign extension might not be performed if the argument received is unsigned). Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>