#MSG_function_register (and maybe #MSG_function_register_default)
-# Launch your processes from a deployment file with #MSG_launch_application
-# Run the simulation with #MSG_main
-
-@htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Simulation Control" --> @endhtmlonly
*/
/** @defgroup m_process_management Process Management Functions
* @brief This section describes the task structure of MSG
* (#msg_task_t) and the functions for managing it. See
* \ref msg_task_usage to see how to put the tasks in action.
- *
- * \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Tasks" --> \endhtmlonly
*/
/** @defgroup msg_mailbox_management Mailbox Management Functions
* @ingroup MSG_API
* @brief This section describes the mailbox structure of MSG
* (#msg_mailbox_t) and the functions for managing it.
- *
- * \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Mailbox" --> \endhtmlonly
*/
/** @defgroup msg_task_usage Task Actions
@ingroup MSG_API
@brief This section describes the functions allowing to build trace-driven simulations.
-\htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Trace-Driven" --> \endhtmlonly
-
This is very handy when you want to test an algorithm or protocol that
does nothing unless it receives some events from outside. For example,
a P2P protocol reacts to requests from the user, but does nothing if
@ingroup SD_API
@brief This section describes the different datatypes provided by SD.
*/
-/** @addtogroup SD_datatypes_management
- \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Data types" --> \endhtmlonly
-*/
+/** @addtogroup SD_datatypes_management */
/** \addtogroup SD_workstation_management
\ingroup SD_API */
/** \addtogroup SD_link_management
@defgroup SURF_c_bindings SURF C bindings
@ingroup SURF_API
@brief Describes the c bindings of SURF
-
-@htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Surf C bindings" --> @endhtmlonly
*/
/**
@defgroup SURF_interface SURF Interface
@ingroup SURF_API
@brief Describes the general interface for all components (Cpu, Network, Storage, Host, VM)
-
-@htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Surf Interface" --> @endhtmlonly
*/
/**
@defgroup SURF_routing_interface SURF Routing Interface
@ingroup SURF_API
@brief Describes the routing interface
-
-@htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Surf Routing" --> @endhtmlonly
*/
/**
@defgroup SURF_cpu_interface SURF Cpu Interface
@ingroup SURF_API
@brief Describes the general Cpu interface for all Cpu implementations
-
-@htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Cpu Interface" --> @endhtmlonly
*/
/**
@defgroup SURF_network_interface SURF Network Interface
@ingroup SURF_API
@brief Describes the general Network interface for all Network implementations
-
-@htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Network Interface" --> @endhtmlonly
*/
/**
@defgroup SURF_storage_interface SURF Storage Interface
@ingroup SURF_API
@brief Describes the general interface for all Storage implementations
-
-@htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Storage Interface" --> @endhtmlonly
*/
/**
@defgroup SURF_host_interface SURF Host Interface
@ingroup SURF_API
@brief Describes the general interface for all Host implementations
-
-@htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Host Interface" --> @endhtmlonly
*/
/**
@defgroup SURF_vm_interface SURF VM Interface
@ingroup SURF_API
@brief Describes the general interface for all VM implementations
-
-@htmlonly <!-- DOXYGEN_NAVBAR_LABEL="VM Interface" --> @endhtmlonly
*/
/**
@defgroup SURF_lmm SURF Linear MaxMin
@ingroup SURF_API
@brief Describes how the linear MaxMin system work
-
-@htmlonly <!-- DOXYGEN_NAVBAR_LABEL="SURF Linear MaxMin" --> @endhtmlonly
*/
/**
@defgroup SURF_callbacks SURF callbacks
@ingroup SURF_API
@brief Describes how to use the SURF callbacks
-
-@htmlonly <!-- DOXYGEN_NAVBAR_LABEL="SURF callbacks" --> @endhtmlonly
*/
/**
@defgroup SURF_plugin_energy SURF Energy Plugin
@ingroup SURF_API
@brief Describes how to use the energy plugin.
-
-@htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Energy plugin" --> @endhtmlonly
*/
+This file follows the Doxygen syntax to be included in the documentation.
+
+/**
MSG comes with an extensive set of examples. It is sometimes difficult
to find the one you need. This list aims at helping you finding the
example from which you can learn what you want to.
constitute a fully working non-trivial example. In addition, its
implementation is rather efficient, as demonstrated in
[57]http://hal.inria.fr/inria-00602216/
+
+
+*/
\ No newline at end of file
/** @addtogroup MSG_examples
*
+ * @example app-pingpong/app-pingpong.c
+ *
* - <b>Ping-Pong: app-pingpong/app-pingpong.c</b>. It's hard to think of a simpler example. The tesh file
* laying in the directory is instructive concerning the way to pass options to the simulators (see \ref options).
*/
XBT_INFO("Ping -> %s", argv[1]);
xbt_assert(MSG_host_by_name(argv[1]) != NULL, "Unknown host %s. Stopping Now! ", argv[1]);
- /** - Do the ping with a 1-Byte task (latency bound) ... */
+ /* - Do the ping with a 1-Byte task (latency bound) ... */
double time = MSG_get_clock();
msg_task_t ping_task = MSG_task_create("small communication (latency bound)", 0.0, 1, NULL);
ping_task->data = xbt_new(double, 1);
*(double *) ping_task->data = time;
MSG_task_send(ping_task, argv[1]);
- /** - ... then wait for the (large) pong */
+ /* - ... then wait for the (large) pong */
msg_task_t pong_task = NULL;
int a = MSG_task_receive(&pong_task,MSG_host_get_name(MSG_host_self()));
xbt_assert(a == MSG_OK, "Unexpected behavior");
XBT_LOG_EXTERNAL_DEFAULT_CATEGORY(msg);
/** @addtogroup m_host_management
- * \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Hosts" --> \endhtmlonly
* (#msg_host_t) and the functions for managing it.
*
* A <em>location</em> (or <em>host</em>) is any possible place where a process may run. Thus it may be represented
XBT_LOG_NEW_DEFAULT_SUBCATEGORY(msg_io, msg, "Logging specific to MSG (io)");
/** @addtogroup msg_file_management
- * \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Files" --> \endhtmlonly
* (#msg_file_t) and the functions for managing it.
*
* \see #msg_file_t
/********************************* Storage **************************************/
/** @addtogroup msg_storage_management
- * \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Storages" --> \endhtmlonly
* (#msg_storage_t) and the functions for managing it.
*/
XBT_LOG_NEW_DEFAULT_SUBCATEGORY(msg_process, msg, "Logging specific to MSG (process)");
/** @addtogroup m_process_management
- * \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Processes" --> \endhtmlonly
*
* Processes (#msg_process_t) are independent agents that can do stuff on their own. They are in charge of executing
* your code interacting with the simulated world.