X-Git-Url: https://git.liburcu.org/?a=blobdiff_plain;f=README;h=ecdda633e20fe3f6fa772a90644b99b2f302ea3b;hb=632dd6bae1cb2b590185c2bdad12e9531409aa53;hp=d454757fceffa30e7622d64dfee07290537bb0ee;hpb=c51e75e62494c2f6aae4a88aa4499444716846d7;p=urcu.git

diff --git a/README b/README
index d454757..ecdda63 100644
--- a/README
+++ b/README
@@ -9,20 +9,21 @@ BUILDING
 	make
 	make install
 
-	Note:	Forcing 32-bit build:
-		* CFLAGS=-m32 ./configure
+	Hints:	Forcing 32-bit build:
+		* CFLAGS="-m32 -g -O2" ./configure
 
 		Forcing 64-bit build:
-		* CFLAGS=-m64 ./configure
+		* CFLAGS="-m64 -g -O2" ./configure
+
+		Forcing a 32-bit build with 386 backward compatibility:
+		* CFLAGS="-m32 -g -O2" ./configure --target=i386-pc-linux-gnu
 
 ARCHITECTURES SUPPORTED
 -----------------------
 
-Currently, x86 (only Pentium and +), x86 64, PowerPC 32/64 and S390 are
-supported. The current use of sys_futex() makes it Linux-dependent, although
-this portability limitation might go away in a near future by using the pthread
-cond vars. Also, the restriction against i386 and i486 might go away if we
-integrate some of glibc runtime CPU-detection tests.
+Currently, x86 (i386, i486, i586, i686), x86 64-bit, PowerPC 32/64, S390, S390x
+and Sparc64 are supported. Only tested on Linux so far, but should
+theoretically work on other operating systems.
 
 QUICK START GUIDE
 -----------------
@@ -99,9 +100,9 @@ Usage of liburcu-defer
 
 	* #include <urcu-defer.h>
 	* Link with "-lurcu-defer"
-	* Provides call_rcu() primitive to enqueue delayed callbacks. Queued
+	* Provides defer_rcu() primitive to enqueue delayed callbacks. Queued
 	  callbacks are executed in batch periodically after a grace period.
-	  Do _not_ use call_rcu() within a read-side critical section, because
+	  Do _not_ use defer_rcu() within a read-side critical section, because
 	  it may call synchronize_rcu() if the thread queue is full.
 
 Being careful with signals
@@ -136,3 +137,13 @@ Usage of DEBUG_YIELD
 
 	DEBUG_YIELD is used to add random delays in the code for testing
 	purposes.
+
+SMP support
+
+	By default the library is configured to use synchronization primitives
+	adequate for SMP systems. On uniprocessor systems, support for SMP
+	systems can be disabled with:
+
+		./configure --disable-smp-support
+
+	theoretically yielding slightly better performance.