diff --git a/doc/developer-guides/contribute_guidelines.rst b/doc/developer-guides/contribute_guidelines.rst index beee1d8c8..d44985cdc 100644 --- a/doc/developer-guides/contribute_guidelines.rst +++ b/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 - 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 diff --git a/doc/developer-guides/doc_guidelines.rst b/doc/developer-guides/doc_guidelines.rst index cec7b8253..b7f099604 100644 --- a/doc/developer-guides/doc_guidelines.rst +++ b/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 diff --git a/doc/developer-guides/hld/hv-ioc-virt.rst b/doc/developer-guides/hld/hv-ioc-virt.rst index fe585d409..fbe2c2737 100644 --- a/doc/developer-guides/hld/hv-ioc-virt.rst +++ b/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 - 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 -------- diff --git a/doc/developer-guides/hld/ivshmem-hld.rst b/doc/developer-guides/hld/ivshmem-hld.rst index 43b1b587b..ffea830e7 100644 --- a/doc/developer-guides/hld/ivshmem-hld.rst +++ b/doc/developer-guides/hld/ivshmem-hld.rst @@ -236,10 +236,10 @@ architecture and threat model for your application. - References: `NIST Crypto Standards and Guidelines `_, `OpenSSL `_ -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 `_, `fapolicyd `_ diff --git a/doc/developer-guides/hld/virtio-i2c.rst b/doc/developer-guides/hld/virtio-i2c.rst index 763de46d8..73036e54d 100644 --- a/doc/developer-guides/hld/virtio-i2c.rst +++ b/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 -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 ,virtio-i2c,[:[@]][:[@]][,[:[@]][:][@]] +-s ,virtio-i2c,[:[@]][:[@]][,[:[@]][:][@]] 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 '@', 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 diff --git a/doc/developer-guides/modularity.rst b/doc/developer-guides/modularity.rst index ecf838897..dbb131ddd 100644 --- a/doc/developer-guides/modularity.rst +++ b/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 diff --git a/doc/tutorials/acrn_on_qemu.rst b/doc/tutorials/acrn_on_qemu.rst index 5c9a92c62..1944188e4 100644 --- a/doc/tutorials/acrn_on_qemu.rst +++ b/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 `_ 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 diff --git a/doc/tutorials/docbuild.rst b/doc/tutorials/docbuild.rst index 417b89ec8..a381774fb 100644 --- a/doc/tutorials/docbuild.rst +++ b/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: diff --git a/doc/tutorials/using_celadon_as_uos.rst b/doc/tutorials/using_celadon_as_uos.rst index ce4332610..15b0d4960 100644 --- a/doc/tutorials/using_celadon_as_uos.rst +++ b/doc/tutorials/using_celadon_as_uos.rst @@ -36,7 +36,7 @@ Build Celadon from 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`::