\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?
- 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:
- - `SIMIX_pre_<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
-the simcall definitions from src/simix/simcalls.in and generates the
-following files:
+the simcall definitions from src/simix/simcalls.in, checks that both
+`simcall_<name>()` and `simcall_HANDLER()` are defined somewhere, and
+generates the following files:
- smx_popping_accessors.h:
Helper functions to get and set simcall arguments and results
Definitions of `simcall_names[]` (debug name of each simcall), and
SIMIX_simcall_enter() that deals with the simcall from within the kernel
-Furthermode if the simcall_<name> or the SIMIX_pre_<name> function are missing,
-a warning will show up with a prototype of the corresponding fonction to fill.
-
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.
There is a simcall by line which follow this format: