dev-manual: Review edits applied to selecting init manager section.

Applied comments based on Ross Burton's review of this new section.

(From yocto-docs rev: d4f5f7b712ea2944efffec9b675341143675efb0)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files changed, 133 insertions, 125 deletions

diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml
index 219ee68d40..e6696319ec 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -411,7 +411,7 @@
                 install -m 0644 ${S}/machconfig ${D}${sysconfdir}/formfactor/
         fi
      }          </literallayout>
-                In the main recipe, note the 
+                In the main recipe, note the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
                 variable, which tells the OpenEmbedded build system where to
                 find files during the build.
@@ -431,27 +431,27 @@
             </para>
 
             <para>
-                By default, the build system uses the 
+                By default, the build system uses the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
                 variable to locate files.
-                This append file extends the locations by setting the 
+                This append file extends the locations by setting the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
                 variable.
                 Setting this variable in the <filename>.bbappend</filename>
-                file is the most reliable and recommended method for adding 
-                directories to the search path used by the build system 
+                file is the most reliable and recommended method for adding
+                directories to the search path used by the build system
                 to find files.
             </para>
 
             <para>
-                The statement in this example extends the directories to include 
-                <filename>${THISDIR}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>, 
-                which resolves to a directory named 
-                <filename>formfactor</filename> in the same directory 
+                The statement in this example extends the directories to include
+                <filename>${THISDIR}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>,
+                which resolves to a directory named
+                <filename>formfactor</filename> in the same directory
                 in which the append file resides (i.e.
                 <filename>meta-intel/meta-crownbay/recipes-bsp/formfactor/formfactor</filename>.
-                This implies that you must have the supporting directory 
-                structure set up that will contain any files or patches you 
+                This implies that you must have the supporting directory
+                structure set up that will contain any files or patches you
                 will be including from the layer.
             </para>
 
@@ -660,7 +660,7 @@
                 script to accept the default value.
                 Once the script completes, the new layer
                 is created in the current working directory.
-                The script names the layer by prepending 
+                The script names the layer by prepending
                 <filename>meta-</filename> to the name you provide.
             </para>
 
@@ -1270,7 +1270,7 @@
 
             <para>
                 To add a post-installation script to a package, add a
-                <filename>pkg_postinst_PACKAGENAME()</filename> function to the 
+                <filename>pkg_postinst_PACKAGENAME()</filename> function to the
                 <filename>.bb</filename> file and use
                 <filename>PACKAGENAME</filename> as the name of the package you want to attach to the
                 <filename>postinst</filename> script.
@@ -1504,8 +1504,8 @@
                 By default, the <filename>PACKAGES</filename> variable contains
                 <filename>${PN}-staticdev</filename>, which includes all static library files.
                 <note>
-                    Some previously released versions of the Yocto Project 
-                    defined the static library files through 
+                    Some previously released versions of the Yocto Project
+                    defined the static library files through
                     <filename>${PN}-dev</filename>.
                 </note>
                 Following, is part of the BitBake configuration file.
@@ -1810,7 +1810,7 @@
             <para>
                 To use the <filename>menuconfig</filename> tool in the Yocto Project development
                 environment, you must build the tool using BitBake.
-                Thus, the environment must be set up using the 
+                Thus, the environment must be set up using the
                 <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
                 script found in the
                 <link linkend='build-directory'>Build Directory</link>.
@@ -2240,7 +2240,7 @@
                         The <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
                         and <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
                         statements enable the OpenEmbedded build system to find the patch file.
-                        For more information on using append files, see the 
+                        For more information on using append files, see the
                         "<link linkend='using-bbappend-files'>Using .bbappend Files</link>"
                         section.
                         </para></listitem>
@@ -2262,7 +2262,7 @@
                 <itemizedlist>
                     <listitem><para><emphasis>Build for the correct target architecture:</emphasis> Your
                         selected <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
-                        definition within the <filename>local.conf</filename> file in the 
+                        definition within the <filename>local.conf</filename> file in the
                         <link linkend='build-directory'>Build Directory</link>
                         specifies the target architecture used when building the Linux kernel.
                         By default, <filename>MACHINE</filename> is set to
@@ -2270,7 +2270,7 @@
                         <trademark class='registered'>Intel</trademark> Architecture
                         target machine suitable for the QEMU emulator.</para></listitem>
                     <listitem><para><emphasis>Identify your <filename>meta-mylayer</filename>
-                        layer:</emphasis> The 
+                        layer:</emphasis> The
                         <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink>
                         variable in the
                         <filename>bblayers.conf</filename> file found in the
@@ -2306,7 +2306,7 @@
                 <orderedlist>
                     <listitem><para><emphasis>Be sure your build environment is initialized</emphasis>:
                         Your environment should be set up since you previously sourced
-                        the 
+                        the
                         <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
                         script.
                         If it is not, source the script again from <filename>poky</filename>.
@@ -2322,7 +2322,7 @@
      $ bitbake -c cleansstate linux-yocto
                         </literallayout></para>
                         <para><note>Never remove any files by hand from the <filename>tmp/deploy</filename>
-                        directory inside the 
+                        directory inside the
                         <link linkend='build-directory'>Build Directory</link>.
                         Always use the various BitBake clean tasks to clear out previous
                         build artifacts.
@@ -2390,7 +2390,7 @@
                     configurations in a <filename>local.conf</filename>
                     configuration file makes it easier to reproduce the same
                     build configuration when using multiple build machines.
-                    See the 
+                    See the
                     "<link linkend='creating-a-general-layer-using-the-yocto-layer-script'>Creating a General Layer Using the yocto-layer Script</link>"
                     section for information on how to quickly set up a layer.
                     </para></listitem>
@@ -2416,7 +2416,7 @@
      <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_NAME'><filename>DISTRO_NAME</filename></ulink> [required]
      <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_VERSION'><filename>DISTRO_VERSION</filename></ulink> [required]
                     </literallayout>
-                    These following variables are optional and you typically 
+                    These following variables are optional and you typically
                     set them from the distribution configuration file:
                     <literallayout class='monospaced'>
      <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></ulink> [optional]
@@ -2427,7 +2427,7 @@
                     <tip>
                         If you want to base your distribution configuration file
                         on the very basic configuration from OE-Core, you
-                        can use 
+                        can use
                         <filename>conf/distro/defaultsetup.conf</filename> as
                         a reference and just include variables that differ
                         as compared to <filename>defaultsetup.conf</filename>.
@@ -2573,7 +2573,7 @@
                 <filename>poky-tiny</filename>.
                 <note>
                     To use <filename>poky-tiny</filename> in your build,
-                    set the 
+                    set the
                     <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO'><filename>DISTRO</filename></ulink>
                     variable in your
                     <filename>local.conf</filename> file to "poky-tiny"
@@ -3069,7 +3069,7 @@
 
                 <para>
                     The alternative to setting up a PR Service is to manually
-                    bump the 
+                    bump the
                     <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>
                     variable.
                 </para>
@@ -3102,8 +3102,8 @@
                 <para>
                     When upgrading the version of a package, assuming the
                     <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PV'>PV</ulink></filename>
-                    changes, the <filename>PR</filename> variable should be 
-                    reset to "r0" (or "$(INC_PR).0" if you are using 
+                    changes, the <filename>PR</filename> variable should be
+                    reset to "r0" (or "$(INC_PR).0" if you are using
                     <filename>INC_PR</filename>).
                 </para>
 
@@ -3163,7 +3163,7 @@
      $ bitbake world -f -c distro_check
                 </literallayout>
                 The results are stored in the <filename>build/tmp/log/distro_check-${DATETIME}.results</filename>
-                file found in the 
+                file found in the
                 <link linkend='source-directory'>Source Directory</link>.
             </para>
         </section>
@@ -3203,7 +3203,7 @@
                     The <filename>do_split_packages</filename> function
                     searches for a pattern of files or directories under a
                     specified path and creates a package for each one it finds
-                    by appending to the 
+                    by appending to the
                     <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>
                     variable and setting the appropriate values for
                     <filename>FILES_packagename</filename>,
@@ -3241,7 +3241,7 @@
                             Thus, if a file in <filename>${libdir}</filename>
                             called <filename>mod_alias.so</filename> is found,
                             a package called <filename>lighttpd-module-alias</filename>
-                            is created for it and the 
+                            is created for it and the
                             <ulink url='&YOCTO_DOCS_REF_URL;#var-DESCRIPTION'><filename>DESCRIPTION</filename></ulink>
                             is set to "Lighttpd module for alias".</para></listitem>
                     </itemizedlist>
@@ -3265,7 +3265,7 @@
                     <filename>do_split_packages</filename>, see the
                     <filename>connman.inc</filename> file in the
                     <filename>meta/recipes-connectivity/connman/</filename>
-                    directory of the <filename>poky</filename> 
+                    directory of the <filename>poky</filename>
                     <link linkend='yocto-project-repositories'>source repository</link>.
                     You can also find examples in
                     <filename>meta/classes/kernel.bbclass</filename>.
@@ -3535,33 +3535,33 @@
             <title>Testing Packages With ptest</title>
 
             <para>
-                A Package Test (ptest) runs tests against packages built 
+                A Package Test (ptest) runs tests against packages built
                 by the OpenEmbedded build system on the target machine.
-                A ptest contains at least two items: the actual test, and 
+                A ptest contains at least two items: the actual test, and
                 a shell script (<filename>run-ptest</filename>) that starts
                 the test.
-                The shell script that starts the test must not contain 
+                The shell script that starts the test must not contain
                 the actual test, the script only starts it.
                 On the other hand, the test can be anything from a simple
-                shell script that runs a binary and checks the output to 
+                shell script that runs a binary and checks the output to
                 an elaborate system of test binaries and data files.
             </para>
 
             <para>
-                The test generates output in the format used by 
+                The test generates output in the format used by
                 Automake:
                 <literallayout class='monospaced'>
      &lt;result&gt;: &lt;testname&gt;
                 </literallayout>
-                where the result can be <filename>PASS</filename>, 
+                where the result can be <filename>PASS</filename>,
                 <filename>FAIL</filename>, or <filename>SKIP</filename>,
                 and the testname can be any identifying string.
             </para>
 
             <note>
                 With this release of the Yocto Project, three recipes exist
-                that are "ptest-enabled": <filename>bash</filename>, 
-                <filename>glib-2.0</filename>, and 
+                that are "ptest-enabled": <filename>bash</filename>,
+                <filename>glib-2.0</filename>, and
                 <filename>dbus</filename>.
                 These three recipes are Autotool-enabled.
             </note>
@@ -3570,20 +3570,20 @@
                 <title>Adding ptest to Your Build</title>
 
                 <para>
-                    To add package testing to your build, add the 
+                    To add package testing to your build, add the
                     <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></ulink>
                     and <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGE_FEATURES'><filename>EXTRA_IMAGE_FEATURES</filename></ulink>
-                    variables to your <filename>local.conf</filename> file, 
-                    which is found in the 
+                    variables to your <filename>local.conf</filename> file,
+                    which is found in the
                     <link linkend='build-directory'>Build Directory</link>:
                     <literallayout class='monospaced'>
-     EXTRA_IMAGE_FEATURES += "ptest" 
+     EXTRA_IMAGE_FEATURES += "ptest"
      DISTRO_FEATURES_append = " ptest-pkgs"
                     </literallayout>
                     Once your build is complete, the ptest files are installed
                     into the <filename>/usr/lib/&lt;package&gt;/ptest</filename>
-                    directory within the image, where 
-                    <filename>&lt;package&gt;</filename> is the name of the 
+                    directory within the image, where
+                    <filename>&lt;package&gt;</filename> is the name of the
                     package.
                 </para>
             </section>
@@ -3592,21 +3592,21 @@
                 <title>Running ptest</title>
 
                 <para>
-                    The <filename>ptest-runner</filename> package installs a 
-                    shell script that loops through all installed ptest test 
-                    suites and runs them in sequence. 
+                    The <filename>ptest-runner</filename> package installs a
+                    shell script that loops through all installed ptest test
+                    suites and runs them in sequence.
                     Consequently, you might want to add this package to
-                    your image. 
+                    your image.
                 </para>
-            </section> 
+            </section>
 
             <section id='getting-your-package-ready'>
                 <title>Getting Your Package Ready</title>
- 
+
                 <para>
-                    In order to enable a recipe to run installed ptests 
-                    on target hardware, 
-                    you need to prepare the recipes that build the packages     
+                    In order to enable a recipe to run installed ptests
+                    on target hardware,
+                    you need to prepare the recipes that build the packages
                     you want to test.
                     Here is what you have to do for each recipe:
                     <itemizedlist>
@@ -3619,10 +3619,10 @@
                             </para></listitem>
                         <listitem><para><emphasis>Create <filename>run-ptest</filename>:</emphasis>
                             This script starts your test.
-                            Locate the script where you will refer to it 
-                            using 
+                            Locate the script where you will refer to it
+                            using
                             <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>.
-                            Here is an example that starts a test for 
+                            Here is an example that starts a test for
                             <filename>dbus</filename>:
                             <literallayout class='monospaced'>
      #!/bin/sh
@@ -3632,45 +3632,45 @@
                             </para></listitem>
                         <listitem><para><emphasis>Ensure dependencies are
                             met:</emphasis>
-                            If the test adds build or runtime dependencies 
-                            that normally do not exist for the package 
-                            (such as requiring "make" to run the test suite), 
-                            use the 
+                            If the test adds build or runtime dependencies
+                            that normally do not exist for the package
+                            (such as requiring "make" to run the test suite),
+                            use the
                             <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink>
-                            and 
+                            and
                             <ulink url='&YOCTO_DOCS_REF_URL;#var-RDEPENDS'><filename>RDEPENDS</filename></ulink>
                             variables in your recipe in order for the package
-                            to meet the dependencies. 
-                            Here is an example where the package has a runtime 
+                            to meet the dependencies.
+                            Here is an example where the package has a runtime
                             dependency on "make":
                             <literallayout class='monospaced'>
      RDEPENDS_${PN}-ptest += "make"
                             </literallayout>
                             </para></listitem>
-                        <listitem><para><emphasis>Add a function to build the 
+                        <listitem><para><emphasis>Add a function to build the
                             test suite:</emphasis>
-                            Not many packages support cross-compilation of 
-                            their test suites. 
-                            Consequently, you usually need to add a 
+                            Not many packages support cross-compilation of
+                            their test suites.
+                            Consequently, you usually need to add a
                             cross-compilation function to the package.
                             </para>
-                            <para>Many packages based on Automake compile and 
+                            <para>Many packages based on Automake compile and
                             run the test suite by using a single command
                             such as <filename>make check</filename>.
                             However, the native <filename>make check</filename>
-                            builds and runs on the same computer, while 
-                            cross-compiling requires that the package is built 
+                            builds and runs on the same computer, while
+                            cross-compiling requires that the package is built
                             on the host but executed on the target.
-                            The built version of Automake that ships with the 
-                            Yocto Project includes a patch that separates 
+                            The built version of Automake that ships with the
+                            Yocto Project includes a patch that separates
                             building and execution.
-                            Consequently, packages that use the unaltered, 
+                            Consequently, packages that use the unaltered,
                             patched version of <filename>make check</filename>
                             automatically cross-compiles.</para>
-                            <para>However, you still must add a 
-                            <filename>do_compile_ptest</filename> function to 
+                            <para>However, you still must add a
+                            <filename>do_compile_ptest</filename> function to
                             build the test suite.
-                            Add a function similar to the following to your 
+                            Add a function similar to the following to your
                             recipe:
                             <literallayout class='monospaced'>
      do_compile_ptest() {
@@ -3680,26 +3680,26 @@
                             </para></listitem>
                        <listitem><para><emphasis>Ensure special configurations
                             are set:</emphasis>
-                            If the package requires special configurations 
+                            If the package requires special configurations
                             prior to compiling the test code, you must
                             insert a <filename>do_configure_ptest</filename>
                             function into the recipe.
                             </para></listitem>
-                       <listitem><para><emphasis>Install the test 
+                       <listitem><para><emphasis>Install the test
                             suite:</emphasis>
-                            The <filename>ptest.bbclass</filename> class 
-                            automatically copies the file 
-                            <filename>run-ptest</filename> to the target and 
+                            The <filename>ptest.bbclass</filename> class
+                            automatically copies the file
+                            <filename>run-ptest</filename> to the target and
                             then runs make <filename>install-ptest</filename>
-                            to run the tests. 
-                            If this is not enough, you need to create a 
-                            <filename>do_install_ptest</filename> function and 
-                            make sure it gets called after the 
+                            to run the tests.
+                            If this is not enough, you need to create a
+                            <filename>do_install_ptest</filename> function and
+                            make sure it gets called after the
                             "make install-ptest" completes.
                             </para></listitem>
                     </itemizedlist>
                 </para>
-            </section>         
+            </section>
         </section>
     </section>
 
@@ -3771,20 +3771,22 @@
         </para>
 
         <para>
-            If you want to use <filename>SysVinit</filename>, you do
+            If you want to use <filename>sysvinit</filename>, you do
             not have to do anything.
             But, if you want to use <filename>systemd</filename>, you must
             take some steps as described in the following sections.
         </para>
 
+<!--
         <note>
             It is recommended that you create your own distribution configuration
-            file to hold these settings instead of using your 
+            file to hold these settings instead of using your
             <filename>local.conf</filename> file.
-            For information on creating your own distribution, see the 
+            For information on creating your own distribution, see the
             "<link linkend='creating-your-own-distribution'>Creating Your Own Distribution</link>"
             section.
         </note>
+-->
 
         <section id='using-systemd-exclusively'>
             <title>Using systemd Exclusively</title>
@@ -3797,7 +3799,7 @@
      VIRTUAL-RUNTIME_init_manager = "systemd"
                 </literallayout>
                 You can also prevent the <filename>sysvinit</filename>
-                distribution feature from 
+                distribution feature from
                 being automatically enabled as follows:
                 <literallayout class='monospaced'>
      DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
@@ -3805,6 +3807,12 @@
                 Doing so removes any redundant <filename>sysvinit</filename>
                 scripts.
             </para>
+
+            <para>
+                For information on the backfill variable, see
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES_BACKFILL_CONSIDERED'><filename>DISTRO_FEATURES_BACKFILL_CONSIDERED</filename></ulink>
+                in the Yocto Project Reference Manual.
+            </para>
         </section>
 
         <section id='using-systemd-for-the-main-image-and-using-sysvinit-for-the-rescue-image'>
@@ -3838,7 +3846,7 @@
             However, on rare occasions where you might want to use a
             layer but exclude parts that are causing problems, such
             as introducing a different version of a recipe, you can
-            use 
+            use
             <ulink url='&YOCTO_DOCS_REF_URL;#var-BBMASK'><filename>BBMASK</filename></ulink>
             to exclude the recipe.
         </para>
@@ -3978,7 +3986,7 @@
                 creation:
                 <itemizedlist>
                     <listitem><para><emphasis>Not using $D in front of absolute paths:</emphasis>
-                        The build system defines 
+                        The build system defines
                         <filename>$</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-D'><filename>D</filename></ulink>
                         at root filesystem creation time, and
                         it is blank when run on the target device.
@@ -4034,9 +4042,9 @@
         </para>
 
         <tip>
-            For best results, install <filename>-dbg</filename> packages for 
+            For best results, install <filename>-dbg</filename> packages for
             the applications you are going to debug.
-            Doing so makes extra debug symbols available that give you more 
+            Doing so makes extra debug symbols available that give you more
             meaningful output.
         </tip>
 
@@ -4097,11 +4105,11 @@
             <para>
                 Before you can initiate a remote debugging session, you need
                 to be sure you have set up the cross-development environment,
-                toolchain, and sysroot. 
+                toolchain, and sysroot.
                 The "<ulink url='&YOCTO_DOCS_ADT_URL;#adt-prepare'>Preparing for Application Development</ulink>"
                 chapter of the Yocto Project Application Developer's Guide
                 describes this process.
-                Be sure you have read that chapter and have set up 
+                Be sure you have read that chapter and have set up
                 your environment.
             </para>
         </section>
@@ -4111,22 +4119,22 @@
 
             <para>
                 Make sure Gdbserver is installed on the target.
-                If it is not, install the package 
+                If it is not, install the package
                 <filename>gdbserver</filename>, which needs the
                 <filename>libthread-db1</filename> package.
             </para>
 
             <para>
-                Here is an example that when entered from the host 
-                connects to the target and launches Gdbserver in order to 
+                Here is an example that when entered from the host
+                connects to the target and launches Gdbserver in order to
                 "debug" a binary named <filename>helloworld</filename>:
                 <literallayout class='monospaced'>
      $ gdbserver localhost:2345 /usr/bin/helloworld
                 </literallayout>
                 Gdbserver should now be listening on port 2345 for debugging
-                commands coming from a remote GDB process that is running on 
+                commands coming from a remote GDB process that is running on
                 the host computer.
-                Communication between Gdbserver and the host GDB are done 
+                Communication between Gdbserver and the host GDB are done
                 using TCP.
                 To use other communication protocols, please refer to the
                 <ulink url='http://www.gnu.org/software/gdb/'>Gdbserver documentation</ulink>.
@@ -4144,23 +4152,23 @@
             <section id="platdev-gdb-remotedebug-launch-gdb-buildcross">
                 <title>Build the Cross-GDB Package</title>
                 <para>
-                    A suitable GDB cross-binary is required that runs on your 
-                    host computer but also knows about the the ABI of the 
+                    A suitable GDB cross-binary is required that runs on your
+                    host computer but also knows about the the ABI of the
                     remote target.
-                    You can get this binary from the 
+                    You can get this binary from the
                     <link linkend='cross-development-toolchain'>Cross-Development Toolchain</link>.
                     Here is an example where the toolchain has been installed
-                    in the default directory 
+                    in the default directory
                     <filename>/opt/poky/&DISTRO;</filename>:
                     <literallayout class='monospaced'>
      /opt/poky/1.4/sysroots/i686-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-gdb
                     </literallayout>
-                    where <filename>arm</filename> is the target architecture 
+                    where <filename>arm</filename> is the target architecture
                     and <filename>linux-gnueabi</filename> is the target ABI.
                 </para>
 
                 <para>
-                    Alternatively, you can use BitBake to build the 
+                    Alternatively, you can use BitBake to build the
                     <filename>gdb-cross</filename> binary.
                     Here is an example:
                     <literallayout class='monospaced'>
@@ -4190,10 +4198,10 @@
                 </para>
 
                 <para>
-                    You need to add a statement in the 
+                    You need to add a statement in the
                     <filename>.gdbinit</filename> file that points to your
                     root filesystem.
-                    Here is an example that points to the root filesystem for 
+                    Here is an example that points to the root filesystem for
                     an ARM-based target device:
                     <literallayout class='monospaced'>
      set sysroot /home/jzhang/sysroot_arm
@@ -4205,14 +4213,14 @@
                 <title>Launch the Host GDB</title>
 
                 <para>
-                    Before launching the host GDB, you need to be sure 
-                    you have sourced the cross-debugging environment script, 
-                    which if you installed the root filesystem in the default 
-                    location is at <filename>/opt/poky/&DISTRO;</filename> 
+                    Before launching the host GDB, you need to be sure
+                    you have sourced the cross-debugging environment script,
+                    which if you installed the root filesystem in the default
+                    location is at <filename>/opt/poky/&DISTRO;</filename>
                     and begins with the string "environment-setup".
-                    For more information, see the 
+                    For more information, see the
                     "<ulink url='&YOCTO_DOCS_ADT_URL;#setting-up-the-cross-development-environment'>Setting Up the Cross-Development Environment</ulink>"
-                    section in the Yocto Project Application Developer's 
+                    section in the Yocto Project Application Developer's
                     Guide.
                 </para>
 
@@ -4222,7 +4230,7 @@
                     Provide the binary file you are going to debug.
                     For example, the following command continues with the
                     example used in the previous section by loading
-                    the <filename>helloworld</filename> binary as well as the 
+                    the <filename>helloworld</filename> binary as well as the
                     debugging information:
                     <literallayout class='monospaced'>
      $ arm-poky-linux-gnuabi-gdb helloworld
@@ -4238,7 +4246,7 @@
 
             <para>
                 From the target, you need to connect to the remote GDB
-                server that is running on the host. 
+                server that is running on the host.
                 You need to specify the remote host and port.
                 Here is the command continuing with the example:
                 <literallayout class='monospaced'>
@@ -4315,7 +4323,7 @@
             <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-DEBUG_BUILD'>DEBUG_BUILD</ulink></filename>
             variable to "1" in the <filename>local.conf</filename> configuration file.
             If you use the <filename>DEBUG_BUILD</filename> variable,
-            you also add extra debugging information that can make the debug 
+            you also add extra debugging information that can make the debug
             packages large.
         </para>
 
@@ -4390,8 +4398,8 @@
                 <ulink url="&YOCTO_GIT_URL;/cgit.cgi/oprofileui/"></ulink>.
                 If the "tools-profile" image feature is selected, all necessary binaries
                 are installed onto the target device for OProfileUI interaction.
-                For a list of image features that ship with the Yocto Project, 
-                see the 
+                For a list of image features that ship with the Yocto Project,
+                see the
                 "<ulink url='&YOCTO_DOCS_REF_URL;#ref-features-image'>Images</ulink>"
                 section in the Yocto Project Reference Manual.
             </para>
@@ -4460,7 +4468,7 @@
                 </para>
 
                 <para>
-                    Downloaded archives reside in the 
+                    Downloaded archives reside in the
                     <link linkend='build-directory'>Build Directory</link> in
                     <filename>/tmp</filename> and are cleared up when they are no longer in use.
                 </para>
@@ -4604,7 +4612,7 @@
                 release of proprietary software.
                 The Yocto Project provides an archiver class to help avoid
                 some of these concerns.
-                See the 
+                See the
                 "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-archiver'>Archiving Sources - <filename>archive*.bbclass</filename></ulink>"
                 section in the Yocto Project Reference Manual for information
                 on this class.
@@ -4752,7 +4760,7 @@
        ##COREBASE##/meta-yocto \
        "
                 </literallayout>
-                Creating and providing an archive of the 
+                Creating and providing an archive of the
                 <link linkend='metadata'>Metadata</link> layers
                 (recipes, configuration files, and so forth)
                 enables you to meet your