github/acrn-hypervisor
1
0
Fork 0
mirror of https://github.com/projectacrn/acrn-hypervisor.git synced 2025-06-19 04:02:05 +00:00
Code Issues Projects Releases Wiki Activity

doc: update inclusive language terms in docs

Browse Source 
Replace white/black master/slave terms with alternatives.  We're not
changing "master" when used in the context of GitHub branches.  GitHub
advises they have a plan to help this transition.  In the text body we
rever to the "master" branch as the "main" branch, but leave any urls or
code-block commands still using "master".

Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
This commit is contained in:
David B. Kinder 2020-08-31 15:40:08 -07:00 committed by David Kinder
parent 6ddf793f16
commit fc1fc0eb8d
9 changed files with 35 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
doc/developer-guides/contribute_guidelines.rst
View File

@ -271,7 +271,7 @@ source files for the hypervisor, devicemodel, and documentation.
right corner of the project acrn-hypervisor repo page in GitHub.)
When you want to submit a pull request with your changes, you'll
first submit them to your personal branch, and then to the project's
master branch for review and merging by the ACRN maintainers.
main branch for review and merging by the ACRN maintainers.
#. On your development computer, clone the fork you just made::
@ -285,7 +285,7 @@ source files for the hypervisor, devicemodel, and documentation.
$ git remote -v
#. Create a topic branch (off of master) for your work (if you're addressing
#. Create a topic branch (off of the main branch) for your work (if you're addressing
an issue, we suggest including the issue number in the branch name)::
$ git checkout master
@ -385,7 +385,7 @@ source files for the hypervisor, devicemodel, and documentation.
#. While you're waiting for your pull request to be accepted and merged, you can
create another branch to work on another issue. (Be sure to make your new branch
off of master and not the previous branch.)::
off of the main branch and not the previous branch.)::
$ git checkout master
$ git checkout -b fix_another_issue
@ -406,9 +406,9 @@ source files for the hypervisor, devicemodel, and documentation.
This is an important step to make sure your changes are properly
merged with changes from other developers that may have happened while you
were working on your changes.
The ``--ignore-whitespace`` option
stops ``git apply`` (called by rebase) from changing
any whitespace. If any merging issues are detected you can address them
The ``--ignore-whitespace`` option stops ``git apply`` (called by
rebase) from changing any whitespace characters (such as spaces, tabs, and
newlines). If any merging issues are detected you can address them
with::
$ git rebase -i <offending-commit-id>

4
doc/developer-guides/doc_guidelines.rst
View File

@ -407,7 +407,7 @@ For example:
Note the blank line between the ``code-block`` directive and the first
line of the code-block body, and the body content is indented three
spaces (to the first non-white space of the directive name).
spaces (to the first non-blank space of the directive name).
This would be rendered as:
@ -478,7 +478,7 @@ Tabs, spaces, and indenting
Indenting is significant in reST file content, and using spaces is
preferred. Extra indenting can (unintentionally) change the way content
is rendered too. For lists and directives, indent the content text to
the first non-white space in the preceding line. For example:
the first non-blank space in the preceding line. For example:
.. code-block:: rest

18
doc/developer-guides/hld/hv-ioc-virt.rst
View File

@ -23,7 +23,7 @@ user OS can directly reuse native CBC driver.
The IOC Mediator has several virtualization requirements, such as S3/S5
wakeup reason emulation, CBC link frame packing/unpacking, signal
whitelist, and RTC configuration.
passlist, and RTC configuration.
IOC Mediator Design
*******************
@ -111,7 +111,7 @@ DM communicates with several native CBC char devices and a PTY device.
The native CBC char devices only include ``/dev/cbc-lifecycle``,
``/dev/cbc-signals``, and ``/dev/cbc-raw0`` - ``/dev/cbc-raw11``. Others
are not used by the IOC DM. IOC DM opens the ``/dev/ptmx`` device to
create a pair of devices (master and slave), The IOC DM uses these
create a pair of devices (primary and secondary), The IOC DM uses these
devices to communicate with UART DM since UART DM needs a TTY capable
device as its backend.
@ -150,7 +150,7 @@ char devices and UART DM immediately.
receives service data from native CBC char devices such as
``/dev/cbc-lifecycle``. If service data is CBC wakeup reason, some wakeup
reason bits will be masked. If service data is CBC signal, the data
will be dropped and will not be defined in the whitelist. If service
will be dropped and will not be defined in the passlist. If service
data comes from a raw channel, the data will be passed forward. Before
transmitting to the virtual UART interface, all data needs to be
packed with an address header and link header.
@ -562,22 +562,22 @@ IOC signal type definitions are as below.
- The IOC backend needs to emulate the channel open/reset/close message which
shouldn't be forward to the native cbc signal channel. The Service VM signal
related services should do a real open/reset/close signal channel.
- Every backend should maintain a whitelist for different VMs. The
whitelist can be stored in the Service VM file system (Read only) in the
- Every backend should maintain a passlist for different VMs. The
passlist can be stored in the Service VM file system (Read only) in the
future, but currently it is hard coded.
IOC mediator has two whitelist tables, one is used for rx
IOC mediator has two passlist tables, one is used for rx
signals(SOC->IOC), and the other one is used for tx signals. The IOC
mediator drops the single signals and group signals if the signals are
not defined in the whitelist. For multi signal, IOC mediator generates a
new multi signal, which contains the signals in the whitelist.
not defined in the passlist. For multi signal, IOC mediator generates a
new multi signal, which contains the signals in the passlist.
.. figure:: images/ioc-image3.png
:width: 600px
:align: center
:name: ioc-med-multi-signal
IOC Mediator - Multi-Signal whitelist
IOC Mediator - Multi-Signal passlist
Raw data
--------

6
doc/developer-guides/hld/ivshmem-hld.rst
View File

@ -236,10 +236,10 @@ architecture and threat model for your application.
- References: `NIST Crypto Standards and Guidelines <https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines>`_, `OpenSSL <https://www.openssl.org/>`_
4. **Applications Whitelisting**
4. **Applications Passlisting**
- For use cases implemented in static environments (for example, Industrial and Automotive usages), follow application whitelist techniques and disable any third-party or native app stores.
- This mechanism can be chained with the access control policies to protect access to whitelisting rules and configuration files (refer to opensource or implement your custom solution).
- For use cases implemented in static environments (for example, Industrial and Automotive usages), follow application approval techniques and disable any third-party or native app stores.
- This mechanism can be chained with the access control policies to protect access to passlisting rules and configuration files (refer to opensource or implement your custom solution).
- References: `NIST SP800-167 <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-167.pdf>`_, `fapolicyd <https://github.com/linux-application-whitelisting/fapolicyd>`_

18
doc/developer-guides/hld/virtio-i2c.rst
View File

