/**
@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
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.
};
~~~~
-\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.
};
~~~~
-\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
- `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
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
<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.
