sascha/workload-automation
1
0
Fork 0
mirror of https://github.com/ARM-software/workload-automation.git synced 2025-04-16 07:40:48 +01:00
Code Issues Releases Wiki Activity

doc: Update links to have more useful display text

Browse Source
This commit is contained in:
Marc Bonnici 2018-06-21 14:56:09 +01:00 committed by setrofim
parent 716af1b966
commit d637557f5a
7 changed files with 19 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/source/developer_information/developer_reference/execution_model.rst
View File

@ -120,8 +120,8 @@ for the run. Priority can then be specified by adding ``extremely_fast``,
``very_fast``, ``fast`` , ``slow``, ``very_slow`` or ``extremely_slow`` ``very_fast``, ``fast`` , ``slow``, ``very_slow`` or ``extremely_slow``
:ref:`decorators <instruments_method_map>` to the method definitions. :ref:`decorators <instruments_method_map>` to the method definitions.
The full list of method names and the signals they map to may be viewed The full list of method names and the signals they map to may be seen at the
:ref:`here <instruments_method_map>`. :ref:`instrument method map <instruments_method_map>`.
Signal dispatching mechanism may also be used directly, for example to Signal dispatching mechanism may also be used directly, for example to
dynamically register callbacks at runtime or allow plugins other than dynamically register callbacks at runtime or allow plugins other than

4
doc/source/developer_information/developer_reference/writing_plugins.rst
View File

@ -859,8 +859,8 @@ Each method in ``Instrument`` must take two arguments, which are ``self`` and
``context``. Supported methods and their corresponding signals can be found in ``context``. Supported methods and their corresponding signals can be found in
the :ref:`Signals Documentation <instruments_method_map>`. To make the :ref:`Signals Documentation <instruments_method_map>`. To make
implementations easier and common, the basic steps to add new instrument is implementations easier and common, the basic steps to add new instrument is
similar to the steps to add new workload and an example can be found similar to the steps to add new workload and an example can be found in the
:ref:`here <adding-an-instrument-example>`. :ref:`How To <adding-an-instrument-example>` section.
.. _instrument-api: .. _instrument-api:

14
doc/source/developer_information/how_tos/adding_plugins.rst
View File

@ -49,7 +49,8 @@ on using the create workload command see ``wa create workload -h``
The first thing to decide is the type of workload you want to create depending The first thing to decide is the type of workload you want to create depending
on the OS you will be using and the aim of the workload. The are currently 6 on the OS you will be using and the aim of the workload. The are currently 6
available workload types to choose as detailed :ref:`here<workload-types>`. available workload types to choose as detailed in the
:ref:`Developer Reference <workload-types>`.
Once you have decided what type of workload you wish to choose this can be Once you have decided what type of workload you wish to choose this can be
specified with ``-k <workload_kind>`` followed by the workload name. This specified with ``-k <workload_kind>`` followed by the workload name. This
@ -383,8 +384,8 @@ The main difference between the two is that this workload will subclass
Adding an Instrument Example Adding an Instrument Example
============================= =============================
This is an example of how we would create a instrument which will trace device This is an example of how we would create a instrument which will trace device
errors using a custom "trace" binary file. For more detailed information please see errors using a custom "trace" binary file. For more detailed information please see the
:ref:`here <instrument-reference>`. The first thing to do is to subclass :ref:`Instrument Reference <instrument-reference>`. The first thing to do is to subclass
:class:`Instrument`, overwrite the variable name with what we want our instrument :class:`Instrument`, overwrite the variable name with what we want our instrument
to be called and locate our binary for our instrument. to be called and locate our binary for our instrument.
@ -400,8 +401,8 @@ to be called and locate our binary for our instrument.
self.binary_file = os.path.join(os.path.dirname(__file__), self.binary_name) self.binary_file = os.path.join(os.path.dirname(__file__), self.binary_name)
self.trace_on_target = None self.trace_on_target = None
We then declare and implement the required methods as detailed We then declare and implement the required methods as detailed in the
:ref:`here <instrument-api>`. For the ``initialize`` method, we want to install :ref:`Instrument API <instrument-api>`. For the ``initialize`` method, we want to install
the executable file to the target so we can use the target's ``install`` the executable file to the target so we can use the target's ``install``
method which will try to copy the file to a location on the device that method which will try to copy the file to a location on the device that
supports execution, change the file mode appropriately and return the supports execution, change the file mode appropriately and return the
@ -414,7 +415,8 @@ Then we implemented the start method, which will simply run the file to start
tracing. Supposing that the call to this binary requires some overhead to begin tracing. Supposing that the call to this binary requires some overhead to begin
collecting errors we might want to decorate the method with the ``@slow`` collecting errors we might want to decorate the method with the ``@slow``
decorator to try and reduce the impact on other running instruments. For more decorator to try and reduce the impact on other running instruments. For more
information on prioritization please see :ref:`here <prioritization>`. :: information on prioritization please see the
:ref:`Developer Reference <prioritization>`. ::
@slow @slow
def start(self, context): def start(self, context):

