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
+CpuPlopAction implementing respectively the interfaces CpuModel, Cpu and
CpuAction. You also need to define a initializing function like this:
~~~~
~~~~
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.",
}
~~~~
-Then you need to add an entry in surf_interface.cpp refering to your
+Then you need to add an entry in surf_interface.cpp referring to your
initialization function.
~~~~
- `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.
+ 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:
+- popping_enum.hpp:
Definition of type `enum e_smx_simcall_t` (one value per existing simcall)
- popping_generated.cpp:
Definitions of `simcall_names[]` (debug name of each simcall), and
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:
~~~
