sascha/workload-automation
1
0
Fork 0
mirror of https://github.com/ARM-software/workload-automation.git synced 2025-09-03 03:42:35 +01:00
Code Issues Releases Wiki Activity

pluginloader: Updated documentation to say plugin instead of extension

Browse Source
This commit is contained in:
Sebastian Goscik
2016-03-17 15:25:54 +00:00
parent 1e6763ee9b
commit c51593a729
16 changed files with 154 additions and 155 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
doc/source/execution_model.rst
View File

@@ -69,7 +69,7 @@ transition and interactions and will not attempt to describe very single thing t
device interface, based on the RunConfiguration. The executor also initialise a
``wlauto.core.execution.ExecutionContext`` which is used to track the current state of the run
execution and also serves as a means of communication between the core framework and the
extensions.
plugins.
#. Finally, the Executor instantiates a ``wlauto.core.execution.Runner``, initializes its job
queue with workload specs from the RunConfiguraiton, and kicks it off.
#. The Runner performs the run time initialization of the device and goes through the workload specs
@@ -100,7 +100,7 @@ The full list of method names and the signals they map to may be viewed
:ref:`here <instrumentation_method_map>`.
Signal dispatching mechanism may also be used directly, for example to dynamically register
callbacks at runtime or allow extensions other than ``Instruments`` to access stages of the run
callbacks at runtime or allow plugins other than ``Instruments`` to access stages of the run
they are normally not aware of.
The sending of signals is the responsibility of the Runner. Signals gets sent during transitions