manuals: simplify style

(From yocto-docs rev: 3332ee547cde0f2f8718f83d526b21339b0a8901)

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

documentation/README

@@ -32,7 +32,7 @@ these instances.
 Manual Organization
 ===================
 
-Folders exist for individual manuals as follows:
+Here the folders corresponding to individual manuals:
 
 * sdk-manual           - The Yocto Project Software Development Kit (SDK) Developer's Guide.
 * bsp-guide            - The Yocto Project Board Support Package (BSP) Developer's Guide

documentation/brief-yoctoprojectqs/index.rst

@@ -297,7 +297,7 @@ modular development and makes it easier to reuse the layer metadata.
 
 Follow these steps to add a hardware layer:
 
-#. **Find a Layer:** Lots of hardware layers exist. The Yocto Project
+#. **Find a Layer:** Many hardware layers are available. The Yocto Project
    :yocto_git:`Source Repositories <>` has many hardware layers.
    This example adds the
    `meta-altera <https://github.com/kraj/meta-altera>`__ hardware layer.
@@ -318,8 +318,8 @@ Follow these steps to add a hardware layer:
       Resolving deltas: 100% (13385/13385), done.
       Checking connectivity... done.
 
-   The hardware layer now exists
+   The hardware layer is now available
-   with other layers inside the Poky reference repository on your build
+   next to other layers inside the Poky reference repository on your build
    host as ``meta-altera`` and contains all the metadata needed to
    support hardware from Altera, which is owned by Intel.
 
@@ -431,8 +431,8 @@ information including the website, wiki pages, and user manuals:
    information.
 
 -  **Yocto Project Mailing Lists:** Related mailing lists provide a forum
-   for discussion, patch submission and announcements. Several mailing
+   for discussion, patch submission and announcements. There are several
-   lists exist and are grouped according to areas of concern. See the
+   mailing lists grouped by topic. See the
    :ref:`ref-manual/resources:mailing lists`
    section in the Yocto Project Reference Manual for a complete list of
    Yocto Project mailing lists.

documentation/bsp-guide/bsp.rst

@@ -267,7 +267,7 @@ maintain the distinction that the BSP layer, a build system, and tools
 are separate components that could be combined in certain end products.
 
 Before looking at the recommended form for the directory structure
-inside a BSP layer, you should be aware that some requirements do exist
+inside a BSP layer, you should be aware that there are some requirements
 in order for a BSP layer to be considered compliant with the Yocto
 Project. For that list of requirements, see the
 ":ref:`bsp-guide/bsp:released bsp requirements`" section.
@@ -763,8 +763,8 @@ workflow.
 
    .. note::
 
-      -  Four hardware reference BSPs exist that are part of the Yocto
+      -  There are four hardware reference BSPs in the Yocto
-         Project release and are located in the ``poky/meta-yocto-bsp``
+         Project release, located in the ``poky/meta-yocto-bsp``
          BSP layer:
 
          -  Texas Instruments Beaglebone (``beaglebone-yocto``)
@@ -773,8 +773,8 @@ workflow.
 
          -  Two general IA platforms (``genericx86`` and ``genericx86-64``)
 
-      -  Three core Intel BSPs exist as part of the Yocto Project
+      -  There are three core Intel BSPs in the Yocto Project
-         release in the ``meta-intel`` layer:
+         release, in the ``meta-intel`` layer:
 
          -  ``intel-core2-32``, which is a BSP optimized for the Core2
             family of CPUs as well as all CPUs prior to the Silvermont
@@ -832,10 +832,8 @@ workflow.
 Requirements and Recommendations for Released BSPs
 ==================================================
 
-Certain requirements exist for a released BSP to be considered compliant
+This section describes requirements and recommendations for a released
-with the Yocto Project. Additionally, recommendations also exist. This
+BSP to be considered compliant with the Yocto Project.
-section describes the requirements and recommendations for released
-BSPs.
 
 Released BSP Requirements
 -------------------------
@@ -864,7 +862,7 @@ Before looking at BSP requirements, you should consider the following:
 
 -  It is not required that specific packages or package modifications
    exist in the BSP layer, beyond the requirements for general
-   compliance with the Yocto Project. For example, no requirement exists
+   compliance with the Yocto Project. For example, there is no requirement
    dictating that a specific kernel or kernel version be used in a given
    BSP.
 
