doc: Spelling and grammar tweaks

Did a partial run of ACRN documents through Acrolinx to catch additional
spelling and grammar fixes missed during regular reviews.

Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
This commit is contained in:
David B. Kinder
2020-09-25 16:24:35 -07:00
committed by David Kinder
parent d54347a054
commit dd0fe54141
58 changed files with 363 additions and 337 deletions

View File

@@ -29,7 +29,7 @@ The ``ACRN-Crashlog`` tool depends on the following libraries
- libblkid
- e2fsprogs
Refer to the :ref:`getting_started` for instructions on how to set-up your
Refer to the :ref:`getting_started` for instructions on how to set up your
build environment, and follow the instructions below to build and configure the
``ACRN-Crashlog`` tool.
@@ -163,7 +163,7 @@ telemetrics-client on the system:
of the telemetrics-client: it runs as a daemon autostarted when the system
boots, and sends the crashlog path to the telemetrics-client that records
events of interest and reports them to the backend using ``telemd`` the
telemetrics daemon. The work flow of ``acrnprobe`` and
telemetrics daemon. The workflow of ``acrnprobe`` and
telemetrics-client is shown in :numref:`crashlog-workflow`:
.. graphviz:: images/crashlog-workflow.dot
@@ -217,7 +217,7 @@ The source code structure:
like ``ipanic``, ``pstore`` and etc. For the log on AaaG, it's collected with
monitoring the change of related folders on the sos image, like
``/data/logs/``. ``acrnprobe`` also provides a flexible way to allow users to
configure which crash or event they want to collect through the xml file
configure which crash or event they want to collect through the XML file
easily.
- ``common``: some utils for logs, command and string.
- ``data``: configuration file, service files and shell script.

View File

@@ -42,7 +42,7 @@ Architecture
Terms
=====
- channel :
channel
Channel represents a way of detecting the system's events. There are 3
channels:
@@ -50,33 +50,33 @@ Terms
+ polling: run a detecting job with fixed time interval.
+ inotify: monitor the change of file or dir.
- trigger :
trigger
Essentially, trigger represents one section of content. It could be
a file's content, a directory's content, or a memory's content which can be
obtained. By monitoring it ``acrnprobe`` could detect certain events which
happened in the system.
a file's content, a directory's content, or a memory's content, which can be
obtained. By monitoring it, ``acrnprobe`` could detect certain events
that happened in the system.
- crash :
crash
A subtype of event. It often corresponds to a crash of programs, system, or
hypervisor. ``acrnprobe`` detects it and reports it as ``CRASH``.
- info :
info
A subtype of event. ``acrnprobe`` detects it and reports it as ``INFO``.
- event queue :
event queue
There is a global queue to receive all events detected.
Generally, events are enqueued in channel, and dequeued in event handler.
- event handler :
event handler
Event handler is a thread to handle events detected by channel.
It's awakened by an enqueued event.
- sender :
sender
The sender corresponds to an exit of event.
There are two senders:
+ Crashlog is responsible for collecting logs and saving it locally.
+ Telemd is responsible for sending log records to telemetrics client.
+ ``crashlog`` is responsible for collecting logs and saving it locally.
+ ``telemd`` is responsible for sending log records to telemetrics client.
Description
===========
@@ -86,30 +86,30 @@ As a log collection mechanism to record critical events on the platform,
1. detect event
From experience, the occurrence of an system event is usually accompanied
From experience, the occurrence of a system event is usually accompanied
by some effects. The effects could be a generated file, an error message in
kernel's log, or a system reboot. To get these effects, for some of them we
can monitor a directory, for other of them we might need to do a detection
can monitor a directory, for others, we might need to do detection
in a time loop.
*So we implement the channel, which represents a common method of detection.*
So we implement the channel, which represents a common method of detection.
2. analyze event and determine the event type
Generally, a specific effect correspond to a particular type of events.
Generally, a specific effect corresponds to a particular type of events.
However, it is the icing on the cake for analyzing the detailed event types
according to some phenomena. *Crash reclassify is implemented for this
purpose.*
according to some phenomena. Crash reclassifying is implemented for this
purpose.
3. collect information for detected events
This is for debug purpose. Events without information are meaningless,
and developers need to use this information to improve their system. *Sender
crashlog is implemented for this purpose.*
and developers need to use this information to improve their system. Sender
``crashlog`` is implemented for this purpose.
4. archive these information as logs, and generate records
There must be a central place to tell user what happened in system.
*Sender telemd is implemented for this purpose.*
Sender ``telemd`` is implemented for this purpose.
Diagram
=======
@@ -172,7 +172,7 @@ Source files
This file provides the function to get system reboot reason from kernel
command line.
- android_events.c
Sync events detected by android crashlog.
Sync events detected by Android ``crashlog``.
- loop.c
This file provides interfaces to read from image.

View File

@@ -81,7 +81,7 @@ Other properties
- ``inherit``:
Specify a parent for a certain crash.
The child crash will inherit all configurations from the specified (by id)
The child crash will inherit all configurations from the specified (by ID)
crash. These inherited configurations could be overwritten by new ones.
Also, this property helps build the crash tree in ``acrnprobe``.
- ``expression``:
@@ -90,7 +90,7 @@ Other properties
Crash tree in acrnprobe
***********************
There could be a parent-child relationship between crashes. Refer to the
There could be a parent/child relationship between crashes. Refer to the
diagrams below, crash B and D are the children of crash A, because crash B and
D inherit from crash A, and crash C is the child of crash B.
@@ -260,10 +260,10 @@ Example:
* ``channel``:
The ``channel`` name to get the virtual machine events.
* ``interval``:
Time interval in seconds of polling vm's image.
Time interval in seconds of polling VM's image.
* ``syncevent``:
Event type ``acrnprobe`` will synchronize from virtual machine's ``crashlog``.
User could specify different types by id. The event type can also be
User could specify different types by ID. The event type can also be
indicated by ``type/subtype``.
Log
@@ -369,6 +369,6 @@ Example:
The name of channel info use.
* ``log``:
The log to be collected. The value is the configured name in log module. User
could specify different logs by id.
could specify different logs by ID.
.. _`XML standard`: http://www.w3.org/TR/REC-xml

View File

@@ -23,7 +23,7 @@ the client. The client is responsible for collecting crash information
and saving it in the crashlog file. After the saving work is done, the
client notifies server and the server will clean up.
The work flow diagram:
The workflow diagram:
::

View File

@@ -78,7 +78,7 @@ Options:
- input file name
* - :kbd:`-o, --ofile=string`
- output filename
- output file name
* - :kbd:`-f, --frequency=unsigned_int`
- TSC frequency in MHz
@@ -155,7 +155,7 @@ data to your Linux system, and run the analysis tool.
-o /home/xxxx/trace_data/20171115-101605/cpu0 --vm_exit --irq
- The analysis report is written to stdout, or to a CSV file if
a filename is specified using ``-o filename``.
a file name is specified using ``-o filename``.
- The scripts require Python3.
Build and Install