@tableofcontents
-@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").
-
-@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,
-cpu_ti.hpp).
-
-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 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.
-
-For instance, if you want to add a new cup model called `Plop`, create two files
-cpu_plop.hpp and cpu_plop_cpp which contains classes CpuPlopModel, CpuPlop and
-CpuPlopAction implementating respectively the interfaces CpuModel, Cpu and
-CpuAction. You also need to define a initializing function like this:
-
-~~~~
-void surf_cpu_model_init_plop()
-{
- xbt_assert(!surf_cpu_model_pm);
-
- surf_cpu_model_pm = new CpuPlopModel();
-
- simgrid::surf::on_postparse.connect(cpu_add_traces);
-
- xbt_dynar_push(model_list, &surf_cpu_model_pm);
-}
-~~~~
-
-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).",
- surf_cpu_model_init_Cas01},
- {"Plop",
- "The new plop CPU model.",
- surf_cpu_model_init_plop},
- {NULL, NULL, NULL} // this array must be NULL terminated
-};
-~~~~
-
-@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?
-
-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
-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.
-
-~~~~
-static void MyNetworkLinkCreatedCallback(NetworkLinkPtr cpu){
- // your code
-}
-
-static void MyNetworkLinkDestructedCallback(NetworkLinkPtr cpu){
- // your code
-}
-
-static void MyNetworkCommunicationCallback(NetworkActionPtr cpu,
- RoutingEdgePtr src,
- RoutingEdgePtr dst){
- // your code
-}
-
-void sg_my_network_plugin_init() {
- networkLinkCreatedCallbacks.connect(MyNetworkLinkCreatedCallback);
- networkLinkDestructedCallbacks.connect(MyNetworkLinkDestructedCallback);
- networkCommunicationCallbacks.connect(MyNetworkCommunicationCallback);
-}
-~~~~
-
-Then you need to add an entry in surf_interface.cpp refering to your
-initialization function.
-
-~~~~
-s_surf_model_description_t surf_plugin_description[] = {
- {"Energy",
- "Cpu energy consumption.",
- sg_host_energy_plugin_init},
- {"MyNetworkPlugin",
- "My network plugin.",
- sg_my_network_plugin_init},
- {NULL, NULL, NULL} // this array must be NULL terminated
-};
-~~~~
-
@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:
- If maestro, executes the simcall directly (and return)
- 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.
+ It is thus the responsibility of the blocking simcalls to call
+ `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
simcall issuer, but when there no need for such things, the handler
-can be omited. In that case, we directly call the function
+can be omitted. In that case, we directly call the function
`simcall_<name>(<args>)`.
To simplify the simcall creation, a python script generates most of
Helper functions to get and set simcall arguments and results
- popping_bodies.cpp:
The BODY function of each simcall
-- popping_enum.h:
- Definition of type `enum e_smx_simcall_t` (one value per existing simcall)
+- popping_enum.hpp:
+ Definition of type `enum class Simcall` (one value per existing simcall)
- 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
+ ActorImpl::simcall_handle() that deals with the simcall from within the kernel
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.
~~~
void Host::setProperty(const char*key, const char *value){
simgrid::simix::kernelImmediate([&] {
- simgrid::surf::HostImpl* surf_host = this->extension<simgrid::surf::HostImpl>();
- surf_host->setProperty(key,value);
+ simgrid::kernel::resource::HostImpl* host =
+ this->extension<simgrid::kernel::resource::HostImpl>();
+ host->setProperty(key,value);
});
}
~~~
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
+in the kernel. When the operations completes, the user process is waken up
with the result:
~~~
You should not do something like that. Please work instead to make XML
avoidable, ie to make the C++ interface nice and usable.
-*/
\ No newline at end of file
+*/
