Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
compile with -g; do clean .o files
[simgrid.git] / doc / modules.doc
index 40f80ae..b57cbb6 100644 (file)
@@ -1,54 +1,13 @@
 /** 
   \defgroup SimGrid_API  API of SimGrid */
 
-/** \defgroup XBT_API      XBT (eXtended Bundle of tools)
+/** \defgroup XBT_API      XBT
        \ingroup SimGrid_API
        \brief The core toolbox of SimGrid, containing usefull datatypes,
        portability support and so on.
 */
-/**    \defgroup XBT_ground Grounding features of the XBT (logging and error reporting)
-       \ingroup XBT_API        */
-       /** \addtogroup  XBT_log
-           \ingroup XBT_ground  */
-          /** \defgroup XBT_log_cats Existing log categories
-              \ingroup XBT_log
-              \brief (automatically extracted) 
-              
-              This is the list of all existing log categories in SimGrid.
-               This list was automatically extracted from the source code by
-               the src/xbt_log_extract_hierarchy utility.
-              
-               You can thus be certain that it is uptodate, but it may somehow
-               lack a final manual touch.
-              Anyway, nothing's perfect ;)
-              */
-       /** \addtogroup  XBT_error
-           \ingroup XBT_ground  */
 
-/**    \defgroup XBT_structs  Datatypes defined in the XBT
-       \ingroup XBT_API        */
-/**       \addtogroup XBT_dict
-          \ingroup XBT_structs */
-/**       \addtogroup XBT_dynar
-          \ingroup XBT_structs */
-/**       \addtogroup XBT_fifo
-          \ingroup XBT_structs */
-/**       \addtogroup XBT_set
-          \ingroup XBT_structs */
-/**        \addtogroup XBT_swag
-          \ingroup XBT_structs */
-/**       \addtogroup XBT_heap
-          \ingroup XBT_structs */
-     
-/**    \defgroup XBT_port     Portability support defined in the XBT 
-                              (you shouldn't use it directly) 
-       \ingroup XBT_API        */
-/**       \addtogroup XBT_context 
-          \ingroup XBT_port    */
-/**       \addtogroup XBT_sysdep
-          \ingroup XBT_port    */
-
-/** \defgroup SURF_API       SURF (simulator kernel)
+/** \defgroup SURF_API       SURF
     \ingroup SimGrid_API
     \brief Kernel of all the simulators used in SimGrid, and associated models.
  
       directly on top of \ref SURF_API (but you probably want to contact us
       before). 
 */
-/**     \addtogroup m_datatypes_management
-        \ingroup MSG_API  */
-/**     \addtogroup m_process_management
-        \ingroup MSG_API  */
-/**     \addtogroup m_host_management
-        \ingroup MSG_API  */
-/**     \addtogroup m_task_management
-        \ingroup MSG_API  */
-/**     \addtogroup msg_gos_functions
-        \ingroup MSG_API  */
-/**     \addtogroup m_channel_management
-        \ingroup MSG_API  */
-/**     \addtogroup msg_easier_life
-        \ingroup MSG_API  */
-/**     \addtogroup msg_simulation
-        \ingroup MSG_API  */
-
 
 /** \defgroup GRAS_API      GRAS
     \ingroup SimGrid_API
     If none of those programming environments fits your needs, you may
     consider implementing your own directly on top of \ref SURF_API (but you
     probably want to contact us before).
-  
-    \section GRAS_funct Offered functionnalities
-     - <b>Communication facilities</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. 
-     - <b>Virtualization</b>: Running both on top of the simulator and on
-       top of real platforms, and portability support.
-       - \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_cond: How to declare specific code for the simulation mode
-          or for the real mode.
-       - \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.
-         
-    \section GRAS_todo TODO
-     Documentation related:
-       - Add an example to the \ref GRAS_msg section, at least
-       - Document examples/gras/gras_stub_generator utility and how to deal
-         with the fact that programs must have a main in RL and not in SG.
-       - Document example/gras/ping as it uses almost all of the GRAS
-         features.
-     
-     Code related: too long to be written here. See the TODO file
-     
-    @{
-*/     
-
-       /** \defgroup GRAS_dd      Data description      */       
-       /** \defgroup GRAS_sock    Sockets               */           
-       /** \defgroup GRAS_msg     Messages              */               
-        
-       /** \defgroup GRAS_globals Globals               */ 
-       /** \defgroup GRAS_cond    Conditional execution */ 
-       /** \defgroup GRAS_virtu   Syscalls              */ 
-
-/** @} */ 
+*/
 
 /** \defgroup SMPI_API      SMPI
     \ingroup SimGrid_API