@ -4,10 +4,10 @@ Virtio-i2c
##########
Virtio-i2c provides a virtual I2C adapter that supports mapping multiple
slave devices under multiple native I2C adapters to one virtio I2C
adapter. The address for the slave device is not changed. Virtio-i2c
also provides an interface to add an acpi node for slave devices so that
the slave device driver in the guest OS does not need to change.
secondary devices under multiple native I2C adapters to one virtio I2C
adapter. The address for the secondary device is not changed. Virtio-i2c
also provides an interface to add an acpi node for secondary devices so that
the secondary device driver in the guest OS does not need to change.
:numref:`virtio-i2c-1` below shows the virtio-i2c architecture.
@ -46,13 +46,13 @@ notifies the frontend. The msg process flow is shown in
Message Process Flow
**Usage:**
-s <slot>,virtio-i2c,<bus>[:<slave_addr>[@<node>]][:<slave_addr>[@<node>]][,<bus>[:<slave_addr>[@<node>]][:<slave_addr>][@<node>]]
-s <slot>,virtio-i2c,<bus>[:<secondary_addr>[@<node>]][:<secondary_addr>[@<node>]][,<bus>[:<secondary_addr>[@<node>]][:<secondary_addr>][@<node>]]
bus:
The bus number for the native I2C adapter; ``2`` means ``/dev/i2c-2``.
slave_addr:
The address for the native slave devices such as ``1C``, ``2F`` ...
secondary_addr:
The address for the native secondary devices such as ``1C``, ``2F`` ...
@:
The prefix for the acpi node.
@ -68,7 +68,7 @@ notifies the frontend. The msg process flow is shown in
-s 19,virtio-i2c,0:70@cam1:2F,4:1C
This adds slave devices 0x70 and 0x2F under the native adapter
This adds secondary devices 0x70 and 0x2F under the native adapter
/dev/i2c-0, and 0x1C under /dev/i2c-6 to the virtio-i2c adapter. Since
0x70 includes '@cam1', acpi info is also added to it. Since 0x2F and
0x1C have '@<node>', no acpi info is added to them.
@ -93,7 +93,7 @@ a virtual I2C adapter will appear in the guest OS:
i2c-0 i2c i915 gmbus dpb I2C adapter
i2c-5 i2c DPDDC-C I2C adapter
You can find the slave device 0x1C under the virtio I2C adapter i2c-6:
You can find the secondary device 0x1C under the virtio I2C adapter i2c-6:
.. code-block:: none

2
doc/developer-guides/modularity.rst
View File

@ -13,7 +13,7 @@ include:
* **Understandability** A modular design is easier to understand due to
encapsulation.
* **Testability** Modules can be integrated and tested in the reverse order of
dependencies among them. White-box integration tests help improve the coverage
dependencies among them. Modular integration tests help improve the coverage
of tests and identify corner cases that are hard to trigger when testing the
hypervisor as a whole.
* **Configurability** Modular design makes it easy to configure certain

5
doc/tutorials/acrn_on_qemu.rst
View File

@ -112,7 +112,8 @@ This concludes setting up of Service VM and preparing it to boot ACRN hypervisor
Install ACRN Hypervisor
***********************
1. Clone ACRN repo with ``tag: acrn-2020w19.5-140000p`` or latest master. Below steps show our tested version,
1. Clone ACRN repo with ``tag: acrn-2020w19.5-140000p`` or the latest
(main) branch. Below steps show our tested version,
.. code-block:: none
@ -244,7 +245,7 @@ Bring-up User VM (L2 Guest)
3. Install latest `IASL tool <https://acpica.org/downloads>`_ and copy the binary to ``/usr/sbin/iasl``.
For this setup, used IASL 20200326 version but anything after 20190215 should be good.
4. Clone latest stable version or master and build ACRN User VM Kernel.
4. Clone latest stable version or main branch and build ACRN User VM Kernel.
.. code-block:: none

2
doc/tutorials/docbuild.rst
View File

@ -280,7 +280,7 @@ folder. Note that there's no direct selection to go to a newer version
from an older one, without going to ``latest`` first.
By default, doc build and publishing assumes we're generating
documentation for the master branch and publishing to the ``/latest/``
documentation for the main branch and publishing to the ``/latest/``
area on https://projectacrn.github.io. When we're generating the
documentation for a tagged version (e.g., 0.2), check out that version
of the repo, and add some extra flags to the make commands:

2
doc/tutorials/using_celadon_as_uos.rst
View File

@ -36,7 +36,7 @@ Build Celadon from source
<https://01.org/projectceladon/documentation/getting-started/build-source>`__ guide
to set up the Celadon project source code.
.. note:: The master branch is based on the Google Android 10
.. note:: The main branch is based on the Google Android 10
pre-Production Early Release. Use the following command to specify a
stable Celadon branch based on the Google Android 9 source code in order
to apply those patches in the :ref:`ACRN patch list`::