Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
Merge branch 'master' of https://framagit.org/simgrid/simgrid
[simgrid.git] / doc / doxygen / inside_extending.doc
index 10d38b6..f0f02b6 100644 (file)
@@ -55,7 +55,7 @@ and add an entry in the corresponding array in surf_interface.cpp
 ~~~~
 s_surf_model_description_t surf_cpu_model_description[] = {
   {"Cas01",
-   "Simplistic CPU model (time=size/power).",
+   "Simplistic CPU model (time=size/speed).",
    surf_cpu_model_init_Cas01},
   {"Plop",
    "The new plop CPU model.",
@@ -138,15 +138,15 @@ 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:
+  - `ActorImpl::simcall_handle` large switch (on simcall) doing for each:
    - `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
+     call `ActorImpl::simcall_answer()` 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.
+     `ActorImpl::simcall_answer()` themselves in their handler.
 
 Note that empty HANDLERs can be omitted. These functions usually do
 some parameter checking, or retrieve some information about the