X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/6b7277f4add5918aabe1e661f03ad1fa7b66f7d3..9913e297eeba0983a5ff635c076e3f458b178766:/doc/doxygen/platform.doc
diff --git a/doc/doxygen/platform.doc b/doc/doxygen/platform.doc
index c8d898c68c..94e1194de1 100644
--- a/doc/doxygen/platform.doc
+++ b/doc/doxygen/platform.doc
@@ -2,6 +2,17 @@
@tableofcontents
+\htmlonly
+
+\endhtmlonly
+\htmlinclude graphical-toc.svg
+\htmlonly
+
+
+\endhtmlonly
+
As @ref starting_components "explained in the introduction," any
SimGrid study must entail the description of the platform on which you
want to simulate your application. You have to describe **each element
@@ -329,7 +340,7 @@ The hosts generated in the above example are named host-1.cluster, host-2.cluste
etc.
-\subsubsection pf_peer \ (Vivaldi netzones only)
+\subsubsection pf_peer <peer> (Vivaldi netzones only)
This tag represents a peer, as in Peer-to-Peer (P2P) networks. This
can only be used in Vivaldi NetZones. It creates the following
@@ -392,7 +403,7 @@ several other tags that are available only in certain contexts.
\subsubsection pf_router <router/>
As said before, router is used only to give some information
-for routing algorithms. So, it does not have any attributes except :
+for routing algorithms. So, it does not have any attributes except:
#### Attributes ####
@@ -605,7 +616,7 @@ that include storage facilities:
Entity name | Description
--------------- | -----------
\ref pf_storage_entity_storage_type "storage_type" | Defines a template for a particular kind of storage (such as a hard-drive) and specifies important features of the storage, such as capacity, performance (read/write), contents, ... Different models of hard-drives use different storage_types (because the difference between an SSD and an HDD does matter), as they differ in some specifications (e.g., different sizes or read/write performance).
-\ref pf_storage_entity_storage "storage" | Defines an actual instance of a storage type (disk, RAM, ...); uses a ``storage_type`` template (see line above) so that you don't need to re-specify the same details over and over again.
+\ref pf_tag_storage "storage" | Defines an actual instance of a storage type (disk, RAM, ...); uses a ``storage_type`` template (see line above) so that you don't need to re-specify the same details over and over again.
\ref pf_tag_mount "mount" | Must be wrapped by a \ref pf_tag_host tag; declares which storage(s) this host has mounted and where (i.e., the mountpoint).
@@ -740,7 +751,7 @@ called alice (which is again not defined here).
| Attribute | Mandatory | Values | Description |
| ----------- | ----------- | -------- | ------------- |
-| id | yes | string | Refers to a \ref pf_storage_entity_storage "<storage>" entity that will be mounted on that computer |
+| id | yes | string | Refers to a \ref pf_tag_storage "<storage>" entity that will be mounted on that computer |
| name | yes | string | Path/location to/of the logical reference (mount point) of this disk
This tag must be enclosed by a \ref pf_tag_host tag. It then specifies where the mountpoint of a given storage device (defined by the ``id`` attribute)
@@ -773,7 +784,7 @@ Here is a simple example, taken from the file ``examples/platform/storage.xml``:
This example is quite interesting, as the same device, called "Disk2", is mounted by
two hosts at the same time! Note, however, that the host called ``alice`` is actually
-attached to this storage, as can be seen in the \ref pf_storage_entity_storage "<storage>"
+attached to this storage, as can be seen in the \ref pf_tag_storage "<storage>"
tag. This means that ``denise`` must access this storage through the network, but SimGrid automatically takes
care of that for you.
@@ -825,7 +836,7 @@ RAM -- Host B
\endverbatim
An easy way to model this scenario is to setup and define the RAM via the
-\ref pf_storage_entity_storage "storage" and \ref pf_storage_entity_storage_type "storage type"
+\ref pf_tag_storage "storage" and \ref pf_storage_entity_storage_type "storage type"
entities and attach it to a remote dummy host; then, every host can have their own links
to this host (modelling for instance certain scenarios, such as PCIe ...)
@@ -990,7 +1001,7 @@ routing model (the path is given relative to SimGrid's source directory)
\verbinclude example_filelist_routing_dijkstra
-Dijkstra example :
+Dijkstra example:
\verbatim
@@ -1040,7 +1051,7 @@ if there are no example files listed here, this is likely to be correct.
\anchor pf_routing_model_full
### Full ###
-Full example :
+Full example:
\verbatim
@@ -1286,7 +1297,7 @@ to bypass some routes defined in lower level zone at an upper stage:
bypasszoneroute is the tag you're looking for. It allows to
bypass routes defined between already defined between zone (if you want
to bypass route for a specific host, you should just use byPassRoute).
-The principle is the same as zoneroute : bypasszoneroute contains
+The principle is the same as zoneroute: bypasszoneroute contains
list of links that are in the path between src and dst.
#### Attributes ####
@@ -1319,10 +1330,10 @@ attribute was not given, this route is presumed to be symmetrical.
As said before, once you choose
a model, it (most likely; the constant network model, for example, doesn't) calculates routes for you. But maybe you want to
define some of your routes, which will be specific. You may also want
-to bypass some routes defined in lower level zone at an upper stage :
+to bypass some routes defined in lower level zone at an upper stage:
bypassRoute is the tag you're looking for. It allows to bypass
routes defined between host/router. The principle is the same
-as route : bypassRoute contains list of links references of
+as route: bypassRoute contains list of links references of
links that are in the path between src and dst.
#### Attributes ####
@@ -1362,7 +1373,7 @@ and zone_2. If you want to make a host (h1) from zone_1 with another one
defined inside zone_Big. If you choose some shortest-path model,
this route will be computed automatically.
-As said before, there are mainly 2 tags for routing :
+As said before, there are mainly 2 tags for routing:
\li zoneroute: to define routes between two zone
\li route: to define routes between two host/router
@@ -1376,7 +1387,7 @@ say that zone_1 contains full routes, and zone_2 contains some Floyd
routing (as we don't want to bother with defining all routes). As
we're using some shortest path algorithms to route into zone_2, we'll
then have to define some route to gives some topological
-information to SimGrid. Here is a file doing it all :
+information to SimGrid. Here is a file doing it all:
\verbatim
@@ -1599,7 +1610,7 @@ platforms.
\subsection pf_exit_zone Exit Zone: why and how
Users that have looked at some of our platforms may have notice a
-non-intuitive schema ... Something like that :
+non-intuitive schema ... Something like that:
\verbatim
@@ -1704,7 +1715,7 @@ You may have noted that conveniently, a peer named FOO defines an zone named FOO
Choosing wisely the routing model to use can significantly fasten your
simulation/save your time when writing the platform/save tremendous
disk space. Here is the list of available model and their
-characteristics (lookup : time to resolve a route):
+characteristics (lookup: time to resolve a route):
\li Full: Full routing data (fast, large memory requirements,
fully expressive)