+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_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?
+
+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
+contextes from their environment (so that they can run in parallel).
+
+The workflow of a simcall is the following:
+
+- `<ret> simcall_<name>(<args>)`
+ - `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
+ - ========== KERNEL MODE ==========
+ - `SIMIX_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
+ 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, 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
+- smx_popping_bodies.cpp:
+ The BODY function of each simcall
+- smx_popping_enum.c:
+ Definition of type `enum e_smx_simcall_t` (one value per existing simcall)
+- smx_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
+
+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:
+
+~~~~
+Simcall -> Name HasAnswer Res Args
+Name -> [a-z0-9_]+
+Has_Answer -> "True" | "False"
+Res -> "(" Type MaybeCast ")"
+Args -> Args Arg | Arg
+Arg -> "(" Name "," Type MaybeCast ")"
+Type -> "char" | "const char*" | "int" | "long" | "unsigned char" | "unsigned short" | "unsigned int" | "unsigned long" | "float" | "double" | "void*" | "FPtr" | "const void*" | "size_t" | "sg_size_t" | "void" | "void*"
+MaybeCast -> "," Cast | ""
+Cast -> [a-z0-9_* ]+
+~~~~
+