From 891fa5b18301c52ecec485bfe4390a107ecfd6c6 Mon Sep 17 00:00:00 2001 From: Martin Quinson Date: Mon, 10 Oct 2016 23:01:20 +0200 Subject: [PATCH] little doc reorg: split a page in two --- doc/Doxyfile.in | 1 + doc/doxygen/index.doc | 3 +- doc/doxygen/inside.doc | 92 +++++--------------------------------- doc/doxygen/uhood_arch.doc | 90 +++++++++++++++++++++++++++++++++++++ src/surf/surf_routing.hpp | 2 +- 5 files changed, 104 insertions(+), 84 deletions(-) create mode 100644 doc/doxygen/uhood_arch.doc diff --git a/doc/Doxyfile.in b/doc/Doxyfile.in index 8aeb6e1b9d..96b7571e64 100644 --- a/doc/Doxyfile.in +++ b/doc/Doxyfile.in @@ -663,6 +663,7 @@ INPUT = doxygen/index.doc \ doxygen/examples.doc \ doxygen/howtos.doc \ doxygen/uhood.doc \ + doxygen/uhood_arch.doc \ doxygen/uhood_switch.doc \ doxygen/inside.doc \ doxygen/inside_doxygen.doc \ diff --git a/doc/doxygen/index.doc b/doc/doxygen/index.doc index e06376dea2..f5240b7b6b 100644 --- a/doc/doxygen/index.doc +++ b/doc/doxygen/index.doc @@ -36,9 +36,10 @@ - @subpage tutorial - @subpage examples - @subpage uhood + - @subpage uhood_arch - Simulating Resource Sharing - @subpage uhood_switch - - @subpage inside + - @subpage uhood_tech - @subpage community - @subpage community_contact - @subpage community_giveback diff --git a/doc/doxygen/inside.doc b/doc/doxygen/inside.doc index 04c4122c8c..4dfbc8f4e8 100644 --- a/doc/doxygen/inside.doc +++ b/doc/doxygen/inside.doc @@ -1,16 +1,17 @@ -/*! @page inside Coding Standard and Project Architecture +/*! @page uhood_tech Coding Standard and Technical Considerations -TBD: Coding Standard There is two main things you want to know about the internals of SimGrid. First, you need to understand the component organization, as SimGrid is heavily layered, with each level being rather highly -specialized and optimized toward a task. For that, please keep reading -this page. If you work actively on the SimGrid project, the second -point you need to understand is about the infrastructure of the -SimGrid project, ie how to extend the framework in any way, how the -automatic tests are run, and so on. These informations are split on -several pages, as follows: +specialized and optimized toward a task. For that, please head to +@ref uhood_arch. + +Then, if you work actively on the SimGrid project, the second point +you need to understand is about the infrastructure of the SimGrid +project, ie how to extend the framework in any way, how the automatic +tests are run, and so on. These informations are split on several +pages, as follows: - @subpage inside_tests - @subpage inside_doxygen @@ -18,79 +19,6 @@ several pages, as follows: - @subpage inside_cmake - @subpage inside_release - -\htmlonly - -\endhtmlonly -\htmlinclude simgrid_modules.map -\htmlonly -
SimGrid Components (click to jump to API) - -\endhtmlonly - - -\section ug_overview Overview of the toolkit components - - -\subsection ug_overview_envs Programing environments layer - -SimGrid provides several programming environments built on top of a unique -simulation kernel. Each environment targets a specific audience and -constitutes a different paradigm. To choose which of them you want to use, -you have to think about what you want to do and what would be the result of -your work. - - - If you want to study a theoretical problem and compare several - heuristics, you probably want to try \ref MSG_API (yet another - historical name). It was designed exactly to that extend and should allow - you to build easily rather realistic multi-agents simulation. Yet, - realism is not the main goal of this environment and the most annoying - technical issues of real platforms are masked here. Check the \ref - MSG_API section for more information. - - - If you want to study the behavior of a MPI application using emulation, - you should have a look at the \ref SMPI_API (Simulated - MPI) programming environment. Unfortunately, this work is still underway. - Check the \ref SMPI_API section for more information. - -If your favorite programming environment/model is not there (BSP, -components, OpenMP, etc.) is not represented in the SimGrid toolkit yet, you may -consider adding it. You should contact us first on the -SimGrid -developers mailing list, though. - -\subsection ug_overview_kernel Simulation kernel layer - -The core functionalities to simulate a virtual platform are provided by a -module called \ref SURF_API. It is -very low-level and is not intended to be used as such by end-users. Instead, -it serve as a basis for the higher level layer. - -SURF main features are a fast max-min linear solver and the ability to -change transparently the model used to describe the platform. This greatly -eases the comparison of the several models existing in the literature. - -See the \ref SURF_API section for more details. - -\subsection ug_overview_fundation Base layer - -The base of the whole toolkit is constituted by the \ref XBT_API -(eXtended Bundle of Tools). - -It is a portable library providing some grounding features such as \ref -XBT_log, \ref XBT_ex and \ref XBT_config. - -XBT also encompass the following convenient C data structures: -\ref XBT_dynar, \ref XBT_fifo, \ref XBT_dict, \ref XBT_heap, \ref XBT_set and -\ref XBT_swag. The code is being migrated in C++ so you should probably want -to use standard C++ containers instead of them if possible. - -It contains some C++ polyfills and utilities as well. - -See the \ref XBT_API section for more details. - - -\subsection ug_lucas_layer Tracing simulation -Finally, a transversal module allows you to trace your simulation. More documentation in the section \ref TRACE_doc +TBD: Coding Standard */ diff --git a/doc/doxygen/uhood_arch.doc b/doc/doxygen/uhood_arch.doc new file mode 100644 index 0000000000..db93f20559 --- /dev/null +++ b/doc/doxygen/uhood_arch.doc @@ -0,0 +1,90 @@ +/*! @page uhood_arch Project Architecture Overview + +This page presents the current code organization, as you will see it +if you dig into the src/ directory. But things will change during +the current Gran Refactoring leading to SimGrid 4. So take the +information on this page with a grain of salt, and don't be affraid if +things are not exactly as documented here. + +At some point, we at least extend this page to present the overall +design that we are currently pursuing for SimGrid 4. + +If you need to extend SimGrid, then you probably need to head to @ref +uhood_tech once you understant the overall design presented on this +page. + +\htmlonly + +\endhtmlonly +\htmlinclude simgrid_modules.map +\htmlonly +
SimGrid Components (click to jump to API) + +\endhtmlonly + + +\section ug_overview Overview of the toolkit components + + +\subsection ug_overview_envs Programing environments layer + +SimGrid provides several programming environments built on top of a unique +simulation kernel. Each environment targets a specific audience and +constitutes a different paradigm. To choose which of them you want to use, +you have to think about what you want to do and what would be the result of +your work. + + - If you want to study a theoretical problem and compare several + heuristics, you probably want to try \ref MSG_API (yet another + historical name). It was designed exactly to that extend and should allow + you to build easily rather realistic multi-agents simulation. Yet, + realism is not the main goal of this environment and the most annoying + technical issues of real platforms are masked here. Check the \ref + MSG_API section for more information. + + - If you want to study the behavior of a MPI application using emulation, + you should have a look at the \ref SMPI_API (Simulated + MPI) programming environment. Unfortunately, this work is still underway. + Check the \ref SMPI_API section for more information. + +If your favorite programming environment/model is not there (BSP, +components, OpenMP, etc.) is not represented in the SimGrid toolkit yet, you may +consider adding it. You should contact us first on the +SimGrid +developers mailing list, though. + +\subsection ug_overview_kernel Simulation kernel layer + +The core functionalities to simulate a virtual platform are provided by a +module called \ref SURF_API. It is +very low-level and is not intended to be used as such by end-users. Instead, +it serve as a basis for the higher level layer. + +SURF main features are a fast max-min linear solver and the ability to +change transparently the model used to describe the platform. This greatly +eases the comparison of the several models existing in the literature. + +See the \ref SURF_API section for more details. + +\subsection ug_overview_fundation Base layer + +The base of the whole toolkit is constituted by the \ref XBT_API +(eXtended Bundle of Tools). + +It is a portable library providing some grounding features such as \ref +XBT_log, \ref XBT_ex and \ref XBT_config. + +XBT also encompass the following convenient C data structures: +\ref XBT_dynar, \ref XBT_fifo, \ref XBT_dict, \ref XBT_heap, \ref XBT_set and +\ref XBT_swag. The code is being migrated in C++ so you should probably want +to use standard C++ containers instead of them if possible. + +It contains some C++ polyfills and utilities as well. + +See the \ref XBT_API section for more details. + + +\subsection ug_lucas_layer Tracing simulation +Finally, a transversal module allows you to trace your simulation. More documentation in the section \ref TRACE_doc + +*/ diff --git a/src/surf/surf_routing.hpp b/src/surf/surf_routing.hpp index 5e096cefc5..bbe4e165b1 100644 --- a/src/surf/surf_routing.hpp +++ b/src/surf/surf_routing.hpp @@ -93,7 +93,7 @@ public: : src_(src), dst_(dst), link_(link) {}; NetCard *src_; NetCard *dst_; - void *link_; + void *link_; // FIXME: void* should die just like the death* }; /** @ingroup SURF_routing_interface -- 2.20.1