X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/77bbf3027c4240a2e833209a3a3f186589da8577..93e627932e2b4dfb8b7b4e319a820aeda261ceb9:/doc/doxygen/inside_extending.doc

diff --git a/doc/doxygen/inside_extending.doc b/doc/doxygen/inside_extending.doc
index 9593489d61..dc0c51e084 100644
--- a/doc/doxygen/inside_extending.doc
+++ b/doc/doxygen/inside_extending.doc
@@ -1,22 +1,22 @@
 /**
 @page inside_extending Extending SimGrid
 
-\tableofcontents
+@tableofcontents
 
-\section simgrid_dev_guide_model How to add a new model?
+@section simgrid_dev_guide_model How to add a new model?
 The figure below shows the architecture of the SURF layer. This layer is composed
 of different kinds of models representing the different systems we want to
 model (i.e., cpu, network, storage, workstation, virtual machine).
 
 A model in SimGrid is composed of three classes: Model, Resource and Action
-(\ref SURF_interface "surf_interface.hpp").
+(@ref SURF_interface "surf_interface.hpp").
 
-\image html surf++.png
-\image latex surf++.pdf "surf++" width=\textwidth
+@image html surf++.png
+@image latex surf++.pdf "surf++" width=\textwidth
 
 Actually there are five kind of models: CpuModel, NetworkModel, WorkstationModel,
 WorkstationVMModel and StorageModel. For each kind of model, there is an
-interface (e.g.: \ref SURF_cpu_interface "cpu_interface.hpp") and some implementations (e.g.: cpu_cas01.hpp,
+interface (e.g.: @ref SURF_cpu_interface "cpu_interface.hpp") and some implementations (e.g.: cpu_cas01.hpp,
 cpu_ti.hpp).
 
 The CPU model Cas01, for instance, is initialized by the function
@@ -27,7 +27,7 @@ that is defined as follows:
 
 s_surf_model_description_t surf_network_model_description[] = {
 
-\subsection simgrid_dev_guide_model_implem How to implement a new model?
+@subsection simgrid_dev_guide_model_implem How to implement a new model?
 
 If you want to create a new implementation of a kind of model you must extend
 the classes of the corresponding interfaces.
@@ -64,18 +64,18 @@ s_surf_model_description_t surf_cpu_model_description[] = {
 };
 ~~~~
 
-\subsection simgrid_dev_guide_model_kind How to add a new kind of model?
+@subsection simgrid_dev_guide_model_kind How to add a new kind of model?
 
 If you want to create a new kind of model, you must create a new interface
 where you extend the classes Model, Resource and Action, and then create an
 implementation of this interface.
 
 
-\section simgrid_dev_guide_surf_callbacks How to use surf callbacks?
+@section simgrid_dev_guide_surf_callbacks How to use surf callbacks?
 
 Adding features to surf could also be handle by using surf callbacks (instead
 of adding new implementation model). The list of available callbacks is
-accessible there \ref SURF_callbacks. An example of using surf callbacks is the
+accessible there @ref SURF_callbacks. An example of using surf callbacks is the
 energy plugin. If you want to add a plugin you need to define callback function
 and to connect them to callbacks handler in an initialization function.
 
@@ -108,7 +108,7 @@ initialization function.
 s_surf_model_description_t surf_plugin_description[] = {
                   {"Energy",
                    "Cpu energy consumption.",
-                   sg_energy_plugin_init},
+                   sg_host_energy_plugin_init},
                   {"MyNetworkPlugin",
                    "My network plugin.",
                    sg_my_network_plugin_init},
@@ -116,10 +116,10 @@ s_surf_model_description_t surf_plugin_description[] = {
 };
 ~~~~
 
-\section simgrid_dev_guide_simcall How to add a new simcall?
+@section simgrid_dev_guide_simcall How to add a new simcall?
 
 First of all you might want to avoid defining a new simcall if possible:
-\ref simgrid_dev_guide_generic_simcall.
+@ref simgrid_dev_guide_generic_simcall.
 
 A simcall is used to go from user mode to kernel mode. There is some
 sort of popping dance involved, as we want to isolate the user
@@ -138,7 +138,7 @@ The workflow of a simcall is the following:
  - `simcall_BODY_<name>(<args>)`
   - Initializes the simcall (store the arguments in position)
   - If maestro, executes the simcall directly (and return)
-  - If not, call `SIMIX_process_yield` to give back the control to maestro
+  - If not, call `ActorImpl::yield` to give back the control to maestro
   - ========== KERNEL MODE ==========
   - `SIMIX_simcall_handle` large switch (on simcall) doing for each:
    - `simcall_HANDLER_<name>(simcall, <args>)` (the manual code handling the simcall)
@@ -173,7 +173,7 @@ generates the following files:
 The simcall.in file list all the simcalls in sections. A line starting by "##"
 define a new section which will be replace by a "ifdef" in the generated code.
 
-\section simgrid_dev_guide_generic_simcall How to avoid adding a new simcall?
+@section simgrid_dev_guide_generic_simcall How to avoid adding a new simcall?
 
 We now have some generic simcalls which can be used to interface with the
 Maestro without creating new simcalls. You might want to use them instead of
@@ -201,7 +201,7 @@ If there is no blocking and no mutation involved (getters), you might consider
 avoiding switching to Maestro and reading directly the data you're interested
 in.
 
-For simcalls which might block, `kernelSync()` can be used. It takes a
+For simcalls which might block, `kernel_sync()` can be used. It takes a
 C++ callback and executes it immediately in maestro. This C++ callback is
 expected to return a `simgrid::kernel::Future<T>` reprensenting the operation
 in the kernal. When the operations completes, the user process is waken up
@@ -209,25 +209,25 @@ with the result:
 
 ~~~
 try {
-  std::vector<char> result = simgrid::simix::kernelSync([&] {
+  std::vector<char> result = simgrid::simix::kernel_sync([&] {
     // Fictional example, simgrid::kernel::readFile does not exist.
     simgrid::kernel::Future<std::vector<char>> result = simgrid::kernel::readFile(file);
     return result;
   });
   XBT_DEBUG("Finished reading file %s: length %zu", file, result.size());
 }
-// If the operation failed, kernelSync() throws an exception:
+// If the operation failed, kernel_sync() throws an exception:
 catch (std::runtime_error& e) {
   XBT_ERROR("Could not read file %s", file);
 }
 ~~~
 
-Asynchronous blocks can be implemented with `kernelAsync()`. It works
-like `kernelSync()` but does not block. Instead, it returns a
+Asynchronous blocks can be implemented with `kernel_async()`. It works
+like `kernel_sync()` but does not block. Instead, it returns a
 `simgrid::simix::Future` representing the operation in the process:
 
 ~~~
-simgrid::simix::Future<std:vector<char>> result = simgrid::simix::kernelSync([&] {
+simgrid::simix::Future<std:vector<char>> result = simgrid::simix::kernel_sync([&] {
   // Fictional example, simgrid::kernel::readFile does not exist.
   simgrid::kernek::Future<std::vector<char>> result = simgrid::kernel::readFile(file);
   return result;
@@ -249,9 +249,9 @@ catch (std::runtime_error& e) {
 }
 ~~~
 
-<b>Note:</b> `kernelSync(f)` could be implemented as `kernelAsync(f).get()`.
+<b>Note:</b> `kernel_sync(f)` could be implemented as `kernel_async(f).get()`.
 
-\section simgrid_dev_guide_tag What is How to add a new tag for xml files?
+@section simgrid_dev_guide_tag What is How to add a new tag for xml files?
 
 You should not do something like that. Please work instead to make XML
 avoidable, ie to make the C++ interface nice and usable.