Add compatibility support for older intel cpus

[urcu.git] / README

diff --git a/README b/README
index e5c04b179cae49d202a49809d09a76f714ada711..0f92ac690f1ce884139b18557cea062e893abc80 100644 (file)
--- a/README
+++ b/README
@@ -4,11 +4,27 @@ by Mathieu Desnoyers and Paul E. McKenney
 BUILDING
 --------
 
+       ./bootstrap (skip if using tarball)
+       ./configure
        make
-       #force 32-bit build with: make -f Makefile32
-       #force 64-bit build with: make -f Makefile64
        make install
-       
+
+       Hints:  Forcing 32-bit build:
+               * CFLAGS=-m32 ./configure
+
+               Forcing 64-bit build:
+               * CFLAGS=-m64 ./configure
+
+               Forcing a 32-bit build with down to 386 compatibility:
+               * CFLAGS=-m32 ./configure --target=i386-pc-linux-gnu
+
+ARCHITECTURES SUPPORTED
+-----------------------
+
+Currently, x86 (i386, i486, i586, i686), 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.
 
 QUICK START GUIDE
 -----------------
@@ -50,6 +66,17 @@ Usage of liburcu-qsbr
          the threads are not active. It provides the fastest read-side at the
          expense of more intrusiveness in the application code.
 
+Usage of liburcu-bp
+
+       * #include <urcu-bp.h>
+       * Link with "-lurcu-bp".
+       * The BP library flavor stands for "bulletproof". It is specifically
+         designed to help tracing library to hook on applications without
+         requiring to modify these applications. urcu_init(),
+         rcu_register_thread() and rcu_unregister_thread() all become nops.
+         The state is dealt with by the library internally at the expense of
+         read-side and write-side performance.
+
 Initialization
 
        Each thread that has reader critical sections (that uses
@@ -111,3 +138,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.