Correct the README regarding eval mode usage

[lttv.git] / lttv / lttv / sync / README

diff --git a/lttv/lttv/sync/README b/lttv/lttv/sync/README
index ada0210b99f01ddc71a64450ea0b4fecbca17b00..0e331ea0d301f49f7d7914ee36ea239ed9972f88 100644 (file)
--- a/lttv/lttv/sync/README
+++ b/lttv/lttv/sync/README
@@ -137,8 +137,11 @@ eval is a special module, it doesn't really perform synchronization, instead
 it calculates and prints different metrics about how well traces are
 synchronized. Although it can be run like other analysis modules, it is most
 useful when run in a postprocessing step, after another synchronization module
-has been run. Eval is most common run in text mode. To do this, run
-lttv -m eval [usual options, ex: -t traces/node1 -t traces/node2 --sync ...]
+has been run. Eval is most common run in text mode. To do this, run:
+lttv -m sync_chain_batch [usual options, ex: -t traces/node1 -t traces/node2
+--sync ...]
+It can also be run from the lttv source tree via runlttv:
+./runlttv -m eval [usual runlttv options, ex: traces/node1 traces/node2]
 
 eval provides a few more options:
 --eval-rtt-file  -  argument: FILE
@@ -192,9 +195,11 @@ This reads parameters, creates SyncState and calls the processing init
 function. The "sync chain" is the set of event-* modules. At the moment there
 is only one module at each stage. However, as more module are added, it will
 become relevant to have many modules at the same stage simultaneously. This
-will require some modifications. I've kept this possibility at the back of my
-mind while designing. It is already partly supported at the matching stage
-through encapsulation of other matching modules.
+will require some modifications. It is already partly supported at the
+matching stage through encapsulation of other matching modules.
+
+sync_chain_unitest:main() provides a fairly simple example of sync chain
+implementation.
 
 ++ Stage 1: Event processing
 Specific to the tracing data source.