src/modules.doc

   1 /**
   2   \defgroup SimGrid_API  API of SimGrid */
   3
   4 /** \defgroup XBT_API      XBT (eXtended Bundle of tools)
   5        \ingroup SimGrid_API
   6        \brief The core toolbox of SimGrid, containing usefull datatypes,
   7        portability support and so on.
   8 */
   9 /**    \defgroup XBT_ground Grounding features of the XBT (logging and error reporting)
  10        \ingroup XBT_API        */
  11        /** \addtogroup  XBT_log
  12            \ingroup XBT_ground  */
  13            /** \defgroup XBT_log_cats Existing log categories
  14                \ingroup XBT_log
  15                \brief (automatically extracted)
  16
  17                This is the list of all existing log categories in SimGrid.
  18                This list was automatically extracted from the source code by
  19                the src/xbt_log_extract_hierarchy utility.
  20
  21                You can thus be certain that it is uptodate, but it may somehow
  22                lack a final manual touch.
  23                Anyway, nothing's perfect ;)
  24                */
  25        /** \addtogroup  XBT_error
  26            \ingroup XBT_ground  */
  27
  28 /**    \defgroup XBT_structs  Datatypes defined in the XBT
  29        \ingroup XBT_API        */
  30 /**       \addtogroup XBT_dict
  31           \ingroup XBT_structs */
  32 /**       \addtogroup XBT_dynar
  33           \ingroup XBT_structs */
  34 /**       \addtogroup XBT_fifo
  35           \ingroup XBT_structs */
  36 /**       \addtogroup XBT_set
  37           \ingroup XBT_structs */
  38 /**        \addtogroup XBT_swag
  39           \ingroup XBT_structs */
  40 /**       \addtogroup XBT_heap
  41           \ingroup XBT_structs */
  42
  43 /**    \defgroup XBT_port     Portability support defined in the XBT
  44                               (you shouldn't use it directly)
  45        \ingroup XBT_API        */
  46 /**       \addtogroup XBT_context
  47           \ingroup XBT_port    */
  48 /**       \addtogroup XBT_sysdep
  49           \ingroup XBT_port    */
  50
  51 /** \defgroup SURF_API       SURF (simulator kernel)
  52     \ingroup SimGrid_API
  53     \brief Kernel of all the simulators used in SimGrid, and associated models.
  54
  55       SURF provides the core functionnalities to simulate a virtual
  56       platform. It is very low-level and is not intended to be used as
  57       such but rather to serve as a basis for higher-level simulators.
  58       We're still working on it and the structure is a little bit
  59       complex. So we'll document it only when we'll be completely satisfied of
  60       the way it is organized.
  61
  62       It is where platform models are encoded. If you need a model that is not
  63       encoded yet, please tell me (<arnaud.legrand@imag.fr>) and we'll
  64       see if it is feasible or not (hopefully it should be but who knows).
  65
  66       Please note that as it is not really intended for public use,
  67       this module is only partially documented.
  68 */
  69
  70 /** \defgroup MSG_API      MSG
  71     \ingroup SimGrid_API
  72     \brief Simple programming environment
  73
  74       MSG was the first distributed programming environment provided within
  75       SimGrid. While almost realistic, it remains quite simple (simplistic?).
  76
  77       \section MSG_who Who should use this (and who shouldn't)
  78
  79       You should use this model if you want to study some heuristics for a
  80       given problem you don't really want to implement. If you want to get a
  81       real implementation of your solution, have a look at the \ref GRAS_API
  82       programming environment. If you want to study an existing MPI program,
  83       have a look at the \ref SMPI_API one. If none of those programming
  84       environments fits your needs, you may consider implementing your own
  85       directly on top of \ref SURF_API (but you probably want to contact us
  86       before).
  87 */
  88 /**     \addtogroup m_datatypes_management
  89         \ingroup MSG_API  */
  90 /**     \addtogroup m_process_management
  91         \ingroup MSG_API  */
  92 /**     \addtogroup m_host_management
  93         \ingroup MSG_API  */
  94 /**     \addtogroup m_task_management
  95         \ingroup MSG_API  */
  96 /**     \addtogroup msg_gos_functions
  97         \ingroup MSG_API  */
  98 /**     \addtogroup m_channel_management
  99         \ingroup MSG_API  */
 100 /**     \addtogroup msg_easier_life
 101         \ingroup MSG_API  */
 102 /**     \addtogroup msg_simulation
 103         \ingroup MSG_API  */
 104
 105
 106 /** \defgroup GRAS_API      GRAS
 107     \ingroup SimGrid_API
 108     \brief Realistic programming environment (Grid Reality And Simulation)
 109
 110     GRAS provide a complete API to implement distributed application on top
 111     of heterogeneous plateforms. In addition to the SimGrid implementation
 112     of this interface (allowing you to work on your application within the
 113     comfort of the simulator), an implementation suited to real platforms is
 114     also provided (allowing you to really use your application once you're
 115     done with developing it).
 116
 117     GRAS thus constitute a complete grid application developement framework,
 118     encompassing both developer helping tools (the simulator and associated
 119     tools) and an efficient while portable execution runtime.
 120
 121     \section GRAS_who Who should use this (and who shouldn't)
 122
 123     You should use this programming environment if you want to develop real
 124     applications, ie if the final result of your work is a program which
 125     may eventually be distributed.
 126     If you just want to study some heuristics for a given problem you don't
 127     want to implement really (ie, if your result would be a theorem), have a
 128     look at the \ref MSG_API one.
 129     If you want to study an existing MPI program, have a look at the
 130     \ref SMPI_API one.
 131     If none of those programming environments fits your needs, you may
 132     consider implementing your own directly on top of \ref SURF_API (but you
 133     probably want to contact us before).
 134
 135     \section GRAS_funct Offered functionnalities
 136      - <b>Communication facilities</b>: Exchanging messages between peers
 137        - \ref GRAS_dd: any data which may transit on the network must be
 138          described beforehand so that GRAS can handle the platform
 139          heterogeneity and convert them if needed.
 140        - \ref GRAS_sock: this is how to open a communication channel to
 141          other processes, and retrive information about them.
 142        - \ref GRAS_msg: communications are message oriented. You have to
 143          describe all possible messages and their payload beforehand, and
 144          can then attach callbacks to the arrival of a given kind of message.
 145      - <b>Virtualization</b>: Running both on top of the simulator and on
 146        top of real platforms, and portability support.
 147        - \ref GRAS_globals: The use of globals is forbidden since the
 148          "processes" are threads in simulation mode. \n
 149          This is how to let GRAS handle your globals properly.
 150        - \ref GRAS_cond: How to declare specific code for the simulation mode
 151           or for the real mode.
 152        - \ref GRAS_virtu: You naturally don't want to call the
 153           gettimeofday(2) function in simulation mode since it would give
 154           you the time on the host running the simulation, not the time in
 155           the simulated world (you are belonging to).\n
 156           This a system call virtualization layer, which also acts as a
 157           portability layer.
 158
 159     \section GRAS_todo TODO
 160      Documentation related:
 161        - Add an example to the \ref GRAS_msg section, at least
 162        - Document examples/gras/gras_stub_generator utility and how to deal
 163          with the fact that programs must have a main in RL and not in SG.
 164        - Document example/gras/ping as it uses almost all of the GRAS
 165          features.
 166
 167      Code related: too long to be written here. See the TODO file
 168
 169     @{
 170 */
 171
 172        /** \defgroup GRAS_dd      Data description      */
 173        /** \defgroup GRAS_sock    Sockets               */
 174        /** \defgroup GRAS_msg     Messages              */
 175
 176        /** \defgroup GRAS_globals Globals               */
 177        /** \defgroup GRAS_cond    Conditional execution */
 178        /** \defgroup GRAS_virtu   Syscalls              */
 179
 180 /** @} */
 181
 182 /** \defgroup SMPI_API      SMPI
 183     \ingroup SimGrid_API
 184     \brief Programming environment for the simulation of MPI applications
 185
 186     Once implemented, this programming environment will allow you to study
 187     within the simulator any MPI application without having to modify them
 188     for that. In other words, it will constitute an emulation solution for
 189     parallel codes.
 190
 191     \section SMPI_who Who should use this (and who shouldn't)
 192
 193     You should use this programming environment of the SimGrid suite if you
 194     want to study existing MPI applications.
 195     If you want to work on a distributed application, have a look at the
 196     \ref GRAS_API environment.
 197     If you want to study some heuristics for a given problem (and if your
 198     goal is to produce theorems, not code), have a look at the \ref MSG_API
 199     environment.
 200     If none of those programming environments fits your needs, you may
 201     consider implementing your own directly on top of \ref SURF_API (but you
 202     probably want to contact us before).
 203
 204  */