Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
first try at killing GRAS -- does not compile yet
[simgrid.git] / doc / ref_guide / doxygen / module-gras.doc
diff --git a/doc/ref_guide/doxygen/module-gras.doc b/doc/ref_guide/doxygen/module-gras.doc
deleted file mode 100644 (file)
index 7b8d028..0000000
+++ /dev/null
@@ -1,71 +0,0 @@
-/** \addtogroup GRAS_API
-
-    \section GRAS_funct GRAS offers the following functionnalities
-     - <b>\ref GRAS_comm</b>: Exchanging messages between peers
-       - \ref GRAS_dd : any data which may transit on the network must be
-         described beforehand so that GRAS can handle the platform
-         heterogeneity and convert them if needed.
-       - \ref GRAS_sock : this is how to open a communication channel to
-         other processes, and retrive information about them.
-       - \ref GRAS_msg : communications are message oriented. You have to
-         describe all possible messages and their payload beforehand, and
-         can then attach callbacks to the arrival of a given kind of message.
-       - \ref GRAS_timer : this is how to program repetitive and delayed
-         tasks, not unlike cron(8) and at(1). This cannot be used to timeout
-         a function (like setitimer(2) or signal(2) games could do).
-     - <b>\ref GRAS_run</b>: Running both on top of the simulator and on
-       top of real platforms, and portability support.
-       - \ref GRAS_virtu : You naturally don't want to call the
-          gettimeofday(2) function in simulation mode since it would give
-          you the time on the host running the simulation, not the time in
-          the simulated world (you are belonging to).\n
-         This a system call virtualization layer, which also acts as a
-          portability layer.
-       - \ref GRAS_globals : The use of globals is forbidden since the
-         "processes" are threads in simulation mode. \n
-        This is how to let GRAS handle your globals properly.
-       - \ref GRAS_emul : Support to emulate code excution (ie, reporting
-         execution time into the simulator and having code sections specific
-         to simulation or to real mode).
-
-
-    @{ */
-       /** @defgroup GRAS_comm    Communication facilities */
-       /** @defgroup GRAS_run     Virtualization */
-
-/** @} */
-#####################################################################
-/** @addtogroup GRAS_comm
-
-   Here are the communication facilities. GRAS allows you to exchange
-   <i>messages</i> on <i>sockets</i> (which can be seen as pipes between
-   processes). On reception, messages start <i>callbacks</i> (that's the
-   default communication mode, not the only one). All messages of a given
-   type convey the same kind of data, and you have to describe it
-   beforehand.
-
-   Timers are also seen as a mean of communication (with yourself). It
-   allows you to run a repetitive task ("do this every N second until I tell
-   you to stop"), or to deffer a treatment ("do this in 3 sec").
-
-    @{ */
-       /** @defgroup GRAS_dd      Data description      */
-       /** @defgroup GRAS_sock    Sockets               */
-       /** @defgroup GRAS_msg     Messages              */
-       /** @defgroup GRAS_timer   Timers                */
-
-/** @} */
-#####################################################################
-/** @addtogroup GRAS_run
-
-   Virtualization facilities allow your code to run both on top of the simulator or in real setting.
-
-    @{ */
-
-       /** @defgroup GRAS_globals Globals               */
-       /** @defgroup GRAS_emul    Emulation support */
-       /** @defgroup GRAS_virtu   Syscalls              */
-
-/** @} */
-
-