X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/7afff55a7df3d64c09ebcf8bfaf6fbb12b288513..9786ce5dc484c08aed9f0b92cbbf3097d2a6d371:/doc/doxygen/inside_extending.doc diff --git a/doc/doxygen/inside_extending.doc b/doc/doxygen/inside_extending.doc index e4da841c1e..e16c1e6ba8 100644 --- a/doc/doxygen/inside_extending.doc +++ b/doc/doxygen/inside_extending.doc @@ -4,23 +4,27 @@ \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? @@ -40,8 +44,7 @@ void surf_cpu_model_init_plop() surf_cpu_model_pm = new CpuPlopModel(); - sg_platf_host_add_cb(cpu_parse_init); - sg_platf_postparse_add_cb(cpu_add_traces); + simgrid::surf::on_postparse.connect(cpu_add_traces); xbt_dynar_push(model_list, &surf_cpu_model_pm); } @@ -92,12 +95,9 @@ static void MyNetworkCommunicationCallback(NetworkActionPtr cpu, } void sg_my_network_plugin_init() { - surf_callback_connect(networkLinkCreatedCallbacks, - MyNetworkLinkCreatedCallback); - surf_callback_connect(networkLinkDestructedCallbacks, - MyNetworkLinkDestructedCallback); - surf_callback_connect(networkCommunicationCallbacks, - MyNetworkCommunicationCallback); + networkLinkCreatedCallbacks.connect(MyNetworkLinkCreatedCallback); + networkLinkDestructedCallbacks.connect(MyNetworkLinkDestructedCallback); + networkCommunicationCallbacks.connect(MyNetworkCommunicationCallback); } ~~~~ @@ -117,36 +117,49 @@ s_surf_model_description_t surf_plugin_description[] = { ~~~~ \section simgrid_dev_guide_simcall How to add a new simcall? -A simcall is used to go from user mode to kernel mode. The workflow of -a simcall is the following: + +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: - ` simcall_()` - `simcall_BODY_()` - - create the simcall - - `SIMIX_process_yield` if not maestro + - 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_enter` - - `SIMIX_pre_(simcall, )` - - `SIMIX_simcall_answer(simcall)` - -To simplify the simcall creation, we have made a python script that -generate 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: + - `SIMIX_simcall_handle` large switch (on simcall) doing for each: + - `simcall_HANDLER_(simcall, )` (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_()`. + +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_()` 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.c: +- 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.c: +- 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 -Furthermode if the simcall_ or the SIMIX_pre_ 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: