Add a batchanalysis module to build and run a sync chain

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

diff --git a/lttv/lttv/sync/README b/lttv/lttv/sync/README
index 78b09b595a216a188e1e1e27a07b9429d70b949f..6310db875e28efdfd43cdf82658ce670b0ee7ba0 100644 (file)
--- a/lttv/lttv/sync/README
+++ b/lttv/lttv/sync/README
@@ -34,6 +34,8 @@ to make sure the following markers are enabled:
 * dev_xmit_extended
 * tcpv4_rcv_extended
 * udpv4_rcv_extended
+You can use the 'ltt-armall' and 'ltt-armnetsync' scripts for this.
+
 You also have to make sure there is some TCP traffic between the traced nodes.
 
 ++ Viewing traces
@@ -135,7 +137,7 @@ Communication is done via objects specialized from Event. At the moment, all
 be in separate files. This way, adding a new set of modules would require
 shipping extra data_structures* files instead of modifying the existing one.
 For this to work, Event.type couldn't be an enum, it could be an int and use
-#defines or constants defined the specialized data_structures* files.
+#defines or constants defined in the specialized data_structures* files.
 Event.event could be a void*.
 
 ++ Stage 2: Event matching
@@ -146,9 +148,10 @@ these can have different types of relation ("one to one", "one to many", or a
 mix) and it will influence the overall behavior of the module.
 eg. TCP, UDP, MPI
 
-matchEvent() takes an Event pointer. An actual matching module doesn't have
-to be able to process every type of event. It has to check that the passed
-event is of a type it can process.
+matchEvent() takes an Event pointer. An actual matching module doesn't have to
+be able to process every type of event. It will only be passed events of a
+type it can process (according to the .canMatch field of its MatchingModule
+struct).
 
 ++ Communication between stages 2 and 3: event groups
 Communication consists of events grouped in Message, Exchange or Broadcast