anchor.diff:  * The platform agnostic area,
   * A platform dependent area (one per platform).
   
  -=== Platform agnostic ===
  +=== Platform agnostic
   
   This grouping defines tests that are expected to be executable and succeed on
  -any platform, though possibly with very different performances, depending on the
  -underlying platform.
  -They are written in plain C code, and may only use functions defined in the
  -standard libC (C99) library (besides the ODP functions being tested, of course).
  -A free C99 specification can be found at
  -http://www.open-std.org/JTC1/sc22/wg14/www/docs/n1256.pdf.
  -No other languages (like scripting) are allowed as their usage would make
  -assumptions on the platform capability.
  -
  -This area is located at: 'test/validation/'
  -
  -The ODP API itself is ordered by module, where each module groups the set of ODP
  -API functions related to the same "topic".
  -Examples of modules includes "classification" (API functions dealing with ingress
  -packets classification), time (functions dealing with time, excluding timers
  -which have their own module), timer,...
  -The complete module list can be seen at:
  -http://docs.opendataplane.org/master/linux-generic-doxygen-html/modules.html[ODP Modules] +
  -Within the platform agnostic area, the tests are also grouped by modules,
  -matching the ODP API modules: 'test/validation/' mainly contains a list of
  -directories matching each module name (as defined by the doxygen "@defgroup" or
  -"@ingroup" statement present in each API ".h" file).
  -
  -Within each of these directories, a library (called "libtest<module>.la") and
  -its associated ".h" file (called "<module>.h") defines all the test functions
  +any platform, though possibly with very different performance, depending on
  +the underlying platform.  They are written in plain C code, and may only use
  +functions defined in the standard libC (C99) library (besides the ODP
  +functions being tested, of course).  A free C99 specification can be found at
  +the http://www.open-std.org/JTC1/sc22/wg14/www/docs/n1256.pdf[open-std.org]
  +web site.  No other languages (like scripting) are allowed as their usage
  +would make assumptions on the platform capability.
  +
  +This area is located at `test/validation/` in the odp git repository.
  +
  +The ODP API itself is ordered by module, where each module groups the set of
  +ODP API functions related to the same "topic".  Examples of modules includes
  +"classification" (API functions dealing with ingress packets classification),
  +time (functions dealing with time, excluding timers which have their own
  +module), timer,...  The complete module list can be seen at:
  +http://docs.opendataplane.org/master/linux-generic-doxygen-html/modules.html[ODP
  +Modules] + Within the platform agnostic area, the tests are also grouped by
  +modules, matching the ODP API modules: `test/validation/` mainly contains a
  +list of directories matching each module name (as defined by the doxygen
  +`@defgroup` or `@ingroup` statement present in each API `.h` file).
  +
  +Within each of these directories, a library (called `libtest<module>.la`) and
  +its associated `.h` file (called `<module>.h`) defines all the test functions
   for this module as well as few other functions to initialize, terminate, and
  -group the tests.
  -An executable called "<module>_main*", is also built. It is permissible to
  -generate more than one executable to cover the functionality in the test library
  -for the module.
  -These executable(s) shall call all the tests for this module. +
  -See <<anchor-1, Module test and naming convention>> for more details.
  +group the tests.  An executable called `<module>_main*`, is also built. It is
  +permissible to generate more than one executable to cover the functionality in
  +the test library for the module.  These executable(s) shall call all the tests
  +for this module. See <<anchor-1, Module test and naming convention>> for
  +more details.
   
   It is important to be aware that the tests defined for a given module
  -(defined in 'test/validation/<module>') are focused to test the ODP functions
  +(defined in `test/validation/<module>`) are focused to test the ODP functions
   belonging to this module, but are not limited to use this module's ODP functions
   only: many modules needs some interaction with some other module to be tested.
   The obvious illustration of this is for module "init" whose functions are
   required by all tests of all other modules (as ODP needs to be initialized to
  -test anything else). +
  -
  -There is a "Makefile.am" located at the top of the platform agnostic area. Its
  +test anything else).
  +
  +There is a `Makefile.am` located at the top of the platform agnostic area. Its
   role is limited to the construction of the different test libraries and the
  -"<module>_main*" executables. No tests are run from this area when "make check"
  +`<module>_main*` executables. No tests are run from this area when `make check`
   is performed.
   
  -==== CUnit ====
  +==== CUnit
   
   Within a given test executable CUnit is used to run the different tests. The
   usage of CUnit implies the following structure:
  
positive.code: return one of the return code expected by the automake test harness
  (0 for success, 77 for skipped, other values for errors).
  
  ==== Defining test wrappers ====
  
  The pktio case above is actually using a script as wrapper around the "standard"
  (platform independent) test executable. Wrappers can also be defined by using
  the LOG_COMPILER variable of automake.
  This is applicable in cases where the same wrapper should be used for more then
  one test, as the test name is passed has parameter to the wrapper. A wrapper is
  just a program expecting one argument: the test name.
  
negative.code: The list of these tests is expected to grow as ODP grows.
  
  The list of test executables is run by the automake test harness, when running
  `make check`.
  Therefore, as required by this harness, each executable should return 0 on
  success (tests passed), 77 on inconclusive, or any other values on failure.
  The automake functionality shows a status line (PASSED/FAIL...) for each of the
  