doc: update inclusive language terms in docs

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>

doc/developer-guides/contribute_guidelines.rst

@@ -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
+   The ``--ignore-whitespace`` option stops ``git apply`` (called by
-   stops ``git apply`` (called by rebase) from changing
+   rebase) from changing any whitespace characters (such as spaces, tabs, and
-   any whitespace. If any merging issues are detected you can address them
+   newlines). If any merging issues are detected you can address them
    with::
 
      $ git rebase -i <offending-commit-id>

doc/developer-guides/doc_guidelines.rst

@@ -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
 

doc/developer-guides/hld/hv-ioc-virt.rst

@@ -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
+-  Every backend should maintain a passlist for different VMs. The
-   whitelist can be stored in the Service VM file system (Read only) in 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
+not defined in the passlist. For multi signal, IOC mediator generates a
-new multi signal, which contains the signals in the whitelist.
+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
 --------

doc/developer-guides/hld/ivshmem-hld.rst

@@ -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.
+   - 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 whitelisting rules and configuration files (refer to opensource or implement your custom solution).
+   - 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>`_
 
 

doc/developer-guides/hld/virtio-i2c.rst

@@ -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
+secondary devices under multiple native I2C adapters to one virtio I2C
-adapter. The address for the slave device is not changed. Virtio-i2c
+adapter. The address for the secondary device is not changed. Virtio-i2c
-also provides an interface to add an acpi node for slave devices so that
+also provides an interface to add an acpi node for secondary devices so that
-the slave device driver in the guest OS does not need to change.
+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:
+   secondary_addr:
-   The address for the native slave devices such as ``1C``, ``2F`` ...
+   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
 

doc/developer-guides/modularity.rst

@@ -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

doc/tutorials/acrn_on_qemu.rst

@@ -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
 

doc/tutorials/docbuild.rst

@@ -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:

doc/tutorials/using_celadon_as_uos.rst

@@ -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`::