@@ -900,7 +898,7 @@ Yocto Project:
 -  *License File:* You must include a license file in the
    ``meta-bsp_root_name`` directory. This license covers the BSP
    Metadata as a whole. You must specify which license to use since no
-   default license exists when one is not specified. See the
+   default license exists. See the
    :yocto_git:`COPYING.MIT </meta-raspberrypi/tree/COPYING.MIT>`
    file for the Raspberry Pi BSP in the ``meta-raspberrypi`` BSP layer
    as an example.
@@ -1107,7 +1105,7 @@ system requirements.
    unsuitable functionality or quality, you can use an encumbered
    version.
 
-A couple different methods exist within the OpenEmbedded build system to
+There are two different methods within the OpenEmbedded build system to
 satisfy the licensing requirements for an encumbered BSP. The following
 list describes them in order of preference:
 
@@ -1186,11 +1184,11 @@ Use these steps to create a BSP layer:
 -  *Create a Machine Configuration File:* Create a
    ``conf/machine/bsp_root_name.conf`` file. See
    :yocto_git:`meta-yocto-bsp/conf/machine </poky/tree/meta-yocto-bsp/conf/machine>`
-   for sample ``bsp_root_name.conf`` files. Other samples such as
+   for sample ``bsp_root_name.conf`` files. There are other samples such as
    :yocto_git:`meta-ti </meta-ti/tree/conf/machine>`
    and
    :yocto_git:`meta-freescale </meta-freescale/tree/conf/machine>`
-   exist from other vendors that have more specific machine and tuning
+   from other vendors that have more specific machine and tuning
    examples.
 
 -  *Create a Kernel Recipe:* Create a kernel recipe in
@@ -1241,7 +1239,7 @@ As mentioned earlier in this section, the existence of a machine
 configuration file is what makes a layer a BSP layer as compared to a
 general or kernel layer.
 
-One or more machine configuration files exist in the
+There are one or more machine configuration files in the
 ``bsp_layer/conf/machine/`` directory of the layer::
 
    bsp_layer/conf/machine/machine1\.conf
@@ -1311,7 +1309,7 @@ Project Reference Manual.
 -  :term:`PREFERRED_PROVIDER_virtual/xserver <PREFERRED_PROVIDER>`:
    The recipe that provides "virtual/xserver" when more than one
    provider is found. In this case, the recipe that provides
-   "virtual/xserver" is "xserver-xorg", which exists in
+   "virtual/xserver" is "xserver-xorg", available in
    ``poky/meta/recipes-graphics/xorg-xserver``.
 
 -  :term:`XSERVER`: The packages that
@@ -1326,7 +1324,7 @@ Project Reference Manual.
 
    .. tip::
 
-      Many ``MACHINE*`` variables exist that help you configure a particular piece
+      There are many ``MACHINE*`` variables that help you configure a particular piece
       of hardware.
 
 -  :term:`EXTRA_IMAGEDEPENDS`:
@@ -1339,9 +1337,9 @@ Project Reference Manual.
 -  :term:`DEFAULTTUNE`: Machines
    use tunings to optimize machine, CPU, and application performance.
    These features, which are collectively known as "tuning features",
-   exist in the :term:`OpenEmbedded-Core (OE-Core)` layer (e.g.
+   are set in the :term:`OpenEmbedded-Core (OE-Core)` layer (e.g.
    ``poky/meta/conf/machine/include``). In this example, the default
-   tuning file is "cortexa8hf-neon".
+   tuning file is ``cortexa8hf-neon``.
 
    .. note::
 

documentation/toaster-manual/reference.rst

@@ -9,8 +9,8 @@ concepts and have some basic command reference material available. This
 final chapter provides conceptual information on layer sources,
 releases, and JSON configuration files. Also provided is a quick look at
 some useful ``manage.py`` commands that are Toaster-specific.
-Information on ``manage.py`` commands does exist across the Web and the
+Information on ``manage.py`` commands is available across the Web and
-information in this manual by no means attempts to provide a command
+this manual by no means attempts to provide a command
 comprehensive reference.
 
 Layer Source
@@ -508,7 +508,7 @@ Useful Commands
 ===============
 
 In addition to the web user interface and the scripts that start and
-stop Toaster, command-line commands exist through the ``manage.py``
+stop Toaster, command-line commands are available through the ``manage.py``
 management script. You can find general documentation on ``manage.py``
 at the
 `Django <https://docs.djangoproject.com/en/2.2/topics/settings/>`__