X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/5e044aacdc2c13e6d78c4f5bb64db0f25140bc10..52fd53c1927b271828348841b782281f64b7bef8:/doc/doxygen/platform.doc

diff --git a/doc/doxygen/platform.doc b/doc/doxygen/platform.doc
index 88f556a87b..94e1194de1 100644
--- a/doc/doxygen/platform.doc
+++ b/doc/doxygen/platform.doc
@@ -5,7 +5,7 @@
 \htmlonly
 <div align="center">
 \endhtmlonly
-\htmlinclude doc-toc.svg
+\htmlinclude graphical-toc.svg
 \htmlonly
 </div>
 <script>
@@ -340,7 +340,7 @@ The hosts generated in the above example are named host-1.cluster, host-2.cluste
 etc.
 
 
-\subsubsection pf_peer \<peer\> (Vivaldi netzones only)
+\subsubsection pf_peer &lt;peer&gt; (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
@@ -403,7 +403,7 @@ several other tags that are available only in certain contexts.
 \subsubsection pf_router &lt;router/&gt;
 
 As said before, <b>router</b> 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 ####
 
@@ -616,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).
 
 
@@ -751,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 "&lt;storage&gt;" entity that will be mounted on that computer |
+| id          | yes         | string   | Refers to a \ref pf_tag_storage "&lt;storage&gt;" 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)
@@ -784,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 "&lt;storage&gt;"
+attached to this storage, as can be seen in the \ref pf_tag_storage "&lt;storage&gt;"
 tag. This means that ``denise`` must access this storage through the network, but SimGrid automatically takes
 care of that for you.
 
@@ -836,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 ...)
 
@@ -1001,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
  <zone id="zone_2" routing="Dijkstra">
      <host id="zone_2_host1" speed="1000000000"/>
@@ -1051,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
 <zone  id="zone0"  routing="Full">
    <host id="host1" speed="1000000000"/>
@@ -1297,7 +1297,7 @@ to bypass some routes defined in lower level zone at an upper stage:
 <b>bypasszoneroute</b> 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 : <b>bypasszoneroute</b> contains
+The principle is the same as zoneroute: <b>bypasszoneroute</b> contains
 list of links that are in the path between src and dst.
 
 #### Attributes ####
@@ -1330,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:
 <b>bypassRoute</b> is the tag you're looking for. It allows to bypass
 routes defined between <b>host/router</b>. The principle is the same
-as route : <b>bypassRoute</b> contains list of links references of
+as route: <b>bypassRoute</b> contains list of links references of
 links that are in the path between src and dst.
 
 #### Attributes ####
@@ -1373,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 <b>zoneroute</b>: to define routes between two  <b>zone</b>
 \li <b>route</b>: to define routes between two <b>host/router</b>
 
@@ -1387,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 <b>route</b> 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
 <zone  id="zone_Big"  routing="Dijkstra">
@@ -1610,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
@@ -1715,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 <b>Full</b>: Full routing data (fast, large memory requirements,
     fully expressive)