ref-manual: Review comments for closer look at YP dev section

Fixes [YOCTO #2808]

Applied minor wording changes as directed by Paul Eggleton's
review of the sections and related variable descriptions.

(From yocto-docs rev: cf30c3dd78d5e55356bb73f43f10e0093a9aa084)

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

2 files changed, 11 insertions, 11 deletions

diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
index d285b16174..3b69b04018 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -802,7 +802,8 @@ Core layer for images cannot be removed
             <glossdef>
                 <para>
                     Points to the area that the OpenEmbedded build system uses
-                    to place images and their related files.
+                    to place images, packages, SDKs and other output
+                    files that are ready to be used outside of the build system.
                     By default, this directory resides within the
                     <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
                     as <filename>tmp/deploy</filename>.
@@ -4065,10 +4066,10 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-TOOLCHAIN_TARGET_TASK'><glossterm>TOOLCHAIN_TARGET_TASK</glossterm>
             <glossdef>
                 <para>
-                    This variable lists packages BitBake uses when it creates
-                    the target part of an SDK (i.e. the part built
-                    for the target hardware), which includes libraries and
-                    headers.
+                    This variable lists packages the OpenEmbedded build system
+                    uses when it creates the target part of an SDK
+                    (i.e. the part built for the target hardware), which
+                    includes libraries and headers.
                 </para>
 
                 <para>
diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml
index 97fd629a74..d8704da314 100644
--- a/documentation/ref-manual/technical-details.xml
+++ b/documentation/ref-manual/technical-details.xml
@@ -847,8 +847,7 @@
                     The <filename>deploy/images</filename> directory can
                     contain multiple root filesystems.</para></listitem>
                 <listitem><para><filename>&lt;kernel-modules&gt;</filename>:
-                    Tarballs that contain all the modules used by the
-                    kernel.
+                    Tarballs that contain all the modules built for the kernel.
                     Kernel module tarballs exist for legacy purposes and
                     can be suppressed by setting the
                     <link linkend='var-MODULE_TARBALL_DEPLOY'><filename>MODULE_TARBALL_DEPLOY</filename></link>
@@ -863,7 +862,7 @@
                     contain multiple bootloaders.
                     </para></listitem>
                 <listitem><para><filename>&lt;symlinks&gt;</filename>:
-                    The <filename>images/deploy</filename> folder contains
+                    The <filename>deploy/images</filename> folder contains
                     a symbolic link that points to the most recently built file
                     for each machine.
                     These links might be useful for external scripts that
@@ -888,13 +887,13 @@
         <para>
             The specific form of this output is a self-extracting
             SDK installer (<filename>*.sh</filename>) that, when run,
-            installs the SDK image, which consists of a cross-development
+            installs the SDK, which consists of a cross-development
             toolchain, a set of libraries and headers, and an SDK
             environment setup script.
             Running this installer essentially sets up your
             cross-development environment.
-            You can think of the cross-toolchains as the "host" part
-            because they run on the SDK machine.
+            You can think of the cross-toolchain as the "host"
+            part because it runs on the SDK machine.
             You can think of the libraries and headers as the "target"
             part because they are built for the target hardware.
             The setup script is added so that you can initialize the