[meta-freescale] [Documentation][PATCH] UG: some grammar edits
Daiane Angolini
daiane.list at gmail.com
Tue Nov 11 03:27:03 PST 2014
On Mon, Nov 10, 2014 at 3:31 PM, Bob Cochran <yocto at mindchasers.com> wrote:
> Signed-off-by: Bob Cochran <yocto at mindchasers.com>
> ---
I merged the patch, and I excluded some extra whitespaces as well.
Daiane
> user-guide/source/devtasks.rst | 62 ++++++++++++++++++++--------------------
> user-guide/source/folders.rst | 12 ++++----
> user-guide/source/index.rst | 4 +--
> user-guide/source/machines.rst | 2 +-
> user-guide/source/metadata.rst | 37 ++++++++++++------------
> user-guide/source/nsteps.rst | 6 ++--
> user-guide/source/weston.rst | 4 +--
> 7 files changed, 63 insertions(+), 64 deletions(-)
>
> diff --git a/user-guide/source/devtasks.rst b/user-guide/source/devtasks.rst
> index 1080d3e..b9f75d3 100644
> --- a/user-guide/source/devtasks.rst
> +++ b/user-guide/source/devtasks.rst
> @@ -6,8 +6,8 @@ Common Development Tasks
> Creating a new layer
> ---------------------
>
> -It is suggested to create a layer when creating or modifying any metadata file (recipe,
> -configuration file or class). The main reason **modularity**. In the other hand,
> +Use a custom layer when creating or modifying any metadata file (recipe,
> +configuration file, or class). The main reason is **modularity**. On the other hand,
> make sure your new metadata has not already be implemented (layer, recipe or machine), so
> before proceeding check the main `Layer Index`_.
>
> @@ -18,12 +18,12 @@ before proceeding check the main `Layer Index`_.
> fsl-community-bsp $ . setup-environment build
>
> 2. Move to the place you want to create your layer and choose a name
> - (e.g. ``fsl-custom``)
> + (e.g. ``fsl-custom``)::
>
> sources $ yocto-layer create fsl-custom
> # Answer the questions. Make sure the priority is set correctly (higher numbers,
> # higher priorities). Set the priority equal to the lowest already present, except
> - # when you have introduce a new recipe with the same name as other and want to shadow
> + # when you create a new recipe with the same name as another recipe and want to shadow
> # the original one.
>
> 3. Add any metadata content. Suggestion: Version the layer with GIT
> @@ -35,8 +35,8 @@ before proceeding check the main `Layer Index`_.
>
> build $ bitbake-layers show-layers
>
> -6. You can then include any new image/machine define on your layer. In case
> - you create a recipe and you want to include it on your next build, add it into your
> +6. You can now include any new image/machine definitions in your layer. If you
> + created a new recipe and want to include it on your next build, add it to your
> ``build/conf/local.conf`` file through the ``CORE_IMAGE_EXTRA_INSTALL`` variable.
>
> .. _patching-kernel:
> @@ -44,28 +44,28 @@ before proceeding check the main `Layer Index`_.
> Patching the Linux Kernel
> -------------------------
>
> -The Linux Kernel is just another recipe for Yocto, so learning to patch it, you learn
> -to patch any other package. In the other hand, Yocto **should not** be used for
> -package development, but in those rare cases follow the below steps. It is assumed
> -that you have already build the package you want to patch.
> +The Linux Kernel is just another Yocto recipe, so by learning to patch it, you learn
> +to patch any other package. On the other hand, Yocto **should not** be used for
> +package development. However, if the need does arise, follow the steps listed below. It is assumed
> +that you have already built the package you want to patch.
>
> * Create the patch or patches. In this example we are patching the
> Linux kernel for `wandboard-dual machine <http://www.wandboard.org/>`_;
> - in other words, the value of ``MACHINE`` on ``build/conf/local.conf`` is
> + in other words, the value of ``MACHINE`` in ``build/conf/local.conf`` is
> ``MACHINE ??= 'wandboard-dual'``
>
> -* In case you already have the patches, make sure these can be nicely applied with
> - the commands ``git apply --check <PATCH_NAME>``, and jump this step::
> +* If you already have the patches available, make sure they can be applied cleanly with
> + the commands ``git apply --check <PATCH_NAME>``. To create new or additional patches::
>
> build $ cd tmp/work/wandboard_dual-poky-linux-gnueabi/linux-wandboard/3.0.35-r0/git
> - build $ # Edit any files you want to change
> - build $ git add <modified file 1> <modified file 2> ..
> - build $ git commit -s -m '<your commit's title>' # Create the commit
> - build $ git format-patch -1 # Create the patch
> + # Edit any files you want to change
> + $ git add <modified file 1> <modified file 2> ..
> + $ git commit -s -m '<your commit's title>' # Create the commit
> + $ git format-patch -1 # Create the patch
>
> * Create a new layer (see :ref:`new-layer`)
>
> -* On the new layer (e.g ``meta-fsl-custom``) , create the corresponding sub-directories
> +* In the new layer (e.g ``meta-fsl-custom``), create the corresponding sub-directories
> and the ```.bbfile``::
>
> sources $ mkdir -p \
> @@ -103,7 +103,7 @@ that you have already build the package you want to patch.
> Building the Kernel Manually
> ----------------------------
>
> -* Prepare the Yocto/Bitbake environment::
> +* Prepare the Yocto/BitBake environment::
>
> fsl-community-bsp $ . setup-environment build
>
> @@ -122,7 +122,7 @@ Building the Kernel Manually
>
> build $ source /opt/poky/<version>/environment-setup-armv7a-vfp-neon-poky-linux-gnueabi
>
> -* Get the Linux Kernel's source code::
> +* Get the Linux Kernel source code::
>
> $ git clone git://git.freescale.com/imx/linux-2.6-imx.git linux-imx
> $ cd linux-imx
> @@ -139,7 +139,7 @@ Building the Kernel Manually
> linux-imx $ export CROSS_COMPILE=arm-poky-linux-gnueabi-
> linux-imx $ unset LDFLAGS
>
> -* Choose configuration and compile::
> +* Choose a configuration and compile::
>
> linux-imx $ make imx6_defconfig
> linux-imx $ make uImage
> @@ -148,7 +148,7 @@ Building the Kernel Manually
>
> linux-imx $ sudo cp arch/arm/boot/uImage /media/Boot
>
> -* If case you want your changes to be reflected on your Yocto Framework,
> +* If you want your changes to be reflected in your Yocto Framework,
> create the patches following the subsection :ref:`patching-kernel`
>
> .. _contributing:
> @@ -157,9 +157,9 @@ Contributing
> ------------
>
> The Yocto Project is open-source, so anyone can contribute. No matter
> -what your contribution is (bug fixing or new metadata), contributions are sent
> -through patches to a community list. Many eyes will look into your patch and
> -at some point it is either rejected or accepted.
> +what your contributions are (bug fixes or new metadata), they should be sent
> +as patches to the community list. Many eyes will look at your patch, and
> +at some point it will either be accepted or rejected.
>
> Follow these steps to contribute:
>
> @@ -168,7 +168,7 @@ Follow these steps to contribute:
> $ git config --global user.name "Your Name Here"
> $ git config --global user.email "your_email at example.com"
>
> -* Subscribed to the `meta-freescale Mailing List`_
> +* Subscribe to the `meta-freescale Mailing List`_
>
> * Always base your work on **master** branches::
>
> @@ -193,17 +193,17 @@ Where ``<branch name>`` is any name you want to give to your local branch (e.g.
> sources/meta-fsl-arm $ git add <file 1> <file 2>
> sources/meta-fsl-arm $ git commit
>
> -On the commit's log, the title must start with the filename change or introduced,
> -then a brief description of the patch's goal, following with a long description.
> +In the commit's log, the title must start with the filename that was changed or created,
> +followed by a brief description of the patch's goal. On subsequent lines, provide a thorough description of the changes.
> Make sure you follow the standards (type ` git log --pretty=oneline` to see previous commits)
>
> * Create a patch::
>
> sources/meta-fsl-arm $ git format-patch -s --subject-prefix='<meta-fsl-arm][PATCH' -1
>
> -Where the last parameter (``-1``) indicate to patch last commit.
> +Where the last parameter (``-1``) indicate to patch the last commit.
> In case you want to create patches for older commits, just indicate the correct index.
> -If your patch is done in other folder, just make sure you change the `--subject-prefix` value.
> +If your patch is done in another folder, just make sure you change the `--subject-prefix` value.
>
> * Send your patch or patches with::
>
> @@ -212,7 +212,7 @@ If your patch is done in other folder, just make sure you change the `--subject-
> where ``<patch>`` is the file created by ``git format-patch``.
>
> * Keep track of patch responses on the mailing list. In case you need to rework your patch,
> - repeat the steps but this time the patch's subject changes to
> + repeat the steps but this time change the patch's subject to
> ``--subject-prefix='<meta-fsl-*][PATCH v2'``
>
> * Once your patch has been approved, you can delete your working branches::
> diff --git a/user-guide/source/folders.rst b/user-guide/source/folders.rst
> index 69c48fd..29afaf1 100644
> --- a/user-guide/source/folders.rst
> +++ b/user-guide/source/folders.rst
> @@ -1,16 +1,16 @@
> Folders
> =======
>
> -* **fsl-community-bsp**: Base (``BASE``) directory where all Yocto data resides (recipes, source code, built packages, images, etc)
> +* **fsl-community-bsp**: Base (``BASE``) directory where all Yocto data reside (recipes, source code, built packages, images, etc.)
>
> -* **BASE/sources**: Source (``SOURCE``) directory where metadata (layers) resides
> +* **BASE/sources**: Source directory where metadata (layers) reside
>
> -* **BASE/build**: Build (``BUILD``) directory where ``bitbake`` commands are executed
> +* **BASE/build**: Build directory where ``bitbake`` commands are executed
>
> -* **BASE/build/tmp**: Target (``TMP``) directory for all bitbake commands
> +* **BASE/build/tmp**: Target directory for all bitbake commands
>
> -* **BASE/build/tmp/work**: Working (``WORKING``) directory for recipes tasks
> +* **BASE/build/tmp/work**: Working directory that holds the task output and source from each recipe
>
> -* **BASE/build/tmp/deploy**: Deploy (``DEPLOY``) directory where bitbake's output data is found
> +* **BASE/build/tmp/deploy**: Deploy directory where bitbake's deployable output files are copied
>
> * **BASE/build/tmp/deploy/images**: Complete and partial images are found under this folder
> diff --git a/user-guide/source/index.rst b/user-guide/source/index.rst
> index 414cd10..04f44f9 100644
> --- a/user-guide/source/index.rst
> +++ b/user-guide/source/index.rst
> @@ -3,8 +3,8 @@
> You can adapt this file completely to your liking, but it should at least
> contain the root `toctree` directive.
>
> -Welcome to Freescale Community BSP User Guide's documentation!
> -==============================================================
> +Welcome to the Freescale Community's BSP User Guide!
> +====================================================
>
> Contents:
>
> diff --git a/user-guide/source/machines.rst b/user-guide/source/machines.rst
> index 7a0b437..55311d2 100644
> --- a/user-guide/source/machines.rst
> +++ b/user-guide/source/machines.rst
> @@ -4,7 +4,7 @@ Machines
> ========
>
> The scope of this release includes both meta-fsl-arm and meta-fsl-arm-extra.
> -Please, see in next table the complete supported board list.
> +Please refer to the table below for the complete list of supported boards.
>
>
> .. include:: machine-list.inc
> diff --git a/user-guide/source/metadata.rst b/user-guide/source/metadata.rst
> index 9fa07fa..f31590e 100644
> --- a/user-guide/source/metadata.rst
> +++ b/user-guide/source/metadata.rst
> @@ -1,11 +1,10 @@
> Metadata
> ========
>
> -BitBake handles the parsing and execution of the data files. The data itself is of
> -various types:
> +BitBake handles the parsing and execution of the data files, which consist of various types:
>
> -* **Recipes**: Provides details about particular pieces of software.
> -* **Class Data**: Abstracts common build information (e.g. how to build a Linux kernel).
> +* **Recipes**: Provides details and build information about particular pieces of software
> +* **Classes**: Abstracts common build subroutines and information (e.g. how to build a Linux kernel)
> * **Configuration Data**: Defines machine-specific settings, policy decisions, and so forth.
> Configuration data acts as the glue to bind everything together.
>
> @@ -15,14 +14,14 @@ Layers
> * Metadata is organized into multiple ``layers``.
> * Layers allow you to isolate different types of customizations from each other.
> * DO NOT do your modifications in existing layers, instead create a layer and
> - create recipes (``.bb`` files) or modified existing ones (``.bbappend`` files)
> + create recipes (``.bb`` files) or modify existing ones (``.bbappend`` files)
>
>
> Configuration Data
> ------------------
>
> -* ``build/conf/local.conf``: Local User Configuration for your build environment
> -* ``build/conf/bblayers.conf``: Define layers, which are directory trees,
> +* ``build/conf/local.conf``: Local user configuration for your build environment
> +* ``build/conf/bblayers.conf``: Defines layers, which are directory trees,
> traversed by BitBake.
> * ``sources/meta-*/conf/layer.conf``: Layer configuration file
> * ``sources/meta-*/conf/machine/*.conf``: Machine configuration files
> @@ -60,8 +59,8 @@ By default, the ``setup-enviroment`` script creates a ``local.conf`` like this::
>
> Important variables:
>
> -* ``MACHINE``: Indicates the machine, ``imx6qsabresd`` is the default
> -* ``BB_NUMBER_THREADS`` and ``PARALLEL_MAKE``: Indicate the max number of threads when
> +* ``MACHINE``: Specifies the machine, ``imx6qsabresd`` is the default
> +* ``BB_NUMBER_THREADS`` and ``PARALLEL_MAKE``: Specifies the max number of threads when
> baking and compiling
> * ``DL_DIR``: Tarball repository. Several users can share the same folder, so data can
> be reused.
> @@ -71,7 +70,7 @@ Build's layer configuration file ``build/conf/bblayers.conf``
>
> * Also created by the ``setup-environment`` script
>
> -* In case you need to add a layer, append it to ``BBLAYERS``::
> +* In case you need to add a layer, add it to ``BBLAYERS``::
>
> LCONF_VERSION = "6"
>
> @@ -93,7 +92,7 @@ Build's layer configuration file ``build/conf/bblayers.conf``
> Layer configuration file ``meta-fsl-arm/conf/layer.conf``
> ---------------------------------------------------------
>
> -This is basically a template, what it changes is the layer's name::
> +This is basically a template that specifies the layer's name and structure::
>
> # We have a conf and classes directory, add to BBPATH
> BBPATH .= ":${LAYERDIR}"
> @@ -116,9 +115,9 @@ This is basically a template, what it changes is the layer's name::
>
> Important variables:
>
> -* ``BBFILES``: Indicates where to look for ``.bb*`` files
> -* ``BBFILE_PRIORITY_fsl-arm``: Indicates layer's priority
> -* ``MIRRORS``: Indicates where to get the source code
> +* ``BBFILES``: Specifies where BitBake looks for ``.bb*`` files
> +* ``BBFILE_PRIORITY_fsl-arm``: Specifies priority for recipes in the meta-fsl-arm layer
> +* ``MIRRORS``: Specifies additional paths where the build system can find source code
>
>
> Machine configuration file: ``meta-fsl-arm/conf/imx6qsabresd.conf``
> @@ -145,10 +144,10 @@ Machine configurations look like this::
>
> Important variables:
>
> -* ``IMAGE_FSTYPES``: Located on `imx-base.inc <http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/conf/machine/include/imx-base.inc>`_.
> - Defines the type of outputs for the Root Filesystem. Default is: ``"tar.bz2 ext3 sdcard"``
> -* ``UBOOT_ENTRYPOINT_*``: Located on `imx-base.inc <http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/conf/machine/include/imx-base.inc>`_.
> +* ``IMAGE_FSTYPES``: Located in `imx-base.inc <http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/conf/machine/include/imx-base.inc>`_.
> + Defines the type of outputs for the root filesystem. Default is: ``"tar.bz2 ext3 sdcard"``
> +* ``UBOOT_ENTRYPOINT_*``: Located in `imx-base.inc <http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/conf/machine/include/imx-base.inc>`_.
> Defines where the Kernel is loaded by U-boot
> -* ``SOC_FAMILY``: Defines machine's family. Only recipes with the same ``SOC_FAMILY`` (defined with the recipe's variable ``COMPATIBLE_MACHINE``)
> +* ``SOC_FAMILY``: Defines the machine's family. Only recipes with the same ``SOC_FAMILY`` (defined with the recipe's variable ``COMPATIBLE_MACHINE``)
> are taken into account when baking for a particular machine.
> -* ``UBOOT_MACHINE``: Define the u-boot configuration file
> +* ``UBOOT_MACHINE``: Defines the u-boot configuration file
> diff --git a/user-guide/source/nsteps.rst b/user-guide/source/nsteps.rst
> index c1dbabe..5a7c302 100644
> --- a/user-guide/source/nsteps.rst
> +++ b/user-guide/source/nsteps.rst
> @@ -1,7 +1,7 @@
> Build and boot in *N*-steps
> ===========================
>
> -1. Check `required host packages`_ packages for your Linux Distribution
> +1. Check `required host packages`_ for your Linux Distribution
>
> 2. Download the `repo`_ tool::
>
> @@ -16,7 +16,7 @@ Build and boot in *N*-steps
> $ cd fsl-community-bsp
> fsl-community-bsp $ repo init \
> -u https://github.com/Freescale/fsl-community-bsp-platform \
> - -b dora
> + -b dizzy
> fsl-community-bsp $ repo sync
>
> 4. Select your machine (:ref:`machines`) and prepare the environment for bitbake::
> @@ -45,7 +45,7 @@ Build and boot in *N*-steps
>
> 7. Place your SD Card in the correct board's slot and boot!
>
> -Found Errors? Subscribe and report it to `meta-freescale list`_
> +Found errors? Subscribe and report it to `meta-freescale list`_
>
> .. links
> .. _required host packages: https://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html#packages
> diff --git a/user-guide/source/weston.rst b/user-guide/source/weston.rst
> index 325bda7..562c4f7 100644
> --- a/user-guide/source/weston.rst
> +++ b/user-guide/source/weston.rst
> @@ -1,7 +1,7 @@
> Weston
> ======
>
> -In order to test Weston the reference implementation of a Wayland compositor use the image *core-image-weston*
> +In order to test Weston, the reference implementation of a Wayland compositor, use the image *core-image-weston*
>
> Add the following to conf/local.conf::
>
> @@ -17,7 +17,7 @@ Remember to use a clean build-dir when changing `DISTRO_FEATURES`
> Simple tests
> ------------
>
> -In order to access Weston examples via console::
> +In order to access Weston examples via a console::
>
> $ export XDG_RUNTIME_DIR=/var/run/user/root
> $ weston-simple-shm => basic wayland example
> --
> 1.7.9.5
>
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
More information about the meta-freescale
mailing list