mirror of
https://github.com/projectacrn/acrn-hypervisor.git
synced 2025-09-10 21:29:20 +00:00
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:
committed by
David Kinder
parent
d54347a054
commit
dd0fe54141
@@ -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.
|
||||
|
@@ -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.
|
||||
|
||||
|
@@ -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
|
||||
|
@@ -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:
|
||||
|
||||
::
|
||||
|
||||
|
@@ -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
|
||||
|
Reference in New Issue
Block a user