X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/6b7277f4add5918aabe1e661f03ad1fa7b66f7d3..a53d7cf0445e5a6c3f2bb6606e6bd3b2b33b7867:/doc/doxygen/platform.doc
diff --git a/doc/doxygen/platform.doc b/doc/doxygen/platform.doc
index c8d898c68c..85ee6d9f8e 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
@@ -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 ...)