5
doc/source/glossary.rst
View File

@ -7,7 +7,7 @@ Glossary
An agenda specifies what is to be done during a Workload Automation An agenda specifies what is to be done during a Workload Automation
run. This includes which workloads will be run, with what configuration run. This includes which workloads will be run, with what configuration
and which augmentations will be enabled, etc. (For more information and which augmentations will be enabled, etc. (For more information
please see :ref:`here <agenda-reference>`.) please see the :ref:`Agenda Reference <agenda-reference>`.)
Alias Alias
An alias associated with a workload or a parameter. In case of An alias associated with a workload or a parameter. In case of
@ -38,7 +38,8 @@ Glossary
An artifact is something that was been generated as part of the run An artifact is something that was been generated as part of the run
for example a file containing output or meta data in the form of log for example a file containing output or meta data in the form of log
files. WA supports multiple "kinds" of artifacts and will handle them files. WA supports multiple "kinds" of artifacts and will handle them
accordingly, for more information please see :ref:`here <artifact>`. accordingly, for more information please see the
:ref:`Developer Reference <artifact>`.
Classifier Classifier
An arbitrary key-value pair that may associated with a :term:`job`\ , a An arbitrary key-value pair that may associated with a :term:`job`\ , a

4
doc/source/instrument_method_map.template
View File

@ -7,8 +7,8 @@ Instrument methods get automatically hooked up to signals based on their names.
Mostly, the method name corresponds to the name of the signal, however there are Mostly, the method name corresponds to the name of the signal, however there are
a few convenience aliases defined (listed first) to make easier to relate a few convenience aliases defined (listed first) to make easier to relate
instrumentation code to the workload execution model. For an overview on when instrumentation code to the workload execution model. For an overview on when
these signals are dispatched during execution please see these signals are dispatched during execution please see the
:ref:`here <signal_dispatch>`. :ref:`Developer Reference <signal_dispatch>`.
$signal_names $signal_names

2
doc/source/user_information/installation.rst
View File

@ -261,7 +261,7 @@ surface. For these, an interaction session needs to be recorded so that it can
be played back by WA. These recordings are device-specific, so they would need be played back by WA. These recordings are device-specific, so they would need
to be done for each device you're planning to use. The tool for doing is to be done for each device you're planning to use. The tool for doing is
``revent`` and it is packaged with WA. You can find instructions on how to use ``revent`` and it is packaged with WA. You can find instructions on how to use
it :ref:`here <revent_files_creation>`. it in the :ref:`How To <revent_files_creation>` section.
This is the list of workloads that rely on such recordings: This is the list of workloads that rely on such recordings:

2
doc/source/user_information/user_guide.rst
View File

@ -44,7 +44,7 @@ dependencies.
Alternatively we provide a Dockerfile that which can be used to create a Docker Alternatively we provide a Dockerfile that which can be used to create a Docker
image for running WA along with its dependencies. More information can be found image for running WA along with its dependencies. More information can be found
:ref:`here <dockerfile>`. in the :ref:`Installation <dockerfile>` section.
(Optional) Verify installation (Optional) Verify installation
------------------------------- -------------------------------