X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/0efcfe60e36cdc4e20e4deebe3abb38d22842b49..049d779ab5486982b7d055be77bd85373f8957a9:/doc/doxygen/inside_extending.doc

diff --git a/doc/doxygen/inside_extending.doc b/doc/doxygen/inside_extending.doc
index 546a6c69ef..e16c1e6ba8 100644
--- a/doc/doxygen/inside_extending.doc
+++ b/doc/doxygen/inside_extending.doc
@@ -4,23 +4,27 @@
 \tableofcontents
 
 \section simgrid_dev_guide_model How to add a new model in surf?
-The figure below show the architecture of the SURF layer. This layer is composed
-of different kind of models representing the differents systems we want to
-modelize (i.e.cpu, network, storage, workstation, virtual machine).
+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
-(surf_interface.hpp).
+(\ref SURF_interface "surf_interface.hpp").
 
 \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.: 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).
 
-init function:
-void surf_cpu_model_init_Cas01()
+The CPU model Cas01, for instance, is initialized by the function
+    void surf_cpu_model_init_Cas01()
+
+The different network models that are offered by simgrid are stored in the array
+that is defined as follows:
+
 s_surf_model_description_t surf_network_model_description[] = {
 
 \subsection simgrid_dev_guide_model_implem How to add a new model implementation in surf?
@@ -40,8 +44,7 @@ void surf_cpu_model_init_plop()
 
   surf_cpu_model_pm = new CpuPlopModel();
 
-  sg_platf_host_add_cb(cpu_parse_init);
-  sg_platf_postparse_add_cb(cpu_add_traces);
+  simgrid::surf::on_postparse.connect(cpu_add_traces);
 
   xbt_dynar_push(model_list, &surf_cpu_model_pm);
 }
@@ -92,12 +95,9 @@ static void MyNetworkCommunicationCallback(NetworkActionPtr cpu,
 }
 
 void sg_my_network_plugin_init() {
-  surf_callback_connect(networkLinkCreatedCallbacks,
-                        MyNetworkLinkCreatedCallback);
-  surf_callback_connect(networkLinkDestructedCallbacks,
-                        MyNetworkLinkDestructedCallback);
-  surf_callback_connect(networkCommunicationCallbacks,
-                        MyNetworkCommunicationCallback);
+  networkLinkCreatedCallbacks.connect(MyNetworkLinkCreatedCallback);
+  networkLinkDestructedCallbacks.connect(MyNetworkLinkDestructedCallback);
+  networkCommunicationCallbacks.connect(MyNetworkCommunicationCallback);
 }
 ~~~~
 
@@ -131,8 +131,18 @@ The workflow of a simcall is the following:
   - If not, call `SIMIX_process_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>)`
-   - `SIMIX_simcall_answer(simcall)`
+   - `simcall_HANDLER_<name>(simcall, <args>)` (the manual code handling the simcall)
+   - If the simcall is not marked as "blocking" in its definition,
+     call `SIMIX_simcall_answer(simcall)` that adds back the issuer
+     process to the list of processes to run in the next scheduling round.
+     It is thus the responsability of the blocking simcalls to call
+     `SIMIX_simcall_answer(simcall)` themselves in their handler.
+
+Note that empty HANDLERs can be omitted. These functions usually do
+some parameter checking, or retrieve some information about the
+simcall issuer, but when there no need for such things, the handler
+can be omited. In that case, we directly call the function
+`simcall_<name>(<args>)`.
 
 To simplify the simcall creation, a python script generates most of
 the code and give helpers for the remaining stuff. That script reads
@@ -142,11 +152,11 @@ generates the following files:
 
 - smx_popping_accessors.h:
   Helper functions to get and set simcall arguments and results
-- smx_popping_bodies.c:
+- smx_popping_bodies.cpp:
   The BODY function of each simcall
 - smx_popping_enum.c:
   Definition of type `enum e_smx_simcall_t` (one value per existing simcall)
-- smx_popping_generated.c:
+- smx_popping_generated.cpp:
   Definitions of `simcall_names[]` (debug name of each simcall), and
   SIMIX_simcall_enter() that deals with the simcall from within the kernel