anchor.diff:  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
  -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.
  +(defined in `test/common_plat/validation/api/<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).
  
positive.code: 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
  
negative.code: listed in the automake TEST variable and will therefore be run on "make check".
  
  For the linux-generic platform, most tested modules fall into this category:
  currently, the `test/linux-generic/test/Makefile.am` looks
  roughly as follows:
  
  [source,am]
  ----
  include $(top_srcdir)/test/Makefile.inc
  TESTS_ENVIRONMENT += TEST_DIR=${top_builddir}/test/common_plat/validation
  
  ALL_API_VALIDATION = ${top_builddir}/test/common_plat/validation/api
  
  SUBDIRS =
  
  if test_vald
  TESTS = validation/api/pktio/pktio_run.sh \
  	validation/api/pktio/pktio_run_tap.sh \
  	$(ALL_API_VALIDATION)/atomic/atomic_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/barrier/barrier_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/buffer/buffer_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/classification/classification_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/cpumask/cpumask_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/crypto/crypto_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/errno/errno_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/hash/hash_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/init/init_main_ok$(EXEEXT) \
  	$(ALL_API_VALIDATION)/init/init_main_abort$(EXEEXT) \
  	$(ALL_API_VALIDATION)/init/init_main_log$(EXEEXT) \
  	$(ALL_API_VALIDATION)/lock/lock_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/packet/packet_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/pool/pool_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/queue/queue_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/random/random_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/scheduler/scheduler_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/std_clib/std_clib_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/thread/thread_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/time/time_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/timer/timer_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/traffic_mngr/traffic_mngr_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/shmem/shmem_main$(EXEEXT) \
  	$(ALL_API_VALIDATION)/system/system_main$(EXEEXT) \
  
  
  ----
  
  With the exception for module pktio, all other modules testing just involves
  calling the platform agnostic <module>_main executables (in
  /test/common_plat/validation/api).
  
  ==== Using other languages
  
  The pktio module, above, is actually tested using a bash script. This script is
  needed to set up the interfaces used by the tests. The `pktio_run` script
  eventually calls the platform agnostic
  `test/common_plat/validation/api/pktio/pktio_main` after setting up the
  interfaces needed by the tests.
  Notice that the path to the script, `validation/api/pktio/pktio_run.sh`,
  is pointing to a file within the <PLATFORM_SPECIFIC> tree so is private to
  this platform. Any languages supported by the tested platform can be used
  there, as it will not impact other platforms.
  The platform "private" executables (such as this script), of course, must also
  return one of the return code expected by the automake test harness
  (0 for success, 77 for skipped, other values for errors).
  