Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
Define __cplusplus for doxygen.
[simgrid.git] / doc / doxygen / platform.doc
index 88f556a..94e1194 100644 (file)
@@ -5,7 +5,7 @@
 \htmlonly
 <div align="center">
 \endhtmlonly
 \htmlonly
 <div align="center">
 \endhtmlonly
-\htmlinclude doc-toc.svg
+\htmlinclude graphical-toc.svg
 \htmlonly
 </div>
 <script>
 \htmlonly
 </div>
 <script>
@@ -340,7 +340,7 @@ The hosts generated in the above example are named host-1.cluster, host-2.cluste
 etc.
 
 
 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
 
 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
 \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 ####
 
 
 #### 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).
 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).
 
 
 \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                                                                                               |
 | ----------- | ----------- | -------- | -------------                                                                                             |
 
 | 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)
 | 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
 
 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.
 
 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
 \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 ...)
 
 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
 
 
 \verbinclude example_filelist_routing_dijkstra
 
-Dijkstra example :
+Dijkstra example:
 \verbatim
  <zone id="zone_2" routing="Dijkstra">
      <host id="zone_2_host1" speed="1000000000"/>
 \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 ###
 
 \anchor pf_routing_model_full
 ### Full ###
 
-Full example :
+Full example:
 \verbatim
 <zone  id="zone0"  routing="Full">
    <host id="host1" speed="1000000000"/>
 \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).
 <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 ####
 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
 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
 <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 ####
 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.
 
     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>
 
 \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
 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">
 
 \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
 
 \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
 
 
 \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
 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)
 
 \li <b>Full</b>: Full routing data (fast, large memory requirements,
     fully expressive)