Commit bb394280 authored by Richard Neill's avatar Richard Neill
Browse files

doc: Fix various typos



In addition to regular typos, update the spellings used for various references:

  * bitbake -> BitBake
  * kubernetes -> Kubernetes
  * licence -> license

Issue-Id: SCM-4397
Signed-off-by: Richard Neill's avatarRichard Neill <richard.neill@arm.com>
Change-Id: I536bb3aab6ec49a1342caa47acabc09e695af14e
parent 40555710
......@@ -158,7 +158,7 @@ Resolved and Known Issues
Resolved issues from v0.2.3:
* ewaol-distro: Fix bitbake fetch for ostree recipe from meta-oe
* ewaol-distro: Fix BitBake fetch for ostree recipe from meta-oe
******
v0.2.3
......@@ -187,7 +187,7 @@ Resolved and Known Issues
Resolved issues from v0.2.2:
* qa-checks: Install pip for Python 3.6
* ewaol-distro: Fix bitbake fetch for runc-opencontainers recipe from
* ewaol-distro: Fix BitBake fetch for runc-opencontainers recipe from
meta-virtualization
******
......@@ -249,7 +249,7 @@ Resolved issues from v0.2:
* qa-checks: Consider latest git commit for matching file's copyright year
* qa-checks: Fix getting the last modification date of external works
* qa-checks: Disable SC2086 shellcheck for k3s-killall.sh from K3s package
* ewaol-distro: Fix bitbake fetch for go-fsnotify recipe from
* ewaol-distro: Fix BitBake fetch for go-fsnotify recipe from
meta-virtualization
****
......@@ -325,7 +325,7 @@ Tools:
configurations from yaml files. This tool is still in experimental stage
and will be replacing kas-ci-build.py in the future
* Added '-j' and '--out-dir' parameters to kas-ci-build.py set the maximum
number of cpu threads available for bitbake and allow user to change build
number of CPU threads available for BitBake and allow user to change build
directory
* Moved project specific configurations for QA checks to meta-ewaol-config
* Various improvements in QA checks for spelling, commit message and license
......@@ -362,7 +362,7 @@ Changed
Documentation:
* Added manual bitbake build preparation documentation
* Added manual BitBake build preparation documentation
* Added QA checks documentation
* Added meta-ewaol public repository URL
* CI Build Tool documentation fixes
......
......@@ -25,7 +25,7 @@ The diagram above gives an overview of the Yocto branch and release process:
* The project has a major release roughly every 6 months where a stable release
branch is created.
* Each major release has a `codename` which is also used to name the stable
release branch (e.g. hardknott).
release branch (e.g. kirkstone).
* Once a stable branch is created and released, it only receives bug fixes with
minor (point) releases on an unscheduled basis.
* The goal is for users and 3rd parties layers to use these codenamed branches
......
......@@ -157,7 +157,7 @@ documentation.
License and Copyright Header
=============================
Contributed files must contain a valid licence and copyright header, following
Contributed files must contain a valid license and copyright header, following
one of the two following formats, based on the source of the contribution:
1. Original works contributed to the project:
......@@ -183,7 +183,7 @@ one of the two following formats, based on the source of the contribution:
Please follow the contribution guideline relating to licensing in order to
select the appropriate SPDX License Identifier for the contributed files.
The licence and copyright header QA check expects the header lines to be
The license and copyright header QA check expects the header lines to be
commented. The current implementation therefore expects each line to begin with
one of the following set of characters: ``#``, ``//``, ``*``, ``;``. Please
refer to the current files within the repository for further guidance on how to
......
......@@ -281,7 +281,7 @@ layer dependencies in :ref:`Yocto Layers <manual/yocto_layers:Yocto Layers>`.
Repository License
******************
The repository's standard licence is the MIT license (more details in
The repository's standard license is the MIT license (more details in
:ref:`license_link:License`), under which most of the repository's content is
provided. Exceptions to this standard license relate to files that represent
modifications to externally licensed works (for example, patch files). These
......
......@@ -25,7 +25,7 @@ An EWAOL baremetal distribution image (``ewaol-baremetal-image``) is enabled if
following image features by default:
* Container engine and runtime with Docker and runc-opencontainers
* Container workload orchestration with the K3s kubernetes distribution
* Container workload orchestration with the K3s Kubernetes distribution
On a baremetal distribution image system boot, a K3s Systemd service
(``k3s.service``) provides a container orchestration environment consisting of a
......@@ -50,7 +50,7 @@ image includes the following image features by default:
* Hardware virtualization support with the Xen type-1 hypervisor
* Container engine and runtime with Docker and runc-opencontainers
* Container workload orchestration with the K3s kubernetes distribution
* Container workload orchestration with the K3s Kubernetes distribution
On an EWAOL virtualization distribution image, the software stack includes the
Xen type-1 hypervisor and provides a Control VM (Dom0) and a single bundled
......
......@@ -8,8 +8,8 @@ Build System
############
An EWAOL build can be configured by setting the target platform via the
``MACHINE`` Bitbake variable, the desired distribution image features via the
``DISTRO_FEATURES`` Bitbake variable, and customizing those features via
``MACHINE`` BitBake variable, the desired distribution image features via the
``DISTRO_FEATURES`` BitBake variable, and customizing those features via
feature-specific modifiable variables.
This page first overviews EWAOL's support for the kas build tool. Each
......@@ -33,7 +33,7 @@ configuration files can extend other kas configuration files, thereby enabling
specialized configurations that inherit common configurations.
The ``meta-ewaol-config/kas`` directory contains kas configuration files that
support building images via kas for the EWAOL project. and fall into three
support building images via kas for the EWAOL project, and fall into three
ordered categories:
* **Architecture Configs**
......@@ -65,7 +65,7 @@ Target Platforms
****************
There is currently one supported target platform (corresponding to the
``MACHINE`` Bitbake variable) with an associated kas configuration file, as
``MACHINE`` BitBake variable) with an associated kas configuration file, as
follows.
N1SDP
......@@ -87,7 +87,7 @@ Distribution Image Features
***************************
For a particular target platform, the available EWAOL distribution image
features (corresponding to the contents of the ``DISTRO_FEATURES`` Bitbake
features (corresponding to the contents of the ``DISTRO_FEATURES`` BitBake
variable) are detailed in this section, along with any associated kas
configuration files, and any associated customization options relevant for that
feature.
......@@ -155,7 +155,7 @@ Virtualization Architecture
* Enables Xen specific configs required by kernel.
* Includes all necessary packages and adjustments to the Control VM's root
filesystem to support management of Xen Guest VMs.
* Uses Bitbake |Multiple Configuration Build|_.
* Uses BitBake |Multiple Configuration Build|_.
* Includes a single Guest VM based on the ``generic-arm64`` ``MACHINE``,
by default.
* Is incompatible with the ``ewaol-baremetal`` distribution image feature.
......@@ -196,7 +196,7 @@ The variables may be set either within an included kas configuration file
(see ``meta-ewaol-config/kas/virtualization.yml`` for example usage), the
environment, or manually via, for example, ``local.conf``. The
``EWAOL_*_ROOTFS_EXTRA_SPACE`` variables apply their values to the relevant
``IMAGE_ROOTFS_EXTRA_SPACE`` bitbake variable.
``IMAGE_ROOTFS_EXTRA_SPACE`` BitBake variable.
Adding Extra EWAOL Guest VM Instances
"""""""""""""""""""""""""""""""""""""
......@@ -206,14 +206,14 @@ distribution image, each one based on the same kernel and image recipe. The
number of Guest VM instances built for and included on the virtualization
distribution image can be set via the ``EWAOL_GUEST_VM_INSTANCES`` variable.
Guest VM instances can be independently configured via Bitbake variables which
Guest VM instances can be independently configured via BitBake variables which
reference the Guest VM's integer instance index, from 1 to the value of
``EWAOL_GUEST_VM_INSTANCES``, inclusive. For example, variables with a prefix
``EWAOL_GUEST_VM1_`` apply to the first Guest VM, variables with a prefix
``EWAOL_GUEST_VM2_`` apply to the second Guest VM, and so on. All Guest VM
instances use the same default configuration, apart from the hostname, which is
generated for each Guest VM by appending the instance index to the
``EWAOL_GUEST_VM_HOSTNAME`` Bitbake variable. By default, the first Guest VM
``EWAOL_GUEST_VM_HOSTNAME`` BitBake variable. By default, the first Guest VM
will have a hostname ``ewaol-guest-vm1``, the second will have a hostname
``ewaol-guest-vm2``, and so on. An example of configuring a second Guest VM
instance using the kas tool is given in
......@@ -329,7 +329,7 @@ Software Development Kit (SDK)
This EWAOL distribution image feature:
* Adds the EWAOL Software Development Kit (SDK) which includes packages
and image features to support on-target software development activites.
and image features to support on-target software development activities.
* Enables two additional SDK build targets, ``ewaol-baremetal-sdk-image``
and ``ewaol-virtualization-sdk-image``, each only compatible with the
corresponding architecture's distribution image feature.
......@@ -376,9 +376,9 @@ Adding Extra Rootfs Space
-------------------------
The size of the root filesystem can be extended via the
``EWAOL_ROOTFS_EXTRA_SPACE`` Bitbake variable, which defaults to ``2000000``
``EWAOL_ROOTFS_EXTRA_SPACE`` BitBake variable, which defaults to ``2000000``
Kilobytes. The value of this variable is appended to the
``IMAGE_ROOTFS_EXTRA_SPACE`` Bitbake variable. For an EWAOL virtualization
``IMAGE_ROOTFS_EXTRA_SPACE`` BitBake variable. For an EWAOL virtualization
distribution image, the root filesystems of both the Control VM and the Guest
VM(s) are extended via this variable, in addition to any other parameters which
affect those filesystems as described in
......@@ -393,7 +393,7 @@ sstate-cache reused between different image types and target platforms. This
optimization can be disabled by setting ``EWAOL_GENERIC_ARM64_FILESYSTEM`` to
``"0"``. The tune used when ``EWAOL_GENERIC_ARM64_FILESYSTEM`` is enabled can
be changed by setting ``EWAOL_GENERIC_ARM64_DEFAULTTUNE``, which configures the
``DEFAULTTUNE`` Bitbake variable for the ``aarch64`` based target platforms
``DEFAULTTUNE`` BitBake variable for the ``aarch64`` based target platforms
builds. See |DEFAULTTUNE|_ for more information.
In summary, the relevant variables and their default values are:
......@@ -403,7 +403,7 @@ In summary, the relevant variables and their default values are:
EWAOL_GENERIC_ARM64_FILESYSTEM: "1" # Enable generic file system (1 or 0).
EWAOL_GENERIC_ARM64_DEFAULTTUNE: "armv8a-crc" # Value of DEFAULTTUNE if generic file system enabled.
Their values can be set by passing them as enviromental variables. For example,
Their values can be set by passing them as environmental variables. For example,
the optimization can be disabled using:
.. code-block:: console
......@@ -411,11 +411,11 @@ the optimization can be disabled using:
EWAOL_GENERIC_ARM64_FILESYSTEM="0" kas build meta-ewaol-config/kas/baremetal.yml:meta-ewaol-config/kas/n1sdp.yml
**************************
Manual Bitbake Build Setup
Manual BitBake Build Setup
**************************
In order to build an EWAOL distribution image without the kas build tool
directly via bitbake, it is necessary to prepare a bitbake project as follows:
directly via BitBake, it is necessary to prepare a BitBake project as follows:
* Configure :ref:`dependent Yocto layers <manual_yocto_layers_layer_dependency_overview>`
in ``bblayers.conf``.
......@@ -423,7 +423,7 @@ directly via bitbake, it is necessary to prepare a bitbake project as follows:
* Configure the image ``DISTRO_FEATURES``, including the EWAOL Architecture
(``ewaol-baremetal`` or ``ewaol-virtualization``), in ``local.conf``.
Assuming correct environment configuration, the Bitbake build can then be run
Assuming correct environment configuration, the BitBake build can then be run
for the desired image target corresponding to one of the following:
* ``ewaol-baremetal-image``
......@@ -434,4 +434,4 @@ for the desired image target corresponding to one of the following:
As the kas build configuration files within the ``meta-ewaol-config/kas/``
directory define the recommended build settings for each feature. Any additional
functionalities may therefore be enabled by reading these configuration files
and manually inserting their changes into the Bitbake build environment.
and manually inserting their changes into the BitBake build environment.
......@@ -17,7 +17,7 @@ specific EWAOL functionalities.
A list of required kernel configs is used as a reference, and compared against
the list of available configs in the kernel build. All reference configs need to
be present either as module (``=m``) or built-in (``=y``). A Bitbake warning
be present either as module (``=m``) or built-in (``=y``). A BitBake warning
message is produced if the kernel is not configured as expected.
The following kernel configuration checks are performed:
......@@ -201,7 +201,7 @@ on it, thereby reporting any test failures of the Guest VM as part of the
Control VM's test suite execution.
The test suite is built and installed in the image according to the following
bitbake recipe:
BitBake recipe:
``meta-ewaol-tests/recipes-tests/runtime-integration-tests/container-engine-integration-tests.bb``.
Currently the test suite contains three top-level integration tests, which run
......@@ -293,7 +293,7 @@ for execution via ``ptest-runner`` or as a standalone BATS suite, as described
in `Running the Tests`_.
The test suite is built and installed in the image according to the following
bitbake recipe within
BitBake recipe within
``meta-ewaol-tests/recipes-tests/runtime-integration-tests/k3s-integration-tests.bb``.
Currently the test suite contains a single top-level integration test which
......@@ -415,7 +415,7 @@ for execution via ``ptest-runner`` or as a standalone BATS suite, as described
in `Running the Tests`_.
The test suite is built and installed in the image according to the following
bitbake recipe within
BitBake recipe within
``meta-ewaol-tests/recipes-tests/runtime-integration-tests/user-accounts-integration-tests.bb``.
The test suite validates that the user accounts described in
......@@ -533,7 +533,7 @@ for execution via ``ptest-runner`` or as a standalone BATS suite, as described
in `Running the Tests`_.
The test suite is built and installed in the image according to the following
bitbake recipe within
BitBake recipe within
``meta-ewaol-tests/recipes-tests/runtime-integration-tests/virtualization-integration-tests.bb``.
The test suite is only available for images that target the virtualization
......
......@@ -602,7 +602,7 @@ running successfully, depending on the target architecture:
.. code-block:: console
systemctl status --no-pager --lines=0 docker.service k3s.service xendomains.services
systemctl status --no-pager --lines=0 docker.service k3s.service xendomains.service
And ensuring the command output lists them as active and running.
......
1.1.0+git0+b9460f26b4
1.0.0+rc93+git0+249bca0a13
3.2.1+git0+ab4d0cf908
4.16+stable0+f265444922
1.1.0+git0+b9460f26b4
20.10.12+ce+git906f57f
3.2.1+git0+ab4d0cf908
3rd
4.16+stable0+f265444922
aarch64
aem
appends
......@@ -44,12 +44,12 @@ customization
customizations
datetime
dbg
devicetree
deprecated
devicetree
diego.sueiro
distro_features
do_fetch
docker's
do_fetch
dom0
domu
efi
......@@ -114,8 +114,8 @@ index.html
initializes
introduction_use_cases_overview
k3s
k3s-integration-tests.bb
k3s_git.bb
k3s-integration-tests.bb
k3s_kernelcfg_check.bbclass
k3s-killall.sh
k3s.service
......@@ -124,6 +124,7 @@ k3s_test_guest_vm_name
k3s_test_log_dir
kb
kernel_features
kirkstone
kubectl
kubernetes
kube-system
......@@ -136,9 +137,9 @@ localhost
loopback
lts
m
maxdepth
manual_build_system_target_platforms
manual_yocto_layers_layer_dependency_overview
maxdepth
mb
meta-arm-bsp
meta-ewaol
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment