initial commit for Enea Linux 5.0 arm

Signed-off-by: Tudor Florea <tudor.florea@enea.com>

241 files changed, 66564 insertions, 0 deletions

diff --git a/documentation/Makefile b/documentation/Makefile
new file mode 100644
index 0000000000..3bc9a213ee
--- /dev/null
+++ b/documentation/Makefile
@@ -0,0 +1,395 @@
+# This is a single Makefile to handle all generated Yocto Project documents.
+# The Makefile needs to live in the documents directory and all figures used
+# in any manuals must be .PNG files and live in the individual book's figures
+# directory as well as in the figures directory for the mega-manual.
+# Note that the figures for the Yocto Project Development Manual
+# differ depending on the BRANCH being built.
+#
+# The Makefile has these targets:
+#
+#    pdf:      generates a PDF version of a manual.  Not valid for the Quick Start
+#              or the mega-manual (single, large HTML file comprised of all
+#              Yocto Project manuals).
+#    html:     generates an HTML version of a manual.
+#    eclipse:  generates an HTML version of a manual that can be used as
+#              eclipse help (including necessary metadata files).
+#    tarball:  creates a tarball for the doc files.
+#    validate: validates
+#    publish:  pushes generated files to the Yocto Project website
+#    clean:    removes files
+#
+# The Makefile generates an HTML and PDF version of every document except the
+# Yocto Project Quick Start and the single, HTML mega-manual, which is comprised
+# of all the individual Yocto Project manuals.  These two manuals are in HTML
+# form only.  The variable DOC indicates the folder name for a given manual. The
+# variable VER represents the distro version of the Yocto Release for which the
+# manuals are being generated.  The variable BRANCH is used to indicate the
+# branch (edison or denzil) and is used only when DOC=dev-manual or
+# DOC=mega-manual.  If you do not specify a BRANCH, the default branch used
+# will be for the latest Yocto Project release.  If you build for either
+# edison or denzil, you must use BRANCH. You do not need to use BRANCH for
+# any release beyond denzil.
+#
+# To build a manual, you must invoke Makefile with the DOC argument.  If you
+# are going to publish the manual, then you must invoke Makefile with both the
+# DOC and the VER argument.  Furthermore, if you are building or publishing
+# the edison or denzil versions of the Yocto Poject Development Manual or
+# the mega-manual, you must also use the BRANCH argument.
+#
+# Examples:
+#
+#     make DOC=bsp-guide
+#     make DOC=yocto-project-qs
+#     make pdf DOC=ref-manual
+#     make DOC=dev-manual BRANCH=edison
+#     make DOC=mega-manual BRANCH=denzil
+#
+# The first example generates the HTML and PDF versions of the BSP Guide.
+# The second example generates the HTML version only of the Quick Start.  Note that
+# the Quick Start only has an HTML version available.  The third example generates
+# both the PDF and HTML versions of the Yocto Project Reference Manual. The
+# fourth example generates both the PDF and HTML 'edison' versions of the YP
+# Development Manual.  The last exmample generates the HTML version of the
+# mega-manual and uses the 'denzil' branch when choosing figures for the
+# tarball of figures.  Any example that does not use the BRANCH argument
+# builds the current version of the manual set.
+#
+# Use the publish target to push the generated manuals to the Yocto Project
+# website.  All files needed for the manual's HTML form are pushed as well as the
+# PDF version (if applicable).
+# Examples:
+#
+#    make publish DOC=bsp-guide VER=1.3
+#    make publish DOC=adt-manual VER=1.3
+#    make publish DOC=dev-manual VER=1.1.1 BRANCH=edison
+#    make publish DOC=dev-manual VER=1.2 BRANCH=denzil
+#
+# The first example publishes the 1.3 version of both the PDF and HTML versions of
+# the BSP Guide.  The second example publishes the 1.3 version of both the PDF and
+# HTML versions of the ADT Manual. The third example publishes the PDF and HTML
+# 'edison' versions of the YP Development Manual.  The fourth example publishes
+# the PDF and HTML 'denzil' versions of the YP Development Manual.
+#
+
+ifeq ($(DOC),bsp-guide)
+XSLTOPTS = --xinclude
+ALLPREQ = html pdf eclipse tarball
+TARFILES = bsp-style.css bsp-guide.html bsp-guide.pdf figures/bsp-title.png \
+           eclipse
+MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse
+FIGURES = figures
+STYLESHEET = $(DOC)/*.css
+
+endif
+
+ifeq ($(DOC),dev-manual)
+XSLTOPTS = --xinclude
+ALLPREQ = html pdf eclipse tarball
+#
+# Note that the tarfile might produce the "Cannot stat: No such file or directory" error
+# message for .PNG files that are not present when building a particular branch.  The
+# list of files is all-inclusive for all branches.  Note, if you don't provide a BRANCH
+# option, it defaults to the latest stuff.  This would be appropriate for "master" branch.
+#
+
+        ifeq ($(BRANCH),edison)
+TARFILES = dev-style.css dev-manual.html dev-manual.pdf \
+           figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
+           figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
+           figures/kernel-example-repos-edison.png \
+           figures/kernel-overview-1.png figures/kernel-overview-2.png \
+           figures/kernel-overview-3-edison.png \
+           figures/source-repos.png figures/yp-download.png \
+           figures/wip.png
+        else ifeq ($(BRANCH),denzil)
+TARFILES = dev-style.css dev-manual.html dev-manual.pdf \
+           figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
+           figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
+           figures/kernel-example-repos-denzil.png \
+           figures/kernel-overview-1.png figures/kernel-overview-2.png \
+           figures/kernel-overview-3-denzil.png \
+           figures/source-repos.png figures/yp-download.png \
+           figures/wip.png
+        else
+TARFILES = dev-style.css dev-manual.html dev-manual.pdf \
+           figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
+           figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
+           figures/kernel-overview-1.png figures/kernel-overview-2-generic.png \
+           figures/source-repos.png figures/yp-download.png figures/recipe-workflow.png \
+           eclipse
+        endif
+
+MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse
+FIGURES = figures
+STYLESHEET = $(DOC)/*.css
+
+endif
+
+ifeq ($(DOC),yocto-project-qs)
+XSLTOPTS = --xinclude
+ALLPREQ = html eclipse tarball
+TARFILES = yocto-project-qs.html qs-style.css figures/yocto-environment.png \
+           figures/building-an-image.png figures/using-a-pre-built-image.png \
+           figures/yocto-project-transp.png \
+           eclipse
+MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse
+FIGURES = figures
+STYLESHEET = $(DOC)/*.css
+endif
+
+ifeq ($(DOC),mega-manual)
+XSLTOPTS = --stringparam html.stylesheet mega-style.css \
+           --stringparam  chapter.autolabel 1 \
+           --stringparam  section.autolabel 1 \
+           --stringparam  section.label.includes.component.label 1 \
+           --xinclude
+ALLPREQ = html tarball
+
+        ifeq ($(BRANCH),edison)
+TARFILES = mega-manual.html mega-style.css figures/yocto-environment.png figures/building-an-image.png  \
+        figures/using-a-pre-built-image.png \
+        figures/poky-title.png \
+        figures/adt-title.png figures/bsp-title.png \
+        figures/kernel-title.png figures/kernel-architecture-overview.png \
+        figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
+        figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
+        figures/kernel-example-repos-edison.png \
+        figures/kernel-overview-1.png figures/kernel-overview-2.png \
+        figures/kernel-overview-3-edison.png \
+        figures/source-repos.png figures/yp-download.png \
+        figures/wip.png
+        else ifeq ($(BRANCH),denzil)
+TARFILES = mega-manual.html mega-style.css figures/yocto-environment.png figures/building-an-image.png  \
+        figures/using-a-pre-built-image.png \
+        figures/poky-title.png \
+        figures/adt-title.png figures/bsp-title.png \
+        figures/kernel-title.png figures/kernel-architecture-overview.png \
+        figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
+        figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
+        figures/kernel-example-repos-denzil.png \
+        figures/kernel-overview-1.png figures/kernel-overview-2.png \
+        figures/kernel-overview-3-denzil.png \
+        figures/source-repos.png figures/yp-download.png \
+        figures/wip.png
+        else
+TARFILES = mega-manual.html mega-style.css figures/yocto-environment.png figures/building-an-image.png  \
+        figures/using-a-pre-built-image.png \
+        figures/poky-title.png figures/buildhistory.png figures/buildhistory-web.png \
+        figures/adt-title.png figures/bsp-title.png \
+        figures/kernel-dev-title.png figures/kernel-architecture-overview.png \
+        figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
+        figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
+        figures/kernel-overview-1.png figures/kernel-overview-2-generic.png \
+        figures/source-repos.png figures/yp-download.png \
+        figures/profile-title.png figures/kernelshark-all.png \
+        figures/kernelshark-choose-events.png figures/kernelshark-i915-display.png \
+        figures/kernelshark-output-display.png figures/lttngmain0.png \
+        figures/oprofileui-busybox.png figures/oprofileui-copy-to-user.png \
+        figures/oprofileui-downloading.png figures/oprofileui-processes.png \
+        figures/perf-probe-do_fork-profile.png figures/perf-report-cycles-u.png \
+        figures/perf-systemwide.png figures/perf-systemwide-libc.png \
+        figures/perf-wget-busybox-annotate-menu.png figures/perf-wget-busybox-annotate-udhcpc.png \
+        figures/perf-wget-busybox-debuginfo.png figures/perf-wget-busybox-dso-zoom.png \
+        figures/perf-wget-busybox-dso-zoom-menu.png figures/perf-wget-busybox-expanded-stripped.png \
+        figures/perf-wget-flat-stripped.png figures/perf-wget-g-copy-from-user-expanded-stripped.png \
+        figures/perf-wget-g-copy-to-user-expanded-debuginfo.png figures/perf-wget-g-copy-to-user-expanded-stripped.png \
+        figures/perf-wget-g-copy-to-user-expanded-stripped-unresolved-hidden.png figures/pybootchartgui-linux-yocto.png \
+        figures/pychart-linux-yocto-rpm.png figures/pychart-linux-yocto-rpm-nostrip.png \
+        figures/sched-wakeup-profile.png figures/sysprof-callers.png \
+        figures/sysprof-copy-from-user.png figures/sysprof-copy-to-user.png figures/cross-development-toolchains.png \
+        figures/yocto-environment-ref.png figures/user-configuration.png figures/source-input.png \
+        figures/package-feeds.png figures/layer-input.png figures/images.png figures/sdk.png \
+        figures/source-fetching.png figures/patching.png figures/configuration-compile-autoreconf.png \
+        figures/analysis-for-package-splitting.png figures/image-generation.png \
+        figures/sdk-generation.png figures/recipe-workflow.png
+        endif
+
+MANUALS = $(DOC)/$(DOC).html
+FIGURES = figures
+STYLESHEET = $(DOC)/*.css
+
+endif
+
+ifeq ($(DOC),ref-manual)
+XSLTOPTS = --xinclude
+ALLPREQ = html pdf eclipse tarball
+TARFILES = ref-manual.html ref-style.css figures/poky-title.png \
+        figures/buildhistory.png figures/buildhistory-web.png eclipse \
+        figures/cross-development-toolchains.png figures/layer-input.png \
+        figures/package-feeds.png figures/source-input.png \
+        figures/user-configuration.png figures/yocto-environment-ref.png \
+        figures/images.png figures/sdk.png figures/source-fetching.png \
+        figures/patching.png figures/configuration-compile-autoreconf.png \
+        figures/analysis-for-package-splitting.png figures/image-generation.png \
+        figures/sdk-generation.png
+MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse
+FIGURES = figures
+STYLESHEET = $(DOC)/*.css
+endif
+
+
+ifeq ($(DOC),adt-manual)
+XSLTOPTS = --xinclude
+ALLPREQ = html pdf eclipse tarball
+TARFILES = adt-manual.html adt-manual.pdf adt-style.css figures/adt-title.png \
+                        eclipse
+MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse
+FIGURES = figures
+STYLESHEET = $(DOC)/*.css
+endif
+
+ifeq ($(DOC),profile-manual)
+XSLTOPTS = --xinclude
+ALLPREQ = html pdf eclipse tarball
+TARFILES = profile-manual.html profile-manual.pdf profile-manual-style.css \
+           figures/profile-title.png figures/kernelshark-all.png \
+           figures/kernelshark-choose-events.png figures/kernelshark-i915-display.png \
+           figures/kernelshark-output-display.png figures/lttngmain0.png \
+           figures/oprofileui-busybox.png figures/oprofileui-copy-to-user.png \
+           figures/oprofileui-downloading.png figures/oprofileui-processes.png \
+           figures/perf-probe-do_fork-profile.png figures/perf-report-cycles-u.png \
+           figures/perf-systemwide.png figures/perf-systemwide-libc.png \
+           figures/perf-wget-busybox-annotate-menu.png figures/perf-wget-busybox-annotate-udhcpc.png \
+           figures/perf-wget-busybox-debuginfo.png figures/perf-wget-busybox-dso-zoom.png \
+           figures/perf-wget-busybox-dso-zoom-menu.png figures/perf-wget-busybox-expanded-stripped.png \
+           figures/perf-wget-flat-stripped.png figures/perf-wget-g-copy-from-user-expanded-stripped.png \
+           figures/perf-wget-g-copy-to-user-expanded-debuginfo.png figures/perf-wget-g-copy-to-user-expanded-stripped.png \
+           figures/perf-wget-g-copy-to-user-expanded-stripped-unresolved-hidden.png figures/pybootchartgui-linux-yocto.png \
+           figures/pychart-linux-yocto-rpm.png figures/pychart-linux-yocto-rpm-nostrip.png \
+           figures/sched-wakeup-profile.png figures/sysprof-callers.png \
+           figures/sysprof-copy-from-user.png figures/sysprof-copy-to-user.png \
+           eclipse
+MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse
+FIGURES = figures
+STYLESHEET = $(DOC)/*.css
+endif
+
+ifeq ($(DOC),kernel-dev)
+XSLTOPTS = --xinclude
+ALLPREQ = html pdf eclipse tarball
+TARFILES = kernel-dev.html kernel-dev.pdf kernel-dev-style.css figures/kernel-dev-title.png \
+           figures/kernel-architecture-overview.png \
+           eclipse
+MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse
+FIGURES = figures
+STYLESHEET = $(DOC)/*.css
+endif
+
+
+##
+# These URI should be rewritten by your distribution's xml catalog to
+# match your localy installed XSL stylesheets.
+XSL_BASE_URI  = http://docbook.sourceforge.net/release/xsl/current
+XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
+
+all: $(ALLPREQ)
+
+pdf:
+ifeq ($(DOC),yocto-project-qs)
+        @echo " "
+        @echo "ERROR: You cannot generate a yocto-project-qs PDF file."
+        @echo " "
+
+else ifeq ($(DOC),mega-manual)
+        @echo " "
+        @echo "ERROR: You cannot generate a mega-manual PDF file."
+        @echo " "
+
+else
+
+        cd $(DOC); ../tools/poky-docbook-to-pdf $(DOC).xml ../template; cd ..
+endif
+
+html:
+ifeq ($(DOC),mega-manual)
+#       See http://www.sagehill.net/docbookxsl/HtmlOutput.html
+        @echo " "
+        @echo "******** Building "$(DOC)
+        @echo " "
+        cd $(DOC); xsltproc $(XSLTOPTS) -o $(DOC).html $(DOC)-customization.xsl $(DOC).xml; cd ..
+        @echo " "
+        @echo "******** Using mega-manual.sed to process external links"
+        @echo " "
+        cd $(DOC); sed -f ../tools/mega-manual.sed < mega-manual.html > mega-output.html; cd ..
+        @echo " "
+        @echo "******** Cleaning up transient file mega-output.html"
+        @echo " "
+        cd $(DOC); rm mega-manual.html; mv mega-output.html mega-manual.html; cd ..
+else
+#       See http://www.sagehill.net/docbookxsl/HtmlOutput.html
+        @echo " "
+        @echo "******** Building "$(DOC)
+        @echo " "
+        cd $(DOC); xsltproc $(XSLTOPTS) -o $(DOC).html $(DOC)-customization.xsl $(DOC).xml; cd ..
+endif
+
+
+eclipse: BASE_DIR = html/$(DOC)/
+
+eclipse: eclipse-generate eclipse-resolve-links
+
+.PHONY : eclipse-generate eclipse-resolve-links
+
+eclipse-generate:
+ifeq ($(filter $(DOC), adt-manual bsp-guide dev-manual kernel-dev profile-manual ref-manual yocto-project-qs),)
+        @echo " "
+        @echo "ERROR: You can only create eclipse documentation"
+        @echo "       of the following documentation parts:"
+        @echo "       - adt-manual"
+        @echo "       - bsp-guide"
+        @echo "       - dev-manual"
+        @echo "       - kernel-dev"
+        @echo "       - profile-manual"
+        @echo "       - ref-manual"
+        @echo "       - yocto-project-qs"
+        @echo " "
+else
+        @echo " "
+        @echo "******** Building eclipse help of "$(DOC)
+        @echo " "
+        cd $(DOC) && \
+                xsltproc $(XSLTOPTS) \
+                                --stringparam base.dir '$(BASE_DIR)' \
+                                -o eclipse/$(DOC).html \
+                                $(DOC)-eclipse-customization.xsl $(DOC).xml && \
+                mv eclipse/toc.xml eclipse/$(DOC)-toc.xml && \
+                cp -rf $(FIGURES) eclipse/$(BASE_DIR) && \
+                cd ..;
+
+        $(call modify-eclipse)
+endif
+
+eclipse-resolve-links:
+        @echo " "
+        @echo "******** Using eclipse-help.sed to process external links"
+        @echo " "
+        $(foreach FILE, \
+                $(wildcard $(DOC)/eclipse/html/$(DOC)/*.html), \
+                $(shell sed -i -f tools/eclipse-help.sed $(FILE)))
+
+tarball: html
+        @echo " "
+        @echo "******** Creating Tarball of document files"
+        @echo " "
+        cd $(DOC); tar -cvzf $(DOC).tgz $(TARFILES); cd ..
+
+validate:
+        cd $(DOC); xmllint --postvalid --xinclude --noout $(DOC).xml; cd ..
+
+
+publish:
+        @if test -f $(DOC)/$(DOC).html; \
+          then \
+            echo " "; \
+            echo "******** Publishing "$(DOC)".html"; \
+            echo " "; \
+            scp -r $(MANUALS) $(STYLESHEET) docs.yp:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \
+            cd $(DOC); scp -r $(FIGURES) docs.yp:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \
+        else \
+          echo " "; \
+          echo $(DOC)".html missing.  Generate the file first then try again."; \
+          echo " "; \
+        fi
+
+clean:
+        rm -rf $(MANUALS); rm $(DOC)/$(DOC).tgz;
diff --git a/documentation/README b/documentation/README
new file mode 100644
index 0000000000..d01678d4f4
--- /dev/null
+++ b/documentation/README
@@ -0,0 +1,91 @@
+documentation
+=============
+
+This is the directory that contains the Yocto Project documentation.  The Yocto
+Project source repositories at http://git.yoctoproject.org/cgit.cgi have two
+instances of the "documentation" directory.  You should understand each of
+these instances.
+
+  poky/documentation - The directory within the poky Git repository containing
+                       the set of Yocto Project manuals.  When you clone the
+                       poky Git repository, the documentation directory
+                       contains the manuals.  The state of the manuals in this
+                       directory is guaranteed to reflect the latest Yocto
+                       Project release.  The manuals at the tip of this
+                       directory will also likely contain most manual
+                       development changes.
+
+  yocto-docs/documentation - The Git repository for the Yocto Project manuals.
+                             This repository is where manual development
+                             occurs.  If you plan on contributing back to the
+                             Yocto Project documentation, you should set up
+                             a local Git repository based on this upstream
+                             repository as follows:
+
+                               git clone git://git.yoctoproject.org/yocto-docs
+
+                             Changes and patches are first pushed to the
+                             yocto-docs Git repository.  Later, they make it
+                             into the poky Git repository found at
+                             git://git.yoctoproject.org/poky.
+
+Manual Organization
+===================
+
+Folders exist for individual manuals as follows:
+
+* adt-manual       - The Yocto Project Application Developer's Guide.
+* bsp-guide        - The Yocto Project Board Support Package (BSP) Developer's Guide
+* dev-manual       - The Yocto Project Development Manual
+* kernel-dev       - The Yocto Project Linux Kernel Development Manual
+* ref-manual       - The Yocto Project Reference Manual
+* yocto-project-qs - The Yocto Project Quick Start
+* mega-manual      - An aggregated manual comprised of all YP manuals and guides
+* profile-manual   - The Yocto Project Profile and Tracing Manual
+
+Each folder is self-contained regarding content and figures.  Note that there
+is a sed file needed to process the links of the mega-manual.  The sed file
+is located in the tools directory.  Also note that the figures folder in the
+mega-manual directory contains duplicates of all the figures in the YP folders
+directories for all YP manuals and guides.
+
+If you want to find HTML versions of the Yocto Project manuals on the web,
+go to http://www.yoctoproject.org and click on the "Documentation" tab.  From
+there you have access to archived documentation from previous releases, current
+documentation for the latest release, and "Docs in Progress" for the release
+currently being developed.
+
+In general, the Yocto Project site (http://www.yoctoproject.org) is a great
+reference for both information and downloads.
+
+Makefile
+========
+
+The Makefile processes manual directories to create HTML, PDF,
+tarballs, etc.  Details on how the Makefile work are documented
+inside the Makefile.  See that file for more information.
+
+To build a manual, you run the make command and pass it the name
+of the folder containing the manual's contents.
+For example, the following command run from the documentation directory
+creates an HTML and a PDF version of the ADT manual.
+The DOC variable specifies the manual you are making:
+
+     $ make DOC=adt-manual
+
+poky.ent
+========
+
+This file defines variables used for documentation production.  The variables
+are used to define release pathnames, URLs for the published manuals, etc.
+
+template
+========
+Contains various templates, fonts, and some old PNG files.
+
+tools
+=====
+Contains a tool to convert the DocBook files to PDF format.  This folder also
+contains the mega-manual.sed file, which is used by Makefile to process
+cross-references from within the manual that normally go to an external
+manual.
diff --git a/documentation/adt-manual/adt-command.xml b/documentation/adt-manual/adt-command.xml
new file mode 100644
index 0000000000..164b1efbff
--- /dev/null
+++ b/documentation/adt-manual/adt-command.xml
@@ -0,0 +1,224 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='using-the-command-line'>
+<title>Using the Command Line</title>
+
+    <para>
+        Recall that earlier the manual discussed how to use an existing toolchain
+        tarball that had been installed into the default installation
+        directory, <filename>/opt/poky/&DISTRO;</filename>, which is outside of the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+        (see the section "<link linkend='using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball)</link>".
+        And, that sourcing your architecture-specific environment setup script
+        initializes a suitable cross-toolchain development environment.
+    </para>
+
+    <para>
+        During this setup, locations for the compiler, QEMU scripts, QEMU binary,
+        a special version of <filename>pkgconfig</filename> and other useful
+        utilities are added to the <filename>PATH</filename> variable.
+        Also, variables to assist
+        <filename>pkgconfig</filename> and <filename>autotools</filename>
+        are also defined so that, for example, <filename>configure.sh</filename>
+        can find pre-generated test results for tests that need target hardware
+        on which to run.
+    </para>
+
+    <para>
+        Collectively, these conditions allow you to easily use the toolchain
+        outside of the OpenEmbedded build environment on both Autotools-based
+        projects and Makefile-based projects.
+        This chapter provides information for both these types of projects.
+    </para>
+
+
+<section id='autotools-based-projects'>
+<title>Autotools-Based Projects</title>
+
+    <para>
+        Once you have a suitable cross-toolchain installed, it is very easy to
+        develop a project outside of the OpenEmbedded build system.
+        This section presents a simple "Helloworld" example that shows how
+        to set up, compile, and run the project.
+    </para>
+
+    <section id='creating-and-running-a-project-based-on-gnu-autotools'>
+        <title>Creating and Running a Project Based on GNU Autotools</title>
+
+        <para>
+            Follow these steps to create a simple Autotools-based project:
+            <orderedlist>
+                <listitem><para><emphasis>Create your directory:</emphasis>
+                    Create a clean directory for your project and then make
+                    that directory your working location:
+                    <literallayout class='monospaced'>
+     $ mkdir $HOME/helloworld
+     $ cd $HOME/helloworld
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Populate the directory:</emphasis>
+                    Create <filename>hello.c</filename>, <filename>Makefile.am</filename>,
+                    and <filename>configure.in</filename> files as follows:
+                    <itemizedlist>
+                        <listitem><para>For <filename>hello.c</filename>, include
+                            these lines:
+                            <literallayout class='monospaced'>
+     #include &lt;stdio.h&gt;
+
+     main()
+        {
+           printf("Hello World!\n");
+        }
+                            </literallayout></para></listitem>
+                        <listitem><para>For <filename>Makefile.am</filename>,
+                            include these lines:
+                            <literallayout class='monospaced'>
+     bin_PROGRAMS = hello
+     hello_SOURCES = hello.c
+                            </literallayout></para></listitem>
+                        <listitem><para>For <filename>configure.in</filename>,
+                            include these lines:
+                            <literallayout class='monospaced'>
+     AC_INIT(hello.c)
+     AM_INIT_AUTOMAKE(hello,0.1)
+     AC_PROG_CC
+     AC_PROG_INSTALL
+     AC_OUTPUT(Makefile)
+                            </literallayout></para></listitem>
+                    </itemizedlist></para></listitem>
+                <listitem><para><emphasis>Source the cross-toolchain
+                    environment setup file:</emphasis>
+                    Installation of the cross-toolchain creates a cross-toolchain
+                    environment setup script in the directory that the ADT
+                    was installed.
+                    Before you can use the tools to develop your project, you must
+                    source this setup script.
+                    The script begins with the string "environment-setup" and contains
+                    the machine architecture, which is followed by the string
+                    "poky-linux".
+                    Here is an example that sources a script from the
+                    default ADT installation directory that uses the
+                    32-bit Intel x86 Architecture and using the
+                    &DISTRO_NAME; Yocto Project release:
+                    <literallayout class='monospaced'>
+     $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Generate the local aclocal.m4
+                    files and create the configure script:</emphasis>
+                    The following GNU Autotools generate the local
+                    <filename>aclocal.m4</filename> files and create the
+                    configure script:
+                    <literallayout class='monospaced'>
+     $ aclocal
+     $ autoconf
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Generate files needed by GNU
+                    coding standards:</emphasis>
+                    GNU coding standards require certain files in order for the
+                    project to be compliant.
+                    This command creates those files:
+                    <literallayout class='monospaced'>
+     $ touch NEWS README AUTHORS ChangeLog
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Generate the configure
+                    file:</emphasis>
+                    This command generates the <filename>configure</filename>:
+                    <literallayout class='monospaced'>
+     $ automake -a
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Cross-compile the project:</emphasis>
+                    This command compiles the project using the cross-compiler:
+                    <literallayout class='monospaced'>
+     $ ./configure ${CONFIGURE_FLAGS}
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Make and install the project:</emphasis>
+                    These two commands generate and install the project into the
+                    destination directory:
+                    <literallayout class='monospaced'>
+     $ make
+     $ make install DESTDIR=./tmp
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Verify the installation:</emphasis>
+                    This command is a simple way to verify the installation
+                    of your project.
+                    Running the command prints the architecture on which
+                    the binary file can run.
+                    This architecture should be the same architecture that
+                    the installed cross-toolchain supports.
+                    <literallayout class='monospaced'>
+     $ file ./tmp/usr/local/bin/hello
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Execute your project:</emphasis>
+                    To execute the project in the shell, simply enter the name.
+                    You could also copy the binary to the actual target hardware
+                    and run the project there as well:
+                    <literallayout class='monospaced'>
+     $ ./hello
+                    </literallayout>
+                    As expected, the project displays the "Hello World!" message.
+                    </para></listitem>
+            </orderedlist>
+        </para>
+    </section>
+
+    <section id='passing-host-options'>
+        <title>Passing Host Options</title>
+
+        <para>
+            For an Autotools-based project, you can use the cross-toolchain by just
+            passing the appropriate host option to <filename>configure.sh</filename>.
+            The host option you use is derived from the name of the environment setup
+            script found in the directory in which you installed the cross-toolchain.
+            For example, the host option for an ARM-based target that uses the GNU EABI
+            is <filename>armv5te-poky-linux-gnueabi</filename>.
+            You will notice that the name of the script is
+            <filename>environment-setup-armv5te-poky-linux-gnueabi</filename>.
+            Thus, the following command works:
+            <literallayout class='monospaced'>
+     $ ./configure --host=armv5te-poky-linux-gnueabi \
+        --with-libtool-sysroot=<replaceable>sysroot-dir</replaceable>
+            </literallayout>
+        </para>
+
+        <para>
+            This single command updates your project and rebuilds it using the appropriate
+            cross-toolchain tools.
+            <note>
+                If the <filename>configure</filename> script results in problems recognizing the
+                <filename>--with-libtool-sysroot=</filename><replaceable>sysroot-dir</replaceable> option,
+                regenerate the script to enable the support by doing the following and then
+                run the script again:
+                <literallayout class='monospaced'>
+     $ libtoolize --automake
+     $ aclocal -I ${OECORE_NATIVE_SYSROOT}/usr/share/aclocal \
+        [-I <replaceable>dir_containing_your_project-specific_m4_macros</replaceable>]
+     $ autoconf
+     $ autoheader
+     $ automake -a
+                </literallayout>
+            </note>
+        </para>
+    </section>
+</section>
+
+<section id='makefile-based-projects'>
+<title>Makefile-Based Projects</title>
+
+    <para>
+        For a Makefile-based project, you use the cross-toolchain by making sure
+        the tools are used.
+        You can do this as follows:
+        <literallayout class='monospaced'>
+     CC=arm-poky-linux-gnueabi-gcc
+     LD=arm-poky-linux-gnueabi-ld
+     CFLAGS=”${CFLAGS} --sysroot=&lt;sysroot-dir&gt;”
+     CXXFLAGS=”${CXXFLAGS} --sysroot=&lt;sysroot-dir&gt;”
+        </literallayout>
+    </para>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/adt-manual/adt-intro.xml b/documentation/adt-manual/adt-intro.xml
new file mode 100644
index 0000000000..ed13a23a5f
--- /dev/null
+++ b/documentation/adt-manual/adt-intro.xml
@@ -0,0 +1,179 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='adt-intro'>
+    <title>The Application Development Toolkit (ADT)</title>
+
+    <para>
+        Part of the Yocto Project development solution is an Application Development
+        Toolkit (ADT).
+        The ADT provides you with a custom-built, cross-development
+        platform suited for developing a user-targeted product application.
+    </para>
+
+    <para>
+        Fundamentally, the ADT consists of the following:
+        <itemizedlist>
+            <listitem><para>An architecture-specific cross-toolchain and matching
+                sysroot both built by the OpenEmbedded build system.
+                The toolchain and sysroot are based on a
+                <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                configuration and extensions,
+                which allows you to cross-develop on the host machine for the target hardware.
+                </para></listitem>
+            <listitem><para>The Eclipse IDE Yocto Plug-in.</para></listitem>
+            <listitem><para>The Quick EMUlator (QEMU), which lets you simulate target hardware.
+                </para></listitem>
+            <listitem><para>Various user-space tools that greatly enhance your application
+                development experience.</para></listitem>
+        </itemizedlist>
+    </para>
+
+    <section id='the-cross-development-toolchain'>
+        <title>The Cross-Development Toolchain</title>
+
+        <para>
+            The
+            <ulink url='&YOCTO_DOCS_DEV_URL;#cross-development-toolchain'>Cross-Development Toolchain</ulink>
+            consists of a cross-compiler, cross-linker, and cross-debugger
+            that are used to develop user-space applications for targeted
+            hardware.
+            This toolchain is created either by running the ADT Installer
+            script, a toolchain installer script, or through a
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            that is based on your Metadata configuration or extension for
+            your targeted device.
+            The cross-toolchain works with a matching target sysroot.
+        </para>
+    </section>
+
+    <section id='sysroot'>
+        <title>Sysroot</title>
+
+        <para>
+            The matching target sysroot contains needed headers and libraries for generating
+            binaries that run on the target architecture.
+            The sysroot is based on the target root filesystem image that is built by
+            the OpenEmbedded build system and uses the same Metadata configuration
+            used to build the cross-toolchain.
+        </para>
+    </section>
+
+    <section id='eclipse-overview'>
+        <title>Eclipse Yocto Plug-in</title>
+
+        <para>
+            The Eclipse IDE is a popular development environment and it fully supports
+            development using the Yocto Project.
+            When you install and configure the Eclipse Yocto Project Plug-in into
+            the Eclipse IDE, you maximize your Yocto Project experience.
+            Installing and configuring the Plug-in results in an environment that
+            has extensions specifically designed to let you more easily develop software.
+            These extensions allow for cross-compilation, deployment, and execution of
+            your output into a QEMU emulation session.
+            You can also perform cross-debugging and profiling.
+            The environment also supports a suite of tools that allows you to perform
+            remote profiling, tracing, collection of power data, collection of
+            latency data, and collection of performance data.
+        </para>
+
+        <para>
+            For information about the application development workflow that uses the Eclipse
+            IDE and for a detailed example of how to install and configure the Eclipse
+            Yocto Project Plug-in, see the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#adt-eclipse'>Working Within Eclipse</ulink>" section
+            of the Yocto Project Development Manual.
+        </para>
+    </section>
+
+    <section id='the-qemu-emulator'>
+        <title>The QEMU Emulator</title>
+
+        <para>
+            The QEMU emulator allows you to simulate your hardware while running your
+            application or image.
+            QEMU is made available a number of ways:
+            <itemizedlist>
+                <listitem><para>
+                    If you use the ADT Installer script to install ADT, you can
+                    specify whether or not to install QEMU.
+                    </para></listitem>
+                <listitem><para>
+                    If you have cloned the <filename>poky</filename> Git
+                    repository to create a
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    and you have sourced the environment setup script, QEMU is
+                    installed and automatically available.
+                    </para></listitem>
+                <listitem><para>
+                    If you have downloaded a Yocto Project release and unpacked
+                    it to create a
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    and you have sourced the environment setup script, QEMU is
+                    installed and automatically available.
+                    </para></listitem>
+                <listitem><para>
+                    If you have installed the cross-toolchain tarball and you
+                    have sourced the toolchain's setup environment script, QEMU
+                    is also installed and automatically available.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='user-space-tools'>
+        <title>User-Space Tools</title>
+
+        <para>
+            User-space tools are included as part of the distribution.
+            You will find these tools helpful during development.
+            The tools include LatencyTOP, PowerTOP, OProfile, Perf, SystemTap, and Lttng-ust.
+            These tools are common development tools for the Linux platform.
+            <itemizedlist>
+                <listitem><para><emphasis>LatencyTOP:</emphasis> LatencyTOP focuses on latency
+                    that causes skips in audio,
+                    stutters in your desktop experience, or situations that overload your server
+                    even when you have plenty of CPU power left.
+                    </para></listitem>
+                <listitem><para><emphasis>PowerTOP:</emphasis> Helps you determine what
+                    software is using the most power.
+                    You can find out more about PowerTOP at
+                    <ulink url='https://01.org/powertop/'></ulink>.</para></listitem>
+                <listitem><para><emphasis>OProfile:</emphasis> A system-wide profiler for Linux
+                    systems that is capable of profiling all running code at low overhead.
+                    You can find out more about OProfile at
+                    <ulink url='http://oprofile.sourceforge.net/about/'></ulink>.
+                    For examples on how to setup and use this tool, see the
+                    "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-oprofile'>OProfile</ulink>"
+                    section in the Yocto Project Profiling and Tracing Manual.
+                    </para></listitem>
+                <listitem><para><emphasis>Perf:</emphasis> Performance counters for Linux used
+                    to keep track of certain types of hardware and software events.
+                    For more information on these types of counters see
+                    <ulink url='https://perf.wiki.kernel.org/'></ulink>.
+                    For examples on how to setup and use this tool, see the
+                    "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-perf'>perf</ulink>"
+                    section in the Yocto Project Profiling and Tracing Manual.
+                    </para></listitem>
+                <listitem><para><emphasis>SystemTap:</emphasis> A free software infrastructure
+                    that simplifies information gathering about a running Linux system.
+                    This information helps you diagnose performance or functional problems.
+                    SystemTap is not available as a user-space tool through the Eclipse IDE Yocto Plug-in.
+                    See <ulink url='http://sourceware.org/systemtap'></ulink> for more information
+                    on SystemTap.
+                    For examples on how to setup and use this tool, see the
+                    "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-systemtap'>SystemTap</ulink>"
+                    section in the Yocto Project Profiling and Tracing Manual.</para></listitem>
+                <listitem><para><emphasis>Lttng-ust:</emphasis> A User-space Tracer designed to
+                    provide detailed information on user-space activity.
+                    See <ulink url='http://lttng.org/ust'></ulink> for more information on Lttng-ust.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/adt-manual/adt-manual-customization.xsl b/documentation/adt-manual/adt-manual-customization.xsl
new file mode 100644
index 0000000000..f08087d93f
--- /dev/null
+++ b/documentation/adt-manual/adt-manual-customization.xsl
@@ -0,0 +1,19 @@
+<?xml version='1.0'?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
+
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
+
+  <xsl:include href="../template/permalinks.xsl"/>
+  <xsl:include href="../template/section.title.xsl"/>
+  <xsl:include href="../template/component.title.xsl"/>
+  <xsl:include href="../template/division.title.xsl"/>
+  <xsl:include href="../template/formal.object.heading.xsl"/>
+
+  <xsl:param name="html.stylesheet" select="'adt-style.css'" />
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="appendix.autolabel" select="A" />
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+  <xsl:param name="generate.id.attributes" select="1" />
+
+</xsl:stylesheet>
diff --git a/documentation/adt-manual/adt-manual-eclipse-customization.xsl b/documentation/adt-manual/adt-manual-eclipse-customization.xsl
new file mode 100644
index 0000000000..d16ffbb68e
--- /dev/null
+++ b/documentation/adt-manual/adt-manual-eclipse-customization.xsl
@@ -0,0 +1,27 @@
+<?xml version='1.0'?>
+<xsl:stylesheet
+        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+        xmlns="http://www.w3.org/1999/xhtml"
+        xmlns:fo="http://www.w3.org/1999/XSL/Format"
+        version="1.0">
+
+  <xsl:import
+          href="http://docbook.sourceforge.net/release/xsl/current/eclipse/eclipse3.xsl" />
+
+  <xsl:param name="chunker.output.indent" select="'yes'"/>
+  <xsl:param name="chunk.quietly" select="1"/>
+  <xsl:param name="chunk.first.sections" select="1"/>
+  <xsl:param name="chunk.section.depth" select="10"/>
+  <xsl:param name="use.id.as.filename" select="1"/>
+  <xsl:param name="ulink.target" select="'_self'" />
+  <xsl:param name="base.dir" select="'html/adt-manual/'"/>
+  <xsl:param name="html.stylesheet" select="'../book.css'"/>
+  <xsl:param name="eclipse.manifest" select="0"/>
+  <xsl:param name="create.plugin.xml" select="0"/>
+  <xsl:param name="suppress.navigation" select="1"/>
+  <xsl:param name="generate.index" select="0"/>
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="appendix.autolabel" select="1" />
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+</xsl:stylesheet>
diff --git a/documentation/adt-manual/adt-manual-intro.xml b/documentation/adt-manual/adt-manual-intro.xml
new file mode 100644
index 0000000000..fccacc4ba4
--- /dev/null
+++ b/documentation/adt-manual/adt-manual-intro.xml
@@ -0,0 +1,33 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='adt-manual-intro'>
+<title>Introduction</title>
+
+    <para>
+        Welcome to the Yocto Project Application Developer's Guide.
+        This manual provides information that lets you begin developing applications
+        using the Yocto Project.
+    </para>
+
+    <para>
+        The Yocto Project provides an application development environment based on
+        an Application Development Toolkit (ADT) and the availability of stand-alone
+        cross-development toolchains and other tools.
+        This manual describes the ADT and how you can configure and install it,
+        how to access and use the cross-development toolchains, how to
+        customize the development packages installation,
+        how to use command line development for both Autotools-based and Makefile-based projects,
+        and an introduction to the <trademark class='trade'>Eclipse</trademark> IDE
+        Yocto Plug-in.
+        <note>
+            The ADT is distribution-neutral and does not require the Yocto
+            Project reference distribution, which is called Poky.
+            This manual, however, uses examples that use the Poky distribution.
+        </note>
+    </para>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/adt-manual/adt-manual.xml b/documentation/adt-manual/adt-manual.xml
new file mode 100644
index 0000000000..57ca64ed17
--- /dev/null
+++ b/documentation/adt-manual/adt-manual.xml
@@ -0,0 +1,135 @@
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<book id='adt-manual' lang='en'
+      xmlns:xi="http://www.w3.org/2003/XInclude"
+      xmlns="http://docbook.org/ns/docbook"
+      >
+    <bookinfo>
+
+        <mediaobject>
+            <imageobject>
+                <imagedata fileref='figures/adt-title.png'
+                    format='SVG'
+                    align='left' scalefit='1' width='100%'/>
+            </imageobject>
+        </mediaobject>
+
+        <title>
+            Yocto Project Application Developer's Guide
+        </title>
+
+        <authorgroup>
+            <author>
+                <firstname>Jessica</firstname> <surname>Zhang</surname>
+                <affiliation>
+                    <orgname>Intel Corporation</orgname>
+                </affiliation>
+                <email>jessica.zhang@intel.com</email>
+            </author>
+        </authorgroup>
+
+        <revhistory>
+            <revision>
+                <revnumber>1.0</revnumber>
+                <date>6 April 2011</date>
+                <revremark>Released with the Yocto Project 1.0 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.0.1</revnumber>
+                <date>23 May 2011</date>
+                <revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.1</revnumber>
+                <date>6 October 2011</date>
+                <revremark>Released with the Yocto Project 1.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.2</revnumber>
+                <date>April 2012</date>
+                <revremark>Released with the Yocto Project 1.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.3</revnumber>
+                <date>October 2012</date>
+                <revremark>Released with the Yocto Project 1.3 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4</revnumber>
+                <date>April 2013</date>
+                <revremark>Released with the Yocto Project 1.4 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5</revnumber>
+                <date>October 2013</date>
+                <revremark>Released with the Yocto Project 1.5 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.1</revnumber>
+                <date>January 2014</date>
+                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.6</revnumber>
+                <date>April 2014</date>
+                <revremark>Released with the Yocto Project 1.6 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7</revnumber>
+                <date>October 2014</date>
+                <revremark>Released with the Yocto Project 1.7 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.1</revnumber>
+                <date>January 2015</date>
+                <revremark>Released with the Yocto Project 1.7.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.2</revnumber>
+                <date>June 2015</date>
+                <revremark>Released with the Yocto Project 1.7.2 Release.</revremark>
+            </revision>
+       </revhistory>
+
+    <copyright>
+      <year>&COPYRIGHT_YEAR;</year>
+      <holder>Linux Foundation</holder>
+    </copyright>
+
+    <legalnotice>
+      <para>
+        Permission is granted to copy, distribute and/or modify this document under
+        the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
+      </para>
+      <note>
+          For the latest version of this manual associated with this
+          Yocto Project release, see the
+          <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>
+          from the Yocto Project website.
+      </note>
+
+    </legalnotice>
+
+    </bookinfo>
+
+    <xi:include href="adt-manual-intro.xml"/>
+
+    <xi:include href="adt-intro.xml"/>
+
+    <xi:include href="adt-prepare.xml"/>
+
+    <xi:include href="adt-package.xml"/>
+
+    <xi:include href="adt-command.xml"/>
+
+<!--    <index id='index'>
+      <title>Index</title>
+    </index>
+-->
+
+</book>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/adt-manual/adt-package.xml b/documentation/adt-manual/adt-package.xml
new file mode 100644
index 0000000000..5c3196ea91
--- /dev/null
+++ b/documentation/adt-manual/adt-package.xml
@@ -0,0 +1,101 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='adt-package'>
+<title>Optionally Customizing the Development Packages Installation</title>
+
+    <para>
+        Because the Yocto Project is suited for embedded Linux development, it is
+        likely that you will need to customize your development packages installation.
+        For example, if you are developing a minimal image, then you might not need
+        certain packages (e.g. graphics support packages).
+        Thus, you would like to be able to remove those packages from your target sysroot.
+    </para>
+
+<section id='package-management-systems'>
+    <title>Package Management Systems</title>
+
+    <para>
+        The OpenEmbedded build system supports the generation of sysroot files using
+        three different Package Management Systems (PMS):
+        <itemizedlist>
+            <listitem><para><emphasis>OPKG:</emphasis> A less well known PMS whose use
+                originated in the OpenEmbedded and OpenWrt embedded Linux projects.
+                This PMS works with files packaged in an <filename>.ipk</filename> format.
+                See <ulink url='http://en.wikipedia.org/wiki/Opkg'></ulink> for more
+                information about OPKG.</para></listitem>
+            <listitem><para><emphasis>RPM:</emphasis> A more widely known PMS intended for GNU/Linux
+                distributions.
+                This PMS works with files packaged in an <filename>.rms</filename> format.
+                The build system currently installs through this PMS by default.
+                See <ulink url='http://en.wikipedia.org/wiki/RPM_Package_Manager'></ulink>
+                for more information about RPM.</para></listitem>
+            <listitem><para><emphasis>Debian:</emphasis> The PMS for Debian-based systems
+                is built on many PMS tools.
+                The lower-level PMS tool <filename>dpkg</filename> forms the base of the Debian PMS.
+                For information on dpkg see
+                <ulink url='http://en.wikipedia.org/wiki/Dpkg'></ulink>.</para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='configuring-the-pms'>
+    <title>Configuring the PMS</title>
+
+    <para>
+        Whichever PMS you are using, you need to be sure that the
+        <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink>
+        variable in the <filename>conf/local.conf</filename>
+        file is set to reflect that system.
+        The first value you choose for the variable specifies the package file format for the root
+        filesystem at sysroot.
+        Additional values specify additional formats for convenience or testing.
+        See the configuration file for details.
+    </para>
+
+    <note>
+        For build performance information related to the PMS, see the
+        "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-package'><filename>package.bbclass</filename></ulink>"
+        section in the Yocto Project Reference Manual.
+    </note>
+
+    <para>
+        As an example, consider a scenario where you are using OPKG and you want to add
+        the <filename>libglade</filename> package to the target sysroot.
+    </para>
+
+    <para>
+        First, you should generate the IPK file for the
+        <filename>libglade</filename> package and add it
+        into a working <filename>opkg</filename> repository.
+        Use these commands:
+        <literallayout class='monospaced'>
+     $ bitbake libglade
+     $ bitbake package-index
+        </literallayout>
+    </para>
+
+    <para>
+        Next, source the environment setup script found in the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        Follow that by setting up the installation destination to point to your
+        sysroot as <replaceable>sysroot_dir</replaceable>.
+        Finally, have an OPKG configuration file <replaceable>conf_file</replaceable>
+        that corresponds to the <filename>opkg</filename> repository you have just created.
+        The following command forms should now work:
+        <literallayout class='monospaced'>
+     $ opkg-cl –f <replaceable>conf_file</replaceable> -o <replaceable>sysroot_dir</replaceable> update
+     $ opkg-cl –f <replaceable>cconf_file</replaceable> -o <replaceable>sysroot_dir</replaceable> \
+        --force-overwrite install libglade
+     $ opkg-cl –f <replaceable>cconf_file</replaceable> -o <replaceable>sysroot_dir</replaceable> \
+        --force-overwrite install libglade-dbg
+     $ opkg-cl –f <replaceable>conf_file&gt; -o </replaceable>sysroot_dir&gt; \
+        --force-overwrite install libglade-dev
+        </literallayout>
+    </para>
+</section>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/adt-manual/adt-prepare.xml b/documentation/adt-manual/adt-prepare.xml
new file mode 100644
index 0000000000..3810568730
--- /dev/null
+++ b/documentation/adt-manual/adt-prepare.xml
@@ -0,0 +1,671 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='adt-prepare'>
+
+<title>Preparing for Application Development</title>
+
+<para>
+    In order to develop applications, you need set up your host development system.
+    Several ways exist that allow you to install cross-development tools, QEMU, the
+    Eclipse Yocto Plug-in, and other tools.
+    This chapter describes how to prepare for application development.
+</para>
+
+<section id='installing-the-adt'>
+    <title>Installing the ADT and Toolchains</title>
+
+    <para>
+        The following list describes installation methods that set up varying degrees of tool
+        availability on your system.
+        Regardless of the installation method you choose,
+        you must <filename>source</filename> the cross-toolchain
+        environment setup script before you use a toolchain.
+        See the "<link linkend='setting-up-the-cross-development-environment'>Setting Up the
+        Cross-Development Environment</link>" section for more information.
+    </para>
+
+    <note>
+        <para>Avoid mixing installation methods when installing toolchains for different architectures.
+        For example, avoid using the ADT Installer to install some toolchains and then hand-installing
+        cross-development toolchains by running the toolchain installer for different architectures.
+        Mixing installation methods can result in situations where the ADT Installer becomes
+        unreliable and might not install the toolchain.</para>
+        <para>If you must mix installation methods, you might avoid problems by deleting
+        <filename>/var/lib/opkg</filename>, thus purging the <filename>opkg</filename> package
+        metadata</para>
+    </note>
+
+    <para>
+        <itemizedlist>
+            <listitem><para><emphasis>Use the ADT installer script:</emphasis>
+                This method is the recommended way to install the ADT because it
+                automates much of the process for you.
+                For example, you can configure the installation to install the QEMU emulator
+                and the user-space NFS, specify which root filesystem profiles to download,
+                and define the target sysroot location.</para></listitem>
+            <listitem><para><emphasis>Use an existing toolchain:</emphasis>
+                Using this method, you select and download an architecture-specific
+                toolchain installer and then run the script to hand-install the toolchain.
+                If you use this method, you just get the cross-toolchain and QEMU - you do not
+                get any of the other mentioned benefits had you run the ADT Installer script.</para></listitem>
+            <listitem><para><emphasis>Use the toolchain from within the Build Directory:</emphasis>
+                If you already have a
+                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
+                you can build the cross-toolchain within the directory.
+                However, like the previous method mentioned, you only get the cross-toolchain and QEMU - you
+                do not get any of the other benefits without taking separate steps.</para></listitem>
+        </itemizedlist>
+    </para>
+
+    <section id='using-the-adt-installer'>
+        <title>Using the ADT Installer</title>
+
+        <para>
+            To run the ADT Installer, you need to get the ADT Installer tarball, be sure
+            you have the necessary host development packages that support the ADT Installer,
+            and then run the ADT Installer Script.
+        </para>
+
+        <para>
+            For a list of the host packages needed to support ADT installation and use, see the
+            "ADT Installer Extras" lists in the
+            "<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-host-development-system'>Required Packages for the Host Development System</ulink>" section
+            of the Yocto Project Reference Manual.
+        </para>
+
+        <section id='getting-the-adt-installer-tarball'>
+            <title>Getting the ADT Installer Tarball</title>
+
+            <para>
+                The ADT Installer is contained in the ADT Installer tarball.
+                You can get the tarball using either of these methods:
+                <itemizedlist>
+                    <listitem><para><emphasis>Download the Tarball:</emphasis>
+                        You can download the tarball from
+                        <ulink url='&YOCTO_ADTINSTALLER_DL_URL;'></ulink> into
+                        any directory.</para></listitem>
+                    <listitem><para><emphasis>Build the Tarball:</emphasis>
+                        You can use
+                        <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>
+                        to generate the tarball inside an existing
+                        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                        </para>
+                        <para>If you use BitBake to generate the ADT Installer
+                        tarball, you must <filename>source</filename> the
+                        environment setup script
+                        (<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                        or
+                        <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>)
+                        located in the Source Directory before running the
+                        <filename>bitbake</filename> command that creates the
+                        tarball.</para>
+                        <para>The following example commands establish
+                        the
+                        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
+                        check out the current release branch, set up the
+                        build environment while also creating the default
+                        Build Directory, and run the
+                        <filename>bitbake</filename> command that results in the
+                        tarball
+                        <filename>poky/build/tmp/deploy/sdk/adt_installer.tar.bz2</filename>:
+                        <note>
+                            Before using BitBake to build the ADT tarball, be
+                            sure to make sure your
+                            <filename>local.conf</filename> file is properly
+                            configured.
+                        </note>
+                        <literallayout class='monospaced'>
+     $ cd ~
+     $ git clone git://git.yoctoproject.org/poky
+     $ cd poky
+     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+     $ source &OE_INIT_FILE;
+     $ bitbake adt-installer
+                        </literallayout></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='configuring-and-running-the-adt-installer-script'>
+            <title>Configuring and Running the ADT Installer Script</title>
+
+            <para>
+                Before running the ADT Installer script, you need to unpack the tarball.
+                You can unpack the tarball in any directory you wish.
+                For example, this command copies the ADT Installer tarball from where
+                it was built into the home directory and then unpacks the tarball into
+                a top-level directory named <filename>adt-installer</filename>:
+                <literallayout class='monospaced'>
+     $ cd ~
+     $ cp poky/build/tmp/deploy/sdk/adt_installer.tar.bz2 $HOME
+     $ tar -xjf adt_installer.tar.bz2
+                </literallayout>
+                Unpacking it creates the directory <filename>adt-installer</filename>,
+                which contains the ADT Installer script (<filename>adt_installer</filename>)
+                and its configuration file (<filename>adt_installer.conf</filename>).
+            </para>
+
+            <para>
+                Before you run the script, however, you should examine the ADT Installer configuration
+                file and be sure you are going to get what you want.
+                Your configurations determine which kernel and filesystem image are downloaded.
+            </para>
+
+            <para>
+                The following list describes the configurations you can define for the ADT Installer.
+                For configuration values and restrictions, see the comments in
+                the <filename>adt-installer.conf</filename> file:
+
+                <itemizedlist>
+                    <listitem><para><filename>YOCTOADT_REPO</filename>: This area
+                        includes the IPKG-based packages and the root filesystem upon which
+                        the installation is based.
+                        If you want to set up your own IPKG repository pointed to by
+                        <filename>YOCTOADT_REPO</filename>, you need to be sure that the
+                        directory structure follows the same layout as the reference directory
+                        set up at <ulink url='http://adtrepo.yoctoproject.org'></ulink>.
+                        Also, your repository needs to be accessible through HTTP.</para></listitem>
+                    <listitem><para><filename>YOCTOADT_TARGETS</filename>: The machine
+                        target architectures for which you want to set up cross-development
+                        environments.</para></listitem>
+                    <listitem><para><filename>YOCTOADT_QEMU</filename>: Indicates whether
+                        or not to install the emulator QEMU.</para></listitem>
+                    <listitem><para><filename>YOCTOADT_NFS_UTIL</filename>: Indicates whether
+                        or not to install user-mode NFS.
+                        If you plan to use the Eclipse IDE Yocto plug-in against QEMU,
+                        you should install NFS.
+                        <note>To boot QEMU images using our userspace NFS server, you need
+                            to be running <filename>portmap</filename> or <filename>rpcbind</filename>.
+                            If you are running <filename>rpcbind</filename>, you will also need to add the
+                            <filename>-i</filename> option when <filename>rpcbind</filename> starts up.
+                            Please make sure you understand the security implications of doing this.
+                            You might also have to modify your firewall settings to allow
+                            NFS booting to work.</note></para></listitem>
+                    <listitem><para><filename>YOCTOADT_ROOTFS_</filename><replaceable>arch</replaceable>: The root
+                        filesystem images you want to download from the
+                        <filename>YOCTOADT_IPKG_REPO</filename> repository.</para></listitem>
+                    <listitem><para><filename>YOCTOADT_TARGET_SYSROOT_IMAGE_</filename><replaceable>arch</replaceable>: The
+                        particular root filesystem used to extract and create the target sysroot.
+                        The value of this variable must have been specified with
+                        <filename>YOCTOADT_ROOTFS_</filename><replaceable>arch</replaceable>.
+                        For example, if you downloaded both <filename>minimal</filename> and
+                        <filename>sato-sdk</filename> images by setting
+                        <filename>YOCTOADT_ROOTFS_</filename><replaceable>arch</replaceable>
+                        to "minimal sato-sdk", then <filename>YOCTOADT_ROOTFS_</filename><replaceable>arch</replaceable>
+                        must be set to either "minimal" or "sato-sdk".
+                        </para></listitem>
+                    <listitem><para><filename>YOCTOADT_TARGET_SYSROOT_LOC_</filename><replaceable>arch</replaceable>: The
+                        location on the development host where the target sysroot is created.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                After you have configured the <filename>adt_installer.conf</filename> file,
+                run the installer using the following command:
+                <literallayout class='monospaced'>
+     $ cd adt-installer
+     $ ./adt_installer
+                </literallayout>
+                Once the installer begins to run, you are asked to enter the
+                location for cross-toolchain installation.
+                The default location is
+                <filename>/opt/poky/</filename><replaceable>release</replaceable>.
+                After either accepting the default location or selecting your
+                own location, you are prompted to run the installation script
+                interactively or in silent mode.
+                If you want to closely monitor the installation,
+                choose “I” for interactive mode rather than “S” for silent mode.
+                Follow the prompts from the script to complete the installation.
+            </para>
+
+            <para>
+                Once the installation completes, the ADT, which includes the
+                cross-toolchain, is installed in the selected installation
+                directory.
+                You will notice environment setup files for the cross-toolchain
+                in the installation directory, and image tarballs in the
+                <filename>adt-installer</filename> directory according to your
+                installer configurations, and the target sysroot located
+                according to the
+                <filename>YOCTOADT_TARGET_SYSROOT_LOC_</filename><replaceable>arch</replaceable>
+                variable also in your configuration file.
+            </para>
+         </section>
+    </section>
+
+    <section id='using-an-existing-toolchain-tarball'>
+        <title>Using a Cross-Toolchain Tarball</title>
+
+        <para>
+            If you want to simply install a cross-toolchain by hand, you can
+            do so by running the toolchain installer.
+            The installer includes the pre-built cross-toolchain, the
+            <filename>runqemu</filename> script, and support files.
+            If you use this method to install the cross-toolchain, you
+            might still need to install the target sysroot by installing and
+            extracting it separately.
+            For information on how to install the sysroot, see the
+            "<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>" section.
+        </para>
+
+        <para>
+            Follow these steps:
+            <orderedlist>
+                <listitem><para><emphasis>Get your toolchain installer using one of the following methods:</emphasis>
+                    <itemizedlist>
+                        <listitem><para>Go to
+                            <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>
+                            and find the folder that matches your host
+                            development system (i.e. <filename>i686</filename>
+                            for 32-bit machines or <filename>x86_64</filename>
+                            for 64-bit machines).</para>
+                            <para>Go into that folder and download the toolchain
+                            installer whose name includes the appropriate target
+                            architecture.
+                            The toolchains provided by the Yocto Project
+                            are based off of the
+                            <filename>core-image-sato</filename> image and
+                            contain libraries appropriate for developing
+                            against that image.
+                            For example, if your host development system is a
+                            64-bit x86 system and you are going to use
+                            your cross-toolchain for a 32-bit x86
+                            target, go into the <filename>x86_64</filename>
+                            folder and download the following installer:
+                            <literallayout class='monospaced'>
+     poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
+                            </literallayout></para></listitem>
+                        <listitem><para>Build your own toolchain installer.
+                            For cases where you cannot use an installer
+                            from the download area, you can build your own as
+                            described in the
+                            "<link linkend='optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</link>"
+                            section.</para></listitem>
+                    </itemizedlist></para></listitem>
+                <listitem><para><emphasis>Once you have the installer, run it to install the toolchain:</emphasis>
+                    <note>
+                        You must change the permissions on the toolchain
+                        installer script so that it is executable.
+                    </note></para>
+                    <para>The following command shows how to run the installer
+                    given a toolchain tarball for a 64-bit x86 development host
+                    system and a 32-bit x86 target architecture.
+                    The example assumes the toolchain installer is located
+                    in <filename>~/Downloads/</filename>.
+                    <literallayout class='monospaced'>
+     $ ~/Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
+                    </literallayout>
+                    The first thing the installer prompts you for is the
+                    directory into which you want to install the toolchain.
+                    The default directory used is
+                    <filename>/opt/poky/&DISTRO;</filename>.
+                    If you do not have write permissions for the directory
+                    into which you are installing the toolchain, the
+                    toolchain installer notifies you and exits.
+                    Be sure you have write permissions in the directory and
+                    run the installer again.</para>
+                    <para>When the script finishes, the cross-toolchain is
+                    installed.
+                    You will notice environment setup files for the
+                    cross-toolchain in the installation directory.
+                    </para></listitem>
+            </orderedlist>
+        </para>
+    </section>
+
+    <section id='using-the-toolchain-from-within-the-build-tree'>
+        <title>Using BitBake and the Build Directory</title>
+
+        <para>
+            A final way of making the cross-toolchain available is to use BitBake
+            to generate the toolchain within an existing
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+            This method does not install the toolchain into the default
+            <filename>/opt</filename> directory.
+            As with the previous method, if you need to install the target sysroot, you must
+            do that separately as well.
+        </para>
+
+        <para>
+            Follow these steps to generate the toolchain into the Build Directory:
+            <orderedlist>
+                <listitem><para><emphasis>Set up the Build Environment:</emphasis>
+                    Source the OpenEmbedded build environment setup
+                    script (i.e.
+                    <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                    or
+                    <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>)
+                    located in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    </para></listitem>
+                <listitem><para><emphasis>Check your Local Configuration File:</emphasis>
+                    At this point, you should be sure that the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink> variable
+                    in the <filename>local.conf</filename> file found in the
+                    <filename>conf</filename> directory of the Build Directory
+                    is set for the target architecture.
+                    Comments within the <filename>local.conf</filename> file
+                    list the values you can use for the
+                    <filename>MACHINE</filename> variable.
+                    <note>
+                        You can populate the Build Directory with the
+                        cross-toolchains for more than a single architecture.
+                        You just need to edit the <filename>MACHINE</filename>
+                        variable in the <filename>local.conf</filename> file and
+                        re-run the <filename>bitbake</filename> command.
+                    </note></para></listitem>
+                <listitem><para><emphasis>Generate the Cross-Toolchain:</emphasis>
+                    Run <filename>bitbake meta-ide-support</filename> to
+                    complete the cross-toolchain generation.
+                    Once the <filename>bitbake</filename> command finishes,
+                    the cross-toolchain is
+                    generated and populated within the Build Directory.
+                    You will notice environment setup files for the
+                    cross-toolchain that contain the string
+                    "<filename>environment-setup</filename>" in the
+                    Build Directory's <filename>tmp</filename> folder.</para>
+                    <para>Be aware that when you use this method to install the
+                    toolchain, you still need to separately extract and install
+                    the sysroot filesystem.
+                    For information on how to do this, see the
+                    "<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>" section.
+                    </para></listitem>
+            </orderedlist>
+        </para>
+    </section>
+</section>
+
+<section id='setting-up-the-cross-development-environment'>
+    <title>Setting Up the Cross-Development Environment</title>
+
+    <para>
+        Before you can develop using the cross-toolchain, you need to set up the
+        cross-development environment by sourcing the toolchain's environment setup script.
+        If you used the ADT Installer or hand-installed cross-toolchain,
+        then you can find this script in the directory you chose for installation.
+        For this release, the default installation directory is
+        <filename>&YOCTO_ADTPATH_DIR;</filename>.
+        If you installed the toolchain in the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
+        you can find the environment setup
+        script for the toolchain in the Build Directory's <filename>tmp</filename> directory.
+    </para>
+
+    <para>
+        Be sure to run the environment setup script that matches the
+        architecture for which you are developing.
+        Environment setup scripts begin with the string
+        "<filename>environment-setup</filename>" and include as part of their
+        name the architecture.
+        For example, the toolchain environment setup script for a 64-bit
+        IA-based architecture installed in the default installation directory
+        would be the following:
+        <literallayout class='monospaced'>
+     &YOCTO_ADTPATH_DIR;/environment-setup-x86_64-poky-linux
+        </literallayout>
+    </para>
+</section>
+
+<section id='securing-kernel-and-filesystem-images'>
+    <title>Securing Kernel and Filesystem Images</title>
+
+    <para>
+        You will need to have a kernel and filesystem image to boot using your
+        hardware or the QEMU emulator.
+        Furthermore, if you plan on booting your image using NFS or you want to use the root filesystem
+        as the target sysroot, you need to extract the root filesystem.
+    </para>
+
+    <section id='getting-the-images'>
+        <title>Getting the Images</title>
+
+        <para>
+            To get the kernel and filesystem images, you either have to build them or download
+            pre-built versions.
+            You can find examples for both these situations in the
+            "<ulink url='&YOCTO_DOCS_QS_URL;#test-run'>A Quick Test Run</ulink>" section of
+            the Yocto Project Quick Start.
+        </para>
+
+        <para>
+            The Yocto Project ships basic kernel and filesystem images for several
+            architectures (<filename>x86</filename>, <filename>x86-64</filename>,
+            <filename>mips</filename>, <filename>powerpc</filename>, and <filename>arm</filename>)
+            that you can use unaltered in the QEMU emulator.
+            These kernel images reside in the release
+            area - <ulink url='&YOCTO_MACHINES_DL_URL;'></ulink>
+            and are ideal for experimentation using Yocto Project.
+            For information on the image types you can build using the OpenEmbedded build system,
+            see the
+            "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter in
+            the Yocto Project Reference Manual.
+        </para>
+
+        <para>
+            If you are planning on developing against your image and you are not
+            building or using one of the Yocto Project development images
+            (e.g. <filename>core-image-*-dev</filename>), you must be sure to
+            include the development packages as part of your image recipe.
+        </para>
+
+        <para>
+            Furthermore, if you plan on remotely deploying and debugging your
+            application from within the
+            Eclipse IDE, you must have an image that contains the Yocto Target Communication
+            Framework (TCF) agent (<filename>tcf-agent</filename>).
+            By default, the Yocto Project provides only one type of pre-built
+            image that contains the <filename>tcf-agent</filename>.
+            And, those images are SDK (e.g.<filename>core-image-sato-sdk</filename>).
+        </para>
+
+        <para>
+            If you want to use a different image type that contains the <filename>tcf-agent</filename>,
+            you can do so one of two ways:
+            <itemizedlist>
+                <listitem><para>Modify the <filename>conf/local.conf</filename> configuration in
+                    the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                    and then rebuild the image.
+                    With this method, you need to modify the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGE_FEATURES'><filename>EXTRA_IMAGE_FEATURES</filename></ulink>
+                    variable to have the value of "tools-debug" before rebuilding the image.
+                    Once the image is rebuilt, the <filename>tcf-agent</filename> will be included
+                    in the image and is launched automatically after the boot.</para></listitem>
+                <listitem><para>Manually build the <filename>tcf-agent</filename>.
+                    To build the agent, follow these steps:
+                    <orderedlist>
+                        <listitem><para>Be sure the ADT is installed as described in the
+                            "<link linkend='installing-the-adt'>Installing the ADT and Toolchains</link>" section.
+                            </para></listitem>
+                        <listitem><para>Set up the cross-development environment as described in the
+                            "<link linkend='setting-up-the-cross-development-environment'>Setting
+                            Up the Cross-Development Environment</link>" section.</para></listitem>
+                        <listitem><para>Get the <filename>tcf-agent</filename> source code using
+                            the following commands:
+                            <literallayout class='monospaced'>
+     $ git clone http://git.eclipse.org/gitroot/tcf/org.eclipse.tcf.agent.git
+     $ cd org.eclipse.tcf.agent/agent
+                            </literallayout></para></listitem>
+                        <listitem><para>Locate the
+                            <filename>Makefile.inc</filename> file inside the
+                            <filename>agent</filename> folder and modify it
+                            for the cross-compilation environment by setting the
+                            <filename>OPSYS</filename> and
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
+                            variables according to your target.
+                            </para></listitem>
+                        <listitem><para>Use the cross-development tools to build the
+                            <filename>tcf-agent</filename>.
+                            Before you "Make" the file, be sure your cross-tools are set up first.
+                            See the "<link linkend='makefile-based-projects'>Makefile-Based Projects</link>"
+                            section for information on how to make sure the cross-tools are set up
+                            correctly.</para>
+                            <para>If the build is successful, the <filename>tcf-agent</filename> output will
+                            be <filename>obj/$(OPSYS)/$(MACHINE)/Debug/agent</filename>.</para></listitem>
+                        <listitem><para>Deploy the agent into the image's root filesystem.</para></listitem>
+                    </orderedlist>
+                </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='extracting-the-root-filesystem'>
+        <title>Extracting the Root Filesystem</title>
+
+        <para>
+            If you install your toolchain by hand or build it using BitBake and
+            you need a root filesystem, you need to extract it separately.
+            If you use the ADT Installer to install the ADT, the root
+            filesystem is automatically extracted and installed.
+        </para>
+
+        <para>
+            Here are some cases where you need to extract the root filesystem:
+            <itemizedlist>
+                <listitem><para>You want to boot the image using NFS.
+                    </para></listitem>
+                <listitem><para>You want to use the root filesystem as the
+                    target sysroot.
+                    For example, the Eclipse IDE environment with the Eclipse
+                    Yocto Plug-in installed allows you to use QEMU to boot
+                    under NFS.</para></listitem>
+                <listitem><para>You want to develop your target application
+                    using the root filesystem as the target sysroot.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            To extract the root filesystem, first <filename>source</filename>
+            the cross-development environment setup script.
+            If you built the toolchain in the Build Directory, you will find
+            the toolchain environment script in the
+            <filename>tmp</filename> directory.
+            If you installed the toolchain by hand, the environment setup
+            script is located in <filename>/opt/poky/&DISTRO;</filename>.
+        </para>
+
+        <para>
+            After sourcing the environment script, use the
+            <filename>runqemu-extract-sdk</filename> command and provide the
+            filesystem image.
+        </para>
+
+        <para>
+            Following is an example.
+            The second command sets up the environment.
+            In this case, the setup script is located in the
+            <filename>/opt/poky/&DISTRO;</filename> directory.
+            The third command extracts the root filesystem from a previously
+            built filesystem that is located in the
+            <filename>~/Downloads</filename> directory.
+            Furthermore, this command extracts the root filesystem into the
+            <filename>qemux86-sato</filename> directory:
+            <literallayout class='monospaced'>
+     $ cd ~
+     $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
+     $ runqemu-extract-sdk \
+        ~/Downloads/core-image-sato-sdk-qemux86-2011091411831.rootfs.tar.bz2 \
+        $HOME/qemux86-sato
+            </literallayout>
+            You could now point to the target sysroot at
+            <filename>qemux86-sato</filename>.
+        </para>
+    </section>
+</section>
+
+<section id='optionally-building-a-toolchain-installer'>
+    <title>Optionally Building a Toolchain Installer</title>
+
+    <para>
+        As an alternative to locating and downloading a toolchain installer,
+        you can build the toolchain installer one of two ways if you have a
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
+        <itemizedlist>
+            <listitem><para>
+                Use <filename>bitbake meta-toolchain</filename>.
+                This method requires you to still install the target
+                sysroot by installing and extracting it separately.
+                For information on how to install the sysroot, see the
+                "<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>"
+                section.
+                </para></listitem>
+            <listitem><para>
+                Use <filename>bitbake</filename> <replaceable>image</replaceable> <filename>-c populate_sdk</filename>.
+                This method has significant advantages over the previous method
+                because it results in a toolchain installer that contains the
+                sysroot that matches your target root filesystem.
+                </para>
+
+                <para>Another powerful feature is that the toolchain is
+                completely self-contained.
+                The binaries are linked against their own copy of
+                <filename>libc</filename>, which results in no dependencies
+                on the target system.
+                To achieve this, the pointer to the dynamic loader is
+                configured at install time since that path cannot be dynamically
+                altered.
+                This is the reason for a wrapper around the
+                <filename>populate_sdk</filename> archive.</para>
+
+                <para>Another feature is that only one set of cross-canadian
+                toolchain binaries are produced per architecture.
+                This feature takes advantage of the fact that the target
+                hardware can be passed to <filename>gcc</filename> as a set of
+                compiler options.
+                Those options are set up by the environment script and
+                contained in variables like CC and LD.
+                This reduces the space needed for the tools.
+                Understand, however, that a sysroot is still needed for every
+                target since those binaries are target-specific.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+         Remember, before using any BitBake command, you
+         must source the build environment setup script
+         (i.e.
+         <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+         or
+         <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>)
+         located in the Source Directory and you must make sure your
+         <filename>conf/local.conf</filename> variables are correct.
+         In particular, you need to be sure the
+         <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
+         variable matches the architecture for which you are building and that
+         the
+         <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKMACHINE'><filename>SDKMACHINE</filename></ulink>
+         variable is correctly set if you are building a toolchain designed to
+         run on an architecture that differs from your current development host
+         machine (i.e. the build machine).
+    </para>
+
+    <para>
+        When the <filename>bitbake</filename> command completes, the toolchain
+        installer will be in
+        <filename>tmp/deploy/sdk</filename> in the Build Directory.
+        <note>
+            By default, this toolchain does not build static binaries.
+            If you want to use the toolchain to build these types of libraries,
+            you need to be sure your image has the appropriate static
+            development libraries.
+            Use the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></ulink>
+            variable inside your <filename>local.conf</filename> file to
+            install the appropriate library packages.
+            Following is an example using <filename>glibc</filename> static
+            development libraries:
+            <literallayout class='monospaced'>
+     IMAGE_INSTALL_append = " glibc-staticdev"
+            </literallayout>
+        </note>
+    </para>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/adt-manual/adt-style.css b/documentation/adt-manual/adt-style.css
new file mode 100644
index 0000000000..d722ad4b7f
--- /dev/null
+++ b/documentation/adt-manual/adt-style.css
@@ -0,0 +1,984 @@
+/*
+   Generic XHTML / DocBook XHTML CSS Stylesheet.
+
+   Browser wrangling and typographic design by
+      Oyvind Kolas / pippin@gimp.org
+
+   Customised for Poky by
+      Matthew Allum / mallum@o-hand.com
+
+   Thanks to:
+     Liam R. E. Quin
+     William Skaggs
+     Jakub Steiner
+
+   Structure
+   ---------
+
+   The stylesheet is divided into the following sections:
+
+       Positioning
+          Margins, paddings, width, font-size, clearing.
+       Decorations
+          Borders, style
+       Colors
+          Colors
+       Graphics
+          Graphical backgrounds
+       Nasty IE tweaks
+          Workarounds needed to make it work in internet explorer,
+          currently makes the stylesheet non validating, but up until
+          this point it is validating.
+       Mozilla extensions
+          Transparency for footer
+          Rounded corners on boxes
+
+*/
+
+
+  /*************** /
+ /  Positioning   /
+/ ***************/
+
+body {
+  font-family: Verdana, Sans, sans-serif;
+
+  min-width: 640px;
+  width: 80%;
+  margin:  0em auto;
+  padding: 2em 5em 5em 5em;
+  color: #333;
+}
+
+h1,h2,h3,h4,h5,h6,h7 {
+  font-family: Arial, Sans;
+  color: #00557D;
+  clear: both;
+}
+
+h1 {
+  font-size: 2em;
+  text-align: left;
+  padding: 0em 0em 0em 0em;
+  margin: 2em 0em 0em 0em;
+}
+
+h2.subtitle {
+  margin: 0.10em 0em 3.0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 1.8em;
+  padding-left: 20%;
+  font-weight: normal;
+  font-style: italic;
+}
+
+h2 {
+  margin: 2em 0em 0.66em 0em;
+  padding: 0.5em 0em 0em 0em;
+  font-size: 1.5em;
+  font-weight: bold;
+}
+
+h3.subtitle {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 142.14%;
+  text-align: right;
+}
+
+h3 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 140%;
+  font-weight: bold;
+}
+
+h4 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 120%;
+  font-weight: bold;
+}
+
+h5 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+h6 {
+  margin: 1em 0em 0em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+.authorgroup {
+  background-color: transparent;
+  background-repeat: no-repeat;
+  padding-top: 256px;
+  background-image: url("figures/adt-title.png");
+  background-position: left top;
+  margin-top: -256px;
+  padding-right: 50px;
+  margin-left: 0px;
+  text-align: right;
+  width: 740px;
+}
+
+h3.author {
+  margin: 0em 0me 0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-weight: normal;
+  font-size: 100%;
+  color: #333;
+  clear: both;
+}
+
+.author tt.email {
+  font-size: 66%;
+}
+
+.titlepage hr {
+  width: 0em;
+  clear: both;
+}
+
+.revhistory {
+  padding-top: 2em;
+  clear: both;
+}
+
+.toc,
+.list-of-tables,
+.list-of-examples,
+.list-of-figures {
+  padding: 1.33em 0em 2.5em 0em;
+  color: #00557D;
+}
+
+.toc p,
+.list-of-tables p,
+.list-of-figures p,
+.list-of-examples p {
+  padding: 0em 0em 0em 0em;
+  padding: 0em 0em 0.3em;
+  margin: 1.5em 0em 0em 0em;
+}
+
+.toc p b,
+.list-of-tables p b,
+.list-of-figures p b,
+.list-of-examples p b{
+  font-size: 100.0%;
+  font-weight: bold;
+}
+
+.toc dl,
+.list-of-tables dl,
+.list-of-figures dl,
+.list-of-examples dl {
+  margin: 0em 0em 0.5em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dt {
+  margin: 0em 0em 0em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dd {
+  margin: 0em 0em 0em 2.6em;
+  padding: 0em 0em 0em 0em;
+}
+
+div.glossary dl,
+div.variablelist dl {
+}
+
+.glossary dl dt,
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  font-weight: normal;
+  width: 20em;
+  text-align: right;
+}
+
+.variablelist dl dt {
+  margin-top: 0.5em;
+}
+
+.glossary dl dd,
+.variablelist dl dd {
+  margin-top: -1em;
+  margin-left: 25.5em;
+}
+
+.glossary dd p,
+.variablelist dd p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+
+div.calloutlist table td {
+  padding: 0em 0em 0em 0em;
+  margin: 0em 0em 0em 0em;
+}
+
+div.calloutlist table td p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+div p.copyright {
+  text-align: left;
+}
+
+div.legalnotice p.legalnotice-title {
+  margin-bottom: 0em;
+}
+
+p {
+  line-height: 1.5em;
+  margin-top: 0em;
+
+}
+
+dl {
+  padding-top: 0em;
+}
+
+hr {
+  border: solid 1px;
+}
+
+
+.mediaobject,
+.mediaobjectco {
+  text-align: center;
+}
+
+img {
+  border: none;
+}
+
+ul {
+  padding: 0em 0em 0em 1.5em;
+}
+
+ul li {
+  padding: 0em 0em 0em 0em;
+}
+
+ul li p {
+  text-align: left;
+}
+
+table {
+  width :100%;
+}
+
+th {
+  padding: 0.25em;
+  text-align: left;
+  font-weight: normal;
+  vertical-align: top;
+}
+
+td {
+  padding: 0.25em;
+  vertical-align: top;
+}
+
+p a[id] {
+  margin: 0px;
+  padding: 0px;
+  display: inline;
+  background-image: none;
+}
+
+a {
+  text-decoration: underline;
+  color: #444;
+}
+
+pre {
+    overflow: auto;
+}
+
+a:hover {
+  text-decoration: underline;
+  /*font-weight: bold;*/
+}
+
+/* This style defines how the permalink character
+   appears by itself and when hovered over with
+   the mouse. */
+
+[alt='Permalink'] { color: #eee; }
+[alt='Permalink']:hover { color: black; }
+
+
+div.informalfigure,
+div.informalexample,
+div.informaltable,
+div.figure,
+div.table,
+div.example {
+  margin: 1em 0em;
+  padding: 1em;
+  page-break-inside: avoid;
+}
+
+
+div.informalfigure p.title b,
+div.informalexample p.title b,
+div.informaltable p.title b,
+div.figure p.title b,
+div.example p.title b,
+div.table p.title b{
+    padding-top: 0em;
+    margin-top: 0em;
+    font-size: 100%;
+    font-weight: normal;
+}
+
+.mediaobject .caption,
+.mediaobject .caption p  {
+  text-align: center;
+  font-size: 80%;
+  padding-top: 0.5em;
+  padding-bottom: 0.5em;
+}
+
+.epigraph {
+  padding-left: 55%;
+  margin-bottom: 1em;
+}
+
+.epigraph p {
+  text-align: left;
+}
+
+.epigraph .quote {
+  font-style: italic;
+}
+.epigraph .attribution {
+  font-style: normal;
+  text-align: right;
+}
+
+span.application {
+  font-style: italic;
+}
+
+.programlisting {
+  font-family: monospace;
+  font-size: 80%;
+  white-space: pre;
+  margin: 1.33em 0em;
+  padding: 1.33em;
+}
+
+.tip,
+.warning,
+.caution,
+.note {
+  margin-top: 1em;
+  margin-bottom: 1em;
+
+}
+
+/* force full width of table within div */
+.tip table,
+.warning table,
+.caution table,
+.note table {
+  border: none;
+  width: 100%;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  padding: 0.8em 0.0em 0.0em 0.0em;
+  margin : 0em 0em 0em 0em;
+}
+
+.tip p,
+.warning p,
+.caution p,
+.note p {
+  margin-top: 0.5em;
+  margin-bottom: 0.5em;
+  padding-right: 1em;
+  text-align: left;
+}
+
+.acronym {
+  text-transform: uppercase;
+}
+
+b.keycap,
+.keycap {
+  padding: 0.09em 0.3em;
+  margin: 0em;
+}
+
+.itemizedlist li {
+  clear: none;
+}
+
+.filename {
+  font-size: medium;
+  font-family: Courier, monospace;
+}
+
+
+div.navheader, div.heading{
+  position: absolute;
+  left: 0em;
+  top: 0em;
+  width: 100%;
+  background-color: #cdf;
+  width: 100%;
+}
+
+div.navfooter, div.footing{
+  position: fixed;
+  left: 0em;
+  bottom: 0em;
+  background-color: #eee;
+  width: 100%;
+}
+
+
+div.navheader td,
+div.navfooter td {
+  font-size: 66%;
+}
+
+div.navheader table th {
+  /*font-family: Georgia, Times, serif;*/
+  /*font-size: x-large;*/
+  font-size: 80%;
+}
+
+div.navheader table {
+  border-left: 0em;
+  border-right: 0em;
+  border-top: 0em;
+  width: 100%;
+}
+
+div.navfooter table {
+  border-left: 0em;
+  border-right: 0em;
+  border-bottom: 0em;
+  width: 100%;
+}
+
+div.navheader table td a,
+div.navfooter table td a {
+  color: #777;
+  text-decoration: none;
+}
+
+/* normal text in the footer */
+div.navfooter table td {
+  color: black;
+}
+
+div.navheader table td a:visited,
+div.navfooter table td a:visited {
+  color: #444;
+}
+
+
+/* links in header and footer */
+div.navheader table td a:hover,
+div.navfooter table td a:hover {
+  text-decoration: underline;
+  background-color: transparent;
+  color: #33a;
+}
+
+div.navheader hr,
+div.navfooter hr {
+  display: none;
+}
+
+
+.qandaset tr.question td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.qandaset tr.answer td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+.answer td {
+  padding-bottom: 1.5em;
+}
+
+.emphasis {
+  font-weight: bold;
+}
+
+
+  /************* /
+ / decorations  /
+/ *************/
+
+.titlepage {
+}
+
+.part .title {
+}
+
+.subtitle {
+    border: none;
+}
+
+/*
+h1 {
+  border: none;
+}
+
+h2 {
+  border-top: solid 0.2em;
+  border-bottom: solid 0.06em;
+}
+
+h3 {
+  border-top: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h4 {
+  border: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h5 {
+  border: 0em;
+}
+*/
+
+.programlisting {
+  border: solid 1px;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example {
+  border: 1px solid;
+}
+
+
+
+.tip,
+.warning,
+.caution,
+.note {
+  border: 1px solid;
+}
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom: 1px solid;
+}
+
+.question td {
+  border-top: 1px solid black;
+}
+
+.answer {
+}
+
+
+b.keycap,
+.keycap {
+  border: 1px solid;
+}
+
+
+div.navheader, div.heading{
+  border-bottom: 1px solid;
+}
+
+
+div.navfooter, div.footing{
+  border-top: 1px solid;
+}
+
+  /********* /
+ /  colors  /
+/ *********/
+
+body {
+  color: #333;
+  background: white;
+}
+
+a {
+  background: transparent;
+}
+
+a:hover {
+  background-color: #dedede;
+}
+
+
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7,
+h8 {
+  background-color: transparent;
+}
+
+hr {
+  border-color: #aaa;
+}
+
+
+.tip, .warning, .caution, .note {
+  border-color: #fff;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom-color: #fff;
+}
+
+
+.warning {
+  background-color: #f0f0f2;
+}
+
+.caution {
+  background-color: #f0f0f2;
+}
+
+.tip {
+  background-color: #f0f0f2;
+}
+
+.note {
+  background-color: #f0f0f2;
+}
+
+.glossary dl dt,
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  color: #044;
+}
+
+div.figure,
+div.table,
+div.example,
+div.informalfigure,
+div.informaltable,
+div.informalexample {
+  border-color: #aaa;
+}
+
+pre.programlisting {
+  color: black;
+  background-color: #fff;
+  border-color: #aaa;
+  border-width: 2px;
+}
+
+.guimenu,
+.guilabel,
+.guimenuitem {
+  background-color: #eee;
+}
+
+
+b.keycap,
+.keycap {
+  background-color: #eee;
+  border-color: #999;
+}
+
+
+div.navheader {
+  border-color: black;
+}
+
+
+div.navfooter {
+  border-color: black;
+}
+
+
+  /*********** /
+ /  graphics  /
+/ ***********/
+
+/*
+body {
+  background-image: url("images/body_bg.jpg");
+  background-attachment: fixed;
+}
+
+.navheader,
+.note,
+.tip {
+  background-image: url("images/note_bg.jpg");
+  background-attachment: fixed;
+}
+
+.warning,
+.caution {
+  background-image: url("images/warning_bg.jpg");
+  background-attachment: fixed;
+}
+
+.figure,
+.informalfigure,
+.example,
+.informalexample,
+.table,
+.informaltable {
+  background-image: url("images/figure_bg.jpg");
+  background-attachment: fixed;
+}
+
+*/
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7{
+}
+
+/*
+Example of how to stick an image as part of the title.
+
+div.article .titlepage .title
+{
+  background-image: url("figures/white-on-black.png");
+  background-position: center;
+  background-repeat: repeat-x;
+}
+*/
+
+div.preface .titlepage .title,
+div.colophon .title,
+div.chapter .titlepage .title,
+div.article .titlepage .title
+{
+}
+
+div.section div.section .titlepage .title,
+div.sect2 .titlepage .title {
+    background: none;
+}
+
+
+h1.title {
+  background-color: transparent;
+  background-repeat: no-repeat;
+  height: 256px;
+  text-indent: -9000px;
+  overflow:hidden;
+}
+
+h2.subtitle {
+  background-color: transparent;
+  text-indent: -9000px;
+  overflow:hidden;
+  width: 0px;
+  display: none;
+}
+
+  /*************************************** /
+ /  pippin.gimp.org specific alterations  /
+/ ***************************************/
+
+/*
+div.heading, div.navheader {
+  color: #777;
+  font-size: 80%;
+  padding: 0;
+  margin: 0;
+  text-align: left;
+  position: absolute;
+  top: 0px;
+  left: 0px;
+  width: 100%;
+  height: 50px;
+  background: url('/gfx/heading_bg.png') transparent;
+  background-repeat: repeat-x;
+  background-attachment: fixed;
+  border: none;
+}
+
+div.heading a {
+  color: #444;
+}
+
+div.footing, div.navfooter {
+  border: none;
+  color: #ddd;
+  font-size: 80%;
+  text-align:right;
+
+  width: 100%;
+  padding-top: 10px;
+  position: absolute;
+  bottom: 0px;
+  left: 0px;
+
+  background: url('/gfx/footing_bg.png') transparent;
+}
+*/
+
+
+
+  /****************** /
+ /  nasty ie tweaks  /
+/ ******************/
+
+/*
+div.heading, div.navheader {
+  width:expression(document.body.clientWidth + "px");
+}
+
+div.footing, div.navfooter {
+  width:expression(document.body.clientWidth + "px");
+  margin-left:expression("-5em");
+}
+body {
+  padding:expression("4em 5em 0em 5em");
+}
+*/
+
+  /**************************************** /
+ / mozilla vendor specific css extensions  /
+/ ****************************************/
+/*
+div.navfooter, div.footing{
+  -moz-opacity: 0.8em;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example,
+.tip,
+.warning,
+.caution,
+.note {
+  -moz-border-radius: 0.5em;
+}
+
+b.keycap,
+.keycap {
+  -moz-border-radius: 0.3em;
+}
+*/
+
+table tr td table tr td {
+  display: none;
+}
+
+
+hr {
+  display: none;
+}
+
+table {
+  border: 0em;
+}
+
+ .photo {
+  float: right;
+  margin-left:   1.5em;
+  margin-bottom: 1.5em;
+  margin-top: 0em;
+  max-width:      17em;
+  border:     1px solid gray;
+  padding:    3px;
+  background: white;
+}
+ .seperator {
+   padding-top: 2em;
+   clear: both;
+  }
+
+  #validators {
+      margin-top: 5em;
+      text-align: right;
+      color: #777;
+  }
+  @media print {
+      body {
+          font-size: 8pt;
+      }
+      .noprint {
+          display: none;
+      }
+  }
+
+
+.tip,
+.note {
+   background: #f0f0f2;
+   color: #333;
+   padding: 20px;
+   margin: 20px;
+}
+
+.tip h3,
+.note h3 {
+   padding: 0em;
+   margin: 0em;
+   font-size: 2em;
+   font-weight: bold;
+   color: #333;
+}
+
+.tip a,
+.note a {
+   color: #333;
+   text-decoration: underline;
+}
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
diff --git a/documentation/adt-manual/figures/adt-title.png b/documentation/adt-manual/figures/adt-title.png
new file mode 100644
index 0000000000..6e71e41f1a
--- /dev/null
+++ b/documentation/adt-manual/figures/adt-title.png
diff --git a/documentation/bsp-guide/bsp-guide-customization.xsl b/documentation/bsp-guide/bsp-guide-customization.xsl
new file mode 100644
index 0000000000..3da37be06f
--- /dev/null
+++ b/documentation/bsp-guide/bsp-guide-customization.xsl
@@ -0,0 +1,19 @@
+<?xml version='1.0'?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
+
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
+
+  <xsl:include href="../template/permalinks.xsl"/>
+  <xsl:include href="../template/section.title.xsl"/>
+  <xsl:include href="../template/component.title.xsl"/>
+  <xsl:include href="../template/division.title.xsl"/>
+  <xsl:include href="../template/formal.object.heading.xsl"/>
+
+  <xsl:param name="html.stylesheet" select="'bsp-style.css'" />
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="appendix.autolabel" select="A" />
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+  <xsl:param name="generate.id.attributes" select="1" />
+
+</xsl:stylesheet>
diff --git a/documentation/bsp-guide/bsp-guide-eclipse-customization.xsl b/documentation/bsp-guide/bsp-guide-eclipse-customization.xsl
new file mode 100644
index 0000000000..1c80bee1cf
--- /dev/null
+++ b/documentation/bsp-guide/bsp-guide-eclipse-customization.xsl
@@ -0,0 +1,27 @@
+<?xml version='1.0'?>
+<xsl:stylesheet
+        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+        xmlns="http://www.w3.org/1999/xhtml"
+        xmlns:fo="http://www.w3.org/1999/XSL/Format"
+        version="1.0">
+
+  <xsl:import
+          href="http://docbook.sourceforge.net/release/xsl/current/eclipse/eclipse3.xsl" />
+
+  <xsl:param name="chunker.output.indent" select="'yes'"/>
+  <xsl:param name="chunk.quietly" select="1"/>
+  <xsl:param name="chunk.first.sections" select="1"/>
+  <xsl:param name="chunk.section.depth" select="10"/>
+  <xsl:param name="use.id.as.filename" select="1"/>
+  <xsl:param name="ulink.target" select="'_self'" />
+  <xsl:param name="base.dir" select="'html/bsp-guide/'"/>
+  <xsl:param name="html.stylesheet" select="'../book.css'"/>
+  <xsl:param name="eclipse.manifest" select="0"/>
+  <xsl:param name="create.plugin.xml" select="0"/>
+  <xsl:param name="suppress.navigation" select="1"/>
+  <xsl:param name="generate.index" select="0"/>
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="appendix.autolabel" select="1" />
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+</xsl:stylesheet>
diff --git a/documentation/bsp-guide/bsp-guide.xml b/documentation/bsp-guide/bsp-guide.xml
new file mode 100644
index 0000000000..637a51211a
--- /dev/null
+++ b/documentation/bsp-guide/bsp-guide.xml
@@ -0,0 +1,138 @@
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<book id='bsp-guide' lang='en'
+      xmlns:xi="http://www.w3.org/2003/XInclude"
+      xmlns="http://docbook.org/ns/docbook"
+      >
+    <bookinfo>
+
+        <mediaobject>
+            <imageobject>
+                <imagedata fileref='figures/bsp-title.png'
+                    format='SVG'
+                    align='center' scalefit='1' width='100%'/>
+            </imageobject>
+        </mediaobject>
+
+        <title>
+            Yocto Project Board Support Package Developer's Guide
+        </title>
+
+        <authorgroup>
+            <author>
+                <firstname>Tom</firstname> <surname>Zanussi</surname>
+                <affiliation>
+                    <orgname>Intel Corporation</orgname>
+                </affiliation>
+                <email>tom.zanussi@intel.com</email>
+            </author>
+            <author>
+                <firstname>Richard</firstname> <surname>Purdie</surname>
+                <affiliation>
+                    <orgname>Linux Foundation</orgname>
+                </affiliation>
+                <email>richard.purdie@linuxfoundation.org</email>
+            </author>
+        </authorgroup>
+
+        <revhistory>
+            <revision>
+                <revnumber>0.9</revnumber>
+                <date>24 November 2010</date>
+                <revremark>The initial document draft released with the Yocto Project 0.9 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.0</revnumber>
+                <date>6 April 2011</date>
+                <revremark>Released with the Yocto Project 1.0 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.0.1</revnumber>
+                <date>23 May 2011</date>
+                <revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.1</revnumber>
+                <date>6 October 2011</date>
+                <revremark>Released with the Yocto Project 1.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.2</revnumber>
+                <date>April 2012</date>
+                <revremark>Released with the Yocto Project 1.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.3</revnumber>
+                <date>October 2012</date>
+                <revremark>Released with the Yocto Project 1.3 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4</revnumber>
+                <date>April 2013</date>
+                <revremark>Released with the Yocto Project 1.4 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5</revnumber>
+                <date>October 2013</date>
+                <revremark>Released with the Yocto Project 1.5 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.1</revnumber>
+                <date>January 2014</date>
+                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.6</revnumber>
+                <date>April 2014</date>
+                <revremark>Released with the Yocto Project 1.6 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7</revnumber>
+                <date>October 2014</date>
+                <revremark>Released with the Yocto Project 1.7 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.1</revnumber>
+                <date>January 2015</date>
+                <revremark>Released with the Yocto Project 1.7.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.2</revnumber>
+                <date>June 2015</date>
+                <revremark>Released with the Yocto Project 1.7.2 Release.</revremark>
+            </revision>
+        </revhistory>
+
+    <copyright>
+      <year>&COPYRIGHT_YEAR;</year>
+      <holder>Linux Foundation</holder>
+    </copyright>
+
+    <legalnotice>
+      <para>
+        Permission is granted to copy, distribute and/or modify this document under
+        the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-nc-sa/2.0/uk/">Creative Commons Attribution-Non-Commercial-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
+      </para>
+      <note>
+          For the latest version of this manual associated with this
+          Yocto Project release, see the
+          <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>
+          from the Yocto Project website.
+      </note>
+    </legalnotice>
+
+    </bookinfo>
+
+    <xi:include href="bsp.xml"/>
+
+<!--    <index id='index'>
+      <title>Index</title>
+    </index>
+-->
+
+</book>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/bsp-guide/bsp-style.css b/documentation/bsp-guide/bsp-style.css
new file mode 100644
index 0000000000..e407ca4a72
--- /dev/null
+++ b/documentation/bsp-guide/bsp-style.css
@@ -0,0 +1,984 @@
+/*
+   Generic XHTML / DocBook XHTML CSS Stylesheet.
+
+   Browser wrangling and typographic design by
+      Oyvind Kolas / pippin@gimp.org
+
+   Customised for Poky by
+      Matthew Allum / mallum@o-hand.com
+
+   Thanks to:
+     Liam R. E. Quin
+     William Skaggs
+     Jakub Steiner
+
+   Structure
+   ---------
+
+   The stylesheet is divided into the following sections:
+
+       Positioning
+          Margins, paddings, width, font-size, clearing.
+       Decorations
+          Borders, style
+       Colors
+          Colors
+       Graphics
+          Graphical backgrounds
+       Nasty IE tweaks
+          Workarounds needed to make it work in internet explorer,
+          currently makes the stylesheet non validating, but up until
+          this point it is validating.
+       Mozilla extensions
+          Transparency for footer
+          Rounded corners on boxes
+
+*/
+
+
+  /*************** /
+ /  Positioning   /
+/ ***************/
+
+body {
+  font-family: Verdana, Sans, sans-serif;
+
+  min-width: 640px;
+  width: 80%;
+  margin:  0em auto;
+  padding: 2em 5em 5em 5em;
+  color: #333;
+}
+
+h1,h2,h3,h4,h5,h6,h7 {
+  font-family: Arial, Sans;
+  color: #00557D;
+  clear: both;
+}
+
+h1 {
+  font-size: 2em;
+  text-align: left;
+  padding: 0em 0em 0em 0em;
+  margin: 2em 0em 0em 0em;
+}
+
+h2.subtitle {
+  margin: 0.10em 0em 3.0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 1.8em;
+  padding-left: 20%;
+  font-weight: normal;
+  font-style: italic;
+}
+
+h2 {
+  margin: 2em 0em 0.66em 0em;
+  padding: 0.5em 0em 0em 0em;
+  font-size: 1.5em;
+  font-weight: bold;
+}
+
+h3.subtitle {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 142.14%;
+  text-align: right;
+}
+
+h3 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 140%;
+  font-weight: bold;
+}
+
+h4 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 120%;
+  font-weight: bold;
+}
+
+h5 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+h6 {
+  margin: 1em 0em 0em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+.authorgroup {
+  background-color: transparent;
+  background-repeat: no-repeat;
+  padding-top: 256px;
+  background-image: url("figures/bsp-title.png");
+  background-position: left top;
+  margin-top: -256px;
+  padding-right: 50px;
+  margin-left: 0px;
+  text-align: right;
+  width: 740px;
+}
+
+h3.author {
+  margin: 0em 0me 0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-weight: normal;
+  font-size: 100%;
+  color: #333;
+  clear: both;
+}
+
+.author tt.email {
+  font-size: 66%;
+}
+
+.titlepage hr {
+  width: 0em;
+  clear: both;
+}
+
+.revhistory {
+  padding-top: 2em;
+  clear: both;
+}
+
+.toc,
+.list-of-tables,
+.list-of-examples,
+.list-of-figures {
+  padding: 1.33em 0em 2.5em 0em;
+  color: #00557D;
+}
+
+.toc p,
+.list-of-tables p,
+.list-of-figures p,
+.list-of-examples p {
+  padding: 0em 0em 0em 0em;
+  padding: 0em 0em 0.3em;
+  margin: 1.5em 0em 0em 0em;
+}
+
+.toc p b,
+.list-of-tables p b,
+.list-of-figures p b,
+.list-of-examples p b{
+  font-size: 100.0%;
+  font-weight: bold;
+}
+
+.toc dl,
+.list-of-tables dl,
+.list-of-figures dl,
+.list-of-examples dl {
+  margin: 0em 0em 0.5em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dt {
+  margin: 0em 0em 0em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dd {
+  margin: 0em 0em 0em 2.6em;
+  padding: 0em 0em 0em 0em;
+}
+
+div.glossary dl,
+div.variablelist dl {
+}
+
+.glossary dl dt,
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  font-weight: normal;
+  width: 20em;
+  text-align: right;
+}
+
+.variablelist dl dt {
+  margin-top: 0.5em;
+}
+
+.glossary dl dd,
+.variablelist dl dd {
+  margin-top: -1em;
+  margin-left: 25.5em;
+}
+
+.glossary dd p,
+.variablelist dd p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+
+div.calloutlist table td {
+  padding: 0em 0em 0em 0em;
+  margin: 0em 0em 0em 0em;
+}
+
+div.calloutlist table td p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+div p.copyright {
+  text-align: left;
+}
+
+div.legalnotice p.legalnotice-title {
+  margin-bottom: 0em;
+}
+
+p {
+  line-height: 1.5em;
+  margin-top: 0em;
+
+}
+
+dl {
+  padding-top: 0em;
+}
+
+hr {
+  border: solid 1px;
+}
+
+
+.mediaobject,
+.mediaobjectco {
+  text-align: center;
+}
+
+img {
+  border: none;
+}
+
+ul {
+  padding: 0em 0em 0em 1.5em;
+}
+
+ul li {
+  padding: 0em 0em 0em 0em;
+}
+
+ul li p {
+  text-align: left;
+}
+
+table {
+  width :100%;
+}
+
+th {
+  padding: 0.25em;
+  text-align: left;
+  font-weight: normal;
+  vertical-align: top;
+}
+
+td {
+  padding: 0.25em;
+  vertical-align: top;
+}
+
+p a[id] {
+  margin: 0px;
+  padding: 0px;
+  display: inline;
+  background-image: none;
+}
+
+a {
+  text-decoration: underline;
+  color: #444;
+}
+
+pre {
+    overflow: auto;
+}
+
+a:hover {
+  text-decoration: underline;
+  /*font-weight: bold;*/
+}
+
+/* This style defines how the permalink character
+   appears by itself and when hovered over with
+   the mouse. */
+
+[alt='Permalink'] { color: #eee; }
+[alt='Permalink']:hover { color: black; }
+
+
+div.informalfigure,
+div.informalexample,
+div.informaltable,
+div.figure,
+div.table,
+div.example {
+  margin: 1em 0em;
+  padding: 1em;
+  page-break-inside: avoid;
+}
+
+
+div.informalfigure p.title b,
+div.informalexample p.title b,
+div.informaltable p.title b,
+div.figure p.title b,
+div.example p.title b,
+div.table p.title b{
+    padding-top: 0em;
+    margin-top: 0em;
+    font-size: 100%;
+    font-weight: normal;
+}
+
+.mediaobject .caption,
+.mediaobject .caption p  {
+  text-align: center;
+  font-size: 80%;
+  padding-top: 0.5em;
+  padding-bottom: 0.5em;
+}
+
+.epigraph {
+  padding-left: 55%;
+  margin-bottom: 1em;
+}
+
+.epigraph p {
+  text-align: left;
+}
+
+.epigraph .quote {
+  font-style: italic;
+}
+.epigraph .attribution {
+  font-style: normal;
+  text-align: right;
+}
+
+span.application {
+  font-style: italic;
+}
+
+.programlisting {
+  font-family: monospace;
+  font-size: 80%;
+  white-space: pre;
+  margin: 1.33em 0em;
+  padding: 1.33em;
+}
+
+.tip,
+.warning,
+.caution,
+.note {
+  margin-top: 1em;
+  margin-bottom: 1em;
+
+}
+
+/* force full width of table within div */
+.tip table,
+.warning table,
+.caution table,
+.note table {
+  border: none;
+  width: 100%;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  padding: 0.8em 0.0em 0.0em 0.0em;
+  margin : 0em 0em 0em 0em;
+}
+
+.tip p,
+.warning p,
+.caution p,
+.note p {
+  margin-top: 0.5em;
+  margin-bottom: 0.5em;
+  padding-right: 1em;
+  text-align: left;
+}
+
+.acronym {
+  text-transform: uppercase;
+}
+
+b.keycap,
+.keycap {
+  padding: 0.09em 0.3em;
+  margin: 0em;
+}
+
+.itemizedlist li {
+  clear: none;
+}
+
+.filename {
+  font-size: medium;
+  font-family: Courier, monospace;
+}
+
+
+div.navheader, div.heading{
+  position: absolute;
+  left: 0em;
+  top: 0em;
+  width: 100%;
+  background-color: #cdf;
+  width: 100%;
+}
+
+div.navfooter, div.footing{
+  position: fixed;
+  left: 0em;
+  bottom: 0em;
+  background-color: #eee;
+  width: 100%;
+}
+
+
+div.navheader td,
+div.navfooter td {
+  font-size: 66%;
+}
+
+div.navheader table th {
+  /*font-family: Georgia, Times, serif;*/
+  /*font-size: x-large;*/
+  font-size: 80%;
+}
+
+div.navheader table {
+  border-left: 0em;
+  border-right: 0em;
+  border-top: 0em;
+  width: 100%;
+}
+
+div.navfooter table {
+  border-left: 0em;
+  border-right: 0em;
+  border-bottom: 0em;
+  width: 100%;
+}
+
+div.navheader table td a,
+div.navfooter table td a {
+  color: #777;
+  text-decoration: none;
+}
+
+/* normal text in the footer */
+div.navfooter table td {
+  color: black;
+}
+
+div.navheader table td a:visited,
+div.navfooter table td a:visited {
+  color: #444;
+}
+
+
+/* links in header and footer */
+div.navheader table td a:hover,
+div.navfooter table td a:hover {
+  text-decoration: underline;
+  background-color: transparent;
+  color: #33a;
+}
+
+div.navheader hr,
+div.navfooter hr {
+  display: none;
+}
+
+
+.qandaset tr.question td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.qandaset tr.answer td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+.answer td {
+  padding-bottom: 1.5em;
+}
+
+.emphasis {
+  font-weight: bold;
+}
+
+
+  /************* /
+ / decorations  /
+/ *************/
+
+.titlepage {
+}
+
+.part .title {
+}
+
+.subtitle {
+    border: none;
+}
+
+/*
+h1 {
+  border: none;
+}
+
+h2 {
+  border-top: solid 0.2em;
+  border-bottom: solid 0.06em;
+}
+
+h3 {
+  border-top: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h4 {
+  border: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h5 {
+  border: 0em;
+}
+*/
+
+.programlisting {
+  border: solid 1px;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example {
+  border: 1px solid;
+}
+
+
+
+.tip,
+.warning,
+.caution,
+.note {
+  border: 1px solid;
+}
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom: 1px solid;
+}
+
+.question td {
+  border-top: 1px solid black;
+}
+
+.answer {
+}
+
+
+b.keycap,
+.keycap {
+  border: 1px solid;
+}
+
+
+div.navheader, div.heading{
+  border-bottom: 1px solid;
+}
+
+
+div.navfooter, div.footing{
+  border-top: 1px solid;
+}
+
+  /********* /
+ /  colors  /
+/ *********/
+
+body {
+  color: #333;
+  background: white;
+}
+
+a {
+  background: transparent;
+}
+
+a:hover {
+  background-color: #dedede;
+}
+
+
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7,
+h8 {
+  background-color: transparent;
+}
+
+hr {
+  border-color: #aaa;
+}
+
+
+.tip, .warning, .caution, .note {
+  border-color: #fff;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom-color: #fff;
+}
+
+
+.warning {
+  background-color: #f0f0f2;
+}
+
+.caution {
+  background-color: #f0f0f2;
+}
+
+.tip {
+  background-color: #f0f0f2;
+}
+
+.note {
+  background-color: #f0f0f2;
+}
+
+.glossary dl dt,
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  color: #044;
+}
+
+div.figure,
+div.table,
+div.example,
+div.informalfigure,
+div.informaltable,
+div.informalexample {
+  border-color: #aaa;
+}
+
+pre.programlisting {
+  color: black;
+  background-color: #fff;
+  border-color: #aaa;
+  border-width: 2px;
+}
+
+.guimenu,
+.guilabel,
+.guimenuitem {
+  background-color: #eee;
+}
+
+
+b.keycap,
+.keycap {
+  background-color: #eee;
+  border-color: #999;
+}
+
+
+div.navheader {
+  border-color: black;
+}
+
+
+div.navfooter {
+  border-color: black;
+}
+
+
+  /*********** /
+ /  graphics  /
+/ ***********/
+
+/*
+body {
+  background-image: url("images/body_bg.jpg");
+  background-attachment: fixed;
+}
+
+.navheader,
+.note,
+.tip {
+  background-image: url("images/note_bg.jpg");
+  background-attachment: fixed;
+}
+
+.warning,
+.caution {
+  background-image: url("images/warning_bg.jpg");
+  background-attachment: fixed;
+}
+
+.figure,
+.informalfigure,
+.example,
+.informalexample,
+.table,
+.informaltable {
+  background-image: url("images/figure_bg.jpg");
+  background-attachment: fixed;
+}
+
+*/
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7{
+}
+
+/*
+Example of how to stick an image as part of the title.
+
+div.article .titlepage .title
+{
+  background-image: url("figures/white-on-black.png");
+  background-position: center;
+  background-repeat: repeat-x;
+}
+*/
+
+div.preface .titlepage .title,
+div.colophon .title,
+div.chapter .titlepage .title {
+  background-position: bottom;
+  background-repeat: repeat-x;
+}
+
+div.section div.section .titlepage .title,
+div.sect2 .titlepage .title {
+    background: none;
+}
+
+
+h1.title {
+  background-color: transparent;
+  background-repeat: no-repeat;
+  height: 256px;
+  text-indent: -9000px;
+  overflow:hidden;
+}
+
+h2.subtitle {
+  background-color: transparent;
+  text-indent: -9000px;
+  overflow:hidden;
+  width: 0px;
+  display: none;
+}
+
+  /*************************************** /
+ /  pippin.gimp.org specific alterations  /
+/ ***************************************/
+
+/*
+div.heading, div.navheader {
+  color: #777;
+  font-size: 80%;
+  padding: 0;
+  margin: 0;
+  text-align: left;
+  position: absolute;
+  top: 0px;
+  left: 0px;
+  width: 100%;
+  height: 50px;
+  background: url('/gfx/heading_bg.png') transparent;
+  background-repeat: repeat-x;
+  background-attachment: fixed;
+  border: none;
+}
+
+div.heading a {
+  color: #444;
+}
+
+div.footing, div.navfooter {
+  border: none;
+  color: #ddd;
+  font-size: 80%;
+  text-align:right;
+
+  width: 100%;
+  padding-top: 10px;
+  position: absolute;
+  bottom: 0px;
+  left: 0px;
+
+  background: url('/gfx/footing_bg.png') transparent;
+}
+*/
+
+
+
+  /****************** /
+ /  nasty ie tweaks  /
+/ ******************/
+
+/*
+div.heading, div.navheader {
+  width:expression(document.body.clientWidth + "px");
+}
+
+div.footing, div.navfooter {
+  width:expression(document.body.clientWidth + "px");
+  margin-left:expression("-5em");
+}
+body {
+  padding:expression("4em 5em 0em 5em");
+}
+*/
+
+  /**************************************** /
+ / mozilla vendor specific css extensions  /
+/ ****************************************/
+/*
+div.navfooter, div.footing{
+  -moz-opacity: 0.8em;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example,
+.tip,
+.warning,
+.caution,
+.note {
+  -moz-border-radius: 0.5em;
+}
+
+b.keycap,
+.keycap {
+  -moz-border-radius: 0.3em;
+}
+*/
+
+table tr td table tr td {
+  display: none;
+}
+
+
+hr {
+  display: none;
+}
+
+table {
+  border: 0em;
+}
+
+ .photo {
+  float: right;
+  margin-left:   1.5em;
+  margin-bottom: 1.5em;
+  margin-top: 0em;
+  max-width:      17em;
+  border:     1px solid gray;
+  padding:    3px;
+  background: white;
+}
+ .seperator {
+   padding-top: 2em;
+   clear: both;
+  }
+
+  #validators {
+      margin-top: 5em;
+      text-align: right;
+      color: #777;
+  }
+  @media print {
+      body {
+          font-size: 8pt;
+      }
+      .noprint {
+          display: none;
+      }
+  }
+
+
+.tip,
+.note {
+   background: #f0f0f2;
+   color: #333;
+   padding: 20px;
+   margin: 20px;
+}
+
+.tip h3,
+.note h3 {
+   padding: 0em;
+   margin: 0em;
+   font-size: 2em;
+   font-weight: bold;
+   color: #333;
+}
+
+.tip a,
+.note a {
+   color: #333;
+   text-decoration: underline;
+}
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml
new file mode 100644
index 0000000000..d4850234d1
--- /dev/null
+++ b/documentation/bsp-guide/bsp.xml
@@ -0,0 +1,1527 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='bsp'>
+
+        <title>Board Support Packages (BSP) - Developer's Guide</title>
+
+        <para>
+            A Board Support Package (BSP) is a collection of information that
+            defines how to support a particular hardware device, set of devices, or
+            hardware platform.
+            The BSP includes information about the hardware features
+            present on the device and kernel configuration information along with any
+            additional hardware drivers required.
+            The BSP also lists any additional software
+            components required in addition to a generic Linux software stack for both
+            essential and optional platform features.
+        </para>
+
+        <para>
+            This guide presents information about BSP Layers, defines a structure for components
+            so that BSPs follow a commonly understood layout, discusses how to customize
+            a recipe for a BSP, addresses BSP licensing, and provides information that
+            shows you how to create and manage a
+            <link linkend='bsp-layers'>BSP Layer</link> using two Yocto Project
+            <link linkend='using-the-yocto-projects-bsp-tools'>BSP Tools</link>.
+        </para>
+
+        <section id='bsp-layers'>
+            <title>BSP Layers</title>
+
+            <para>
+                A BSP consists of a file structure inside a base directory.
+                Collectively, you can think of the base directory, its file structure,
+                and the contents as a BSP Layer.
+                Although not a strict requirement, layers in the Yocto Project use the
+                following well established naming convention:
+                <literallayout class='monospaced'>
+     meta-<replaceable>bsp_name</replaceable>
+                </literallayout>
+                The string "meta-" is prepended to the machine or platform name, which is
+                "bsp_name" in the above form.
+            </para>
+
+            <para>
+                To help understand the BSP layer concept, consider the BSPs that the
+                Yocto Project supports and provides with each release.
+                You can see the layers in the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-repositories'>Yocto Project Source Repositories</ulink>
+                through a web interface at
+                <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'></ulink>.
+                If you go to that interface, you will find near the bottom of the list
+                under "Yocto Metadata Layers" several BSP layers all of which are
+                supported by the Yocto Project (e.g. <filename>meta-minnow</filename>,
+                <filename>meta-raspberrypi</filename>, and
+                <filename>meta-intel</filename>).
+                Each of these layers is a repository unto itself and clicking on a
+                layer reveals information that includes two links from which you can choose
+                to set up a clone of the layer's repository on your local host system.
+                Here is an example that clones the Minnow Board BSP layer:
+                <literallayout class='monospaced'>
+     $ git clone git://git.yoctoproject.org/meta-minnow
+                </literallayout>
+                For information on the BSP development workflow, see the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#developing-a-board-support-package-bsp'>Developing a Board Support Package (BSP)</ulink>"
+                section in the Yocto Project Development Manual.
+                For more information on how to set up a local copy of source files
+                from a Git repository, see the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Set Up</ulink>"
+                section also in the Yocto Project Development Manual.
+            </para>
+
+            <para>
+                The layer's base directory (<filename>meta-<replaceable>bsp_name</replaceable></filename>) is the root
+                of the BSP Layer.
+                This root is what you add to the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink>
+                variable in the <filename>conf/bblayers.conf</filename> file found in the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
+                which is established after you run one of the OpenEmbedded build environment
+                setup scripts (i.e.
+                <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                and
+                <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>).
+                Adding the root allows the OpenEmbedded build system to recognize the BSP
+                definition and from it build an image.
+                Here is an example:
+                <literallayout class='monospaced'>
+     BBLAYERS ?= " \
+       /usr/local/src/yocto/meta \
+       /usr/local/src/yocto/meta-yocto \
+       /usr/local/src/yocto/meta-yocto-bsp \
+       /usr/local/src/yocto/meta-mylayer \
+       "
+
+     BBLAYERS_NON_REMOVABLE ?= " \
+       /usr/local/src/yocto/meta \
+       /usr/local/src/yocto/meta-yocto \
+       "
+                </literallayout>
+            </para>
+
+            <para>
+                Some BSPs require additional layers on
+                top of the BSP's root layer in order to be functional.
+                For these cases, you also need to add those layers to the
+                <filename>BBLAYERS</filename> variable in order to build the BSP.
+                You must also specify in the "Dependencies" section of the BSP's
+                <filename>README</filename> file any requirements for additional
+                layers and, preferably, any
+                build instructions that might be contained elsewhere
+                in the <filename>README</filename> file.
+            </para>
+
+            <para>
+                Some layers function as a layer to hold other BSP layers.
+                An example of this type of layer is the <filename>meta-intel</filename> layer.
+                The <filename>meta-intel</filename> layer contains many individual BSP layers.
+            </para>
+
+            <para>
+                For more detailed information on layers, see the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
+                section of the Yocto Project Development Manual.
+            </para>
+        </section>
+
+
+        <section id="bsp-filelayout">
+            <title>Example Filesystem Layout</title>
+
+            <para>
+                Providing a common form allows end-users to understand and become familiar
+                with the layout.
+                A common format also encourages standardization of software support of hardware.
+            </para>
+
+            <para>
+                The proposed form does have elements that are specific to the
+                OpenEmbedded build system.
+                It is intended that this information can be
+                used by other build systems besides the OpenEmbedded build system
+                and that it will be simple
+                to extract information and convert it to other formats if required.
+                The OpenEmbedded build system, through its standard layers mechanism, can directly
+                accept the format described as a layer.
+                The BSP captures all
+                the hardware-specific details in one place in a standard format, which is
+                useful for any person wishing to use the hardware platform regardless of
+                the build system they are using.
+            </para>
+
+            <para>
+                The BSP specification does not include a build system or other tools -
+                it is concerned with the hardware-specific components only.
+                At the end-distribution point, you can ship the BSP combined with a build system
+                and other tools.
+                However, it is important to maintain the distinction that these
+                are separate components that happen to be combined in certain end products.
+            </para>
+
+            <para>
+                Before looking at the common form for the file structure inside a BSP Layer,
+                you should be aware that some requirements do exist in order for a BSP to
+                be considered compliant with the Yocto Project.
+                For that list of requirements, see the
+                "<link linkend='released-bsp-requirements'>Released BSP Requirements</link>"
+                section.
+            </para>
+
+            <para>
+                Below is the common form for the file structure inside a BSP Layer.
+                While you can use this basic form for the standard, realize that the actual structures
+                for specific BSPs could differ.
+
+                <literallayout class='monospaced'>
+     meta-<replaceable>bsp_name</replaceable>/
+     meta-<replaceable>bsp_name</replaceable>/<replaceable>bsp_license_file</replaceable>
+     meta-<replaceable>bsp_name</replaceable>/README
+     meta-<replaceable>bsp_name</replaceable>/README.sources
+     meta-<replaceable>bsp_name</replaceable>/binary/<replaceable>bootable_images</replaceable>
+     meta-<replaceable>bsp_name</replaceable>/conf/layer.conf
+     meta-<replaceable>bsp_name</replaceable>/conf/machine/*.conf
+     meta-<replaceable>bsp_name</replaceable>/recipes-bsp/*
+     meta-<replaceable>bsp_name</replaceable>/recipes-core/*
+     meta-<replaceable>bsp_name</replaceable>/recipes-graphics/*
+     meta-<replaceable>bsp_name</replaceable>/recipes-kernel/linux/linux-yocto_<replaceable>kernel_rev</replaceable>.bbappend
+                </literallayout>
+            </para>
+
+            <para>
+                Below is an example of the Crown Bay BSP:
+
+                <literallayout class='monospaced'>
+     meta-crownbay/COPYING.MIT
+     meta-crownbay/README
+     meta-crownbay/README.sources
+     meta-crownbay/binary/
+     meta-crownbay/conf/
+     meta-crownbay/conf/layer.conf
+     meta-crownbay/conf/machine/
+     meta-crownbay/conf/machine/crownbay.conf
+     meta-crownbay/conf/machine/crownbay-noemgd.conf
+     meta-crownbay/recipes-bsp/
+     meta-crownbay/recipes-bsp/formfactor/
+     meta-crownbay/recipes-bsp/formfactor/formfactor_0.0.bbappend
+     meta-crownbay/recipes-bsp/formfactor/formfactor/
+     meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay/
+     meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay/machconfig
+     meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay-noemgd/
+     meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay-noemgd/machconfig
+     meta-crownbay/recipes-graphics/
+     meta-crownbay/recipes-graphics/xorg-xserver/
+     meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
+     meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/
+     meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/
+     meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
+     meta-crownbay/recipes-kernel/
+     meta-crownbay/recipes-kernel/linux/
+     meta-crownbay/recipes-kernel/linux/linux-yocto-dev.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.10.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto_3.10.bbappend
+                </literallayout>
+            </para>
+
+            <para>
+                The following sections describe each part of the proposed BSP format.
+            </para>
+
+            <section id="bsp-filelayout-license">
+            <title>License Files</title>
+
+            <para>
+                You can find these files in the BSP Layer at:
+                <literallayout class='monospaced'>
+     meta-<replaceable>bsp_name</replaceable>/<replaceable>bsp_license_file</replaceable>
+                </literallayout>
+            </para>
+
+            <para>
+                These optional files satisfy licensing requirements for the BSP.
+                The type or types of files here can vary depending on the licensing requirements.
+                For example, in the Crown Bay BSP all licensing requirements are handled with the
+                <filename>COPYING.MIT</filename> file.
+            </para>
+
+            <para>
+                Licensing files can be MIT, BSD, GPLv*, and so forth.
+                These files are recommended for the BSP but are optional and totally up to the BSP developer.
+            </para>
+            </section>
+
+            <section id="bsp-filelayout-readme">
+            <title>README File</title>
+            <para>
+                You can find this file in the BSP Layer at:
+                <literallayout class='monospaced'>
+     meta-<replaceable>bsp_name</replaceable>/README
+                </literallayout>
+            </para>
+
+            <para>
+                This file provides information on how to boot the live images that are optionally
+                included in the <filename>binary/</filename> directory.
+                The <filename>README</filename> file also provides special information needed for
+                building the image.
+            </para>
+
+            <para>
+                At a minimum, the <filename>README</filename> file must
+                contain a list of dependencies, such as the names of
+                any other layers on which the BSP depends and the name of
+                the BSP maintainer with his or her contact information.
+            </para>
+            </section>
+
+            <section id="bsp-filelayout-readme-sources">
+            <title>README.sources File</title>
+            <para>
+                You can find this file in the BSP Layer at:
+                <literallayout class='monospaced'>
+     meta-<replaceable>bsp_name</replaceable>/README.sources
+                </literallayout>
+            </para>
+
+            <para>
+                This file provides information on where to locate the BSP source files.
+                For example, information provides where to find the sources that comprise
+                the images shipped with the BSP.
+                Information is also included to help you find the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                used to generate the images that ship with the BSP.
+            </para>
+            </section>
+
+            <section id="bsp-filelayout-binary">
+            <title>Pre-built User Binaries</title>
+            <para>
+                You can find these files in the BSP Layer at:
+                <literallayout class='monospaced'>
+     meta-<replaceable>bsp_name</replaceable>/binary/<replaceable>bootable_images</replaceable>
+                </literallayout>
+            </para>
+
+            <para>
+                This optional area contains useful pre-built kernels and user-space filesystem
+                images appropriate to the target system.
+                This directory typically contains graphical (e.g. Sato) and minimal live images
+                when the BSP tarball has been created and made available in the
+                <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
+                You can use these kernels and images to get a system running and quickly get started
+                on development tasks.
+            </para>
+
+            <para>
+                The exact types of binaries present are highly hardware-dependent.
+                However, a <filename>README</filename> file should be present in the BSP Layer that explains how to use
+                the kernels and images with the target hardware.
+                If pre-built binaries are present, source code to meet licensing requirements must also
+                exist in some form.
+            </para>
+            </section>
+
+            <section id='bsp-filelayout-layer'>
+            <title>Layer Configuration File</title>
+            <para>
+                You can find this file in the BSP Layer at:
+                <literallayout class='monospaced'>
+     meta-<replaceable>bsp_name</replaceable>/conf/layer.conf
+                </literallayout>
+            </para>
+
+            <para>
+                The <filename>conf/layer.conf</filename> file identifies the file structure as a
+                layer, identifies the
+                contents of the layer, and contains information about how the build
+                system should use it.
+                Generally, a standard boilerplate file such as the following works.
+                In the following example, you would replace "<replaceable>bsp</replaceable>" and
+                "<replaceable>_bsp</replaceable>" with the actual name
+                of the BSP (i.e. <replaceable>bsp_name</replaceable> from the example template).
+            </para>
+
+            <para>
+               <literallayout class='monospaced'>
+     # We have a conf and classes directory, add to BBPATH
+     BBPATH .= ":${LAYERDIR}"
+
+     # We have a recipes directory, add to BBFILES
+     BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
+             ${LAYERDIR}/recipes-*/*/*.bbappend"
+
+     BBFILE_COLLECTIONS += "bsp"
+     BBFILE_PATTERN_bsp = "^${LAYERDIR}/"
+     BBFILE_PRIORITY_bsp = "6"
+                </literallayout>
+            </para>
+
+            <para>
+                To illustrate the string substitutions, here are the corresponding statements
+                from the Crown Bay <filename>conf/layer.conf</filename> file:
+               <literallayout class='monospaced'>
+     BBFILE_COLLECTIONS += "crownbay"
+     BBFILE_PATTERN_crownbay = "^${LAYERDIR}/"
+     BBFILE_PRIORITY_crownbay = "6"
+                </literallayout>
+            </para>
+
+            <para>
+                This file simply makes
+                <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>
+                aware of the recipes and configuration directories.
+                The file must exist so that the OpenEmbedded build system can recognize the BSP.
+            </para>
+            </section>
+
+            <section id="bsp-filelayout-machine">
+            <title>Hardware Configuration Options</title>
+            <para>
+                You can find these files in the BSP Layer at:
+                <literallayout class='monospaced'>
+     meta-<replaceable>bsp_name</replaceable>/conf/machine/*.conf
+                </literallayout>
+            </para>
+
+            <para>
+                The machine files bind together all the information contained elsewhere
+                in the BSP into a format that the build system can understand.
+                If the BSP supports multiple machines, multiple machine configuration files
+                can be present.
+                These filenames correspond to the values to which users have set the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink> variable.
+            </para>
+
+            <para>
+                These files define things such as the kernel package to use
+                (<ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></ulink>
+                of virtual/kernel), the hardware drivers to
+                include in different types of images, any special software components
+                that are needed, any bootloader information, and also any special image
+                format requirements.
+            </para>
+
+            <para>
+                Each BSP Layer requires at least one machine file.
+                However, you can supply more than one file.
+            </para>
+
+            <para>
+                This <filename>crownbay.conf</filename> file could also include
+                a hardware "tuning" file that is commonly used to
+                define the package architecture and specify
+                optimization flags, which are carefully chosen to give best
+                performance on a given processor.
+            </para>
+
+            <para>
+                Tuning files are found in the <filename>meta/conf/machine/include</filename>
+                directory within the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                For example, the <filename>ia32-base.inc</filename> file resides in the
+                <filename>meta/conf/machine/include</filename> directory.
+            </para>
+
+            <para>
+                To use an include file, you simply include them in the machine configuration file.
+                For example, the Crown Bay BSP <filename>crownbay.conf</filename> contains the
+                following statements:
+                <literallayout class='monospaced'>
+     require conf/machine/include/intel-core2-32-common.inc
+     require conf/machine/include/meta-intel.inc
+     require conf/machine/include/meta-intel-emgd.inc
+                </literallayout>
+            </para>
+            </section>
+
+            <section id='bsp-filelayout-misc-recipes'>
+            <title>Miscellaneous BSP-Specific Recipe Files</title>
+            <para>
+                You can find these files in the BSP Layer at:
+                <literallayout class='monospaced'>
+     meta-<replaceable>bsp_name</replaceable>/recipes-bsp/*
+                </literallayout>
+            </para>
+
+            <para>
+                This optional directory contains miscellaneous recipe files for the BSP.
+                Most notably would be the formfactor files.
+                For example, in the Crown Bay BSP there is the
+                <filename>formfactor_0.0.bbappend</filename> file, which is an
+                append file used to augment the recipe that starts the build.
+                Furthermore, there are machine-specific settings used during the
+                build that are defined by the <filename>machconfig</filename> file.
+                In the Crown Bay example, two <filename>machconfig</filename> files
+                exist: one that supports the Intel® Embedded Media and Graphics
+                Driver (Intel® EMGD) and one that does not:
+                <literallayout class='monospaced'>
+     meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay/machconfig
+     meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay-noemgd/machconfig
+     meta-crownbay/recipes-bsp/formfactor/formfactor_0.0.bbappend
+                </literallayout>
+            </para>
+
+            <note><para>
+                If a BSP does not have a formfactor entry, defaults are established according to
+                the formfactor configuration file that is installed by the main
+                formfactor recipe
+                <filename>meta/recipes-bsp/formfactor/formfactor_0.0.bb</filename>,
+                which is found in the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            </para></note>
+            </section>
+
+            <section id='bsp-filelayout-recipes-graphics'>
+            <title>Display Support Files</title>
+            <para>
+                You can find these files in the BSP Layer at:
+                <literallayout class='monospaced'>
+     meta-<replaceable>bsp_name</replaceable>/recipes-graphics/*
+                </literallayout>
+            </para>
+
+            <para>
+                This optional directory contains recipes for the BSP if it has
+                special requirements for graphics support.
+                All files that are needed for the BSP to support a display are kept here.
+                For example, the Crown Bay BSP's <filename>xorg.conf</filename> file
+                detects the graphics support needed (i.e. the Intel® Embedded Media
+                Graphics Driver (EMGD) or the Video Electronics Standards Association
+                (VESA) graphics):
+                <literallayout class='monospaced'>
+     meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
+     meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
+                </literallayout>
+            </para>
+            </section>
+
+            <section id='bsp-filelayout-kernel'>
+            <title>Linux Kernel Configuration</title>
+            <para>
+                You can find these files in the BSP Layer at:
+                <literallayout class='monospaced'>
+     meta-<replaceable>bsp_name</replaceable>/recipes-kernel/linux/linux-yocto_*.bbappend
+                </literallayout>
+            </para>
+
+            <para>
+                These files append your specific changes to the main kernel recipe you are using.
+            </para>
+            <para>
+                For your BSP, you typically want to use an existing Yocto Project kernel recipe found in the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                at <filename>meta/recipes-kernel/linux</filename>.
+                You can append your specific changes to the kernel recipe by using a
+                similarly named append file, which is located in the BSP Layer (e.g.
+                the <filename>meta-<replaceable>bsp_name</replaceable>/recipes-kernel/linux</filename> directory).
+            </para>
+            <para>
+                Suppose you are using the <filename>linux-yocto_3.10.bb</filename> recipe to build
+                the kernel.
+                In other words, you have selected the kernel in your
+                <replaceable>bsp_name</replaceable><filename>.conf</filename> file by adding these types
+                of statements:
+                <literallayout class='monospaced'>
+     PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+     PREFERRED_VERSION_linux-yocto ?= "3.10%"
+                </literallayout>
+                <note>
+                    When the preferred provider is assumed by default, the
+                    <filename>PREFERRED_PROVIDER</filename> statement does not appear in the
+                    <replaceable>bsp_name</replaceable><filename>.conf</filename> file.
+                </note>
+                You would use the <filename>linux-yocto_3.10.bbappend</filename> file to append
+                specific BSP settings to the kernel, thus configuring the kernel for your particular BSP.
+            </para>
+            <para>
+                As an example, look at the existing Crown Bay BSP.
+                The append file used is:
+                <literallayout class='monospaced'>
+     meta-crownbay/recipes-kernel/linux/linux-yocto_3.10.bbappend
+                </literallayout>
+                The following listing shows the file.
+                Be aware that the actual commit ID strings in this example listing might be different
+                than the actual strings in the file from the <filename>meta-intel</filename>
+                Git source repository.
+                <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+
+     COMPATIBLE_MACHINE_crownbay = "crownbay"
+     KMACHINE_crownbay = "crownbay"
+     KBRANCH_crownbay = "standard/crownbay"
+     KERNEL_FEATURES_append_crownbay = " features/drm-emgd/drm-emgd-1.18 cfg/vesafb"
+
+     COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
+     KMACHINE_crownbay-noemgd = "crownbay"
+     KBRANCH_crownbay-noemgd = "standard/crownbay"
+     KERNEL_FEATURES_append_crownbay-noemgd = " cfg/vesafb"
+
+     LINUX_VERSION_crownbay = "3.10.35"
+     SRCREV_meta_crownbay = "b6e58b33dd427fe471f8827c83e311acdf4558a4"
+     SRCREV_machine_crownbay = "cee957655fe67826b2e827e2db41f156fa8f0cc4"
+     SRCREV_emgd_crownbay = "42d5e4548e8e79e094fa8697949eed4cf6af00a3"
+
+     LINUX_VERSION_crownbay-noemgd = "3.10.35"
+     SRCREV_meta_crownbay-noemgd = "b6e58b33dd427fe471f8827c83e311acdf4558a4"
+     SRCREV_machine_crownbay-noemgd = "cee957655fe67826b2e827e2db41f156fa8f0cc4"
+
+     SRC_URI_crownbay = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},emgd-1.18;name=machine,meta,emgd"
+                </literallayout>
+                This append file contains statements used to support the Crown Bay BSP.
+                The file defines machines using the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></ulink>
+                variable and uses the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink> variable to
+                ensure the machine name used by the OpenEmbedded build system maps to the
+                machine name used by the Linux Yocto kernel.
+                The file also uses the optional
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-KBRANCH'><filename>KBRANCH</filename></ulink> variable
+                to ensure the build process uses the <filename>standard/crownbay</filename>
+                kernel branch.
+                The
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink>
+                variable enables features specific to the kernel
+                (e.g. graphics support in this case).
+                The append file points to specific commits in the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> Git
+                repository and the <filename>meta</filename> Git repository branches to identify the
+                exact kernel needed to build the Crown Bay BSP.
+                Finally, the file includes the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                statement to locate the source files.
+            </para>
+
+            <para>
+                One thing missing in this particular BSP, which you will typically need when
+                developing a BSP, is the kernel configuration file (<filename>.config</filename>) for your BSP.
+                When developing a BSP, you probably have a kernel configuration file or a set of kernel
+                configuration files that, when taken together, define the kernel configuration for your BSP.
+                You can accomplish this definition by putting the configurations in a file or a set of files
+                inside a directory located at the same level as your kernel's append file and having the same
+                name as the kernel's main recipe file.
+                With all these conditions met, simply reference those files in the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                statement in the append file.
+            </para>
+
+            <para>
+                For example, suppose you had some configuration options in a file called
+                <filename>network_configs.cfg</filename>.
+                You can place that file inside a directory named <filename>linux-yocto</filename> and then add
+                a <filename>SRC_URI</filename> statement such as the following to the append file.
+                When the OpenEmbedded build system builds the kernel, the configuration options are
+                picked up and applied.
+                <literallayout class='monospaced'>
+     SRC_URI += "file://network_configs.cfg"
+                </literallayout>
+            </para>
+
+            <para>
+                To group related configurations into multiple files, you perform a similar procedure.
+                Here is an example that groups separate configurations specifically for Ethernet and graphics
+                into their own files and adds the configurations
+                by using a <filename>SRC_URI</filename> statement like the following in your append file:
+                <literallayout class='monospaced'>
+     SRC_URI += "file://myconfig.cfg \
+            file://eth.cfg \
+            file://gfx.cfg"
+                </literallayout>
+            </para>
+
+            <para>
+                The <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+                variable is in boilerplate form in the
+                previous example in order to make it easy to do that.
+                This variable must be in your layer or BitBake will not find the patches or
+                configurations even if you have them in your <filename>SRC_URI</filename>.
+                The <filename>FILESEXTRAPATHS</filename> variable enables the build process to
+                find those configuration files.
+            </para>
+
+            <note>
+                <para>
+                    Other methods exist to accomplish grouping and defining configuration options.
+                    For example, if you are working with a local clone of the kernel repository,
+                    you could checkout the kernel's <filename>meta</filename> branch, make your changes,
+                    and then push the changes to the local bare clone of the kernel.
+                    The result is that you directly add configuration options to the
+                    <filename>meta</filename> branch for your BSP.
+                    The configuration options will likely end up in that location anyway if the BSP gets
+                    added to the Yocto Project.
+                </para>
+
+                <para>
+                    In general, however, the Yocto Project maintainers take care of moving the
+                    <filename>SRC_URI</filename>-specified
+                    configuration options to the kernel's <filename>meta</filename> branch.
+                    Not only is it easier for BSP developers to not have to worry about putting those
+                   configurations in the branch, but having the maintainers do it allows them to apply
+                    'global' knowledge about the kinds of common configuration options multiple BSPs in
+                    the tree are typically using.
+                    This allows for promotion of common configurations into common features.
+                </para>
+            </note>
+            </section>
+        </section>
+
+        <section id='requirements-and-recommendations-for-released-bsps'>
+            <title>Requirements and Recommendations for Released BSPs</title>
+
+            <para>
+                Certain requirements exist for a released BSP to be considered
+                compliant with the Yocto Project.
+                Additionally, recommendations also exist.
+                This section describes the requirements and recommendations for
+                released BSPs.
+            </para>
+
+            <section id='released-bsp-requirements'>
+                <title>Released BSP Requirements</title>
+
+                <para>
+                    Before looking at BSP requirements, you should consider the following:
+                    <itemizedlist>
+                        <listitem><para>The requirements here assume the BSP layer is a well-formed, "legal"
+                            layer that can be added to the Yocto Project.
+                            For guidelines on creating a layer that meets these base requirements, see the
+                            "<link linkend='bsp-layers'>BSP Layers</link>" and the
+                            "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding
+                            and Creating Layers"</ulink> in the Yocto Project Development Manual.</para></listitem>
+                        <listitem><para>The requirements in this section apply regardless of how you
+                            ultimately package a BSP.
+                            You should consult the packaging and distribution guidelines for your
+                            specific release process.
+                            For an example of packaging and distribution requirements, see the
+                            "<ulink url='https://wiki.yoctoproject.org/wiki/Third_Party_BSP_Release_Process'>Third Party BSP Release Process</ulink>"
+                            wiki page.</para></listitem>
+                        <listitem><para>The requirements for the BSP as it is made available to a developer
+                            are completely independent of the released form of the BSP.
+                            For example, the BSP Metadata can be contained within a Git repository
+                            and could have a directory structure completely different from what appears
+                            in the officially released BSP layer.</para></listitem>
+                        <listitem><para>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 dictating that a specific kernel or
+                            kernel version be used in a given BSP.</para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    Following are the requirements for a released BSP that conforms to the
+                    Yocto Project:
+                    <itemizedlist>
+                        <listitem><para><emphasis>Layer Name:</emphasis>
+                            The BSP must have a layer name that follows the Yocto
+                            Project standards.
+                            For information on BSP layer names, see the
+                            "<link linkend='bsp-layers'>BSP Layers</link>" section.
+                            </para></listitem>
+                        <listitem><para><emphasis>File System Layout:</emphasis>
+                            When possible, use the same directory names in your
+                            BSP layer as listed in the <filename>recipes.txt</filename> file.
+                            In particular, you should place recipes
+                            (<filename>.bb</filename> files) and recipe
+                            modifications (<filename>.bbappend</filename> files) into
+                            <filename>recipes-*</filename> subdirectories by functional area
+                            as outlined in <filename>recipes.txt</filename>.
+                            If you cannot find a category in <filename>recipes.txt</filename>
+                            to fit a particular recipe, you can make up your own
+                            <filename>recipes-*</filename> subdirectory.
+                            You can find <filename>recipes.txt</filename> in the
+                            <filename>meta</filename> directory of the
+                            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
+                            or in the OpenEmbedded Core Layer
+                            (<filename>openembedded-core</filename>) found at
+                            <ulink url='http://git.openembedded.org/openembedded-core/tree/meta'></ulink>.
+                            </para>
+                            <para>Within any particular <filename>recipes-*</filename> category, the layout
+                            should match what is found in the OpenEmbedded Core
+                            Git repository (<filename>openembedded-core</filename>)
+                            or the Source Directory (<filename>poky</filename>).
+                            In other words, make sure you place related files in appropriately
+                            related <filename>recipes-*</filename> subdirectories specific to the
+                            recipe's function, or within a subdirectory containing a set of closely-related
+                            recipes.
+                            The recipes themselves should follow the general guidelines
+                            for recipes used in the Yocto Project found in the
+                            "<ulink url='https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide'>Yocto Recipe and Patch Style Guide</ulink>".
+                            </para></listitem>
+                        <listitem><para><emphasis>License File:</emphasis>
+                            You must include a license file in the
+                            <filename>meta-<replaceable>bsp_name</replaceable></filename> directory.
+                            This license covers the BSP Metadata as a whole.
+                            You must specify which license to use since there is no
+                            default license if one is not specified.
+                            See the
+                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fri2/COPYING.MIT'><filename>COPYING.MIT</filename></ulink>
+                            file for the Fish River Island 2 BSP in the <filename>meta-fri2</filename> BSP layer
+                            as an example.</para></listitem>
+                        <listitem><para><emphasis>README File:</emphasis>
+                            You must include a <filename>README</filename> file in the
+                            <filename>meta-<replaceable>bsp_name</replaceable></filename> directory.
+                            See the
+                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fri2/README'><filename>README</filename></ulink>
+                            file for the Fish River Island 2 BSP in the <filename>meta-fri2</filename> BSP layer
+                            as an example.</para>
+                            <para>At a minimum, the <filename>README</filename> file should
+                            contain the following:
+                            <itemizedlist>
+                                <listitem><para>A brief description about the hardware the BSP
+                                    targets.</para></listitem>
+                                <listitem><para>A list of all the dependencies
+                                    on which a BSP layer depends.
+                                    These dependencies are typically a list of required layers needed
+                                    to build the BSP.
+                                    However, the dependencies should also contain information regarding
+                                    any other dependencies the BSP might have.</para></listitem>
+                                <listitem><para>Any required special licensing information.
+                                    For example, this information includes information on
+                                    special variables needed to satisfy a EULA,
+                                    or instructions on information needed to build or distribute
+                                    binaries built from the BSP Metadata.</para></listitem>
+                                <listitem><para>The name and contact information for the
+                                    BSP layer maintainer.
+                                    This is the person to whom patches and questions should
+                                    be sent.
+                                    For information on how to find the right person, see the
+                                    "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>How to Submit a Change</ulink>"
+                                    section in the Yocto Project Development Manual.
+                                    </para></listitem>
+                                <listitem><para>Instructions on how to build the BSP using the BSP
+                                    layer.</para></listitem>
+                                <listitem><para>Instructions on how to boot the BSP build from
+                                    the BSP layer.</para></listitem>
+                                <listitem><para>Instructions on how to boot the binary images
+                                    contained in the <filename>binary</filename> directory,
+                                    if present.</para></listitem>
+                                <listitem><para>Information on any known bugs or issues that users
+                                    should know about when either building or booting the BSP
+                                    binaries.</para></listitem>
+                            </itemizedlist></para></listitem>
+                        <listitem><para><emphasis>README.sources File:</emphasis>
+                            You must include a <filename>README.sources</filename> in the
+                            <filename>meta-<replaceable>bsp_name</replaceable></filename> directory.
+                            This file specifies exactly where you can find the sources used to
+                            generate the binary images contained in the
+                            <filename>binary</filename> directory, if present.
+                            See the
+                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fri2/README.sources'><filename>README.sources</filename></ulink>
+                            file for the Fish River Island 2 BSP in the <filename>meta-fri2</filename> BSP layer
+                            as an example.</para></listitem>
+                        <listitem><para><emphasis>Layer Configuration File:</emphasis>
+                            You must include a <filename>conf/layer.conf</filename> in the
+                            <filename>meta-<replaceable>bsp_name</replaceable></filename> directory.
+                            This file identifies the <filename>meta-<replaceable>bsp_name</replaceable></filename>
+                            BSP layer as a layer to the build system.</para></listitem>
+                        <listitem><para><emphasis>Machine Configuration File:</emphasis>
+                            You must include one or more
+                            <filename>conf/machine/<replaceable>bsp_name</replaceable>.conf</filename>
+                            files in the <filename>meta-<replaceable>bsp_name</replaceable></filename> directory.
+                            These configuration files define machine targets that can be built
+                            using the BSP layer.
+                            Multiple machine configuration files define variations of machine
+                            configurations that are supported by the BSP.
+                            If a BSP supports multiple machine variations, you need to
+                            adequately describe each variation in the BSP
+                            <filename>README</filename> file.
+                            Do not use multiple machine configuration files to describe disparate
+                            hardware.
+                            If you do have very different targets, you should create separate
+                            BSP layers for each target.
+                            <note>It is completely possible for a developer to structure the
+                            working repository as a conglomeration of unrelated BSP
+                            files, and to possibly generate BSPs targeted for release
+                            from that directory using scripts or some other mechanism
+                            (e.g. <filename>meta-yocto-bsp</filename> layer).
+                            Such considerations are outside the scope of this document.</note>
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </section>
+
+            <section id='released-bsp-recommendations'>
+                <title>Released BSP Recommendations</title>
+
+                <para>
+                    Following are recommendations for a released BSP that conforms to the
+                    Yocto Project:
+                    <itemizedlist>
+                        <listitem><para><emphasis>Bootable Images:</emphasis>
+                            BSP releases
+                            can contain one or more bootable images.
+                            Including bootable images allows users to easily try out the BSP
+                            on their own hardware.</para>
+                            <para>In some cases, it might not be convenient to include a
+                            bootable image.
+                            In this case, you might want to make two versions of the
+                            BSP available: one that contains binary images, and one
+                            that does not.
+                            The version that does not contain bootable images avoids
+                            unnecessary download times for users not interested in the images.
+                            </para>
+                            <para>If you need to distribute a BSP and include bootable images or build kernel and
+                            filesystems meant to allow users to boot the BSP for evaluation
+                            purposes, you should put the images and artifacts within a
+                            <filename>binary/</filename> subdirectory located in the
+                            <filename>meta-<replaceable>bsp_name</replaceable></filename> directory.
+                            <note>If you do include a bootable image as part of the BSP and the image
+                            was built by software covered by the GPL or other open source licenses,
+                            it is your responsibility to understand
+                            and meet all licensing requirements, which could include distribution
+                            of source files.</note></para></listitem>
+                        <listitem><para><emphasis>Use a Yocto Linux Kernel:</emphasis>
+                            Kernel recipes in the BSP should be based on a Yocto Linux kernel.
+                            Basing your recipes on these kernels reduces the costs for maintaining
+                            the BSP and increases its scalability.
+                            See the <filename>Yocto Linux Kernel</filename> category in the
+                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>Source Repositories</ulink>
+                            for these kernels.</para></listitem>
+                    </itemizedlist>
+                </para>
+            </section>
+        </section>
+
+        <section id='customizing-a-recipe-for-a-bsp'>
+            <title>Customizing a Recipe for a BSP</title>
+
+            <para>
+               If you plan on customizing a recipe for a particular BSP, you need to do the
+               following:
+               <itemizedlist>
+                   <listitem><para>Create a <filename>.bbappend</filename>
+                       file for the modified recipe.
+                       For information on using append files, see the
+                       "<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files</ulink>"
+                       section in the Yocto Project Development Manual.
+                       </para></listitem>
+                   <listitem><para>
+                       Ensure your directory structure in the BSP layer
+                       that supports your machine is such that it can be found
+                       by the build system.
+                       See the example later in this section for more information.
+                       </para></listitem>
+                   <listitem><para>
+                       Put the append file in a directory whose name matches
+                       the machine's name and is located in an appropriate
+                       sub-directory inside the BSP layer (i.e.
+                       <filename>recipes-bsp</filename>, <filename>recipes-graphics</filename>,
+                       <filename>recipes-core</filename>, and so forth).
+                       </para></listitem>
+                   <listitem><para>Place the BSP-specific files in the directory named for
+                       your machine inside the BSP layer.
+                       </para></listitem>
+               </itemizedlist>
+           </para>
+
+           <para>
+               Following is a specific example to help you better understand the process.
+               Consider an example that customizes a recipe by adding
+               a BSP-specific configuration file named <filename>interfaces</filename> to the
+               <filename>init-ifupdown_1.0.bb</filename> recipe for machine "xyz".
+               Do the following:
+               <orderedlist>
+                   <listitem><para>Edit the <filename>init-ifupdown_1.0.bbappend</filename> file so that it
+                       contains the following:
+                       <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+                       </literallayout>
+                       The append file needs to be in the
+                       <filename>meta-xyz/recipes-core/init-ifupdown</filename> directory.
+                       </para></listitem>
+                   <listitem><para>Create and place the new <filename>interfaces</filename>
+                       configuration file in the BSP's layer here:
+                       <literallayout class='monospaced'>
+     meta-xyz/recipes-core/init-ifupdown/files/xyz/interfaces
+                       </literallayout>
+                       The
+                       <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+                       variable in the append files extends the search path
+                       the build system uses to find files during the build.
+                       Consequently, for this example you need to have the
+                       <filename>files</filename> directory in the same location
+                       as your append file.</para></listitem>
+               </orderedlist>
+            </para>
+        </section>
+
+        <section id='bsp-licensing-considerations'>
+            <title>BSP Licensing Considerations</title>
+
+            <para>
+                In some cases, a BSP contains separately licensed Intellectual Property (IP)
+                for a component or components.
+                For these cases, you are required to accept the terms of a commercial or other
+                type of license that requires some kind of explicit End User License Agreement (EULA).
+                Once the license is accepted, the OpenEmbedded build system can then build and
+                include the corresponding component in the final BSP image.
+                If the BSP is available as a pre-built image, you can download the image after
+                agreeing to the license or EULA.
+            </para>
+
+            <para>
+                You could find that some separately licensed components that are essential
+                for normal operation of the system might not have an unencumbered (or free)
+                substitute.
+                Without these essential components, the system would be non-functional.
+                Then again, you might find that other licensed components that are simply
+                'good-to-have' or purely elective do have an unencumbered, free replacement
+                component that you can use rather than agreeing to the separately licensed component.
+                Even for components essential to the system, you might find an unencumbered component
+                that is not identical but will work as a less-capable version of the
+                licensed version in the BSP recipe.
+            </para>
+
+            <para>
+                For cases where you can substitute a free component and still
+                maintain the system's functionality, the "Downloads" page from the
+                <ulink url='&YOCTO_HOME_URL;'>Yocto Project website's</ulink>
+                makes available de-featured BSPs
+                that are completely free of any IP encumbrances.
+                For these cases, you can use the substitution directly and
+                without any further licensing requirements.
+                If present, these fully de-featured BSPs are named appropriately
+                different as compared to the names of the respective
+                encumbered BSPs.
+                If available, these substitutions are your
+                simplest and most preferred options.
+                Use of these substitutions of course assumes the resulting functionality meets
+                system requirements.
+            </para>
+
+            <para>
+                If however, a non-encumbered version is unavailable or
+                it provides unsuitable functionality or quality, you can use an encumbered
+                version.
+            </para>
+
+            <para>
+                A couple different methods exist within the OpenEmbedded build system to
+                satisfy the licensing requirements for an encumbered BSP.
+                The following list describes them in order of preference:
+                <orderedlist>
+                    <listitem><para><emphasis>Use the
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE_FLAGS'><filename>LICENSE_FLAGS</filename></ulink>
+                        variable to define the recipes that have commercial or other
+                        types of specially-licensed packages:</emphasis>
+                        For each of those recipes, you can
+                        specify a matching license string in a
+                        <filename>local.conf</filename> variable named
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE_FLAGS_WHITELIST'><filename>LICENSE_FLAGS_WHITELIST</filename></ulink>.
+                        Specifying the matching license string signifies that you agree to the license.
+                        Thus, the build system can build the corresponding recipe and include
+                        the component in the image.
+                        See the
+                        "<ulink url='&YOCTO_DOCS_REF_URL;#enabling-commercially-licensed-recipes'>Enabling
+                        Commercially Licensed Recipes</ulink>" section in the Yocto Project Reference
+                        Manual for details on how to use these variables.</para>
+                        <para>If you build as you normally would, without
+                        specifying any recipes in the
+                        <filename>LICENSE_FLAGS_WHITELIST</filename>, the build stops and
+                        provides you with the list of recipes that you have
+                        tried to include in the image that need entries in
+                        the <filename>LICENSE_FLAGS_WHITELIST</filename>.
+                        Once you enter the appropriate license flags into the whitelist,
+                        restart the build to continue where it left off.
+                        During the build, the prompt will not appear again
+                        since you have satisfied the requirement.</para>
+                        <para>Once the appropriate license flags are on the white list
+                        in the <filename>LICENSE_FLAGS_WHITELIST</filename> variable, you
+                        can build the encumbered image with no change at all
+                        to the normal build process.</para></listitem>
+                    <listitem><para><emphasis>Get a pre-built version of the BSP:</emphasis>
+                        You can get this type of BSP by visiting the
+                        "Downloads" page of the
+                        <ulink url='&YOCTO_HOME_URL;'>Yocto Project website</ulink>.
+                        You can download BSP tarballs that contain proprietary components
+                        after agreeing to the licensing
+                        requirements of each of the individually encumbered
+                        packages as part of the download process.
+                        Obtaining the BSP this way allows you to access an encumbered
+                        image immediately after agreeing to the
+                        click-through license agreements presented by the
+                        website.
+                        Note that if you want to build the image
+                        yourself using the recipes contained within the BSP
+                        tarball, you will still need to create an
+                        appropriate <filename>LICENSE_FLAGS_WHITELIST</filename> to match the
+                        encumbered recipes in the BSP.</para></listitem>
+                </orderedlist>
+            </para>
+
+            <note>
+                Pre-compiled images are bundled with
+                a time-limited kernel that runs for a
+                predetermined amount of time (10 days) before it forces
+                the system to reboot.
+                This limitation is meant to discourage direct redistribution
+                of the image.
+                You must eventually rebuild the image if you want to remove this restriction.
+            </note>
+        </section>
+
+        <section id='using-the-yocto-projects-bsp-tools'>
+            <title>Using the Yocto Project's BSP Tools</title>
+
+            <para>
+                The Yocto Project includes a couple of tools that enable
+                you to create a <link linkend='bsp-layers'>BSP layer</link>
+                from scratch and do basic configuration and maintenance
+                of the kernel without ever looking at a Metadata file.
+                These tools are <filename>yocto-bsp</filename> and <filename>yocto-kernel</filename>,
+                respectively.
+            </para>
+
+            <para>
+                The following sections describe the common location and help features as well
+                as provide details for the
+                <filename>yocto-bsp</filename> and <filename>yocto-kernel</filename> tools.
+            </para>
+
+            <section id='common-features'>
+                <title>Common Features</title>
+
+                <para>
+                    Designed to have a  command interface somewhat like
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>, each
+                    tool is structured as a set of sub-commands under a
+                    top-level command.
+                    The top-level command (<filename>yocto-bsp</filename>
+                    or <filename>yocto-kernel</filename>) itself does
+                    nothing but invoke or provide help on the sub-commands
+                    it supports.
+                </para>
+
+                <para>
+                    Both tools reside in the <filename>scripts/</filename> subdirectory
+                    of the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    Consequently, to use the scripts, you must <filename>source</filename> the
+                    environment just as you would when invoking a build:
+                    <literallayout class='monospaced'>
+     $ source oe-init-build-env <replaceable>build_dir</replaceable>
+                    </literallayout>
+                </para>
+
+                <para>
+                    The most immediately useful function is to get help on both tools.
+                    The built-in help system makes it easy to drill down at
+                    any time and view the syntax required for any specific command.
+                    Simply enter the name of the command with the <filename>help</filename>
+                    switch:
+                    <literallayout class='monospaced'>
+     $ yocto-bsp help
+     Usage:
+
+      Create a customized Yocto BSP layer.
+
+      usage: yocto-bsp [--version] [--help] COMMAND [ARGS]
+
+      Current 'yocto-bsp' commands are:
+         create            Create a new Yocto BSP
+         list              List available values for options and BSP properties
+
+      See 'yocto-bsp help COMMAND' for more information on a specific command.
+
+
+     Options:
+       --version    show program's version number and exit
+       -h, --help   show this help message and exit
+       -D, --debug  output debug information
+                    </literallayout>
+                </para>
+
+                <para>
+                    Similarly, entering just the name of a sub-command shows the detailed usage
+                    for that sub-command:
+                    <literallayout class='monospaced'>
+     $ yocto-bsp create
+
+     Usage:
+
+      Create a new Yocto BSP
+
+      usage: yocto-bsp create &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
+             [-i &lt;JSON PROPERTY FILE&gt; | --infile &lt;JSON PROPERTY_FILE&gt;]
+
+      This command creates a Yocto BSP based on the specified parameters.
+      The new BSP will be a new Yocto BSP layer contained by default within
+      the top-level directory specified as 'meta-bsp-name'.  The -o option
+      can be used to place the BSP layer in a directory with a different
+      name and location.
+
+      ...
+                    </literallayout>
+                </para>
+
+                <para>
+                    For any sub-command, you can use the word "help" option just before the
+                    sub-command to get more extensive documentation:
+                    <literallayout class='monospaced'>
+     $ yocto-bsp help create
+
+     NAME
+         yocto-bsp create - Create a new Yocto BSP
+
+     SYNOPSIS
+         yocto-bsp create &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
+             [-i &lt;JSON PROPERTY FILE&gt; | --infile &lt;JSON PROPERTY_FILE&gt;]
+
+     DESCRIPTION
+         This command creates a Yocto BSP based on the specified
+         parameters.  The new BSP will be a new Yocto BSP layer contained
+         by default within the top-level directory specified as
+         'meta-bsp-name'.  The -o option can be used to place the BSP layer
+         in a directory with a different name and location.
+
+         The value of the 'karch' parameter determines the set of files
+         that will be generated for the BSP, along with the specific set of
+         'properties' that will be used to fill out the BSP-specific
+         portions of the BSP.  The possible values for the 'karch' parameter
+         can be listed via 'yocto-bsp list karch'.
+
+         ...
+                    </literallayout>
+                </para>
+
+                <para>
+                    Now that you know where these two commands reside and how to access information
+                    on them, you should find it relatively straightforward to discover the commands
+                    necessary to create a BSP and perform basic kernel maintenance on that BSP using
+                    the tools.
+                    <note>
+                        You can also use the <filename>yocto-layer</filename> tool to create
+                        a "generic" layer.
+                        For information on this tool, see the
+                        "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-general-layer-using-the-yocto-layer-script'>Creating a General Layer Using the yocto-layer Script</ulink>"
+                        section in the Yocto Project Development Guide.
+                    </note>
+                </para>
+
+                <para>
+                    The next sections provide a concrete starting point to expand on a few points that
+                    might not be immediately obvious or that could use further explanation.
+                </para>
+            </section>
+
+
+            <section id='creating-a-new-bsp-layer-using-the-yocto-bsp-script'>
+                <title>Creating a new BSP Layer Using the yocto-bsp Script</title>
+
+                <para>
+                    The <filename>yocto-bsp</filename> script creates a new
+                    <link linkend='bsp-layers'>BSP layer</link> for any architecture supported
+                    by the Yocto Project, as well as QEMU versions of the same.
+                    The default mode of the script's operation is to prompt you for information needed
+                    to generate the BSP layer.
+                </para>
+
+                <para>
+                    For the current set of BSPs, the script prompts you for various important
+                    parameters such as:
+                    <itemizedlist>
+                        <listitem><para>The kernel to use</para></listitem>
+                        <listitem><para>The branch of that kernel to use (or re-use)</para></listitem>
+                        <listitem><para>Whether or not to use X, and if so, which drivers to use</para></listitem>
+                        <listitem><para>Whether to turn on SMP</para></listitem>
+                        <listitem><para>Whether the BSP has a keyboard</para></listitem>
+                        <listitem><para>Whether the BSP has a touchscreen</para></listitem>
+                        <listitem><para>Remaining configurable items associated with the BSP</para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    You use the <filename>yocto-bsp create</filename> sub-command to create
+                    a new BSP layer.
+                    This command requires you to specify a particular kernel architecture
+                    (<filename>karch</filename>) on which to base the BSP.
+                    Assuming you have sourced the environment, you can use the
+                    <filename>yocto-bsp list karch</filename> sub-command to list the
+                    architectures available for BSP creation as follows:
+                    <literallayout class='monospaced'>
+     $ yocto-bsp list karch
+     Architectures available:
+         powerpc
+         i386
+         x86_64
+         arm
+         qemu
+         mips
+                    </literallayout>
+                </para>
+
+                <para>
+                    The remainder of this section presents an example that uses
+                    <filename>myarm</filename> as the machine name and <filename>qemu</filename>
+                    as the machine architecture.
+                    Of the available architectures, <filename>qemu</filename> is the only architecture
+                    that causes the script to prompt you further for an actual architecture.
+                    In every other way, this architecture is representative of how creating a BSP for
+                    an actual machine would work.
+                    The reason the example uses this architecture is because it is an emulated architecture
+                    and can easily be followed without requiring actual hardware.
+                </para>
+
+                <para>
+                    As the <filename>yocto-bsp create</filename> command runs, default values for
+                    the prompts appear in brackets.
+                    Pressing enter without supplying anything on the command line or pressing enter
+                    with an invalid response causes the script to accept the default value.
+                    Once the script completes, the new <filename>meta-myarm</filename> BSP layer
+                    is created in the current working directory.
+                    This example assumes you have sourced the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                    setup script.
+                </para>
+
+                <para>
+                    Following is the complete example:
+                    <literallayout class='monospaced'>
+     $ yocto-bsp create myarm qemu
+     Checking basic git connectivity...
+     Done.
+
+     Which qemu architecture would you like to use? [default: i386]
+             1) i386    (32-bit)
+             2) x86_64  (64-bit)
+             3) ARM     (32-bit)
+             4) PowerPC (32-bit)
+             5) MIPS    (32-bit)
+     3
+     Would you like to use the default (3.10) kernel? (y/n) [default: y] y
+     Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [y/n] [default: y]
+     Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.10.git...
+     Please choose a machine branch to base your new BSP branch on: [default: standard/base]
+             1) standard/arm-versatile-926ejs
+             2) standard/base
+             3) standard/beagleboard
+             4) standard/beaglebone
+             5) standard/ck
+             6) standard/crownbay
+             7) standard/edgerouter
+             8) standard/emenlow
+             9) standard/fri2
+             10) standard/fsl-mpc8315e-rdb
+             11) standard/mti-malta32
+             12) standard/mti-malta64
+             13) standard/qemuppc
+             14) standard/routerstationpro
+             15) standard/sys940x
+     1
+     Would you like SMP support? (y/n) [default: y]
+     Does your BSP have a touchscreen? (y/n) [default: n]
+     Does your BSP have a keyboard? (y/n) [default: y]
+
+     New qemu BSP created in meta-myarm
+                    </literallayout>
+                    Take a closer look at the example now:
+                    <orderedlist>
+                        <listitem><para>For the QEMU architecture,
+                            the script first prompts you for which emulated architecture to use.
+                            In the example, we use the ARM architecture.
+                            </para></listitem>
+                        <listitem><para>The script then prompts you for the kernel.
+                            The default 3.14 kernel is acceptable.
+                            So, the example accepts the default.
+                            If you enter 'n', the script prompts you to further enter the kernel
+                            you do want to use.</para></listitem>
+                        <listitem><para>Next, the script asks whether you would like to have a new
+                            branch created especially for your BSP in the local
+                            <ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink>
+                            Git repository .
+                            If not, then the script re-uses an existing branch.</para>
+                            <para>In this example, the default (or "yes") is accepted.
+                            Thus, a new branch is created for the BSP rather than using a common, shared
+                            branch.
+                            The new branch is the branch committed to for any patches you might later add.
+                            The reason a new branch is the default is that typically
+                            new BSPs do require BSP-specific patches.
+                            The tool thus assumes that most of time a new branch is required.
+                            </para></listitem>
+                        <listitem><para>Regardless of which choice you make in the previous step,
+                            you are now given the opportunity to select a particular machine branch on
+                            which to base your new BSP-specific machine branch
+                            (or to re-use if you had elected to not create a new branch).
+                            Because this example is generating an ARM-based BSP, the example
+                            uses <filename>#1</filename> at the prompt, which selects the ARM-versatile branch.
+                            </para></listitem>
+                        <listitem><para>The remainder of the prompts are routine.
+                            Defaults are accepted for each.</para></listitem>
+                        <listitem><para>By default, the script creates the new BSP Layer in the
+                            current working directory of the
+                            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
+                            (i.e. <filename>poky/build</filename>).
+                            </para></listitem>
+                    </orderedlist>
+                </para>
+
+                <para>
+                    Once the BSP Layer is created, you must add it to your
+                    <filename>bblayers.conf</filename> file.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     BBLAYERS = ? " \
+        /usr/local/src/yocto/meta \
+        /usr/local/src/yocto/meta-yocto \
+        /usr/local/src/yocto/meta-yocto-bsp \
+        /usr/local/src/yocto/meta-myarm \
+        "
+
+     BBLAYERS_NON_REMOVABLE ?= " \
+        /usr/local/src/yocto/meta \
+        /usr/local/src/yocto/meta-yocto \
+        "
+                    </literallayout>
+                    Adding the layer to this file allows the build system to build the BSP and
+                    the <filename>yocto-kernel</filename> tool to be able to find the layer and
+                    other Metadata it needs on which to operate.
+                </para>
+            </section>
+
+            <section id='managing-kernel-patches-and-config-items-with-yocto-kernel'>
+                <title>Managing Kernel Patches and Config Items with yocto-kernel</title>
+
+                <para>
+                    Assuming you have created a <link linkend='bsp-layers'>BSP Layer</link> using
+                    <link linkend='creating-a-new-bsp-layer-using-the-yocto-bsp-script'>
+                    <filename>yocto-bsp</filename></link> and you added it to your
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink>
+                    variable in the <filename>bblayers.conf</filename> file, you can now use
+                    the <filename>yocto-kernel</filename> script to add patches and configuration
+                    items to the BSP's kernel.
+                </para>
+
+                <para>
+                    The <filename>yocto-kernel</filename> script allows you to add, remove, and list patches
+                    and kernel config settings to a BSP's kernel
+                    <filename>.bbappend</filename> file.
+                    All you need to do is use the appropriate sub-command.
+                    Recall that the easiest way to see exactly what sub-commands are available
+                    is to use the <filename>yocto-kernel</filename> built-in help as follows:
+                    <literallayout class='monospaced'>
+     $ yocto-kernel
+     Usage:
+
+      Modify and list Yocto BSP kernel config items and patches.
+
+      usage: yocto-kernel [--version] [--help] COMMAND [ARGS]
+
+      Current 'yocto-kernel' commands are:
+        config list       List the modifiable set of bare kernel config options for a BSP
+        config add        Add or modify bare kernel config options for a BSP
+        config rm         Remove bare kernel config options from a BSP
+        patch list        List the patches associated with a BSP
+        patch add         Patch the Yocto kernel for a BSP
+        patch rm          Remove patches from a BSP
+        feature list      List the features used by a BSP
+        feature add       Have a BSP use a feature
+        feature rm        Have a BSP stop using a feature
+        features list     List the features available to BSPs
+        feature describe  Describe a particular feature
+        feature create    Create a new BSP-local feature
+        feature destroy   Remove a BSP-local feature
+
+      See 'yocto-kernel help COMMAND' for more information on a specific command.
+
+
+
+     Options:
+       --version    show program's version number and exit
+       -h, --help   show this help message and exit
+       -D, --debug  output debug information
+                    </literallayout>
+                </para>
+
+                <para>
+                    The <filename>yocto-kernel patch add</filename> sub-command allows you to add a
+                    patch to a BSP.
+                    The following example adds two patches to the <filename>myarm</filename> BSP:
+                    <literallayout class='monospaced'>
+     $ yocto-kernel patch add myarm ~/test.patch
+     Added patches:
+             test.patch
+
+     $ yocto-kernel patch add myarm ~/yocto-testmod.patch
+     Added patches:
+             yocto-testmod.patch
+                    </literallayout>
+                    <note>Although the previous example adds patches one at a time, it is possible
+                    to add multiple patches at the same time.</note>
+                </para>
+
+                <para>
+                    You can verify patches have been added by using the
+                    <filename>yocto-kernel patch list</filename> sub-command.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     $ yocto-kernel patch list myarm
+     The current set of machine-specific patches for myarm is:
+             1) test.patch
+             2) yocto-testmod.patch
+                    </literallayout>
+                </para>
+
+                <para>
+                    You can also use the <filename>yocto-kernel</filename> script to
+                    remove a patch using the <filename>yocto-kernel patch rm</filename> sub-command.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     $ yocto-kernel patch rm myarm
+     Specify the patches to remove:
+             1) test.patch
+             2) yocto-testmod.patch
+     1
+     Removed patches:
+             test.patch
+                    </literallayout>
+                </para>
+
+                <para>
+                    Again, using the <filename>yocto-kernel patch list</filename> sub-command,
+                    you can verify that the patch was in fact removed:
+                    <literallayout class='monospaced'>
+     $ yocto-kernel patch list myarm
+     The current set of machine-specific patches for myarm is:
+             1) yocto-testmod.patch
+                    </literallayout>
+                </para>
+
+                <para>
+                    In a completely similar way, you can use the <filename>yocto-kernel config add</filename>
+                    sub-command to add one or more kernel config item settings to a BSP.
+                    The following commands add a couple of config items to the
+                    <filename>myarm</filename> BSP:
+                    <literallayout class='monospaced'>
+     $ yocto-kernel config add myarm CONFIG_MISC_DEVICES=y
+     Added items:
+             CONFIG_MISC_DEVICES=y
+
+     $ yocto-kernel config add myarm CONFIG_YOCTO_TESTMOD=y
+     Added items:
+             CONFIG_YOCTO_TESTMOD=y
+                    </literallayout>
+                    <note>Although the previous example adds config items one at a time, it is possible
+                    to add multiple config items at the same time.</note>
+                </para>
+
+                <para>
+                    You can list the config items now associated with the BSP.
+                    Doing so shows you the config items you added as well as others associated
+                    with the BSP:
+                    <literallayout class='monospaced'>
+     $ yocto-kernel config list myarm
+     The current set of machine-specific kernel config items for myarm is:
+             1) CONFIG_MISC_DEVICES=y
+             2) CONFIG_YOCTO_TESTMOD=y
+                    </literallayout>
+                </para>
+
+                <para>
+                    Finally, you can remove one or more config items using the
+                    <filename>yocto-kernel config rm</filename> sub-command in a manner
+                    completely analogous to <filename>yocto-kernel patch rm</filename>.
+                </para>
+            </section>
+        </section>
+</chapter>
diff --git a/documentation/bsp-guide/figures/bsp-title.png b/documentation/bsp-guide/figures/bsp-title.png
new file mode 100644
index 0000000000..f624dd4f94
--- /dev/null
+++ b/documentation/bsp-guide/figures/bsp-title.png
diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml
new file mode 100644
index 0000000000..64504299cc
--- /dev/null
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -0,0 +1,9738 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='extendpoky'>
+
+<title>Common Tasks</title>
+    <para>
+        This chapter describes fundamental procedures such as creating layers,
+        adding new software packages, extending or customizing images,
+        porting work to new hardware (adding a new machine), and so forth.
+        You will find that the procedures documented here occur often in the
+        development cycle using the Yocto Project.
+    </para>
+
+    <section id="understanding-and-creating-layers">
+        <title>Understanding and Creating Layers</title>
+
+        <para>
+            The OpenEmbedded build system supports organizing
+            <link linkend='metadata'>Metadata</link> into multiple layers.
+            Layers allow you to isolate different types of customizations from
+            each other.
+            You might find it tempting to keep everything in one layer when
+            working on a single project.
+            However, the more modular your Metadata, the easier
+            it is to cope with future changes.
+        </para>
+
+        <para>
+            To illustrate how layers are used to keep things modular, consider
+            machine customizations.
+            These types of customizations typically reside in a special layer,
+            rather than a general layer, called a Board Support Package (BSP)
+            Layer.
+            Furthermore, the machine customizations should be isolated from
+            recipes and Metadata that support a new GUI environment,
+            for example.
+            This situation gives you a couple of layers: one for the machine
+            configurations, and one for the GUI environment.
+            It is important to understand, however, that the BSP layer can
+            still make machine-specific additions to recipes within the GUI
+            environment layer without polluting the GUI layer itself
+            with those machine-specific changes.
+            You can accomplish this through a recipe that is a BitBake append
+            (<filename>.bbappend</filename>) file, which is described later
+            in this section.
+        </para>
+
+        <para>
+        </para>
+
+        <section id='yocto-project-layers'>
+            <title>Layers</title>
+
+            <para>
+                The <link linkend='source-directory'>Source Directory</link>
+                contains both general layers and BSP
+                layers right out of the box.
+                You can easily identify layers that ship with a
+                Yocto Project release in the Source Directory by their
+                folder names.
+                Folders that represent layers typically have names that begin with
+                the string <filename>meta-</filename>.
+                <note>
+                    It is not a requirement that a layer name begin with the
+                    prefix <filename>meta-</filename>, but it is a commonly
+                    accepted standard in the Yocto Project community.
+                </note>
+                For example, when you set up the Source Directory structure,
+                you will see several layers:
+                <filename>meta</filename>,
+                <filename>meta-skeleton</filename>,
+                <filename>meta-selftest</filename>,
+                <filename>meta-yocto</filename>, and
+                <filename>meta-yocto-bsp</filename>.
+                Each of these folders represents a distinct layer.
+            </para>
+
+            <para>
+                As another example, if you set up a local copy of the
+                <filename>meta-intel</filename> Git repository
+                and then explore the folder of that general layer,
+                you will discover many Intel-specific BSP layers inside.
+                For more information on BSP layers, see the
+                "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
+                section in the Yocto Project Board Support Package (BSP)
+                Developer's Guide.
+            </para>
+        </section>
+
+        <section id='creating-your-own-layer'>
+            <title>Creating Your Own Layer</title>
+
+            <para>
+                It is very easy to create your own layers to use with the
+                OpenEmbedded build system.
+                The Yocto Project ships with scripts that speed up creating
+                general layers and BSP layers.
+                This section describes the steps you perform by hand to create
+                a layer so that you can better understand them.
+                For information about the layer-creation scripts, see the
+                "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>"
+                section in the Yocto Project Board Support Package (BSP)
+                Developer's Guide and the
+                "<link linkend='creating-a-general-layer-using-the-yocto-layer-script'>Creating a General Layer Using the yocto-layer Script</link>"
+                section further down in this manual.
+            </para>
+
+            <para>
+                Follow these general steps to create your layer:
+                <orderedlist>
+                    <listitem><para><emphasis>Check Existing Layers:</emphasis>
+                        Before creating a new layer, you should be sure someone
+                        has not already created a layer containing the Metadata
+                        you need.
+                        You can see the
+                        <ulink url='http://layers.openembedded.org/layerindex/layers/'><filename>OpenEmbedded Metadata Index</filename></ulink>
+                        for a list of layers from the OpenEmbedded community
+                        that can be used in the Yocto Project.
+                        </para></listitem>
+                    <listitem><para><emphasis>Create a Directory:</emphasis>
+                        Create the directory for your layer.
+                        While not strictly required, prepend the name of the
+                        folder with the string <filename>meta-</filename>.
+                        For example:
+                        <literallayout class='monospaced'>
+     meta-mylayer
+     meta-GUI_xyz
+     meta-mymachine
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para><emphasis>Create a Layer Configuration
+                       File:</emphasis>
+                       Inside your new layer folder, you need to create a
+                       <filename>conf/layer.conf</filename> file.
+                       It is easiest to take an existing layer configuration
+                       file and copy that to your layer's
+                       <filename>conf</filename> directory and then modify the
+                       file as needed.</para>
+                       <para>The
+                       <filename>meta-yocto-bsp/conf/layer.conf</filename> file
+                       demonstrates the required syntax:
+                       <literallayout class='monospaced'>
+     # We have a conf and classes directory, add to BBPATH
+     BBPATH .= ":${LAYERDIR}"
+
+     # We have recipes-* directories, add to BBFILES
+     BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
+                 ${LAYERDIR}/recipes-*/*/*.bbappend"
+
+     BBFILE_COLLECTIONS += "yoctobsp"
+     BBFILE_PATTERN_yoctobsp = "^${LAYERDIR}/"
+     BBFILE_PRIORITY_yoctobsp = "5"
+     LAYERVERSION_yoctobsp = "3"
+                        </literallayout></para>
+                        <para>Here is an explanation of the example:
+                        <itemizedlist>
+                            <listitem><para>The configuration and
+                                classes directory is appended to
+                                <ulink url='&YOCTO_DOCS_REF_URL;#var-BBPATH'><filename>BBPATH</filename></ulink>.
+                                <note>
+                                    All non-distro layers, which include all BSP
+                                    layers, are expected to append the layer
+                                    directory to the
+                                    <filename>BBPATH</filename>.
+                                    On the other hand, distro layers, such as
+                                    <filename>meta-yocto</filename>, can choose
+                                    to enforce their own precedence over
+                                    <filename>BBPATH</filename>.
+                                    For an example of that syntax, see the
+                                    <filename>layer.conf</filename> file for
+                                    the <filename>meta-yocto</filename> layer.
+                                </note></para></listitem>
+                            <listitem><para>The recipes for the layers are
+                                appended to
+                                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILES'>BBFILES</ulink></filename>.
+                                </para></listitem>
+                            <listitem><para>The
+                                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILE_COLLECTIONS'>BBFILE_COLLECTIONS</ulink></filename>
+                                variable is then appended with the layer name.
+                                </para></listitem>
+                            <listitem><para>The
+                                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILE_PATTERN'>BBFILE_PATTERN</ulink></filename>
+                                variable is set to a regular expression and is
+                                used to match files from
+                                <filename>BBFILES</filename> into a particular
+                                layer.
+                                In this case,
+                                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERDIR'>LAYERDIR</ulink></filename>
+                                is used to make <filename>BBFILE_PATTERN</filename> match within the
+                                layer's path.</para></listitem>
+                            <listitem><para>The
+                                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILE_PRIORITY'>BBFILE_PRIORITY</ulink></filename>
+                                variable then assigns a priority to the layer.
+                                Applying priorities is useful in situations
+                                where the same recipe might appear in multiple
+                                layers and allows you to choose the layer
+                                that takes precedence.</para></listitem>
+                            <listitem><para>The
+                                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERVERSION'>LAYERVERSION</ulink></filename>
+                                variable optionally specifies the version of a
+                                layer as a single number.</para></listitem>
+                        </itemizedlist></para>
+                        <para>Note the use of the
+                        <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERDIR'>LAYERDIR</ulink></filename>
+                        variable, which expands to the directory of the current
+                        layer.</para>
+                        <para>Through the use of the <filename>BBPATH</filename>
+                        variable, BitBake locates class files
+                        (<filename>.bbclass</filename>),
+                        configuration files, and files that are included
+                        with <filename>include</filename> and
+                        <filename>require</filename> statements.
+                        For these cases, BitBake uses the first file that
+                        matches the name found in <filename>BBPATH</filename>.
+                        This is similar to the way the <filename>PATH</filename>
+                        variable is used for binaries.
+                        It is recommended, therefore, that you use unique
+                        class and configuration
+                        filenames in your custom layer.</para></listitem>
+                    <listitem><para><emphasis>Add Content:</emphasis> Depending
+                        on the type of layer, add the content.
+                        If the layer adds support for a machine, add the machine
+                        configuration in a <filename>conf/machine/</filename>
+                        file within the layer.
+                        If the layer adds distro policy, add the distro
+                        configuration in a <filename>conf/distro/</filename>
+                        file within the layer.
+                        If the layer introduces new recipes, put the recipes
+                        you need in <filename>recipes-*</filename>
+                        subdirectories within the layer.
+                        <note>In order to be compliant with the Yocto Project,
+                            a layer must contain a
+                            <ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-readme'>README file.</ulink>
+                            </note></para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+
+        <section id='best-practices-to-follow-when-creating-layers'>
+            <title>Best Practices to Follow When Creating Layers</title>
+
+            <para>
+                To create layers that are easier to maintain and that will
+                not impact builds for other machines, you should consider the
+                information in the following sections.
+            </para>
+
+            <section id='avoid-overlaying-entire-recipes'>
+                <title>Avoid "Overlaying" Entire Recipes</title>
+
+                <para>
+                    Avoid "overlaying" entire recipes from other layers in your
+                    configuration.
+                    In other words, do not copy an entire recipe into your
+                    layer and then modify it.
+                    Rather, use an append file (<filename>.bbappend</filename>)
+                    to override
+                    only those parts of the original recipe you need to modify.
+                </para>
+            </section>
+
+            <section id='avoid-duplicating-include-files'>
+                <title>Avoid Duplicating Include Files</title>
+
+                <para>
+                    Avoid duplicating include files.
+                    Use append files (<filename>.bbappend</filename>)
+                    for each recipe
+                    that uses an include file.
+                    Or, if you are introducing a new recipe that requires
+                    the included file, use the path relative to the original
+                    layer directory to refer to the file.
+                    For example, use
+                    <filename>require recipes-core/somepackage/somefile.inc</filename>
+                    instead of <filename>require somefile.inc</filename>.
+                    If you're finding you have to overlay the include file,
+                    it could indicate a deficiency in the include file in
+                    the layer to which it originally belongs.
+                    If this is the case, you need to address that deficiency
+                    instead of overlaying the include file.
+                </para>
+
+                <para>
+                    For example, consider how support plug-ins for the Qt 4
+                    database are configured.
+                    The Source Directory does not have MySQL or PostgreSQL.
+                    However, OpenEmbedded's layer <filename>meta-oe</filename>
+                    does.
+                    Consequently, <filename>meta-oe</filename> uses
+                    append files to modify the
+                    <filename>QT_SQL_DRIVER_FLAGS</filename> variable to
+                    enable the appropriate plug-ins.
+                    This variable was added to the <filename>qt4.inc</filename>
+                    include file in the Source Directory specifically to allow
+                    the <filename>meta-oe</filename> layer to be able to control
+                    which plug-ins are built.
+                </para>
+            </section>
+
+            <section id='structure-your-layers'>
+                <title>Structure Your Layers</title>
+
+                <para>
+                    Proper use of overrides within append files and placement
+                    of machine-specific files within your layer can ensure that
+                    a build is not using the wrong Metadata and negatively
+                    impacting a build for a different machine.
+                    Following are some examples:
+                    <itemizedlist>
+                        <listitem><para><emphasis>Modifying Variables to Support
+                            a Different Machine:</emphasis>
+                            Suppose you have a layer named
+                            <filename>meta-one</filename> that adds support
+                            for building machine "one".
+                            To do so, you use an append file named
+                            <filename>base-files.bbappend</filename> and
+                            create a dependency on "foo" by altering the
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink>
+                            variable:
+                            <literallayout class='monospaced'>
+     DEPENDS = "foo"
+                            </literallayout>
+                            The dependency is created during any build that
+                            includes the layer
+                            <filename>meta-one</filename>.
+                            However, you might not want this dependency
+                            for all machines.
+                            For example, suppose you are building for
+                            machine "two" but your
+                            <filename>bblayers.conf</filename> file has the
+                            <filename>meta-one</filename> layer included.
+                            During the build, the
+                            <filename>base-files</filename> for machine
+                            "two" will also have the dependency on
+                            <filename>foo</filename>.</para>
+                            <para>To make sure your changes apply only when
+                            building machine "one", use a machine override
+                            with the <filename>DEPENDS</filename> statement:
+                            <literallayout class='monospaced'>
+     DEPENDS_one = "foo"
+                            </literallayout>
+                            You should follow the same strategy when using
+                            <filename>_append</filename> and
+                            <filename>_prepend</filename> operations:
+                            <literallayout class='monospaced'>
+     DEPENDS_append_one = " foo"
+     DEPENDS_prepend_one = "foo "
+                            </literallayout>
+                            As an actual example, here's a line from the recipe for
+                            the OProfile profiler, which lists an extra build-time
+                            dependency when building specifically for 64-bit PowerPC:
+                            <literallayout class='monospaced'>
+     DEPENDS_append_powerpc64 = " libpfm4"
+                            </literallayout>
+                            <note>
+                                Avoiding "+=" and "=+" and using
+                                machine-specific
+                                <filename>_append</filename>
+                                and <filename>_prepend</filename> operations
+                                is recommended as well.
+                            </note></para></listitem>
+                        <listitem><para><emphasis>Place Machine-Specific Files
+                            in Machine-Specific Locations:</emphasis>
+                            When you have a base recipe, such as
+                            <filename>base-files.bb</filename>, that
+                            contains a
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                            statement to a file, you can use an append file
+                            to cause the build to use your own version of
+                            the file.
+                            For example, an append file in your layer at
+                            <filename>meta-one/recipes-core/base-files/base-files.bbappend</filename>
+                            could extend
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
+                            using
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+                            as follows:
+                            <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
+                            </literallayout>
+                            The build for machine "one" will pick up your
+                            machine-specific file as long as you have the
+                            file in
+                            <filename>meta-one/recipes-core/base-files/base-files/</filename>.
+                            However, if you are building for a different
+                            machine and the
+                            <filename>bblayers.conf</filename> file includes
+                            the <filename>meta-one</filename> layer and
+                            the location of your machine-specific file is
+                            the first location where that file is found
+                            according to <filename>FILESPATH</filename>,
+                            builds for all machines will also use that
+                            machine-specific file.</para>
+                            <para>You can make sure that a machine-specific
+                            file is used for a particular machine by putting
+                            the file in a subdirectory specific to the
+                            machine.
+                            For example, rather than placing the file in
+                            <filename>meta-one/recipes-core/base-files/base-files/</filename>
+                            as shown above, put it in
+                            <filename>meta-one/recipes-core/base-files/base-files/one/</filename>.
+                            Not only does this make sure the file is used
+                            only when building for machine "one", but the
+                            build process locates the file more quickly.</para>
+                            <para>In summary, you need to place all files
+                            referenced from <filename>SRC_URI</filename>
+                            in a machine-specific subdirectory within the
+                            layer in order to restrict those files to
+                            machine-specific builds.</para></listitem>
+                    </itemizedlist>
+                </para>
+            </section>
+
+            <section id='other-recommendations'>
+                <title>Other Recommendations</title>
+
+                <para>
+                    We also recommend the following:
+                    <itemizedlist>
+                        <listitem><para>Store custom layers in a Git repository
+                            that uses the
+                            <filename>meta-<replaceable>layer_name</replaceable></filename> format.
+                            </para></listitem>
+                        <listitem><para>Clone the repository alongside other
+                            <filename>meta</filename> directories in the
+                            <link linkend='source-directory'>Source Directory</link>.
+                            </para></listitem>
+                     </itemizedlist>
+                     Following these recommendations keeps your Source Directory and
+                     its configuration entirely inside the Yocto Project's core
+                     base.
+                </para>
+            </section>
+        </section>
+
+        <section id='enabling-your-layer'>
+            <title>Enabling Your Layer</title>
+
+            <para>
+                Before the OpenEmbedded build system can use your new layer,
+                you need to enable it.
+                To enable your layer, simply add your layer's path to the
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'>BBLAYERS</ulink></filename>
+                variable in your <filename>conf/bblayers.conf</filename> file,
+                which is found in the
+                <link linkend='build-directory'>Build Directory</link>.
+                The following example shows how to enable a layer named
+                <filename>meta-mylayer</filename>:
+                <literallayout class='monospaced'>
+     LCONF_VERSION = "6"
+
+     BBPATH = "${TOPDIR}"
+     BBFILES ?= ""
+
+     BBLAYERS ?= " \
+       $HOME/poky/meta \
+       $HOME/poky/meta-yocto \
+       $HOME/poky/meta-yocto-bsp \
+       $HOME/poky/meta-mylayer \
+       "
+
+     BBLAYERS_NON_REMOVABLE ?= " \
+       $HOME/poky/meta \
+       $HOME/poky/meta-yocto \
+       "
+                </literallayout>
+            </para>
+
+            <para>
+                BitBake parses each <filename>conf/layer.conf</filename> file
+                as specified in the <filename>BBLAYERS</filename> variable
+                within the <filename>conf/bblayers.conf</filename> file.
+                During the processing of each
+                <filename>conf/layer.conf</filename> file, BitBake adds the
+                recipes, classes and configurations contained within the
+                particular layer to the source directory.
+            </para>
+        </section>
+
+        <section id='using-bbappend-files'>
+            <title>Using .bbappend Files</title>
+
+            <para>
+                Recipes used to append Metadata to other recipes are called
+                BitBake append files.
+                BitBake append files use the <filename>.bbappend</filename> file
+                type suffix, while the corresponding recipes to which Metadata
+                is being appended use the <filename>.bb</filename> file type
+                suffix.
+            </para>
+
+            <para>
+                A <filename>.bbappend</filename> file allows your layer to make
+                additions or changes to the content of another layer's recipe
+                without having to copy the other recipe into your layer.
+                Your <filename>.bbappend</filename> file resides in your layer,
+                while the main <filename>.bb</filename> recipe file to
+                which you are appending Metadata resides in a different layer.
+            </para>
+
+            <para>
+                Append files must have the same root names as their corresponding
+                recipes.
+                For example, the append file
+                <filename>someapp_&DISTRO;.bbappend</filename> must apply to
+                <filename>someapp_&DISTRO;.bb</filename>.
+                This means the original recipe and append file names are version
+                number-specific.
+                If the corresponding recipe is renamed to update to a newer
+                version, the corresponding <filename>.bbappend</filename> file must
+                be renamed (and possibly updated) as well.
+                During the build process, BitBake displays an error on starting
+                if it detects a <filename>.bbappend</filename> file that does
+                not have a corresponding recipe with a matching name.
+                See the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-BB_DANGLINGAPPENDS_WARNONLY'><filename>BB_DANGLINGAPPENDS_WARNONLY</filename></ulink>
+                variable for information on how to handle this error.
+            </para>
+
+            <para>
+                Being able to append information to an existing recipe not only
+                avoids duplication, but also automatically applies recipe
+                changes in a different layer to your layer.
+                If you were copying recipes, you would have to manually merge
+                changes as they occur.
+            </para>
+
+            <para>
+                As an example, consider the main formfactor recipe and a
+                corresponding formfactor append file both from the
+                <link linkend='source-directory'>Source Directory</link>.
+                Here is the main formfactor recipe, which is named
+                <filename>formfactor_0.0.bb</filename> and located in the
+                "meta" layer at
+                <filename>meta/recipes-bsp/formfactor</filename>:
+                <literallayout class='monospaced'>
+     SUMMARY = "Device formfactor information"
+     SECTION = "base"
+     LICENSE = "MIT"
+     LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
+                    file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+     PR = "r45"
+
+     SRC_URI = "file://config file://machconfig"
+     S = "${WORKDIR}"
+
+     PACKAGE_ARCH = "${MACHINE_ARCH}"
+     INHIBIT_DEFAULT_DEPS = "1"
+
+     do_install() {
+             # Install file only if it has contents
+             install -d ${D}${sysconfdir}/formfactor/
+             install -m 0644 ${S}/config ${D}${sysconfdir}/formfactor/
+             if [ -s "${S}/machconfig" ]; then
+                     install -m 0644 ${S}/machconfig ${D}${sysconfdir}/formfactor/
+             fi
+     }
+                </literallayout>
+                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.
+            </para>
+
+            <para>
+                Following is the append file, which is named
+                <filename>formfactor_0.0.bbappend</filename> and is from the
+                Crown Bay BSP Layer named
+                <filename>meta-intel/meta-crownbay</filename>.
+                The file is in <filename>recipes-bsp/formfactor</filename>:
+                <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+                </literallayout>
+            </para>
+
+            <para>
+                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
+                <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
+                to find files.
+            </para>
+
+            <para>
+                The statement in this example extends the directories to include
+                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-THISDIR'><filename>THISDIR</filename></ulink><filename>}/${</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
+                will be including from the layer.
+            </para>
+
+            <para>
+                Using the immediate expansion assignment operator
+                <filename>:=</filename> is important because of the reference to
+                <filename>THISDIR</filename>.
+                The trailing colon character is important as it ensures that
+                items in the list remain colon-separated.
+                <note>
+                    <para>
+                        BitBake automatically defines the
+                        <filename>THISDIR</filename> variable.
+                        You should never set this variable yourself.
+                        Using "_prepend" ensures your path will
+                        be searched prior to other paths in the final list.
+                    </para>
+
+                    <para>
+                        Also, not all append files add extra files.
+                        Many append files simply exist to add build options
+                        (e.g. <filename>systemd</filename>).
+                        For these cases, it is not necessary to use the
+                        "_prepend" part of the statement.
+                    </para>
+                </note>
+            </para>
+        </section>
+
+        <section id='prioritizing-your-layer'>
+            <title>Prioritizing Your Layer</title>
+
+            <para>
+                Each layer is assigned a priority value.
+                Priority values control which layer takes precedence if there
+                are recipe files with the same name in multiple layers.
+                For these cases, the recipe file from the layer with a higher
+                priority number takes precedence.
+                Priority values also affect the order in which multiple
+                <filename>.bbappend</filename> files for the same recipe are
+                applied.
+                You can either specify the priority manually, or allow the
+                build system to calculate it based on the layer's dependencies.
+            </para>
+
+            <para>
+                To specify the layer's priority manually, use the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILE_PRIORITY'><filename>BBFILE_PRIORITY</filename></ulink>
+                variable.
+                For example:
+                <literallayout class='monospaced'>
+     BBFILE_PRIORITY_mylayer = "1"
+                </literallayout>
+            </para>
+
+            <note>
+                <para>It is possible for a recipe with a lower version number
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>
+                in a layer that has a higher priority to take precedence.</para>
+                <para>Also, the layer priority does not currently affect the
+                precedence order of <filename>.conf</filename>
+                or <filename>.bbclass</filename> files.
+                Future versions of BitBake might address this.</para>
+            </note>
+        </section>
+
+        <section id='managing-layers'>
+            <title>Managing Layers</title>
+
+            <para>
+                You can use the BitBake layer management tool to provide a view
+                into the structure of recipes across a multi-layer project.
+                Being able to generate output that reports on configured layers
+                with their paths and priorities and on
+                <filename>.bbappend</filename> files and their applicable
+                recipes can help to reveal potential problems.
+            </para>
+
+            <para>
+                Use the following form when running the layer management tool.
+                <literallayout class='monospaced'>
+     $ bitbake-layers <replaceable>command</replaceable> [<replaceable>arguments</replaceable>]
+                </literallayout>
+                The following list describes the available commands:
+                <itemizedlist>
+                    <listitem><para><filename><emphasis>help:</emphasis></filename>
+                        Displays general help or help on a specified command.
+                        </para></listitem>
+                    <listitem><para><filename><emphasis>show-layers:</emphasis></filename>
+                        Shows the current configured layers.
+                        </para></listitem>
+                    <listitem><para><filename><emphasis>show-recipes:</emphasis></filename>
+                        Lists available recipes and the layers that provide them.
+                        </para></listitem>
+                    <listitem><para><filename><emphasis>show-overlayed:</emphasis></filename>
+                        Lists overlayed recipes.
+                        A recipe is overlayed when a recipe with the same name
+                        exists in another layer that has a higher layer
+                        priority.
+                        </para></listitem>
+                    <listitem><para><filename><emphasis>show-appends:</emphasis></filename>
+                        Lists <filename>.bbappend</filename> files and the
+                        recipe files to which they apply.
+                        </para></listitem>
+                    <listitem><para><filename><emphasis>show-cross-depends:</emphasis></filename>
+                        Lists dependency relationships between recipes that
+                        cross layer boundaries.
+                        </para></listitem>
+                    <listitem><para><filename><emphasis>flatten:</emphasis></filename>
+                        Flattens the layer configuration into a separate output
+                        directory.
+                        Flattening your layer configuration builds a "flattened"
+                        directory that contains the contents of all layers,
+                        with any overlayed recipes removed and any
+                        <filename>.bbappend</filename> files appended to the
+                        corresponding recipes.
+                        You might have to perform some manual cleanup of the
+                        flattened layer as follows:
+                        <itemizedlist>
+                            <listitem><para>Non-recipe files (such as patches)
+                                are overwritten.
+                                The flatten command shows a warning for these
+                                files.
+                                </para></listitem>
+                            <listitem><para>Anything beyond the normal layer
+                                setup has been added to the
+                                <filename>layer.conf</filename> file.
+                                Only the lowest priority layer's
+                                <filename>layer.conf</filename> is used.
+                                </para></listitem>
+                            <listitem><para>Overridden and appended items from
+                                <filename>.bbappend</filename> files need to be
+                                cleaned up.
+                                The contents of each
+                                <filename>.bbappend</filename> end up in the
+                                flattened recipe.
+                                However, if there are appended or changed
+                                variable values, you need to tidy these up
+                                yourself.
+                                Consider the following example.
+                                Here, the <filename>bitbake-layers</filename>
+                                command adds the line
+                                <filename>#### bbappended ...</filename> so that
+                                you know where the following lines originate:
+                                <literallayout class='monospaced'>
+     ...
+     DESCRIPTION = "A useful utility"
+     ...
+     EXTRA_OECONF = "&dash;&dash;enable-something"
+     ...
+
+     #### bbappended from meta-anotherlayer ####
+
+     DESCRIPTION = "Customized utility"
+     EXTRA_OECONF += "&dash;&dash;enable-somethingelse"
+                                </literallayout>
+                                Ideally, you would tidy up these utilities as
+                                follows:
+                                <literallayout class='monospaced'>
+     ...
+     DESCRIPTION = "Customized utility"
+     ...
+     EXTRA_OECONF = "&dash;&dash;enable-something &dash;&dash;enable-somethingelse"
+     ...
+                                </literallayout></para></listitem>
+                        </itemizedlist></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='creating-a-general-layer-using-the-yocto-layer-script'>
+            <title>Creating a General Layer Using the yocto-layer Script</title>
+
+            <para>
+                The <filename>yocto-layer</filename> script simplifies
+                creating a new general layer.
+                <note>
+                    For information on BSP layers, see the
+                    "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
+                    section in the Yocto Project Board Specific (BSP)
+                    Developer's Guide.
+                </note>
+                The default mode of the script's operation is to prompt you for
+                information needed to generate the layer:
+                <itemizedlist>
+                    <listitem><para>The layer priority.
+                        </para></listitem>
+                    <listitem><para>Whether or not to create a sample recipe.
+                        </para></listitem>
+                    <listitem><para>Whether or not to create a sample
+                        append file.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                Use the <filename>yocto-layer create</filename> sub-command
+                to create a new general layer.
+                In its simplest form, you can create a layer as follows:
+                <literallayout class='monospaced'>
+     $ yocto-layer create mylayer
+                </literallayout>
+                The previous example creates a layer named
+                <filename>meta-mylayer</filename> in the current directory.
+            </para>
+
+            <para>
+                As the <filename>yocto-layer create</filename> command runs,
+                default values for the prompts appear in brackets.
+                Pressing enter without supplying anything for the prompts
+                or pressing enter and providing an invalid response causes the
+                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
+                <filename>meta-</filename> to the name you provide.
+            </para>
+
+            <para>
+                Minimally, the script creates the following within the layer:
+                <itemizedlist>
+                    <listitem><para><emphasis>The <filename>conf</filename>
+                        directory:</emphasis>
+                        This directory contains the layer's configuration file.
+                        The root name for the file is the same as the root name
+                        your provided for the layer (e.g.
+                        <filename><replaceable>layer</replaceable>.conf</filename>).
+                        </para></listitem>
+                    <listitem><para><emphasis>The
+                        <filename>COPYING.MIT</filename> file:</emphasis>
+                        The copyright and use notice for the software.
+                        </para></listitem>
+                    <listitem><para><emphasis>The <filename>README</filename>
+                        file:</emphasis>
+                        A file describing the contents of your new layer.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                If you choose to generate a sample recipe file, the script
+                prompts you for the name for the recipe and then creates it
+                in <filename><replaceable>layer</replaceable>/recipes-example/example/</filename>.
+                The script creates a <filename>.bb</filename> file and a
+                directory, which contains a sample
+                <filename>helloworld.c</filename> source file, along with
+                a sample patch file.
+                If you do not provide a recipe name, the script uses
+                "example".
+            </para>
+
+            <para>
+                If you choose to generate a sample append file, the script
+                prompts you for the name for the file and then creates it
+                in <filename><replaceable>layer</replaceable>/recipes-example-bbappend/example-bbappend/</filename>.
+                The script creates a <filename>.bbappend</filename> file and a
+                directory, which contains a sample patch file.
+                If you do not provide a recipe name, the script uses
+                "example".
+                The script also prompts you for the version of the append file.
+                The version should match the recipe to which the append file
+                is associated.
+            </para>
+
+            <para>
+                The easiest way to see how the <filename>yocto-layer</filename>
+                script works is to experiment with the script.
+                You can also read the usage information by entering the
+                following:
+                <literallayout class='monospaced'>
+     $ yocto-layer help
+                </literallayout>
+            </para>
+
+            <para>
+                Once you create your general layer, you must add it to your
+                <filename>bblayers.conf</filename> file.
+                Here is an example where a layer named
+                <filename>meta-mylayer</filename> is added:
+                <literallayout class='monospaced'>
+     BBLAYERS = ?" \
+        /usr/local/src/yocto/meta \
+        /usr/local/src/yocto/meta-yocto \
+        /usr/local/src/yocto/meta-yocto-bsp \
+        /usr/local/src/yocto/meta-mylayer \
+        "
+
+     BBLAYERS_NON_REMOVABLE ?= " \
+        /usr/local/src/yocto/meta \
+        /usr/local/src/yocto/meta-yocto \
+        "
+                </literallayout>
+                Adding the layer to this file enables the build system to
+                locate the layer during the build.
+                </para>
+        </section>
+    </section>
+
+    <section id='usingpoky-extend-customimage'>
+        <title>Customizing Images</title>
+
+        <para>
+            You can customize images to satisfy particular requirements.
+            This section describes several methods and provides guidelines for each.
+        </para>
+
+        <section id='usingpoky-extend-customimage-localconf'>
+            <title>Customizing Images Using <filename>local.conf</filename></title>
+
+            <para>
+                Probably the easiest way to customize an image is to add a
+                package by way of the <filename>local.conf</filename>
+                configuration file.
+                Because it is limited to local use, this method generally only
+                allows you to add packages and is not as flexible as creating
+                your own customized image.
+                When you add packages using local variables this way, you need
+                to realize that these variable changes are in effect for every
+                build and consequently affect all images, which might not
+                be what you require.
+            </para>
+
+            <para>
+                To add a package to your image using the local configuration
+                file, use the
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'>IMAGE_INSTALL</ulink></filename>
+                variable with the <filename>_append</filename> operator:
+                <literallayout class='monospaced'>
+     IMAGE_INSTALL_append = " strace"
+                </literallayout>
+                Use of the syntax is important - specifically, the space between
+                the quote and the package name, which is
+                <filename>strace</filename> in this example.
+                This space is required since the <filename>_append</filename>
+                operator does not add the space.
+            </para>
+
+            <para>
+                Furthermore, you must use <filename>_append</filename> instead
+                of the <filename>+=</filename> operator if you want to avoid
+                ordering issues.
+                The reason for this is because doing so unconditionally appends
+                to the variable and avoids ordering problems due to the
+                variable being set in image recipes and
+                <filename>.bbclass</filename> files with operators like
+                <filename>?=</filename>.
+                Using <filename>_append</filename> ensures the operation takes
+                affect.
+            </para>
+
+            <para>
+                As shown in its simplest use,
+                <filename>IMAGE_INSTALL_append</filename> affects all images.
+                It is possible to extend the syntax so that the variable
+                applies to a specific image only.
+                Here is an example:
+                <literallayout class='monospaced'>
+     IMAGE_INSTALL_append_pn-core-image-minimal = " strace"
+                </literallayout>
+                This example adds <filename>strace</filename> to the
+                <filename>core-image-minimal</filename> image only.
+            </para>
+
+            <para>
+                You can add packages using a similar approach through the
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-CORE_IMAGE_EXTRA_INSTALL'>CORE_IMAGE_EXTRA_INSTALL</ulink></filename>
+                variable.
+                If you use this variable, only
+                <filename>core-image-*</filename> images are affected.
+            </para>
+        </section>
+
+        <section id='usingpoky-extend-customimage-imagefeatures'>
+            <title>Customizing Images Using Custom <filename>IMAGE_FEATURES</filename> and
+                <filename>EXTRA_IMAGE_FEATURES</filename></title>
+
+            <para>
+                Another method for customizing your image is to enable or
+                disable high-level image features by using the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></ulink>
+                and <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGE_FEATURES'><filename>EXTRA_IMAGE_FEATURES</filename></ulink>
+                variables.
+                Although the functions for both variables are nearly equivalent,
+                best practices dictate using <filename>IMAGE_FEATURES</filename>
+                from within a recipe and using
+                <filename>EXTRA_IMAGE_FEATURES</filename> from within
+                your <filename>local.conf</filename> file, which is found in the
+                <link linkend='build-directory'>Build Directory</link>.
+            </para>
+
+            <para>
+                To understand how these features work, the best reference is
+                <filename>meta/classes/core-image.bbclass</filename>.
+                In summary, the file looks at the contents of the
+                <filename>IMAGE_FEATURES</filename> variable and then maps
+                those contents into a set of package groups.
+                Based on this information, the build system automatically
+                adds the appropriate packages to the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></ulink>
+                variable.
+                Effectively, you are enabling extra features by extending the
+                class or creating a custom class for use with specialized image
+                <filename>.bb</filename> files.
+            </para>
+
+            <para>
+                Use the <filename>EXTRA_IMAGE_FEATURES</filename> variable
+                from within your local configuration file.
+                Using a separate area from which to enable features with
+                this variable helps you avoid overwriting the features in the
+                image recipe that are enabled with
+                <filename>IMAGE_FEATURES</filename>.
+                The value of <filename>EXTRA_IMAGE_FEATURES</filename> is added
+                to <filename>IMAGE_FEATURES</filename> within
+                <filename>meta/conf/bitbake.conf</filename>.
+            </para>
+
+            <para>
+                To illustrate how you can use these variables to modify your
+                image, consider an example that selects the SSH server.
+                The Yocto Project ships with two SSH servers you can use
+                with your images: Dropbear and OpenSSH.
+                Dropbear is a minimal SSH server appropriate for
+                resource-constrained environments, while OpenSSH is a
+                well-known standard SSH server implementation.
+                By default, the <filename>core-image-sato</filename> image
+                is configured to use Dropbear.
+                The <filename>core-image-full-cmdline</filename> and
+                <filename>core-image-lsb</filename> images both
+                include OpenSSH.
+                The <filename>core-image-minimal</filename> image does not
+                contain an SSH server.
+            </para>
+
+            <para>
+                You can customize your image and change these defaults.
+                Edit the <filename>IMAGE_FEATURES</filename> variable
+                in your recipe or use the
+                <filename>EXTRA_IMAGE_FEATURES</filename> in your
+                <filename>local.conf</filename> file so that it configures the
+                image you are working with to include
+                <filename>ssh-server-dropbear</filename> or
+                <filename>ssh-server-openssh</filename>.
+            </para>
+
+            <note>
+                See the
+                "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>"
+                section in the Yocto Project Reference Manual for a complete
+                list of image features that ship with the Yocto Project.
+            </note>
+        </section>
+
+        <section id='usingpoky-extend-customimage-custombb'>
+            <title>Customizing Images Using Custom .bb Files</title>
+
+            <para>
+                You can also customize an image by creating a custom recipe
+                that defines additional software as part of the image.
+                The following example shows the form for the two lines you need:
+                <literallayout class='monospaced'>
+     IMAGE_INSTALL = "packagegroup-core-x11-base package1 package2"
+
+     inherit core-image
+                </literallayout>
+            </para>
+
+            <para>
+                Defining the software using a custom recipe gives you total
+                control over the contents of the image.
+                It is important to use the correct names of packages in the
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'>IMAGE_INSTALL</ulink></filename>
+                variable.
+                You must use the OpenEmbedded notation and not the Debian notation for the names
+                (e.g. <filename>glibc-dev</filename> instead of <filename>libc6-dev</filename>).
+            </para>
+
+            <para>
+                The other method for creating a custom image is to base it on an existing image.
+                For example, if you want to create an image based on <filename>core-image-sato</filename>
+                but add the additional package <filename>strace</filename> to the image,
+                copy the <filename>meta/recipes-sato/images/core-image-sato.bb</filename> to a
+                new <filename>.bb</filename> and add the following line to the end of the copy:
+                <literallayout class='monospaced'>
+     IMAGE_INSTALL += "strace"
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='usingpoky-extend-customimage-customtasks'>
+            <title>Customizing Images Using Custom Package Groups</title>
+
+            <para>
+                For complex custom images, the best approach for customizing
+                an image is to create a custom package group recipe that is
+                used to build the image or images.
+                A good example of a package group recipe is
+                <filename>meta/recipes-core/packagegroups/packagegroup-core-boot.bb</filename>.
+                The
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'>PACKAGES</ulink></filename>
+                variable lists the package group packages you wish to produce.
+                <filename>inherit packagegroup</filename> sets appropriate
+                default values and automatically adds <filename>-dev</filename>,
+                <filename>-dbg</filename>, and <filename>-ptest</filename>
+                complementary packages for every package specified in
+                <filename>PACKAGES</filename>.
+                Note that the inherit line should be towards
+                the top of the recipe, certainly before you set
+                <filename>PACKAGES</filename>.
+                For each package you specify in <filename>PACKAGES</filename>,
+                you can use
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-RDEPENDS'>RDEPENDS</ulink></filename>
+                and
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS'>RRECOMMENDS</ulink></filename>
+                entries to provide a list of packages the parent task package
+                should contain.
+                Following is an example:
+                <literallayout class='monospaced'>
+     DESCRIPTION = "My Custom Package Groups"
+
+     inherit packagegroup
+
+     PACKAGES = "\
+         packagegroup-custom-apps \
+         packagegroup-custom-tools \
+         "
+
+     RDEPENDS_packagegroup-custom-apps = "\
+         dropbear \
+         portmap \
+         psplash"
+
+     RDEPENDS_packagegroup-custom-tools = "\
+         oprofile \
+         oprofileui-server \
+         lttng-control \
+         lttng-viewer"
+
+     RRECOMMENDS_packagegroup-custom-tools = "\
+         kernel-module-oprofile"
+                </literallayout>
+            </para>
+
+            <para>
+                In the previous example, two package group packages are created with their dependencies and their
+                recommended package dependencies listed: <filename>packagegroup-custom-apps</filename>, and
+                <filename>packagegroup-custom-tools</filename>.
+                To build an image using these package group packages, you need to add
+                <filename>packagegroup-custom-apps</filename> and/or
+                <filename>packagegroup-custom-tools</filename> to
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'>IMAGE_INSTALL</ulink></filename>.
+                For other forms of image dependencies see the other areas of this section.
+            </para>
+        </section>
+    </section>
+
+    <section id='new-recipe-writing-a-new-recipe'>
+        <title>Writing a New Recipe</title>
+
+        <para>
+            Recipes (<filename>.bb</filename> files) are fundamental components
+            in the Yocto Project environment.
+            Each software component built by the OpenEmbedded build system
+            requires a recipe to define the component.
+            This section describes how to create, write, and test a new
+            recipe.
+            <note>
+                For information on variables that are useful for recipes and
+                for information about recipe naming issues, see the
+                "<ulink url='&YOCTO_DOCS_REF_URL;#ref-varlocality-recipe-required'>Required</ulink>"
+                section of the Yocto Project Reference Manual.
+            </note>
+        </para>
+
+        <section id='new-recipe-overview'>
+            <title>Overview</title>
+
+            <para>
+                The following figure shows the basic process for creating a
+                new recipe.
+                The remainder of the section provides details for the steps.
+                <imagedata fileref="figures/recipe-workflow.png" width="6in" depth="7in" align="center" scalefit="1" />
+            </para>
+        </section>
+
+        <section id='new-recipe-locate-a-base-recipe'>
+            <title>Locate a Base Recipe</title>
+
+            <para>
+                Before writing a recipe from scratch, it is often useful to
+                discover whether someone else has already written one that
+                meets (or comes close to meeting) your needs.
+                The Yocto Project and OpenEmbedded communities maintain many
+                recipes that might be candidates for what you are doing.
+                You can find a good central index of these recipes in the
+                <ulink url='http://layers.openembedded.org'>OpenEmbedded metadata index</ulink>.
+            </para>
+
+            <para>
+                Working from an existing recipe or a skeleton recipe is the
+                best way to get started.
+                Here are some points on both methods:
+                <itemizedlist>
+                    <listitem><para><emphasis>Locate and modify a recipe that
+                        is close to what you want to do:</emphasis>
+                        This method works when you are familiar with the
+                        current recipe space.
+                        The method does not work so well for those new to
+                        the Yocto Project or writing recipes.</para>
+                        <para>Some risks associated with this method are
+                        using a recipe that has areas totally unrelated to
+                        what you are trying to accomplish with your recipe,
+                        not recognizing areas of the recipe that you might
+                        have to add from scratch, and so forth.
+                        All these risks stem from unfamiliarity with the
+                        existing recipe space.</para></listitem>
+                    <listitem><para><emphasis>Use and modify the following
+                        skeleton recipe:</emphasis>
+                        <literallayout class='monospaced'>
+     SUMMARY = ""
+     HOMEPAGE = ""
+     LICENSE = ""
+
+     LIC_FILES_CHKSUM = ""
+
+     SRC_URI = ""
+     SRC_URI[md5sum] = ""
+     SRC_URI[sha256sum] = ""
+
+     S = "${WORKDIR}/${PN}-${PV}"
+
+     inherit <replaceable>stuff</replaceable>
+                        </literallayout>
+                        Modifying this recipe is the recommended method for
+                        creating a new recipe.
+                        The recipe provides the fundamental areas that you need
+                        to include, exclude, or alter to fit your needs.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='new-recipe-storing-and-naming-the-recipe'>
+            <title>Storing and Naming the Recipe</title>
+
+            <para>
+                Once you have your base recipe, you should put it in your
+                own layer and name it appropriately.
+                Locating it correctly ensures that the OpenEmbedded build
+                system can find it when you use BitBake to process the
+                recipe.
+            </para>
+
+            <itemizedlist>
+                <listitem><para><emphasis>Storing Your Recipe:</emphasis>
+                    The OpenEmbedded build system locates your recipe
+                    through the layer's <filename>conf/layer.conf</filename>
+                    file and the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILES'><filename>BBFILES</filename></ulink>
+                    variable.
+                    This variable sets up a path from which the build system can
+                    locate recipes.
+                    Here is the typical use:
+                    <literallayout class='monospaced'>
+     BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
+                 ${LAYERDIR}/recipes-*/*/*.bbappend"
+                    </literallayout>
+                    Consequently, you need to be sure you locate your new recipe
+                    inside your layer such that it can be found.</para>
+                    <para>You can find more information on how layers are
+                    structured in the
+                    "<link linkend='understanding-and-creating-layers'>Understanding and Creating Layers</link>"
+                    section.</para></listitem>
+                <listitem><para><emphasis>Naming Your Recipe:</emphasis>
+                    When you name your recipe, you need to follow this naming
+                    convention:
+                    <literallayout class='monospaced'>
+     <replaceable>basename</replaceable>_<replaceable>version</replaceable>.bb
+                    </literallayout>
+                    Use lower-cased characters and do not include the reserved
+                    suffixes <filename>-native</filename>,
+                    <filename>-cross</filename>, <filename>-initial</filename>,
+                    or <filename>-dev</filename> casually (i.e. do not use them
+                    as part of your recipe name unless the string applies).
+                    Here are some examples:
+                    <literallayout class='monospaced'>
+     cups_1.7.0.bb
+     gawk_4.0.2.bb
+     irssi_0.8.16-rc1.bb
+                    </literallayout></para></listitem>
+            </itemizedlist>
+        </section>
+
+        <section id='understanding-recipe-syntax'>
+            <title>Understanding Recipe Syntax</title>
+
+            <para>
+                Understanding recipe file syntax is important for
+                writing recipes.
+                The following list overviews the basic items that make up a
+                BitBake recipe file.
+                For more complete BitBake syntax descriptions, see the
+                "<ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual-metadata'>Syntax and Operators</ulink>"
+                chapter of the BitBake User Manual.
+                <itemizedlist>
+                    <listitem><para><emphasis>Variable Assignments and Manipulations:</emphasis>
+                        Variable assignments allow a value to be assigned to a
+                        variable.
+                        The assignment can be static text or might include
+                        the contents of other variables.
+                        In addition to the assignment, appending and prepending
+                        operations are also supported.</para>
+                        <para>The following example shows some of the ways
+                        you can use variables in recipes:
+                        <literallayout class='monospaced'>
+     S = "${WORKDIR}/postfix-${PV}"
+     CFLAGS += "-DNO_ASM"
+     SRC_URI_append = " file://fixup.patch"
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para><emphasis>Functions:</emphasis>
+                        Functions provide a series of actions to be performed.
+                        You usually use functions to override the default
+                        implementation of a task function or to complement
+                        a default function (i.e. append or prepend to an
+                        existing function).
+                        Standard functions use <filename>sh</filename> shell
+                        syntax, although access to OpenEmbedded variables and
+                        internal methods are also available.</para>
+                        <para>The following is an example function from the
+                        <filename>sed</filename> recipe:
+                        <literallayout class='monospaced'>
+     do_install () {
+         autotools_do_install
+         install -d ${D}${base_bindir}
+         mv ${D}${bindir}/sed ${D}${base_bindir}/sed
+         rmdir ${D}${bindir}/
+     }
+                        </literallayout>
+                        It is also possible to implement new functions that
+                        are called between existing tasks as long as the
+                        new functions are not replacing or complementing the
+                        default functions.
+                        You can implement functions in Python
+                        instead of shell.
+                        Both of these options are not seen in the majority of
+                        recipes.</para></listitem>
+                    <listitem><para><emphasis>Keywords:</emphasis>
+                        BitBake recipes use only a few keywords.
+                        You use keywords to include common
+                        functions (<filename>inherit</filename>), load parts
+                        of a recipe from other files
+                        (<filename>include</filename> and
+                        <filename>require</filename>) and export variables
+                        to the environment (<filename>export</filename>).</para>
+                        <para>The following example shows the use of some of
+                        these keywords:
+                        <literallayout class='monospaced'>
+     export POSTCONF = "${STAGING_BINDIR}/postconf"
+     inherit autoconf
+     require otherfile.inc
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para><emphasis>Comments:</emphasis>
+                        Any lines that begin with the hash character
+                        (<filename>#</filename>) are treated as comment lines
+                        and are ignored:
+                        <literallayout class='monospaced'>
+     # This is a comment
+                        </literallayout>
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                This next list summarizes the most important and most commonly
+                used parts of the recipe syntax.
+                For more information on these parts of the syntax, you can
+                reference the
+                <ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual-metadata'>Syntax and Operators</ulink>
+                chapter in the BitBake User Manual.
+                <itemizedlist>
+                    <listitem><para><emphasis>Line Continuation: <filename>\</filename></emphasis> -
+                        Use the backward slash (<filename>\</filename>)
+                        character to split a statement over multiple lines.
+                        Place the slash character at the end of the line that
+                        is to be continued on the next line:
+                        <literallayout class='monospaced'>
+     VAR = "A really long \
+            line"
+                        </literallayout>
+                        <note>
+                            You cannot have any characters including spaces
+                            or tabs after the slash character.
+                        </note>
+                        </para></listitem>
+                    <listitem><para><emphasis>Using Variables: <filename>${...}</filename></emphasis> -
+                        Use the <filename>${<replaceable>varname</replaceable>}</filename> syntax to
+                        access the contents of a variable:
+                        <literallayout class='monospaced'>
+     SRC_URI = "${SOURCEFORGE_MIRROR}/libpng/zlib-${PV}.tar.gz"
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para><emphasis>Quote All Assignments: <filename>"<replaceable>value</replaceable>"</filename></emphasis> -
+                        Use double quotes around the value in all variable
+                        assignments.
+                        <literallayout class='monospaced'>
+     VAR1 = "${OTHERVAR}"
+     VAR2 = "The version is ${PV}"
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para><emphasis>Conditional Assignment: <filename>?=</filename></emphasis> -
+                        Conditional assignment is used to assign a value to
+                        a variable, but only when the variable is currently
+                        unset.
+                        Use the question mark followed by the equal sign
+                        (<filename>?=</filename>) to make a "soft" assignment
+                        used for conditional assignment.
+                        Typically, "soft" assignments are used in the
+                        <filename>local.conf</filename> file for variables
+                        that are allowed to come through from the external
+                        environment.
+                        </para>
+                        <para>Here is an example where
+                        <filename>VAR1</filename> is set to "New value" if
+                        it is currently empty.
+                        However, if <filename>VAR1</filename> has already been
+                        set, it remains unchanged:
+                        <literallayout class='monospaced'>
+     VAR1 ?= "New value"
+                        </literallayout>
+                        In this next example, <filename>VAR1</filename>
+                        is left with the value "Original value":
+                        <literallayout class='monospaced'>
+     VAR1 = "Original value"
+     VAR1 ?= "New value"
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para><emphasis>Appending: <filename>+=</filename></emphasis> -
+                        Use the plus character followed by the equals sign
+                        (<filename>+=</filename>) to append values to existing
+                        variables.
+                        <note>
+                            This operator adds a space between the existing
+                            content of the variable and the new content.
+                        </note></para>
+                        <para>Here is an example:
+                        <literallayout class='monospaced'>
+     SRC_URI += "file://fix-makefile.patch"
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para><emphasis>Prepending: <filename>=+</filename></emphasis> -
+                        Use the equals sign followed by the plus character
+                        (<filename>=+</filename>) to prepend values to existing
+                        variables.
+                        <note>
+                            This operator adds a space between the new content
+                            and the existing content of the variable.
+                        </note></para>
+                        <para>Here is an example:
+                        <literallayout class='monospaced'>
+     VAR =+ "Starts"
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para><emphasis>Appending: <filename>_append</filename></emphasis> -
+                        Use the <filename>_append</filename> operator to
+                        append values to existing variables.
+                        This operator does not add any additional space.
+                        Also, the operator is applied after all the
+                        <filename>+=</filename>, and
+                        <filename>=+</filename> operators have been applied and
+                        after all <filename>=</filename> assignments have
+                        occurred.
+                        </para>
+                        <para>The following example shows the space being
+                        explicitly added to the start to ensure the appended
+                        value is not merged with the existing value:
+                        <literallayout class='monospaced'>
+     SRC_URI_append = " file://fix-makefile.patch"
+                        </literallayout>
+                        You can also use the <filename>_append</filename>
+                        operator with overrides, which results in the actions
+                        only being performed for the specified target or
+                        machine:
+                        <literallayout class='monospaced'>
+     SRC_URI_append_sh4 = " file://fix-makefile.patch"
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para><emphasis>Prepending: <filename>_prepend</filename></emphasis> -
+                        Use the <filename>_prepend</filename> operator to
+                        prepend values to existing variables.
+                        This operator does not add any additional space.
+                        Also, the operator is applied after all the
+                        <filename>+=</filename>, and
+                        <filename>=+</filename> operators have been applied and
+                        after all <filename>=</filename> assignments have
+                        occurred.
+                        </para>
+                        <para>The following example shows the space being
+                        explicitly added to the end to ensure the prepended
+                        value is not merged with the existing value:
+                        <literallayout class='monospaced'>
+     CFLAGS_prepend = "-I${S}/myincludes "
+                        </literallayout>
+                        You can also use the <filename>_prepend</filename>
+                        operator with overrides, which results in the actions
+                        only being performed for the specified target or
+                        machine:
+                        <literallayout class='monospaced'>
+     CFLAGS_prepend_sh4 = "-I${S}/myincludes "
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para><emphasis>Overrides:</emphasis> -
+                        You can use overrides to set a value conditionally,
+                        typically based on how the recipe is being built.
+                        For example, to set the
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-KBRANCH'><filename>KBRANCH</filename></ulink>
+                        variable's value to "standard/base" for any target
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>,
+                        except for qemuarm where it should be set to
+                        "standard/arm-versatile-926ejs", you would do the
+                        following:
+                        <literallayout class='monospaced'>
+     KBRANCH = "standard/base"
+     KBRANCH_qemuarm  = "standard/arm-versatile-926ejs"
+                        </literallayout>
+                        Overrides are also used to separate alternate values
+                        of a variable in other situations.
+                        For example, when setting variables such as
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-FILES'><filename>FILES</filename></ulink>
+                        and
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-RDEPENDS'><filename>RDEPENDS</filename></ulink>
+                        that are specific to individual packages produced by
+                        a recipe, you should always use an override that
+                        specifies the name of the package.
+                        </para></listitem>
+                    <listitem><para><emphasis>Indentation:</emphasis>
+                        Use spaces for indentation rather than than tabs.
+                        For shell functions, both currently work.
+                        However, it is a policy decision of the Yocto Project
+                        to use tabs in shell functions.
+                        Realize that some layers have a policy to use spaces
+                        for all indentation.
+                        </para></listitem>
+                    <listitem><para><emphasis>Using Python for Complex Operations: <filename>${@<replaceable>python_code</replaceable>}</filename></emphasis> -
+                        For more advanced processing, it is possible to use
+                        Python code during variable assignments (e.g.
+                        search and replacement on a variable).</para>
+                        <para>You indicate Python code using the
+                        <filename>${@<replaceable>python_code</replaceable>}</filename>
+                        syntax for the variable assignment:
+                        <literallayout class='monospaced'>
+     SRC_URI = "ftp://ftp.info-zip.org/pub/infozip/src/zip${@d.getVar('PV',1).replace('.', '')}.tgz
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para><emphasis>Shell Function Syntax:</emphasis>
+                        Write shell functions as if you were writing a shell
+                        script when you describe a list of actions to take.
+                        You should ensure that your script works with a generic
+                        <filename>sh</filename> and that it does not require
+                        any <filename>bash</filename> or other shell-specific
+                        functionality.
+                        The same considerations apply to various system
+                        utilities (e.g. <filename>sed</filename>,
+                        <filename>grep</filename>, <filename>awk</filename>,
+                        and so forth) that you might wish to use.
+                        If in doubt, you should check with multiple
+                        implementations - including those from BusyBox.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='new-recipe-running-a-build-on-the-recipe'>
+            <title>Running a Build on the Recipe</title>
+
+            <para>
+                Creating a new recipe is usually an iterative process that
+                requires using BitBake to process the recipe multiple times in
+                order to progressively discover and add information to the
+                recipe file.
+            </para>
+
+            <para>
+                Assuming you have sourced a build environment setup script (i.e.
+                <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                or
+                <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>)
+                and you are in the
+                <link linkend='build-directory'>Build Directory</link>,
+                use BitBake to process your recipe.
+                All you need to provide is the
+                <filename><replaceable>basename</replaceable></filename> of the recipe as described
+                in the previous section:
+                <literallayout class='monospaced'>
+     $ bitbake <replaceable>basename</replaceable>
+                </literallayout>
+
+            </para>
+
+            <para>
+                During the build, the OpenEmbedded build system creates a
+                temporary work directory for each recipe
+                (<filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink><filename>}</filename>)
+                where it keeps extracted source files, log files, intermediate
+                compilation and packaging files, and so forth.
+            </para>
+
+            <para>
+                The per-recipe temporary work directory is constructed as follows and
+                depends on several factors:
+                <literallayout class='monospaced'>
+     BASE_WORKDIR ?= "${TMPDIR}/work"
+     WORKDIR = "${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
+                </literallayout>
+                As an example, assume a Source Directory top-level folder named
+                <filename>poky</filename>, a default Build Directory at
+                <filename>poky/build</filename>, and a
+                <filename>qemux86-poky-linux</filename> machine target system.
+                Furthermore, suppose your recipe is named
+                <filename>foo_1.3.0.bb</filename>.
+                In this case, the work directory the build system uses to
+                build the package would be as follows:
+                <literallayout class='monospaced'>
+     poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
+                </literallayout>
+                Inside this directory you can find sub-directories such as
+                <filename>image</filename>, <filename>packages-split</filename>,
+                and <filename>temp</filename>.
+                After the build, you can examine these to determine how well
+                the build went.
+                <note>
+                    You can find log files for each task in the recipe's
+                    <filename>temp</filename> directory (e.g.
+                    <filename>poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0/temp</filename>).
+                    Log files are named <filename>log.<replaceable>taskname</replaceable></filename>
+                    (e.g. <filename>log.do_configure</filename>,
+                    <filename>log.do_fetch</filename>, and
+                    <filename>log.do_compile</filename>).
+                </note>
+            </para>
+
+            <para>
+                You can find more information about the build process in the
+                "<ulink url='&YOCTO_DOCS_REF_URL;#closer-look'>A Closer Look at the Yocto Project Development Environment</ulink>"
+                chapter of the Yocto Project Reference Manual.
+            </para>
+
+            <para>
+                You can also reference the following variables in the
+                Yocto Project Reference Manual's glossary for more information:
+                <itemizedlist>
+                    <listitem><ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink>:
+                        The top-level build output directory</listitem>
+                    <listitem><ulink url='&YOCTO_DOCS_REF_URL;#var-MULTIMACH_TARGET_SYS'><filename>MULTIMACH_TARGET_SYS</filename></ulink>:
+                        The target system identifier</listitem>
+                    <listitem><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink>:
+                        The recipe name</listitem>
+                    <listitem><ulink url='&YOCTO_DOCS_REF_URL;#var-EXTENDPE'><filename>EXTENDPE</filename></ulink>:
+                        The epoch - (if
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-PE'><filename>PE</filename></ulink>
+                        is not specified, which is usually the case for most
+                        recipes, then <filename>EXTENDPE</filename> is blank)</listitem>
+                    <listitem><ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>:
+                        The recipe version</listitem>
+                    <listitem><ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>:
+                        The recipe revision</listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='new-recipe-fetching-code'>
+            <title>Fetching Code</title>
+
+            <para>
+                The first thing your recipe must do is specify how to fetch
+                the source files.
+                Fetching is controlled mainly through the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                variable.
+                Your recipe must have a <filename>SRC_URI</filename> variable
+                that points to where the source is located.
+                For a graphical representation of source locations, see the
+                "<ulink url='&YOCTO_DOCS_REF_URL;#sources-dev-environment'>Sources</ulink>"
+                section in the Yocto Project Reference Manual.
+            </para>
+
+            <para>
+                The
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-fetch'><filename>do_fetch</filename></ulink>
+                task uses the prefix of each entry in the
+                <filename>SRC_URI</filename> variable value to determine which
+                fetcher to use to get your source files.
+                It is the <filename>SRC_URI</filename> variable that triggers
+                the fetcher.
+                The
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-patch'><filename>do_patch</filename></ulink>
+                task uses the variable after source is fetched to apply
+                patches.
+                The OpenEmbedded build system uses
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESOVERRIDES'><filename>FILESOVERRIDES</filename></ulink>
+                for scanning directory locations for local files in
+                <filename>SRC_URI</filename>.
+            </para>
+
+            <para>
+                The <filename>SRC_URI</filename> variable in your recipe must
+                define each unique location for your source files.
+                It is good practice to not hard-code pathnames in an URL used
+                in <filename>SRC_URI</filename>.
+                Rather than hard-code these paths, use
+                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink><filename>}</filename>,
+                which causes the fetch process to use the version specified in
+                the recipe filename.
+                Specifying the version in this manner means that upgrading the
+                recipe to a future version is as simple as renaming the recipe
+                to match the new version.
+            </para>
+
+            <para>
+                Here is a simple example from the
+                <filename>meta/recipes-devtools/cdrtools/cdrtools-native_3.01a20.bb</filename>
+                recipe where the source comes from a single tarball.
+                Notice the use of the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>
+                variable:
+                <literallayout class='monospaced'>
+     SRC_URI = "ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-${PV}.tar.bz2"
+                </literallayout>
+            </para>
+
+            <para>
+                Files mentioned in <filename>SRC_URI</filename> whose names end
+                in a typical archive extension (e.g. <filename>.tar</filename>,
+                <filename>.tar.gz</filename>, <filename>.tar.bz2</filename>,
+                <filename>.zip</filename>, and so forth), are automatically
+                extracted during the
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-unpack'><filename>do_unpack</filename></ulink>
+                task.
+                For another example that specifies these types of files, see
+                the
+                "<link linkend='new-recipe-autotooled-package'>Autotooled Package</link>"
+                section.
+            </para>
+
+            <para>
+                Another way of specifying source is from an SCM.
+                For Git repositories, you must specify
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRCREV'><filename>SRCREV</filename></ulink>
+                and you should specify
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>
+                to include the revision with
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRCPV'><filename>SRCPV</filename></ulink>.
+                Here is an example from the recipe
+                <filename>meta/recipes-kernel/blktrace/blktrace_git.bb</filename>:
+                <literallayout class='monospaced'>
+     SRCREV = "d6918c8832793b4205ed3bfede78c2f915c23385"
+
+     PR = "r6"
+     PV = "1.0.5+git${SRCPV}"
+
+     SRC_URI = "git://git.kernel.dk/blktrace.git \
+                file://ldflags.patch"
+                </literallayout>
+            </para>
+
+            <para>
+                If your <filename>SRC_URI</filename> statement includes
+                URLs pointing to individual files fetched from a remote server
+                other than a version control system, BitBake attempts to
+                verify the files against checksums defined in your recipe to
+                ensure they have not been tampered with or otherwise modified
+                since the recipe was written.
+                Two checksums are used:
+                <filename>SRC_URI[md5sum]</filename> and
+                <filename>SRC_URI[sha256sum]</filename>.
+            </para>
+
+            <para>
+                If your <filename>SRC_URI</filename> variable points to
+                more than a single URL (excluding SCM URLs), you need to
+                provide the <filename>md5</filename> and
+                <filename>sha256</filename> checksums for each URL.
+                For these cases, you provide a name for each URL as part of
+                the <filename>SRC_URI</filename> and then reference that name
+                in the subsequent checksum statements.
+                Here is an example:
+                <literallayout class='monospaced'>
+     SRC_URI = "${DEBIAN_MIRROR}/main/a/apmd/apmd_3.2.2.orig.tar.gz;name=tarball \
+                ${DEBIAN_MIRROR}/main/a/apmd/apmd_${PV}.diff.gz;name=patch
+
+     SRC_URI[tarball.md5sum] = "b1e6309e8331e0f4e6efd311c2d97fa8"
+     SRC_URI[tarball.sha256sum] = "7f7d9f60b7766b852881d40b8ff91d8e39fccb0d1d913102a5c75a2dbb52332d"
+
+     SRC_URI[patch.md5sum] = "57e1b689264ea80f78353519eece0c92"
+     SRC_URI[patch.sha256sum] = "7905ff96be93d725544d0040e425c42f9c05580db3c272f11cff75b9aa89d430"
+                </literallayout>
+            </para>
+
+            <para>
+                Proper values for <filename>md5</filename> and
+                <filename>sha256</filename> checksums might be available
+                with other signatures on the download page for the upstream
+                source (e.g. <filename>md5</filename>,
+                <filename>sha1</filename>, <filename>sha256</filename>,
+                <filename>GPG</filename>, and so forth).
+                Because the OpenEmbedded build system only deals with
+                <filename>sha256sum</filename> and <filename>md5sum</filename>,
+                you should verify all the signatures you find by hand.
+            </para>
+
+            <para>
+                If no <filename>SRC_URI</filename> checksums are specified
+                when you attempt to build the recipe, the build will produce
+                an error for each missing checksum.
+                As part of the error message, the build system provides
+                the checksum string corresponding to the fetched file.
+                Once you have the correct checksums, you can copy and paste
+                them into your recipe and then run the build again to continue.
+                <note>
+                    As mentioned, if the upstream source provides signatures
+                    for verifying the downloaded source code, you should
+                    verify those manually before setting the checksum values
+                    in the recipe and continuing with the build.
+                </note>
+            </para>
+
+            <para>
+                This final example is a bit more complicated and is from the
+                <filename>meta/recipes-sato/rxvt-unicode/rxvt-unicode_9.20.bb</filename>
+                recipe.
+                The example's <filename>SRC_URI</filename> statement identifies
+                multiple files as the source files for the recipe: a tarball, a
+                patch file, a desktop file, and an icon.
+                <literallayout class='monospaced'>
+     SRC_URI = "http://dist.schmorp.de/rxvt-unicode/Attic/rxvt-unicode-${PV}.tar.bz2 \
+                file://xwc.patch \
+                file://rxvt.desktop \
+                file://rxvt.png"
+                </literallayout>
+            </para>
+
+            <para>
+                When you specify local files using the
+                <filename>file://</filename> URI protocol, the build system
+                fetches files from the local machine.
+                The path is relative to the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
+                variable and searches specific directories in a certain order:
+                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BP'><filename>BP</filename></ulink><filename>}</filename>,
+                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BPN'><filename>BPN</filename></ulink><filename>}</filename>,
+                and <filename>files</filename>.
+                The directories are assumed to be subdirectories of the
+                directory in which the recipe or append file resides.
+                For another example that specifies these types of files, see the
+                "<link linkend='new-recipe-single-c-file-package-hello-world'>Single .c File Package (Hello World!)</link>"
+                section.
+            </para>
+
+            <para>
+                The previous example also specifies a patch file.
+                Patch files are files whose names end in
+                <filename>.patch</filename> or <filename>.diff</filename>.
+                The build system automatically applies patches as described
+                in the
+                "<link linkend='new-recipe-patching-code'>Patching Code</link>" section.
+            </para>
+        </section>
+
+        <section id='new-recipe-unpacking-code'>
+            <title>Unpacking Code</title>
+
+            <para>
+                During the build, the
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-unpack'><filename>do_unpack</filename></ulink>
+                task unpacks the source with
+                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink><filename>}</filename>
+                pointing to where it is unpacked.
+            </para>
+
+            <para>
+                If you are fetching your source files from an upstream source
+                archived tarball and the tarball's internal structure matches
+                the common convention of a top-level subdirectory named
+                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BPN'><filename>BPN</filename></ulink><filename>}-${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink><filename>}</filename>,
+                then you do not need to set <filename>S</filename>.
+                However, if <filename>SRC_URI</filename> specifies to fetch
+                source from an archive that does not use this convention,
+                or from an SCM like Git or Subversion, your recipe needs to
+                define <filename>S</filename>.
+            </para>
+
+            <para>
+                If processing your recipe using BitBake successfully unpacks
+                the source files, you need to be sure that the directory
+                pointed to by <filename>${S}</filename> matches the structure
+                of the source.
+            </para>
+        </section>
+
+        <section id='new-recipe-patching-code'>
+            <title>Patching Code</title>
+
+            <para>
+                Sometimes it is necessary to patch code after it has been
+                fetched.
+                Any files mentioned in <filename>SRC_URI</filename> whose
+                names end in <filename>.patch</filename> or
+                <filename>.diff</filename> are treated as patches.
+                The
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-patch'><filename>do_patch</filename></ulink>
+                task automatically applies these patches.
+            </para>
+
+            <para>
+                The build system should be able to apply patches with the "-p1"
+                option (i.e. one directory level in the path will be stripped
+                off).
+                If your patch needs to have more directory levels stripped off,
+                specify the number of levels using the "striplevel" option in
+                the <filename>SRC_URI</filename> entry for the patch.
+                Alternatively, if your patch needs to be applied in a specific
+                subdirectory that is not specified in the patch file, use the
+                "patchdir" option in the entry.
+            </para>
+
+            <para>
+                As with all local files referenced in
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                using <filename>file://</filename>, you should place
+                patch files in a directory next to the recipe either
+                named the same as the base name of the recipe
+                (<ulink url='&YOCTO_DOCS_REF_URL;#var-BPN'><filename>BPN</filename></ulink>),
+                or "files".
+            </para>
+        </section>
+
+        <section id='new-recipe-licensing'>
+            <title>Licensing</title>
+
+            <para>
+                Your recipe needs to have both the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE'><filename>LICENSE</filename></ulink>
+                and
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-LIC_FILES_CHKSUM'><filename>LIC_FILES_CHKSUM</filename></ulink>
+                variables:
+                <itemizedlist>
+                    <listitem><para><emphasis><filename>LICENSE</filename>:</emphasis>
+                        This variable specifies the license for the software.
+                        If you do not know the license under which the software
+                        you are building is distributed, you should go to the
+                        source code and look for that information.
+                        Typical files containing this information include
+                        <filename>COPYING</filename>,
+                        <filename>LICENSE</filename>, and
+                        <filename>README</filename> files.
+                        You could also find the information near the top of
+                        a source file.
+                        For example, given a piece of software licensed under
+                        the GNU General Public License version 2, you would
+                        set <filename>LICENSE</filename> as follows:
+                        <literallayout class='monospaced'>
+     LICENSE = "GPLv2"
+                        </literallayout></para>
+                        <para>The licenses you specify within
+                        <filename>LICENSE</filename> can have any name as long
+                        as you do not use spaces, since spaces are used as
+                        separators between license names.
+                        For standard licenses, use the names of the files in
+                        <filename>meta/files/common-licenses/</filename>
+                        or the <filename>SPDXLICENSEMAP</filename> flag names
+                        defined in <filename>meta/conf/licenses.conf</filename>.
+                        </para></listitem>
+                    <listitem><para><emphasis><filename>LIC_FILES_CHKSUM</filename>:</emphasis>
+                        The OpenEmbedded build system uses this variable to
+                        make sure the license text has not changed.
+                        If it has, the build produces an error and it affords
+                        you the chance to figure it out and correct the problem.
+                        </para>
+                        <para>You need to specify all applicable licensing
+                        files for the software.
+                        At the end of the configuration step, the build process
+                        will compare the checksums of the files to be sure
+                        the text has not changed.
+                        Any differences result in an error with the message
+                        containing the current checksum.
+                        For more explanation and examples of how to set the
+                        <filename>LIC_FILES_CHKSUM</filename> variable, see the
+                        "<ulink url='&YOCTO_DOCS_REF_URL;#usingpoky-configuring-LIC_FILES_CHKSUM'>Tracking License Changes</ulink>"
+                        section in the Yocto Project Reference Manual.</para>
+                        <para>To determine the correct checksum string, you
+                        can list the appropriate files in the
+                        <filename>LIC_FILES_CHKSUM</filename> variable with
+                        incorrect md5 strings, attempt to build the software,
+                        and then note the resulting error messages that will
+                        report the correct md5 strings.
+                        See the
+                        "<link linkend='new-recipe-fetching-code'>Fetching Code</link>"
+                        section for additional information.
+                    </para>
+
+                    <para>
+                        Here is an example that assumes the software has a
+                        <filename>COPYING</filename> file:
+                        <literallayout class='monospaced'>
+     LIC_FILES_CHKSUM = "file://COPYING;md5=xxx"
+                        </literallayout>
+                        When you try to build the software, the build system
+                        will produce an error and give you the correct string
+                        that you can substitute into the recipe file for a
+                        subsequent build.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+<!--
+
+            <para>
+                For trying this out I created a new recipe named
+                <filename>htop_1.0.2.bb</filename> and put it in
+                <filename>poky/meta/recipes-extended/htop</filename>.
+                There are two license type statements in my very simple
+                recipe:
+                <literallayout class='monospaced'>
+     LICENSE = ""
+
+     LIC_FILES_CHKSUM = ""
+
+     SRC_URI[md5sum] = ""
+     SRC_URI[sha256sum] = ""
+                </literallayout>
+                Evidently, you need to run a <filename>bitbake -c cleanall htop</filename>.
+                Next, you delete or comment out the two <filename>SRC_URI</filename>
+                lines at the end and then attempt to build the software with
+                <filename>bitbake htop</filename>.
+                Doing so causes BitBake to report some errors and and give
+                you the actual strings you need for the last two
+                <filename>SRC_URI</filename> lines.
+                Prior to this, you have to dig around in the home page of the
+                source for <filename>htop</filename> and determine that the
+                software is released under GPLv2.
+                You can provide that in the <filename>LICENSE</filename>
+                statement.
+                Now you edit your recipe to have those two strings for
+                the <filename>SRC_URI</filename> statements:
+                <literallayout class='monospaced'>
+     LICENSE = "GPLv2"
+
+     LIC_FILES_CHKSUM = ""
+
+     SRC_URI = "${SOURCEFORGE_MIRROR}/htop/htop-${PV}.tar.gz"
+     SRC_URI[md5sum] = "0d01cca8df3349c74569cefebbd9919e"
+     SRC_URI[sha256sum] = "ee60657b044ece0df096c053060df7abf3cce3a568ab34d260049e6a37ccd8a1"
+                </literallayout>
+                At this point, you can build the software again using the
+                <filename>bitbake htop</filename> command.
+                There is just a set of errors now associated with the
+                empty <filename>LIC_FILES_CHKSUM</filename> variable now.
+            </para>
+-->
+
+        </section>
+
+        <section id='new-recipe-configuring-the-recipe'>
+            <title>Configuring the Recipe</title>
+
+            <para>
+                Most software provides some means of setting build-time
+                configuration options before compilation.
+                Typically, setting these options is accomplished by running a
+                configure script with some options, or by modifying a build
+                configuration file.
+            </para>
+
+            <para>
+                A major part of build-time configuration is about checking for
+                build-time dependencies and possibly enabling optional
+                functionality as a result.
+                You need to specify any build-time dependencies for the
+                software you are building in your recipe's
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink>
+                value, in terms of other recipes that satisfy those
+                dependencies.
+                You can often find build-time or runtime
+                dependencies described in the software's documentation.
+            </para>
+
+            <para>
+                The following list provides configuration items of note based
+                on how your software is built:
+                <itemizedlist>
+                    <listitem><para><emphasis>Autotools:</emphasis>
+                        If your source files have a
+                        <filename>configure.ac</filename> file, then your
+                        software is built using Autotools.
+                        If this is the case, you just need to worry about
+                        modifying the configuration.</para>
+                        <para>When using Autotools, your recipe needs to inherit
+                        the
+                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-autotools'><filename>autotools</filename></ulink>
+                        class and your recipe does not have to contain a
+                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-configure'><filename>do_configure</filename></ulink>
+                        task.
+                        However, you might still want to make some adjustments.
+                        For example, you can set
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_OECONF'><filename>EXTRA_OECONF</filename></ulink>
+                        to pass any needed configure options that are specific
+                        to the recipe.</para></listitem>
+                    <listitem><para><emphasis>CMake:</emphasis>
+                        If your source files have a
+                        <filename>CMakeLists.txt</filename> file, then your
+                        software is built using CMake.
+                        If this is the case, you just need to worry about
+                        modifying the configuration.</para>
+                        <para>When you use CMake, your recipe needs to inherit
+                        the
+                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-cmake'><filename>cmake</filename></ulink>
+                        class and your recipe does not have to contain a
+                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-configure'><filename>do_configure</filename></ulink>
+                        task.
+                        You can make some adjustments by setting
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_OECMAKE'><filename>EXTRA_OECMAKE</filename></ulink>
+                        to pass any needed configure options that are specific
+                        to the recipe.</para></listitem>
+                    <listitem><para><emphasis>Other:</emphasis>
+                        If your source files do not have a
+                        <filename>configure.ac</filename> or
+                        <filename>CMakeLists.txt</filename> file, then your
+                        software is built using some method other than Autotools
+                        or CMake.
+                        If this is the case, you normally need to provide a
+                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-configure'><filename>do_configure</filename></ulink>
+                        task in your recipe
+                        unless, of course, there is nothing to configure.
+                        </para>
+                        <para>Even if your software is not being built by
+                        Autotools or CMake, you still might not need to deal
+                        with any configuration issues.
+                        You need to determine if configuration is even a required step.
+                        You might need to modify a Makefile or some configuration file
+                        used for the build to specify necessary build options.
+                        Or, perhaps you might need to run a provided, custom
+                        configure script with the appropriate options.</para>
+                        <para>For the case involving a custom configure
+                        script, you would run
+                        <filename>./configure &dash;&dash;help</filename> and look for
+                        the options you need to set.</para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                Once configuration succeeds, it is always good practice to
+                look at the <filename>log.do_configure</filename> file to
+                ensure that the appropriate options have been enabled and no
+                additional build-time dependencies need to be added to
+                <filename>DEPENDS</filename>.
+                For example, if the configure script reports that it found
+                something not mentioned in <filename>DEPENDS</filename>, or
+                that it did not find something that it needed for some
+                desired optional functionality, then you would need to add
+                those to <filename>DEPENDS</filename>.
+                Looking at the log might also reveal items being checked for,
+                enabled, or both that you do not want, or items not being found
+                that are in <filename>DEPENDS</filename>, in which case
+                you would need to look at passing extra options to the
+                configure script as needed.
+                For reference information on configure options specific to the
+                software you are building, you can consult the output of the
+                <filename>./configure &dash;&dash;help</filename> command within
+                <filename>${S}</filename> or consult the software's upstream
+                documentation.
+            </para>
+        </section>
+
+        <section id='new-recipe-compilation'>
+            <title>Compilation</title>
+
+            <para>
+                During a build, the <filename>do_compile</filename> task
+                happens after source is fetched, unpacked, and configured.
+                If the recipe passes through <filename>do_compile</filename>
+                successfully, nothing needs to be done.
+            </para>
+
+            <para>
+                However, if the compile step fails, you need to diagnose the
+                failure.
+                Here are some common issues that cause failures:
+                <itemizedlist>
+                    <listitem><para><emphasis>Parallel build failures:</emphasis>
+                        These failures manifest themselves as intermittent
+                        errors, or errors reporting that a file or directory
+                        that should be created by some other part of the build
+                        process could not be found.
+                        This type of failure can occur even if, upon inspection,
+                        the file or directory does exist after the build has
+                        failed, because that part of the build process happened
+                        in the wrong order.</para>
+                        <para>To fix the problem, you need to either satisfy
+                        the missing dependency in the Makefile or whatever
+                        script produced the Makefile, or (as a workaround)
+                        set
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></ulink>
+                        to an empty string:
+                        <literallayout class='monospaced'>
+     PARALLEL_MAKE = ""
+                        </literallayout></para>
+                        <para>
+                            For information on parallel Makefile issues, see the
+                            "<link linkend='debugging-parallel-make-races'>Debugging Parallel Make Races</link>"
+                            section.
+                            </para></listitem>
+                    <listitem><para><emphasis>Improper host path usage:</emphasis>
+                        This failure applies to recipes building for the target
+                        or <filename>nativesdk</filename> only.
+                        The failure occurs when the compilation process uses
+                        improper headers, libraries, or other files from the
+                        host system when cross-compiling for the target.
+                        </para>
+                        <para>To fix the problem, examine the
+                        <filename>log.do_compile</filename> file to identify
+                        the host paths being used (e.g.
+                        <filename>/usr/include</filename>,
+                        <filename>/usr/lib</filename>, and so forth) and then
+                        either add configure options, apply a patch, or do both.
+                        </para></listitem>
+                    <listitem><para><emphasis>Failure to find required
+                        libraries/headers:</emphasis>
+                        If a build-time dependency is missing because it has
+                        not been declared in
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink>,
+                        or because the dependency exists but the path used by
+                        the build process to find the file is incorrect and the
+                        configure step did not detect it, the compilation
+                        process could fail.
+                        For either of these failures, the compilation process
+                        notes that files could not be found.
+                        In these cases, you need to go back and add additional
+                        options to the configure script as well as possibly
+                        add additional build-time dependencies to
+                        <filename>DEPENDS</filename>.</para>
+                        <para>Occasionally, it is necessary to apply a patch
+                        to the source to ensure the correct paths are used.
+                        If you need to specify paths to find files staged
+                        into the sysroot from other recipes, use the variables
+                        that the OpenEmbedded build system provides
+                        (e.g.
+                        <filename>STAGING_BINDIR</filename>,
+                        <filename>STAGING_INCDIR</filename>,
+                        <filename>STAGING_DATADIR</filename>, and so forth).
+<!--
+                        (e.g.
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-STAGING_BINDIR'><filename>STAGING_BINDIR</filename></ulink>,
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-STAGING_INCDIR'><filename>STAGING_INCDIR</filename></ulink>,
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-STAGING_DATADIR'><filename>STAGING_DATADIR</filename></ulink>,
+                        and so forth).
+-->
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='new-recipe-installing'>
+            <title>Installing</title>
+
+            <para>
+                During <filename>do_install</filename>, the task copies the
+                built files along with their hierarchy to locations that
+                would mirror their locations on the target device.
+                The installation process copies files from the
+                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink><filename>}</filename>,
+                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-B'><filename>B</filename></ulink><filename>}</filename>,
+                and
+                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink><filename>}</filename>
+                directories to the
+                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-D'><filename>D</filename></ulink><filename>}</filename>
+                directory to create the structure as it should appear on the
+                target system.
+            </para>
+
+            <para>
+                How your software is built affects what you must do to be
+                sure your software is installed correctly.
+                The following list describes what you must do for installation
+                depending on the type of build system used by the software
+                being built:
+                <itemizedlist>
+                    <listitem><para><emphasis>Autotools and CMake:</emphasis>
+                        If the software your recipe is building uses Autotools
+                        or CMake, the OpenEmbedded build
+                        system understands how to install the software.
+                        Consequently, you do not have to have a
+                        <filename>do_install</filename> task as part of your
+                        recipe.
+                        You just need to make sure the install portion of the
+                        build completes with no issues.
+                        However, if you wish to install additional files not
+                        already being installed by
+                        <filename>make install</filename>, you should do this
+                        using a <filename>do_install_append</filename> function
+                        using the install command as described in
+                        the "Manual" bulleted item later in this list.
+                        </para></listitem>
+                    <listitem><para><emphasis>Other (using
+                        <filename>make install</filename>):</emphasis>
+                        You need to define a
+                        <filename>do_install</filename> function in your
+                        recipe.
+                        The function should call
+                        <filename>oe_runmake install</filename> and will likely
+                        need to pass in the destination directory as well.
+                        How you pass that path is dependent on how the
+                        <filename>Makefile</filename> being run is written
+                        (e.g. <filename>DESTDIR=${D}</filename>,
+                        <filename>PREFIX=${D}</filename>,
+                        <filename>INSTALLROOT=${D}</filename>, and so forth).
+                        </para>
+                        <para>For an example recipe using
+                        <filename>make install</filename>, see the
+                        "<link linkend='new-recipe-makefile-based-package'>Makefile-Based Package</link>"
+                        section.</para></listitem>
+                    <listitem><para><emphasis>Manual:</emphasis>
+                        You need to define a
+                        <filename>do_install</filename> function in your
+                        recipe.
+                        The function must first use
+                        <filename>install -d</filename> to create the
+                        directories under
+                        <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-D'><filename>D</filename></ulink><filename>}</filename>.
+                        Once the directories exist, your function can use
+                        <filename>install</filename> to manually install the
+                        built software into the directories.</para>
+                        <para>You can find more information on
+                        <filename>install</filename> at
+                        <ulink url='http://www.gnu.org/software/coreutils/manual/html_node/install-invocation.html'></ulink>.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                For the scenarios that do not use Autotools or
+                CMake, you need to track the installation
+                and diagnose and fix any issues until everything installs
+                correctly.
+                You need to look in the default location of
+                <filename>${D}</filename>, which is
+                <filename>${WORKDIR}/image</filename>, to be sure your
+                files have been installed correctly.
+            </para>
+
+            <note><title>Notes</title>
+                <itemizedlist>
+                    <listitem><para>
+                        During the installation process, you might need to
+                        modify some of the installed files to suit the target
+                        layout.
+                        For example, you might need to replace hard-coded paths
+                        in an initscript with values of variables provided by
+                        the build system, such as replacing
+                        <filename>/usr/bin/</filename> with
+                        <filename>${bindir}</filename>.
+                        If you do perform such modifications during
+                        <filename>do_install</filename>, be sure to modify the
+                        destination file after copying rather than before
+                        copying.
+                        Modifying after copying ensures that the build system
+                        can re-execute <filename>do_install</filename> if
+                        needed.
+                        </para></listitem>
+                    <listitem><para>
+                        <filename>oe_runmake install</filename>, which can be
+                        run directly or can be run indirectly by the
+                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-autotools'><filename>autotools</filename></ulink>
+                        and
+                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-cmake'><filename>cmake</filename></ulink>
+                        classes, runs <filename>make install</filename> in
+                        parallel.
+                        Sometimes, a Makefile can have missing dependencies
+                        between targets that can result in race conditions.
+                        If you experience intermittent failures during
+                        <filename>do_install</filename>, you might be able to
+                        work around them by disabling parallel Makefile
+                        installs by adding the following to the recipe:
+                        <literallayout class='monospaced'>
+     PARALLEL_MAKEINST = ""
+                        </literallayout>
+                        See
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKEINST'><filename>PARALLEL_MAKEINST</filename></ulink>
+                        for additional information.
+                        </para></listitem>
+                </itemizedlist>
+            </note>
+        </section>
+
+        <section id='new-recipe-enabling-system-services'>
+            <title>Enabling System Services</title>
+
+            <para>
+                If you want to install a service, which is a process that
+                usually starts on boot and runs in the background, then
+                you must include some additional definitions in your recipe.
+            </para>
+
+            <para>
+                If you are adding services and the service initialization
+                script or the service file itself is not installed, you must
+                provide for that installation in your recipe using a
+                <filename>do_install_append</filename> function.
+                If your recipe already has a <filename>do_install</filename>
+                function, update the function near its end rather than
+                adding an additional <filename>do_install_append</filename>
+                function.
+            </para>
+
+            <para>
+                When you create the installation for your services, you need
+                to accomplish what is normally done by
+                <filename>make install</filename>.
+                In other words, make sure your installation arranges the output
+                similar to how it is arranged on the target system.
+            </para>
+
+            <para>
+                The OpenEmbedded build system provides support for starting
+                services two different ways:
+                <itemizedlist>
+                    <listitem><para><emphasis>SysVinit:</emphasis>
+                        SysVinit is a system and service manager that
+                        manages the init system used to control the very basic
+                        functions of your system.
+                        The init program is the first program
+                        started by the Linux kernel when the system boots.
+                        Init then controls the startup, running and shutdown
+                        of all other programs.</para>
+                        <para>To enable a service using SysVinit, your recipe
+                        needs to inherit the
+                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-update-rc.d'><filename>update-rc.d</filename></ulink>
+                        class.
+                        The class helps facilitate safely installing the
+                        package on the target.</para>
+                        <para>You will need to set the
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-INITSCRIPT_PACKAGES'><filename>INITSCRIPT_PACKAGES</filename></ulink>,
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-INITSCRIPT_NAME'><filename>INITSCRIPT_NAME</filename></ulink>,
+                        and
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-INITSCRIPT_PARAMS'><filename>INITSCRIPT_PARAMS</filename></ulink>
+                        variables within your recipe.</para></listitem>
+                    <listitem><para><emphasis>systemd:</emphasis>
+                        System Management Daemon (systemd) was designed to
+                        replace SysVinit and to provide
+                        enhanced management of services.
+                        For more information on systemd, see the systemd
+                        homepage at
+                        <ulink url='http://freedesktop.org/wiki/Software/systemd/'></ulink>.
+                        </para>
+                        <para>To enable a service using systemd, your recipe
+                        needs to inherit the
+                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-systemd'><filename>systemd</filename></ulink>
+                        class.
+                        See the <filename>systemd.bbclass</filename> file
+                        located in your
+                        <link linkend='source-directory'>Source Directory</link>.
+                        section for more information.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='new-recipe-packaging'>
+            <title>Packaging</title>
+
+            <para>
+                Successful packaging is a combination of automated processes
+                performed by the OpenEmbedded build system and some
+                specific steps you need to take.
+                The following list describes the process:
+                <itemizedlist>
+                    <listitem><para><emphasis>Splitting Files</emphasis>:
+                        The <filename>do_package</filename> task splits the
+                        files produced by the recipe into logical components.
+                        Even software that produces a single binary might
+                        still have debug symbols, documentation, and other
+                        logical components that should be split out.
+                        The <filename>do_package</filename> task ensures
+                        that files are split up and packaged correctly.
+                        </para></listitem>
+                    <listitem><para><emphasis>Running QA Checks</emphasis>:
+                        The
+                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-insane'><filename>insane</filename></ulink>
+                        class adds a step to
+                        the package generation process so that output quality
+                        assurance checks are generated by the OpenEmbedded
+                        build system.
+                        This step performs a range of checks to be sure the
+                        build's output is free of common problems that show
+                        up during runtime.
+                        For information on these checks, see the
+                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-insane'><filename>insane</filename></ulink>
+                        class and the
+                        "<ulink url='&YOCTO_DOCS_REF_URL;#ref-qa-checks'>QA Error and Warning Messages</ulink>"
+                        chapter in the Yocto Project Reference Manual.
+                        </para></listitem>
+                    <listitem><para><emphasis>Hand-Checking Your Packages</emphasis>:
+                        After you build your software, you need to be sure
+                        your packages are correct.
+                        Examine the
+                        <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink><filename>}/packages-split</filename>
+                        directory and make sure files are where you expect
+                        them to be.
+                        If you discover problems, you can set
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>,
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-FILES'><filename>FILES</filename></ulink>,
+                        <filename>do_install(_append)</filename>, and so forth as
+                        needed.
+                        </para></listitem>
+                    <listitem><para><emphasis>Splitting an Application into Multiple Packages</emphasis>:
+                        If you need to split an application into several
+                        packages, see the
+                        "<link linkend='splitting-an-application-into-multiple-packages'>Splitting an Application into Multiple Packages</link>"
+                        section for an example.
+                        </para></listitem>
+                    <listitem><para><emphasis>Installing a Post-Installation Script</emphasis>:
+                        For an example showing how to install a
+                        post-installation script, see the
+                        "<link linkend='new-recipe-post-installation-scripts'>Post-Installation Scripts</link>"
+                        section.
+                        </para></listitem>
+                    <listitem><para><emphasis>Marking Package Architecture</emphasis>:
+                        Depending on what your recipe is building and how it
+                        is configured, it might be important to mark the
+                        packages produced as being specific to a particular
+                        machine, or to mark them as not being specific to
+                        a particular machine or architecture at all.
+                        By default, packages produced for the target are
+                        marked as being specific to the architecture of the
+                        target machine because that is usually the desired
+                        result.
+                        However, if the recipe configures the software to be
+                        built specific to the target machine (e.g. the
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
+                        value is passed into the configure script or a patch
+                        is applied only for a particular machine), then you
+                        should mark the packages produced as being
+                        machine-specific by adding the following to the
+                        recipe:
+                        <literallayout class='monospaced'>
+     PACKAGE_ARCH = "${MACHINE_ARCH}"
+                        </literallayout>
+                        On the other hand, if the recipe produces packages
+                        that do not contain anything specific to the target
+                        machine or architecture at all (e.g. recipes
+                        that simply package script files or configuration
+                        files), you should use the
+                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-allarch'><filename>allarch</filename></ulink>
+                        class to do this for you by adding this to your
+                        recipe:
+                        <literallayout class='monospaced'>
+     inherit allarch
+                        </literallayout>
+                        Ensuring that the package architecture is correct is
+                        not critical while you are doing the first few builds
+                        of your recipe.
+                        However, it is important in order
+                        to ensure that your recipe rebuilds (or does not
+                        rebuild) appropriately in response to changes in
+                        configuration, and to ensure that you get the
+                        appropriate packages installed on the target machine,
+                        particularly if you run separate builds for more
+                        than one target machine.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='properly-versioning-pre-release-recipes'>
+            <title>Properly Versioning Pre-Release Recipes</title>
+
+            <para>
+                Sometimes the name of a recipe can lead to versioning
+                problems when the recipe is upgraded to a final release.
+                For example, consider the
+                <filename>irssi_0.8.16-rc1.bb</filename> recipe file in
+                the list of example recipes in the
+                "<link linkend='new-recipe-storing-and-naming-the-recipe'>Storing and Naming the Recipe</link>"
+                section.
+                This recipe is at a release candidate stage (i.e.
+                "rc1").
+                When the recipe is released, the recipe filename becomes
+                <filename>irssi_0.8.16.bb</filename>.
+                The version change from <filename>0.8.16-rc1</filename>
+                to <filename>0.8.16</filename> is seen as a decrease by the
+                build system and package managers, so the resulting packages
+                will not correctly trigger an upgrade.
+            </para>
+
+            <para>
+                In order to ensure the versions compare properly, the
+                recommended convention is to set
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>
+                within the recipe to
+                "<replaceable>previous_version</replaceable>+<replaceable>current_version</replaceable>".
+                You can use an additional variable so that you can use the
+                current version elsewhere.
+                Here is an example:
+                <literallayout class='monospaced'>
+     REALPV = "0.8.16-rc1"
+     PV = "0.8.15+${REALPV}"
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='new-recipe-post-installation-scripts'>
+            <title>Post-Installation Scripts</title>
+
+            <para>
+                Post-installation scripts run immediately after installing
+                a package on the target or during image creation when a
+                package is included in an image.
+                To add a post-installation script to a package, add a
+                <filename>pkg_postinst_PACKAGENAME()</filename> function to
+                the recipe file (<filename>.bb</filename>) and replace
+                <filename>PACKAGENAME</filename> with the name of the package
+                you want to attach to the <filename>postinst</filename>
+                script.
+                To apply the post-installation script to the main package
+                for the recipe, which is usually what is required, specify
+                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>
+                in place of <filename>PACKAGENAME</filename>.
+            </para>
+
+            <para>
+                A post-installation function has the following structure:
+                <literallayout class='monospaced'>
+     pkg_postinst_PACKAGENAME() {
+     #!/bin/sh -e
+     # Commands to carry out
+     }
+                </literallayout>
+            </para>
+
+            <para>
+                The script defined in the post-installation function is
+                called when the root filesystem is created.
+                If the script succeeds, the package is marked as installed.
+                If the script fails, the package is marked as unpacked and
+                the script is executed when the image boots again.
+            </para>
+
+            <para>
+                Sometimes it is necessary for the execution of a
+                post-installation script to be delayed until the first boot.
+                For example, the script might need to be executed on the
+                device itself.
+                To delay script execution until boot time, use the following
+                structure in the post-installation script:
+                <literallayout class='monospaced'>
+     pkg_postinst_PACKAGENAME() {
+     #!/bin/sh -e
+     if [ x"$D" = "x" ]; then
+          # Actions to carry out on the device go here
+     else
+          exit 1
+     fi
+     }
+                </literallayout>
+            </para>
+
+            <para>
+                The previous example delays execution until the image boots
+                again because the environment variable <filename>D</filename>
+                points to the directory containing the image when
+                the root filesystem is created at build time but is unset
+                when executed on the first boot.
+            </para>
+
+            <note>
+                Equivalent support for pre-install, pre-uninstall, and
+                post-uninstall scripts exist by way of
+                <filename>pkg_preinst</filename>,
+                <filename>pkg_prerm</filename>, and
+                <filename>pkg_postrm</filename>, respectively.
+                These scrips work in exactly the same way as does
+                <filename>pkg_postinst</filename> with the exception that they
+                run at different times.
+                Also, because of when they run, they are not applicable to
+                being run at image creation time like
+                <filename>pkg_postinst</filename>.
+            </note>
+        </section>
+
+        <section id='new-recipe-testing'>
+            <title>Testing</title>
+
+            <para>
+                The final step for completing your recipe is to be sure that
+                the software you built runs correctly.
+                To accomplish runtime testing, add the build's output
+                packages to your image and test them on the target.
+            </para>
+
+            <para>
+                For information on how to customize your image by adding
+                specific packages, see the
+                "<link linkend='usingpoky-extend-customimage'>Customizing Images</link>"
+                section.
+            </para>
+        </section>
+
+        <section id='new-recipe-testing-examples'>
+            <title>Examples</title>
+
+            <para>
+                To help summarize how to write a recipe, this section provides
+                some examples given various scenarios:
+                <itemizedlist>
+                    <listitem><para>Recipes that use local files</para></listitem>
+                    <listitem><para>Using an Autotooled package</para></listitem>
+                    <listitem><para>Using a Makefile-based package</para></listitem>
+                    <listitem><para>Splitting an application into multiple packages</para></listitem>
+                    <listitem><para>Adding binaries to an image</para></listitem>
+                </itemizedlist>
+            </para>
+
+            <section id='new-recipe-single-c-file-package-hello-world'>
+                <title>Single .c File Package (Hello World!)</title>
+
+                <para>
+                    Building an application from a single file that is stored
+                    locally (e.g. under <filename>files</filename>) requires
+                    a recipe that has the file listed in the
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'>SRC_URI</ulink></filename>
+                    variable.
+                    Additionally, you need to manually write the
+                    <filename>do_compile</filename> and
+                    <filename>do_install</filename> tasks.
+                    The <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-S'>S</ulink></filename>
+                    variable defines the directory containing the source code,
+                    which is set to
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink>
+                    in this case - the directory BitBake uses for the build.
+                    <literallayout class='monospaced'>
+     SUMMARY = "Simple helloworld application"
+     SECTION = "examples"
+     LICENSE = "MIT"
+     LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
+
+     SRC_URI = "file://helloworld.c"
+
+     S = "${WORKDIR}"
+
+     do_compile() {
+        ${CC} helloworld.c -o helloworld
+     }
+
+     do_install() {
+        install -d ${D}${bindir}
+        install -m 0755 helloworld ${D}${bindir}
+     }
+                    </literallayout>
+                </para>
+
+                <para>
+                    By default, the <filename>helloworld</filename>,
+                    <filename>helloworld-dbg</filename>, and
+                    <filename>helloworld-dev</filename> packages are built.
+                    For information on how to customize the packaging process,
+                    see the
+                    "<link linkend='splitting-an-application-into-multiple-packages'>Splitting an Application into Multiple Packages</link>"
+                    section.
+                </para>
+            </section>
+
+            <section id='new-recipe-autotooled-package'>
+                <title>Autotooled Package</title>
+                <para>
+                    Applications that use Autotools such as <filename>autoconf</filename> and
+                    <filename>automake</filename> require a recipe that has a source archive listed in
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'>SRC_URI</ulink></filename> and
+                    also inherit the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-autotools'><filename>autotools</filename></ulink>
+                    class, which contains the definitions of all the steps
+                    needed to build an Autotool-based application.
+                    The result of the build is automatically packaged.
+                    And, if the application uses NLS for localization, packages with local information are
+                    generated (one package per language).
+                    Following is one example: (<filename>hello_2.3.bb</filename>)
+                    <literallayout class='monospaced'>
+     SUMMARY = "GNU Helloworld application"
+     SECTION = "examples"
+     LICENSE = "GPLv2+"
+     LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
+
+     SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
+
+     inherit autotools gettext
+                     </literallayout>
+                </para>
+
+                <para>
+                    The variable
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</ulink></filename>
+                    is used to track source license changes as described in the
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#usingpoky-configuring-LIC_FILES_CHKSUM'>Tracking License Changes</ulink>" section.
+                    You can quickly create Autotool-based recipes in a manner similar to the previous example.
+                </para>
+            </section>
+
+            <section id='new-recipe-makefile-based-package'>
+                <title>Makefile-Based Package</title>
+
+                <para>
+                    Applications that use GNU <filename>make</filename> also require a recipe that has
+                    the source archive listed in
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'>SRC_URI</ulink></filename>.
+                    You do not need to add a <filename>do_compile</filename> step since by default BitBake
+                    starts the <filename>make</filename> command to compile the application.
+                    If you need additional <filename>make</filename> options, you should store them in the
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_OEMAKE'>EXTRA_OEMAKE</ulink></filename>
+                    variable.
+                    BitBake passes these options into the GNU <filename>make</filename> invocation.
+                    Note that a <filename>do_install</filename> task is still required.
+                    Otherwise, BitBake runs an empty <filename>do_install</filename> task by default.
+                </para>
+
+               <para>
+                    Some applications might require extra parameters to be passed to the compiler.
+                    For example, the application might need an additional header path.
+                    You can accomplish this by adding to the
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-CFLAGS'>CFLAGS</ulink></filename> variable.
+                    The following example shows this:
+                    <literallayout class='monospaced'>
+     CFLAGS_prepend = "-I ${S}/include "
+                    </literallayout>
+                </para>
+
+                <para>
+                In the following example, <filename>mtd-utils</filename> is a makefile-based package:
+                    <literallayout class='monospaced'>
+     SUMMARY = "Tools for managing memory technology devices"
+     SECTION = "base"
+     DEPENDS = "zlib lzo e2fsprogs util-linux"
+     HOMEPAGE = "http://www.linux-mtd.infradead.org/"
+     LICENSE = "GPLv2+"
+     LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
+                         file://include/common.h;beginline=1;endline=17;md5=ba05b07912a44ea2bf81ce409380049c"
+
+     # Use the latest version at 26 Oct, 2013
+     SRCREV = "9f107132a6a073cce37434ca9cda6917dd8d866b"
+     SRC_URI = "git://git.infradead.org/mtd-utils.git \
+                     file://add-exclusion-to-mkfs-jffs2-git-2.patch \
+     "
+
+     PV = "1.5.1+git${SRCPV}"
+
+     S = "${WORKDIR}/git/"
+
+     EXTRA_OEMAKE = "'CC=${CC}' 'RANLIB=${RANLIB}' 'AR=${AR}' 'CFLAGS=${CFLAGS} -I${S}/include -DWITHOUT_XATTR' 'BUILDDIR=${S}'"
+
+     do_install () {
+             oe_runmake install DESTDIR=${D} SBINDIR=${sbindir} MANDIR=${mandir} INCLUDEDIR=${includedir}
+     }
+
+     PACKAGES =+ "mtd-utils-jffs2 mtd-utils-ubifs mtd-utils-misc"
+
+     FILES_mtd-utils-jffs2 = "${sbindir}/mkfs.jffs2 ${sbindir}/jffs2dump ${sbindir}/jffs2reader ${sbindir}/sumtool"
+     FILES_mtd-utils-ubifs = "${sbindir}/mkfs.ubifs ${sbindir}/ubi*"
+     FILES_mtd-utils-misc = "${sbindir}/nftl* ${sbindir}/ftl* ${sbindir}/rfd* ${sbindir}/doc* ${sbindir}/serve_image ${sbindir}/recv_image"
+
+     PARALLEL_MAKE = ""
+
+     BBCLASSEXTEND = "native"
+                    </literallayout>
+                </para>
+            </section>
+
+            <section id='splitting-an-application-into-multiple-packages'>
+                <title>Splitting an Application into Multiple Packages</title>
+
+                <para>
+                    You can use the variables
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'>PACKAGES</ulink></filename> and
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-FILES'>FILES</ulink></filename>
+                    to split an application into multiple packages.
+                </para>
+
+                <para>
+                    Following is an example that uses the <filename>libxpm</filename> recipe.
+                    By default, this recipe generates a single package that contains the library along
+                    with a few binaries.
+                    You can modify the recipe to split the binaries into separate packages:
+                    <literallayout class='monospaced'>
+     require xorg-lib-common.inc
+
+     SUMMARY = "X11 Pixmap library"
+     LICENSE = "X-BSD"
+     LIC_FILES_CHKSUM = "file://COPYING;md5=3e07763d16963c3af12db271a31abaa5"
+     DEPENDS += "libxext libsm libxt"
+     PR = "r3"
+     PE = "1"
+
+     XORG_PN = "libXpm"
+
+     PACKAGES =+ "sxpm cxpm"
+     FILES_cxpm = "${bindir}/cxpm"
+     FILES_sxpm = "${bindir}/sxpm"
+                    </literallayout>
+                </para>
+
+                <para>
+                    In the previous example, we want to ship the <filename>sxpm</filename>
+                    and <filename>cxpm</filename> binaries in separate packages.
+                    Since <filename>bindir</filename> would be packaged into the main
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'>PN</ulink></filename>
+                    package by default, we prepend the <filename>PACKAGES</filename>
+                    variable so additional package names are added to the start of list.
+                    This results in the extra <filename>FILES_*</filename>
+                    variables then containing information that define which files and
+                    directories go into which packages.
+                    Files included by earlier packages are skipped by latter packages.
+                    Thus, the main <filename>PN</filename> package
+                    does not include the above listed files.
+                </para>
+            </section>
+
+            <section id='packaging-externally-produced-binaries'>
+                <title>Packaging Externally Produced Binaries</title>
+
+                <para>
+                    Sometimes, you need to add pre-compiled binaries to an
+                    image.
+                    For example, suppose that binaries for proprietary code
+                    exist, which are created by a particular division of a
+                    company.
+                    Your part of the company needs to use those binaries as
+                    part of an image that you are building using the
+                    OpenEmbedded build system.
+                    Since you only have the binaries and not the source code,
+                    you cannot use a typical recipe that expects to fetch the
+                    source specified in
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                    and then compile it.
+                </para>
+
+                <para>
+                    One method is to package the binaries and then install them
+                    as part of the image.
+                    Generally, it is not a good idea to package binaries
+                    since, among other things, it can hinder the ability to
+                    reproduce builds and could lead to compatibility problems
+                    with ABI in the future.
+                    However, sometimes you have no choice.
+                </para>
+
+                <para>
+                    The easiest solution is to create a recipe that uses
+                    the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-bin-package'><filename>bin_package</filename></ulink>
+                    class and to be sure that you are using default locations
+                    for build artifacts.
+                    In most cases, the <filename>bin_package</filename> class
+                    handles "skipping" the configure and compile steps as well
+                    as sets things up to grab packages from the appropriate
+                    area.
+                    In particular, this class sets <filename>noexec</filename>
+                    on both the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-configure'><filename>do_configure</filename></ulink>
+                    and
+                    <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-compile'><filename>do_compile</filename></ulink>
+                    tasks, sets
+                    <filename>FILES_${PN}</filename> to "/" so that it picks
+                    up all files, and sets up a
+                    <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink>
+                    task, which effectively copies all files from
+                    <filename>${S}</filename> to <filename>${D}</filename>.
+                    The <filename>bin_package</filename> class works well when
+                    the files extracted into <filename>${S}</filename> are
+                    already laid out in the way they should be laid out
+                    on the target.
+                    For more information on these variables, see the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-FILES'><filename>FILES</filename></ulink>,
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink>,
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink>,
+                    and
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-D'><filename>D</filename></ulink>
+                    variables in the Yocto Project Reference Manual's variable
+                    glossary.
+                </para>
+
+                <para>
+                    If you can't use the <filename>bin_package</filename>
+                    class, you need to be sure you are doing the following:
+                    <itemizedlist>
+                        <listitem><para>Create a recipe where the
+                            <filename>do_configure</filename> and
+                            <filename>do_compile</filename> tasks do nothing:
+                            <literallayout class='monospaced'>
+     do_configure[noexec] = "1"
+     do_compile[noexec] = "1"
+                            </literallayout>
+                            Alternatively, you can make these tasks an empty
+                            function.
+                            </para></listitem>
+                        <listitem><para>Make sure your
+                            <filename>do_install</filename> task installs the
+                            binaries appropriately.
+                            </para></listitem>
+                        <listitem><para>Ensure that you set up
+                            <filename>FILES</filename> (usually
+                            <filename>FILES_${PN}</filename>) to point to the
+                            files you have installed, which of course depends
+                            on where you have installed them and whether
+                            those files are in different locations than the
+                            defaults.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </section>
+        </section>
+    </section>
+
+    <section id="platdev-newmachine">
+        <title>Adding a New Machine</title>
+
+        <para>
+            Adding a new machine to the Yocto Project is a straightforward
+            process.
+            This section describes how to add machines that are similar
+            to those that the Yocto Project already supports.
+            <note>
+                Although well within the capabilities of the Yocto Project,
+                adding a totally new architecture might require
+                changes to <filename>gcc/glibc</filename> and to the site
+                information, which is beyond the scope of this manual.
+            </note>
+        </para>
+
+        <para>
+            For a complete example that shows how to add a new machine,
+            see the
+            "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>"
+            section in the Yocto Project Board Support Package (BSP) Developer's Guide.
+        </para>
+
+        <section id="platdev-newmachine-conffile">
+            <title>Adding the Machine Configuration File</title>
+
+            <para>
+                To add a new machine, you need to add a new machine
+                configuration file to the layer's
+                <filename>conf/machine</filename> directory.
+                This configuration file provides details about the device
+                you are adding.
+            </para>
+
+            <para>
+                The OpenEmbedded build system uses the root name of the
+                machine configuration file to reference the new machine.
+                For example, given a machine configuration file named
+                <filename>crownbay.conf</filename>, the build system
+                recognizes the machine as "crownbay".
+            </para>
+
+            <para>
+                The most important variables you must set in your machine
+                configuration file or include from a lower-level configuration
+                file are as follows:
+                <itemizedlist>
+                    <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-TARGET_ARCH'>TARGET_ARCH</ulink></filename>
+                        (e.g. "arm")</para></listitem>
+                    <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER'>PREFERRED_PROVIDER</ulink>_virtual/kernel</filename>
+                        </para></listitem>
+                    <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_FEATURES'>MACHINE_FEATURES</ulink></filename>
+                        (e.g. "apm screen wifi")</para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                You might also need these variables:
+                <itemizedlist>
+                    <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-SERIAL_CONSOLES'>SERIAL_CONSOLES</ulink></filename>
+                        (e.g. "115200;ttyS0 115200;ttyS1")</para></listitem>
+                    <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_IMAGETYPE'>KERNEL_IMAGETYPE</ulink></filename>
+                        (e.g. "zImage")</para></listitem>
+                    <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_FSTYPES'>IMAGE_FSTYPES</ulink></filename>
+                        (e.g. "tar.gz jffs2")</para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                You can find full details on these variables in the reference
+                section.
+                You can leverage existing machine <filename>.conf</filename>
+                files from <filename>meta-yocto-bsp/conf/machine/</filename>.
+            </para>
+        </section>
+
+        <section id="platdev-newmachine-kernel">
+            <title>Adding a Kernel for the Machine</title>
+
+            <para>
+                The OpenEmbedded build system needs to be able to build a kernel
+                for the machine.
+                You need to either create a new kernel recipe for this machine,
+                or extend an existing kernel recipe.
+                You can find several kernel recipe examples in the
+                Source Directory at
+                <filename>meta/recipes-kernel/linux</filename>
+                that you can use as references.
+            </para>
+
+            <para>
+                If you are creating a new kernel recipe, normal recipe-writing
+                rules apply for setting up a
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'>SRC_URI</ulink></filename>.
+                Thus, you need to specify any necessary patches and set
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-S'>S</ulink></filename>
+                to point at the source code.
+                You need to create a <filename>do_configure</filename> task that
+                configures the unpacked kernel with a
+                <filename>defconfig</filename> file.
+                You can do this by using a <filename>make defconfig</filename>
+                command or, more commonly, by copying in a suitable
+                <filename>defconfig</filename> file and then running
+                <filename>make oldconfig</filename>.
+                By making use of <filename>inherit kernel</filename> and
+                potentially some of the <filename>linux-*.inc</filename> files,
+                most other functionality is centralized and the defaults of the
+                class normally work well.
+            </para>
+
+            <para>
+                If you are extending an existing kernel recipe, it is usually
+                a matter of adding a suitable <filename>defconfig</filename>
+                file.
+                The file needs to be added into a location similar to
+                <filename>defconfig</filename> files used for other machines
+                in a given kernel recipe.
+                A possible way to do this is by listing the file in the
+                <filename>SRC_URI</filename> and adding the machine to the
+                expression in
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'>COMPATIBLE_MACHINE</ulink></filename>:
+                <literallayout class='monospaced'>
+     COMPATIBLE_MACHINE = '(qemux86|qemumips)'
+                </literallayout>
+            </para>
+        </section>
+
+        <section id="platdev-newmachine-formfactor">
+            <title>Adding a Formfactor Configuration File</title>
+
+            <para>
+                A formfactor configuration file provides information about the
+                target hardware for which the image is being built and information that
+                the build system cannot obtain from other sources such as the kernel.
+                Some examples of information contained in a formfactor configuration file include
+                framebuffer orientation, whether or not the system has a keyboard,
+                the positioning of the keyboard in relation to the screen, and
+                the screen resolution.
+            </para>
+
+            <para>
+                The build system uses reasonable defaults in most cases.
+                However, if customization is
+                necessary, you need to create a <filename>machconfig</filename> file
+                in the <filename>meta/recipes-bsp/formfactor/files</filename>
+                directory.
+                This directory contains directories for specific machines such as
+                <filename>qemuarm</filename> and <filename>qemux86</filename>.
+                For information about the settings available and the defaults, see the
+                <filename>meta/recipes-bsp/formfactor/files/config</filename> file found in the
+                same area.
+            </para>
+
+            <para>
+                Following is an example for "qemuarm" machine:
+                <literallayout class='monospaced'>
+     HAVE_TOUCHSCREEN=1
+     HAVE_KEYBOARD=1
+
+     DISPLAY_CAN_ROTATE=0
+     DISPLAY_ORIENTATION=0
+     #DISPLAY_WIDTH_PIXELS=640
+     #DISPLAY_HEIGHT_PIXELS=480
+     #DISPLAY_BPP=16
+     DISPLAY_DPI=150
+     DISPLAY_SUBPIXEL_ORDER=vrgb
+                </literallayout>
+            </para>
+        </section>
+    </section>
+
+    <section id="platdev-working-with-libraries">
+        <title>Working With Libraries</title>
+
+        <para>
+            Libraries are an integral part of your system.
+            This section describes some common practices you might find
+            helpful when working with libraries to build your system:
+            <itemizedlist>
+                <listitem><para><link linkend='including-static-library-files'>How to include static library files</link>
+                    </para></listitem>
+                <listitem><para><link linkend='combining-multiple-versions-library-files-into-one-image'>How to use the Multilib feature to combine multiple versions of library files into a single image</link>
+                    </para></listitem>
+                <listitem><para><link linkend='installing-multiple-versions-of-the-same-library'>How to install multiple versions of the same library in parallel on the same system</link>
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+
+        <section id='including-static-library-files'>
+            <title>Including Static Library Files</title>
+
+            <para>
+                If you are building a library and the library offers static linking, you can control
+                which static library files (<filename>*.a</filename> files) get included in the
+                built library.
+            </para>
+
+            <para>
+                The <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>
+                and <ulink url='&YOCTO_DOCS_REF_URL;#var-FILES'><filename>FILES_*</filename></ulink>
+                variables in the
+                <filename>meta/conf/bitbake.conf</filename> configuration file define how files installed
+                by the <filename>do_install</filename> task are packaged.
+                By default, the <filename>PACKAGES</filename> variable includes
+                <filename>${PN}-staticdev</filename>, which represents all static library files.
+                <note>
+                    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, where
+                you can see how the static library files are defined:
+                <literallayout class='monospaced'>
+     PACKAGE_BEFORE_PN ?= ""
+     PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
+     PACKAGES_DYNAMIC = "^${PN}-locale-.*"
+     FILES = ""
+
+     FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
+                 ${sysconfdir} ${sharedstatedir} ${localstatedir} \
+                 ${base_bindir}/* ${base_sbindir}/* \
+                 ${base_libdir}/*${SOLIBS} \
+                 ${base_prefix}/lib/udev/rules.d ${prefix}/lib/udev/rules.d \
+                 ${datadir}/${BPN} ${libdir}/${BPN}/* \
+                 ${datadir}/pixmaps ${datadir}/applications \
+                 ${datadir}/idl ${datadir}/omf ${datadir}/sounds \
+                 ${libdir}/bonobo/servers"
+
+     FILES_${PN}-bin = "${bindir}/* ${sbindir}/*"
+
+     FILES_${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
+                 ${datadir}/gnome/help"
+     SECTION_${PN}-doc = "doc"
+
+     FILES_SOLIBSDEV ?= "${base_libdir}/lib*${SOLIBSDEV} ${libdir}/lib*${SOLIBSDEV}"
+     FILES_${PN}-dev = "${includedir} ${FILES_SOLIBSDEV} ${libdir}/*.la \
+                     ${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
+                     ${datadir}/aclocal ${base_libdir}/*.o \
+                     ${libdir}/${BPN}/*.la ${base_libdir}/*.la"
+     SECTION_${PN}-dev = "devel"
+     ALLOW_EMPTY_${PN}-dev = "1"
+     RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"
+
+     FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a ${libdir}/${BPN}/*.a"
+     SECTION_${PN}-staticdev = "devel"
+     RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
+                </literallayout>
+            </para>
+        </section>
+
+        <section id="combining-multiple-versions-library-files-into-one-image">
+            <title>Combining Multiple Versions of Library Files into One Image</title>
+
+            <para>
+                The build system offers the ability to build libraries with different
+                target optimizations or architecture formats and combine these together
+                into one system image.
+                You can link different binaries in the image
+                against the different libraries as needed for specific use cases.
+                This feature is called "Multilib."
+            </para>
+
+            <para>
+                An example would be where you have most of a system compiled in 32-bit
+                mode using 32-bit libraries, but you have something large, like a database
+                engine, that needs to be a 64-bit application and uses 64-bit libraries.
+                Multilib allows you to get the best of both 32-bit and 64-bit libraries.
+            </para>
+
+            <para>
+                While the Multilib feature is most commonly used for 32 and 64-bit differences,
+                the approach the build system uses facilitates different target optimizations.
+                You could compile some binaries to use one set of libraries and other binaries
+                to use a different set of libraries.
+                The libraries could differ in architecture, compiler options, or other
+                optimizations.
+            </para>
+
+            <para>
+                This section overviews the Multilib process only.
+                For more details on how to implement Multilib, see the
+                <ulink url='&YOCTO_WIKI_URL;/wiki/Multilib'>Multilib</ulink> wiki
+                page.
+            </para>
+
+            <para>
+                Aside from this wiki page, several examples exist in the
+                <filename>meta-skeleton</filename> layer found in the
+               <link linkend='source-directory'>Source Directory</link>:
+                <itemizedlist>
+                    <listitem><para><filename>conf/multilib-example.conf</filename>
+                        configuration file</para></listitem>
+                    <listitem><para><filename>conf/multilib-example2.conf</filename>
+                        configuration file</para></listitem>
+                    <listitem><para><filename>recipes-multilib/images/core-image-multilib-example.bb</filename>
+                        recipe</para></listitem>
+                </itemizedlist>
+            </para>
+
+            <section id='preparing-to-use-multilib'>
+                <title>Preparing to Use Multilib</title>
+
+                <para>
+                    User-specific requirements drive the Multilib feature.
+                    Consequently, there is no one "out-of-the-box" configuration that likely
+                    exists to meet your needs.
+                </para>
+
+                <para>
+                    In order to enable Multilib, you first need to ensure your recipe is
+                    extended to support multiple libraries.
+                    Many standard recipes are already extended and support multiple libraries.
+                    You can check in the <filename>meta/conf/multilib.conf</filename>
+                    configuration file in the
+                    <link linkend='source-directory'>Source Directory</link> to see how this is
+                    done using the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></ulink>
+                    variable.
+                    Eventually, all recipes will be covered and this list will
+                    not be needed.
+                </para>
+
+                <para>
+                    For the most part, the Multilib class extension works automatically to
+                    extend the package name from <filename>${PN}</filename> to
+                    <filename>${MLPREFIX}${PN}</filename>, where <filename>MLPREFIX</filename>
+                    is the particular multilib (e.g. "lib32-" or "lib64-").
+                    Standard variables such as
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink>,
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-RDEPENDS'><filename>RDEPENDS</filename></ulink>,
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-RPROVIDES'><filename>RPROVIDES</filename></ulink>,
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS'><filename>RRECOMMENDS</filename></ulink>,
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>, and
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES_DYNAMIC'><filename>PACKAGES_DYNAMIC</filename></ulink>
+                    are automatically extended by the system.
+                    If you are extending any manual code in the recipe, you can use the
+                    <filename>${MLPREFIX}</filename> variable to ensure those names are extended
+                    correctly.
+                    This automatic extension code resides in <filename>multilib.bbclass</filename>.
+                </para>
+            </section>
+
+            <section id='using-multilib'>
+                <title>Using Multilib</title>
+
+                <para>
+                    After you have set up the recipes, you need to define the actual
+                    combination of multiple libraries you want to build.
+                    You accomplish this through your <filename>local.conf</filename>
+                    configuration file in the
+                    <link linkend='build-directory'>Build Directory</link>.
+                    An example configuration would be as follows:
+                    <literallayout class='monospaced'>
+     MACHINE = "qemux86-64"
+     require conf/multilib.conf
+     MULTILIBS = "multilib:lib32"
+     DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
+     IMAGE_INSTALL = "lib32-connman"
+                    </literallayout>
+                    This example enables an
+                    additional library named <filename>lib32</filename> alongside the
+                    normal target packages.
+                    When combining these "lib32" alternatives, the example uses "x86" for tuning.
+                    For information on this particular tuning, see
+                    <filename>meta/conf/machine/include/ia32/arch-ia32.inc</filename>.
+                </para>
+
+                <para>
+                    The example then includes <filename>lib32-connman</filename>
+                    in all the images, which illustrates one method of including a
+                    multiple library dependency.
+                    You can use a normal image build to include this dependency,
+                    for example:
+                    <literallayout class='monospaced'>
+     $ bitbake core-image-sato
+                    </literallayout>
+                    You can also build Multilib packages specifically with a command like this:
+                    <literallayout class='monospaced'>
+     $ bitbake lib32-connman
+                    </literallayout>
+                </para>
+            </section>
+
+            <section id='additional-implementation-details'>
+                <title>Additional Implementation Details</title>
+
+                <para>
+                    Different packaging systems have different levels of native Multilib
+                    support.
+                    For the RPM Package Management System, the following implementation details
+                    exist:
+                    <itemizedlist>
+                        <listitem><para>A unique architecture is defined for the Multilib packages,
+                            along with creating a unique deploy folder under
+                            <filename>tmp/deploy/rpm</filename> in the
+                            <link linkend='build-directory'>Build Directory</link>.
+                            For example, consider <filename>lib32</filename> in a
+                            <filename>qemux86-64</filename> image.
+                            The possible architectures in the system are "all", "qemux86_64",
+                            "lib32_qemux86_64", and "lib32_x86".</para></listitem>
+                        <listitem><para>The <filename>${MLPREFIX}</filename> variable is stripped from
+                            <filename>${PN}</filename> during RPM packaging.
+                            The naming for a normal RPM package and a Multilib RPM package in a
+                            <filename>qemux86-64</filename> system resolves to something similar to
+                            <filename>bash-4.1-r2.x86_64.rpm</filename> and
+                            <filename>bash-4.1.r2.lib32_x86.rpm</filename>, respectively.
+                            </para></listitem>
+                        <listitem><para>When installing a Multilib image, the RPM backend first
+                            installs the base image and then installs the Multilib libraries.
+                            </para></listitem>
+                        <listitem><para>The build system relies on RPM to resolve the identical files in the
+                            two (or more) Multilib packages.</para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    For the IPK Package Management System, the following implementation details exist:
+                    <itemizedlist>
+                        <listitem><para>The <filename>${MLPREFIX}</filename> is not stripped from
+                            <filename>${PN}</filename> during IPK packaging.
+                            The naming for a normal RPM package and a Multilib IPK package in a
+                            <filename>qemux86-64</filename> system resolves to something like
+                            <filename>bash_4.1-r2.x86_64.ipk</filename> and
+                            <filename>lib32-bash_4.1-rw_x86.ipk</filename>, respectively.
+                            </para></listitem>
+                        <listitem><para>The IPK deploy folder is not modified with
+                            <filename>${MLPREFIX}</filename> because packages with and without
+                            the Multilib feature can exist in the same folder due to the
+                            <filename>${PN}</filename> differences.</para></listitem>
+                        <listitem><para>IPK defines a sanity check for Multilib installation
+                            using certain rules for file comparison, overridden, etc.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </section>
+        </section>
+
+        <section id='installing-multiple-versions-of-the-same-library'>
+            <title>Installing Multiple Versions of the Same Library</title>
+
+            <para>
+                Situations can exist where you need to install and use
+                multiple versions of the same library on the same system
+                at the same time.
+                These situations almost always exist when a library API
+                changes and you have multiple pieces of software that
+                depend on the separate versions of the library.
+                To accommodate these situations, you can install multiple
+                versions of the same library in parallel on the same system.
+            </para>
+
+            <para>
+                The process is straightforward as long as the libraries use
+                proper versioning.
+                With properly versioned libraries, all you need to do to
+                individually specify the libraries is create separate,
+                appropriately named recipes where the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink> part of the
+                name includes a portion that differentiates each library version
+                (e.g.the major part of the version number).
+                Thus, instead of having a single recipe that loads one version
+                of a library (e.g. <filename>clutter</filename>), you provide
+                multiple recipes that result in different versions
+                of the libraries you want.
+                As an example, the following two recipes would allow the
+                two separate versions of the <filename>clutter</filename>
+                library to co-exist on the same system:
+                <literallayout class='monospaced'>
+     clutter-1.6_1.6.20.bb
+     clutter-1.8_1.8.4.bb
+                </literallayout>
+                Additionally, if you have other recipes that depend on a given
+                library, you need to use the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink>
+                variable to create the dependency.
+                Continuing with the same example, if you want to have a recipe
+                depend on the 1.8 version of the <filename>clutter</filename>
+                library, use the following in your recipe:
+                <literallayout class='monospaced'>
+     DEPENDS = "clutter-1.8"
+                </literallayout>
+            </para>
+        </section>
+    </section>
+
+    <section id='creating-partitioned-images'>
+        <title>Creating Partitioned Images</title>
+
+        <para>
+            Creating an image for a particular hardware target using the
+            OpenEmbedded build system does not necessarily mean you can boot
+            that image as is on your device.
+            Physical devices accept and boot images in various ways depending
+            on the specifics of the device.
+            Usually, information about the hardware can tell you what image
+            format the device requires.
+            Should your device require multiple partitions on an SD card, flash,
+            or an HDD, you can use the OpenEmbedded Image Creator,
+                <filename>wic</filename>, to create the properly partitioned image.
+        </para>
+
+        <para>
+            The <filename>wic</filename> command generates partitioned images
+            from existing OpenEmbedded build artifacts.
+            Image generation is driven by partitioning commands contained
+            in an Openembedded kickstart file (<filename>.wks</filename>)
+            specified either directly on the command line or as one of a
+            selection of canned <filename>.wks</filename> files as shown
+            with the <filename>wic list images</filename> command in the
+            "<link linkend='using-a-provided-kickstart_file'>Using an Existing Kickstart File</link>"
+            section.
+            When applied to a given set of build artifacts, the result is an
+            image or set of images that can be directly written onto media and
+            used on a particular system.
+        </para>
+
+        <para>
+                The <filename>wic</filename> command and the infrastructure
+                it is based on is by definition incomplete.
+            Its purpose is to allow the generation of customized images,
+            and as such was designed to be completely extensible through a
+            plugin interface.
+            See the
+            "<link linkend='openembedded-kickstart-plugins'>Plugins</link>"
+            section for information on these plugins.
+            </para>
+
+        <para>
+            This section provides some background information on
+            <filename>wic</filename>, describes what you need to have in
+            place to run the tool, provides instruction on how to use
+            <filename>wic</filename>, and provides several examples.
+        </para>
+
+        <section id='wic-background'>
+            <title>Background</title>
+
+            <para>
+                This section provides some background on the
+                <filename>wic</filename> utility.
+                While none of this information is required to use
+                <filename>wic</filename>, you might find it interesting.
+                <itemizedlist>
+                    <listitem><para>
+                        The name "wic" is derived from OpenEmbedded
+                        Image Creator (oeic).
+                        The "oe" diphthong in "oeic" was promoted to the
+                        letter "w", because "oeic" is both difficult to remember and
+                        pronounce.</para></listitem>
+                    <listitem><para>
+                        <filename>wic</filename> is loosely based on the
+                        Meego Image Creator (<filename>mic</filename>)
+                        framework.
+                        The <filename>wic</filename> implementation has been
+                        heavily modified to make direct use of OpenEmbedded
+                        build artifacts instead of package installation and
+                        configuration, which are already incorporated within
+                        the OpenEmbedded artifacts.</para></listitem>
+                    <listitem><para>
+                        <filename>wic</filename> is a completely independent
+                        standalone utility that initially provides
+                        easier-to-use and more flexible replacements for a
+                        couple bits of existing functionality in OE Core's
+                        <filename>boot-directdisk.bbclass</filename> and
+                        <filename>mkefidisk.sh</filename> scripts.
+                        The difference between
+                        <filename>wic</filename> and those examples is
+                        that with <filename>wic</filename> the
+                        functionality of those scripts is implemented
+                        by a general-purpose partitioning language, which is
+                        based on Redhat kickstart syntax.</para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='wic-requirements'>
+            <title>Requirements</title>
+
+            <para>
+                In order to use the <filename>wic</filename> utility
+                with the OpenEmbedded Build system, your system needs
+                to meet the following requirements:
+                <itemizedlist>
+                    <listitem><para>The Linux distribution on your
+                        development host must support the Yocto Project.
+                        See the
+                        "<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>"
+                        section in the Yocto Project Reference Manual for this
+                        list of distributions.</para></listitem>
+                    <listitem><para>
+                        The standard system utilities, such as
+                        <filename>cp</filename>, must be installed on your
+                        development host system.
+                        </para></listitem>
+                    <listitem><para>
+                        The
+                        <ulink url='http://www.gnu.org/software/parted/'>GNU Parted</ulink>
+                        package must be installed on your development host
+                        system.
+                        </para></listitem>
+                    <listitem><para>
+                        You need to have the build artifacts already
+                        available, which typically means that you must
+                        have already created an image using the
+                        Openembedded build system (e.g.
+                        <filename>core-image-minimal</filename>).
+                        While it might seem redundant to generate an image in
+                        order to create an image using
+                        <filename>wic</filename>, the current version of
+                        <filename>wic</filename> requires the artifacts
+                        in the form generated by the build system.
+                        </para></listitem>
+                    <listitem><para>
+                        You must have sourced one of the build environment
+                        setup scripts (i.e.
+                        <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                        or
+                        <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>)
+                        found in the
+                        <link linkend='build-directory'>Build Directory</link>.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='wic-getting-help'>
+            <title>Getting Help</title>
+
+            <para>
+                You can get general help for the <filename>wic</filename>
+                by entering the <filename>wic</filename> command by itself
+                or by entering the command with a help argument as follows:
+                <literallayout class='monospaced'>
+     $ wic -h
+     $ wic &dash;&dash;help
+                </literallayout>
+            </para>
+
+            <para>
+                Currently, <filename>wic</filename> supports two commands:
+                <filename>create</filename> and <filename>list</filename>.
+                You can get help for these commands as follows:
+                <literallayout class='monospaced'>
+     $ wic help <replaceable>command</replaceable>
+                </literallayout>
+            </para>
+
+            <para>
+                You can also get detailed help on a number of topics
+                from the help system.
+                The output of <filename>wic &dash;&dash;help</filename>
+                displays a list of available help
+                topics under a "Help topics" heading.
+                You can have the help system display the help text for
+                a given topic by prefacing the topic with
+                <filename>wic help</filename>:
+                <literallayout class='monospaced'>
+     $ wic help <replaceable>help_topic</replaceable>
+                </literallayout>
+            </para>
+
+            <para>
+                You can find out more about the images
+                <filename>wic</filename> creates using the existing
+                kickstart files with the following form of the command:
+                <literallayout class='monospaced'>
+     $ wic list <replaceable>image</replaceable> help
+                </literallayout>
+                where <filename><replaceable>image</replaceable></filename> is either
+                <filename>directdisk</filename> or
+                <filename>mkefidisk</filename>.
+            </para>
+        </section>
+
+        <section id='operational-modes'>
+            <title>Operational Modes</title>
+
+            <para>
+                    You can use <filename>wic</filename> in two different
+                    modes, depending on how much control you need for
+                    specifying the Openembedded build artifacts that are
+                used for creating the image: Raw and Cooked:
+                <itemizedlist>
+                    <listitem><para><emphasis>Raw Mode:</emphasis>
+                        You explicitly specify build artifacts through
+                        command-line arguments.</para></listitem>
+                    <listitem><para><emphasis>Cooked Mode:</emphasis>
+                        The current
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
+                        setting and image name are used to automatically locate
+                        and provide the build artifacts.</para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                Regardless of the mode you use, you need to have the build
+                artifacts ready and available.
+                Additionally, the environment must be set up using the
+                <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                or
+                <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>
+                script found in the
+                <link linkend='build-directory'>Build Directory</link>.
+            </para>
+
+            <section id='raw-mode'>
+                <title>Raw Mode</title>
+
+                <para>
+                    The general form of the 'wic' command in raw mode is:
+                    <literallayout class='monospaced'>
+     $ wic create <replaceable>image_name</replaceable>.wks [<replaceable>options</replaceable>] [...]
+
+         Where:
+
+             <replaceable>image_name</replaceable>.wks
+                               An OpenEmbedded kickstart file.  You can provide
+                               your own custom file or use a file from a set of
+                               existing files as described by further options.
+
+             -o <replaceable>OUTDIR</replaceable>, &dash;&dash;outdir=<replaceable>OUTDIR</replaceable>
+                               The name of a directory in which to create image.
+
+             -i <replaceable>PROPERTIES_FILE</replaceable>, &dash;&dash;infile=<replaceable>PROPERTIES_FILE</replaceable>
+                               The name of a file containing the values for image
+                               properties as a JSON file.
+
+             -e <replaceable>IMAGE_NAME</replaceable>, &dash;&dash;image-name=<replaceable>IMAGE_NAME</replaceable>
+                               The name of the image from which to use the artifacts
+                               (e.g. <filename>core-image-sato</filename>).
+
+             -r <replaceable>ROOTFS_DIR</replaceable>, &dash;&dash;rootfs-dir=<replaceable>ROOTFS_DIR</replaceable>
+                               The path to the <filename>/rootfs</filename> directory to use as the
+                               <filename>.wks</filename> rootfs source.
+
+             -b <replaceable>BOOTIMG_DIR</replaceable>, &dash;&dash;bootimg-dir=<replaceable>BOOTIMG_DIR</replaceable>
+                               The path to the directory containing the boot artifacts
+                               (e.g. <filename>/EFI</filename> or <filename>/syslinux</filename>) to use as the <filename>.wks</filename> bootimg
+                               source.
+
+             -k <replaceable>KERNEL_DIR</replaceable>, &dash;&dash;kernel-dir=<replaceable>KERNEL_DIR</replaceable>
+                               The path to the directory containing the kernel to use
+                               in the <filename>.wks</filename> boot image.
+
+             -n <replaceable>NATIVE_SYSROOT</replaceable>, &dash;&dash;native-sysroot=<replaceable>NATIVE_SYSROOT</replaceable>
+                               The path to the native sysroot containing the tools to use
+                               to build the image.
+
+             -s, &dash;&dash;skip-build-check
+                               Skips the build check.
+
+             -D, &dash;&dash;debug
+                               Output debug information.
+                    </literallayout>
+                    <note>
+                        You do not need root privileges to run
+                        <filename>wic</filename>.
+                        In fact, you should not run as root when using the
+                        utility.
+                    </note>
+                </para>
+            </section>
+
+            <section id='cooked-mode'>
+                <title>Cooked Mode</title>
+
+                <para>
+                    The general form of the <filename>wic</filename> command
+                    using Cooked Mode is:
+                    <literallayout class='monospaced'>
+     $ wic create <replaceable>kickstart_file</replaceable> -e <replaceable>image_name</replaceable>
+
+         Where:
+
+             <replaceable>kickstart_file</replaceable>
+                               An OpenEmbedded kickstart file. You can provide your own
+                               custom file or supplied file.
+
+             <replaceable>image_name</replaceable>
+                               Specifies the image built using the OpenEmbedded build
+                               system.
+                    </literallayout>
+                    This form is the simplest and most user-friendly, as it
+                    does not require specifying all individual parameters.
+                    All you need to provide is your own
+                    <filename>.wks</filename> file or one provided with the
+                    release.
+                </para>
+            </section>
+        </section>
+
+        <section id='using-a-provided-kickstart_file'>
+            <title>Using an Existing Kickstart File</title>
+
+            <para>
+                If you do not want to create your own
+                <filename>.wks</filename> file, you can use an existing
+                file provided by the <filename>wic</filename> installation.
+                Use the following command to list the available files:
+                <literallayout class='monospaced'>
+     $ wic list images
+     directdisk Create a 'pcbios' direct disk image
+     mkefidisk Create an EFI disk image
+                 </literallayout>
+                 When you use an existing file, you do not have to use the
+                 <filename>.wks</filename> extension.
+                 Here is an example in Raw Mode that uses the
+                 <filename>directdisk</filename> file:
+                 <literallayout class='monospaced'>
+     $ wic create directdisk -r <replaceable>rootfs_dir</replaceable> -b <replaceable>bootimg_dir</replaceable> \
+           -k <replaceable>kernel_dir</replaceable> -n <replaceable>native_sysroot</replaceable>
+                </literallayout>
+            </para>
+
+            <para>
+                Here are the actual partition language commands
+                used in the <filename>mkefidisk.wks</filename> file to generate
+                an image:
+                <literallayout class='monospaced'>
+     # short-description: Create an EFI disk image
+     # long-description: Creates a partitioned EFI disk image that the user
+     # can directly dd to boot media.
+
+     part /boot --source bootimg-efi --ondisk sda --label msdos --active --align 1024
+
+     part / --source rootfs --ondisk sda --fstype=ext3 --label platform --align 1024
+
+     part swap --ondisk sda --size 44 --label swap1 --fstype=swap
+
+     bootloader  --timeout=10  --append="rootwait rootfstype=ext3 console=ttyPCH0,115200 console=tty0 vmalloc=256MB snd-hda-intel.enable_msi=0"
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='wic-usage-examples'>
+            <title>Examples</title>
+
+            <para>
+                This section provides several examples that show how to use
+                the <filename>wic</filename> utility.
+                All the examples assume the list of requirements in the
+                "<link linkend='wic-requirements'>Requirements</link>" section
+                have been met.
+                The examples assume the previously generated image is
+                <filename>core-image-minimal</filename>.
+            </para>
+
+            <section id='generate-an-image-using-a-provided-kickstart-file'>
+                <title>Generate an Image using an Existing Kickstart File</title>
+
+                <para>
+                    This example runs in Cooked Mode and uses the
+                    <filename>mkefidisk</filename> kickstart file:
+                    <literallayout class='monospaced'>
+     $ wic create mkefidisk -e core-image-minimal
+     Checking basic build environment...
+     Done.
+
+     Creating image(s)...
+
+     Info: The new image(s) can be found here:
+      /var/tmp/wic/build/mkefidisk-201310230946-sda.direct
+
+     The following build artifacts were used to create the image(s):
+      ROOTFS_DIR: /home/trz/yocto/yocto-image/build/tmp/work/minnow-poky-linux/core-image-minimal/1.0-r0/rootfs
+      BOOTIMG_DIR: /home/trz/yocto/yocto-image/build/tmp/work/minnow-poky-linux/core-image-minimal/1.0-r0/core-image-minimal-1.0/hddimg
+      KERNEL_DIR: /home/trz/yocto/yocto-image/build/tmp/sysroots/minnow/usr/src/kernel
+      NATIVE_SYSROOT: /home/trz/yocto/yocto-image/build/tmp/sysroots/x86_64-linux
+
+
+     The image(s) were created using OE kickstart file:
+      /home/trz/yocto/yocto-image/scripts/lib/image/canned-wks/mkefidisk.wks
+                    </literallayout>
+                    This example shows the easiest way to create an image
+                    by running in Cooked Mode and using the
+                    <filename>-e</filename> option with an existing kickstart
+                    file.
+                    All that is necessary is to specify the image used to
+                    generate the artifacts.
+                    Your <filename>local.conf</filename> needs to have the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
+                    variable set to the machine you are using, which is
+                    "minnow" in this example.
+                </para>
+
+                <para>
+                    The output specifies the exact created as well as where
+                    it was created.
+                    The output also names the artifacts used and the exact
+                    <filename>.wks</filename> script that was used to generate
+                    the image.
+                    <note>
+                        You should always verify the details provided in the
+                        output to make sure that the image was indeed created
+                        exactly as expected.
+                    </note>
+                </para>
+
+                <para>
+                    Continuing with the example, you can now directly
+                    <filename>dd</filename> the image to a USB stick, or
+                    whatever media for which you built your image,
+                    and boot the resulting media:
+                    <literallayout class='monospaced'>
+     $ sudo dd if=/var/tmp/wic/build/mkefidisk-201310230946-sda.direct of=/dev/sdb
+     [sudo] password for trz:
+     182274+0 records in
+     182274+0 records out
+     93324288 bytes (93 MB) copied, 14.4777 s, 6.4 MB/s
+     [trz@empanada ~]$ sudo eject /dev/sdb
+                    </literallayout>
+                </para>
+            </section>
+
+            <section id='using-a-modified-kickstart-file'>
+                <title>Using a Modified Kickstart File</title>
+
+                <para>
+                    Because <filename>wic</filename> image creation is driven
+                    by the kickstart file, it is easy to affect image creation
+                    by changing the parameters in the file.
+                    This next example demonstrates that through modification
+                    of the <filename>directdisk</filename> kickstart file.
+                </para>
+
+                <para>
+                    As mentioned earlier, you can use the command
+                    <filename>wic list images</filename> to show the list
+                    of existing kickstart files.
+                    The directory in which these files reside is
+                    <filename>scripts/lib/image/canned-wks/</filename>
+                    located in the
+                    <link linkend='source-directory'>Source Directory</link>.
+                    Because the available files reside in this directory, you
+                    can create and add your own custom files to the directory.
+                    Subsequent use of the <filename>wic list images</filename>
+                    command would then include your kickstart files.
+                </para>
+
+                <para>
+                    In this example, the existing
+                    <filename>directdisk</filename> file already does most
+                    of what is needed.
+                    However, for the hardware in this example, the image will
+                    need to boot from <filename>sdb</filename> instead of
+                    <filename>sda</filename>, which is what the
+                    <filename>directdisk</filename> kickstart file uses.
+                </para>
+
+                <para>
+                    The example begins by making a copy of the
+                    <filename>directdisk.wks</filename> file in the
+                    <filename>scripts/lib/image/canned-wks</filename>
+                    directory and then changing the lines that specify the
+                    target disk from which to boot.
+                    <literallayout class='monospaced'>
+     $ cp /home/trz/yocto/yocto-image/scripts/lib/image/canned-wks/directdisk.wks \
+          /home/trz/yocto/yocto-image/scripts/lib/image/canned-wks/directdisksdb.wks
+                    </literallayout>
+                    Next, the example modifies the
+                    <filename>directdisksdb.wks</filename> file and changes all
+                    instances of "<filename>&dash;&dash;ondisk sda</filename>"
+                    to "<filename>&dash;&dash;ondisk sdb</filename>".
+                    The example changes the following two lines and leaves the
+                    remaining lines untouched:
+                    <literallayout class='monospaced'>
+     part /boot &dash;&dash;source bootimg-pcbios &dash;&dash;ondisk sdb &dash;&dash;label boot &dash;&dash;active &dash;&dash;align 1024
+     part / &dash;&dash;source rootfs &dash;&dash;ondisk sdb &dash;&dash;fstype=ext3 &dash;&dash;label platform &dash;&dash;align 1024
+                    </literallayout>
+                    Once the lines are changed, the example generates the
+                    <filename>directdisksdb</filename> image.
+                    The command points the process at the
+                    <filename>core-image-minimal</filename> artifacts for the
+                    Next Unit of Computing (nuc)
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
+                    the <filename>local.conf</filename>.
+                    <literallayout class='monospaced'>
+     $ wic create directdisksdb -e core-image-minimal
+     Checking basic build environment...
+     Done.
+
+     Creating image(s)...
+
+     Info: The new image(s) can be found here:
+      /var/tmp/wic/build/directdisksdb-201310231131-sdb.direct
+
+     The following build artifacts were used to create the image(s):
+      ROOTFS_DIR: /home/trz/yocto/yocto-image/build/tmp/work/nuc-poky-linux/core-image-minimal/1.0-r0/rootfs
+      BOOTIMG_DIR: /home/trz/yocto/yocto-image/build/tmp/sysroots/nuc/usr/share
+      KERNEL_DIR: /home/trz/yocto/yocto-image/build/tmp/sysroots/nuc/usr/src/kernel
+      NATIVE_SYSROOT: /home/trz/yocto/yocto-image/build/tmp/sysroots/x86_64-linux
+
+
+     The image(s) were created using OE kickstart file:
+      /home/trz/yocto/yocto-image/scripts/lib/image/canned-wks/directdisksdb.wks
+                    </literallayout>
+                    Continuing with the example, you can now directly
+                    <filename>dd</filename> the image to a USB stick, or
+                    whatever media for which you built your image,
+                    and boot the resulting media:
+                    <literallayout class='monospaced'>
+     $ sudo dd if=/var/tmp/wic/build/directdisksdb-201310231131-sdb.direct of=/dev/sdb
+     86018+0 records in
+     86018+0 records out
+     44041216 bytes (44 MB) copied, 13.0734 s, 3.4 MB/s
+     [trz@empanada tmp]$ sudo eject /dev/sdb
+                    </literallayout>
+                </para>
+            </section>
+
+            <section id='creating-an-image-based-on-core-image-minimal-and-crownbay-noemgd'>
+                <title>Creating an Image Based on <filename>core-image-minimal</filename> and <filename>crownbay-noemgd</filename></title>
+
+                <para>
+                    This example creates an image based on
+                    <filename>core-image-minimal</filename> and a
+                    <filename>crownbay-noemgd</filename>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
+                    that works right out of the box.
+                    <literallayout class='monospaced'>
+     $ wic create directdisk -e core-image-minimal
+
+     Checking basic build environment...
+     Done.
+
+     Creating image(s)...
+
+     Info: The new image(s) can be found here:
+      /var/tmp/wic/build/directdisk-201309252350-sda.direct
+
+     The following build artifacts were used to create the image(s):
+
+     ROOTFS_DIR: /home/trz/yocto/yocto-image/build/tmp/work/crownbay_noemgd-poky-linux/core-image-minimal/1.0-r0/rootfs
+     BOOTIMG_DIR: /home/trz/yocto/yocto-image/build/tmp/sysroots/crownbay-noemgd/usr/share
+     KERNEL_DIR: /home/trz/yocto/yocto-image/build/tmp/sysroots/crownbay-noemgd/usr/src/kernel
+     NATIVE_SYSROOT: /home/trz/yocto/yocto-image/build/tmp/sysroots/crownbay-noemgd/usr/src/kernel
+
+     The image(s) were created using OE kickstart file:
+      /home/trz/yocto/yocto-image/scripts/lib/image/canned-wks/directdisk.wks
+                    </literallayout>
+                </para>
+            </section>
+
+            <section id='using-a-modified-kickstart-file-and-running-in-raw-mode'>
+                <title>Using a Modified Kickstart File and Running in Raw Mode</title>
+
+                <para>
+                    This next example manually specifies each build artifact
+                    (runs in Raw Mode) and uses a modified kickstart file.
+                    The example also uses the <filename>-o</filename> option
+                    to cause <filename>wic</filename> to create the output
+                    somewhere other than the default
+                    <filename>/var/tmp/wic</filename> directory:
+                    <literallayout class='monospaced'>
+     $ wic create ~/test.wks -o /home/trz/testwic &dash;&dash;rootfs-dir \
+          /home/trz/yocto/yocto-image/build/tmp/work/crownbay_noemgd-poky-linux/core-image-minimal/1.0-r0/rootfs \
+          &dash;&dash;bootimg-dir /home/trz/yocto/yocto-image/build/tmp/sysroots/crownbay-noemgd/usr/share \
+          &dash;&dash;kernel-dir /home/trz/yocto/yocto-image/build/tmp/sysroots/crownbay-noemgd/usr/src/kernel \
+          &dash;&dash;native-sysroot /home/trz/yocto/yocto-image/build/tmp/sysroots/x86_64-linux
+
+     Creating image(s)...
+
+     Info: The new image(s) can be found here:
+      /home/trz/testwic/build/test-201309260032-sda.direct
+
+     The following build artifacts were used to create the image(s):
+
+     ROOTFS_DIR: /home/trz/yocto/yocto-image/build/tmp/work/crownbay_noemgd-poky-linux/core-image-minimal/1.0-r0/rootfs
+     BOOTIMG_DIR: /home/trz/yocto/yocto-image/build/tmp/sysroots/crownbay-noemgd/usr/share
+     KERNEL_DIR: /home/trz/yocto/yocto-image/build/tmp/sysroots/crownbay-noemgd/usr/src/kernel
+     NATIVE_SYSROOT: /home/trz/yocto/yocto-image/build/tmp/sysroots/crownbay-noemgd/usr/src/kernel
+
+     The image(s) were created using OE kickstart file:
+      /home/trz/test.wks
+                    </literallayout>
+                    For this example,
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
+                    did not have to be specified in the
+                    <filename>local.conf</filename> file since the artifact is
+                    manually specified.
+                </para>
+            </section>
+        </section>
+
+        <section id='openembedded-kickstart-plugins'>
+            <title>Plugins</title>
+
+            <para>
+                    Plugins allow <filename>wic</filename> functionality to
+                    be extended and specialized by users.
+                This section documents the plugin interface, which is
+                currently restricted to source plugins.
+            </para>
+
+            <para>
+                    Source plugins provide a mechanism to customize
+                    various aspects of the image generation process in
+                    <filename>wic</filename>, mainly the contents of
+                    partitions.
+                    The plugins provide a mechanism for mapping values
+                    specified in <filename>.wks</filename> files using the
+                    <filename>&dash;&dash;source</filename> keyword to a
+                particular plugin implementation that populates a
+                corresponding partition.
+            </para>
+
+            <para>
+                    A source plugin is created as a subclass of
+                    <filename>SourcePlugin</filename>.
+                The plugin file containing it is added to
+                    <filename>scripts/lib/mic/plugins/source/</filename> to
+                    make the plugin implementation available to the
+                    <filename>wic</filename> implementation.
+                For more information, see
+                    <filename>scripts/lib/mic/pluginbase.py</filename>.
+            </para>
+
+            <para>
+                    Source plugins can also be implemented and added by
+                    external layers.
+                As such, any plugins found in a
+                    <filename>scripts/lib/mic/plugins/source/</filename>
+                    directory in an external layer are also made
+                    available.
+            </para>
+
+            <para>
+                    When the <filename>wic</filename> implementation needs
+                    to invoke a partition-specific implementation, it looks
+                    for the plugin that has the same name as the
+                    <filename>&dash;&dash;source</filename> parameter given to
+                that partition.
+                For example, if the partition is set up as follows:
+                <literallayout class='monospaced'>
+     part /boot &dash;&dash;source bootimg-pcbios   ...
+                </literallayout>
+                    The methods defined as class members of the plugin
+                    having the matching <filename>bootimg-pcbios.name</filename>
+                class member are used.
+            </para>
+
+            <para>
+                    To be more concrete, here is the plugin definition that
+                    matches a
+                <filename>&dash;&dash;source bootimg-pcbios</filename> usage,
+                along with an example
+                    method called by the <filename>wic</filename> implementation
+                when it needs to invoke an implementation-specific
+                    partition-preparation function:
+                <literallayout class='monospaced'>
+    class BootimgPcbiosPlugin(SourcePlugin):
+        name = 'bootimg-pcbios'
+
+    @classmethod
+        def do_prepare_partition(self, part, ...)
+                </literallayout>
+                    If the subclass itself does not implement a function, a
+                    default version in a superclass is located and
+                    used, which is why all plugins must be derived from
+                    <filename>SourcePlugin</filename>.
+            </para>
+
+            <para>
+                    The <filename>SourcePlugin</filename> class defines the
+                    following methods, which is the current set of methods
+                    that can be implemented or overridden by
+                    <filename>&dash;&dash;source</filename> plugins.
+                Any methods not implemented by a
+                <filename>SourcePlugin</filename> subclass inherit the
+                implementations present in the
+                    <filename>SourcePlugin</filename> class.
+                For more information, see the
+                    <filename>SourcePlugin</filename> source for details:
+            </para>
+
+            <para>
+                <itemizedlist>
+                    <listitem><para><emphasis><filename>do_prepare_partition()</filename>:</emphasis>
+                        Called to do the actual content population for a
+                        partition.
+                        In other words, the method prepares the final
+                        partition image that is incorporated into the
+                        disk image.
+                        </para></listitem>
+                    <listitem><para><emphasis><filename>do_configure_partition()</filename>:</emphasis>
+                        Called before
+                        <filename>do_prepare_partition()</filename>.
+                        This method is typically used to create custom
+                        configuration files for a partition (e.g. syslinux or
+                        grub configuration files).
+                        </para></listitem>
+                    <listitem><para><emphasis><filename>do_install_disk()</filename>:</emphasis>
+                        Called after all partitions have been prepared and
+                        assembled into a disk image.
+                        This method provides a hook to allow finalization of a
+                        disk image, (e.g. writing an MBR).
+                        </para></listitem>
+                    <listitem><para><emphasis><filename>do_stage_partition()</filename>:</emphasis>
+                        Special content-staging hook called before
+                        <filename>do_prepare_partition()</filename>.
+                        This method is normally empty.</para>
+                        <para>Typically, a partition just uses the passed-in
+                        parameters (e.g. the unmodified value of
+                                <filename>bootimg_dir</filename>).
+                        However, in some cases things might need to be
+                        more tailored.
+                        As an example, certain files might additionally
+                        need to be taken from
+                        <filename>bootimg_dir + /boot</filename>.
+                                This hook allows those files to be staged in a
+                                customized fashion.
+                        <note>
+                            <filename>get_bitbake_var()</filename>
+                            allows you to access non-standard variables
+                            that you might want to use for this.
+                        </note>
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                This scheme is extensible.
+                Adding more hooks is a simple matter of adding more
+                plugin methods to <filename>SourcePlugin</filename> and
+                derived classes.
+                The code that then needs to call the plugin methods uses
+                <filename>plugin.get_source_plugin_methods()</filename>
+                to find the method or methods needed by the call.
+                Retrieval of those methods is accomplished
+                by filling up a dict with keys
+                containing the method names of interest.
+                On success, these will be filled in with the actual
+                methods.
+                Please see the <filename>wic</filename>
+                implementation for examples and details.
+            </para>
+        </section>
+
+        <section id='openembedded-kickstart-wks-reference'>
+            <title>OpenEmbedded Kickstart (.wks) Reference</title>
+
+            <para>
+                The current <filename>wic</filename> implementation supports
+                only the basic kickstart partitioning commands:
+                <filename>partition</filename> (or <filename>part</filename>
+                for short) and <filename>bootloader</filename>.
+                <note>
+                    Future updates will implement more commands and options.
+                    If you use anything that is not specifically
+                    supported, results can be unpredictable.
+                </note>
+            </para>
+
+            <para>
+                The following is a list of the commands, their syntax,
+                and meanings.
+                The commands are based on the Fedora
+                kickstart versions but with modifications to
+                reflect <filename>wic</filename> capabilities.
+                You can see the original documentation for those commands
+                at the following links:
+                <itemizedlist>
+                    <listitem><para>
+                        <ulink url='http://fedoraproject.org/wiki/Anaconda/Kickstart#part_or_partition'>http://fedoraproject.org/wiki/Anaconda/Kickstart#part_or_partition</ulink>
+                                    </para></listitem>
+                    <listitem><para>
+                        <ulink url='http://fedoraproject.org/wiki/Anaconda/Kickstart#bootloader'>http://fedoraproject.org/wiki/Anaconda/Kickstart#bootloader</ulink>
+                                    </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <section id='command-part-or-partition'>
+                <title>Command: part or partition</title>
+
+                <para>
+                This command creates a partition on the system and uses the
+                following syntax:
+                    <literallayout class='monospaced'>
+     part <replaceable>mntpoint</replaceable>
+                    </literallayout>
+                    The <filename><replaceable>mntpoint</replaceable></filename>
+                    is where the
+                    partition will be mounted and must be of one of the
+                    following forms:
+                    <itemizedlist>
+                        <listitem><para><filename>/<replaceable>path</replaceable></filename>:
+                            For example, <filename>/</filename>,
+                            <filename>/usr</filename>, and
+                            <filename>/home</filename></para></listitem>
+                        <listitem><para><filename>swap</filename>:
+                            The partition will be used as swap space.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    Following are the supported options:
+                    <itemizedlist>
+                        <listitem><para><emphasis><filename>&dash;&dash;size</filename>:</emphasis>
+                            The minimum partition size in MBytes.
+                            Specify an integer value such as 500.
+                            Do not append the number with "MB".
+                            You do not need this option if you use
+                            <filename>&dash;&dash;source</filename>.</para></listitem>
+                        <listitem><para><emphasis><filename>&dash;&dash;source</filename>:</emphasis>
+                            This option is a
+                            <filename>wic</filename>-specific option that
+                            names the source of the data that populates
+                            the partition.
+                            The most common value for this option is
+                            "rootfs", but you can use any value that maps to
+                            a valid source plugin.
+                            For information on the source plugins, see the
+                            "<link linkend='openembedded-kickstart-plugins'>Plugins</link>"
+                            section.</para>
+                            <para>If you use
+                            <filename>&dash;&dash;source rootfs</filename>,
+                            <filename>wic</filename> creates a partition as
+                            large as needed and to fill it with the contents of
+                                        the root filesystem pointed to by the
+                                        <filename>-r</filename> command-line option
+                                        or the equivalent rootfs derived from the
+                                        <filename>-e</filename> command-line
+                                        option.
+                            The filesystem type used to create the
+                            partition is driven by the value of the
+                                        <filename>&dash;&dash;fstype</filename> option
+                                        specified for the partition.
+                            See the entry on
+                            <filename>&dash;&dash;fstype</filename> that
+                            follows for more information.
+                                        </para>
+                            <para>If you use
+                            <filename>&dash;&dash;source <replaceable>plugin-name</replaceable></filename>,
+                            <filename>wic</filename> creates a partition as
+                            large as needed and fills it with the contents of
+                            the partition that is generated by the
+                            specified plugin name using the data pointed
+                            to by the <filename>-r</filename> command-line
+                            option or the equivalent rootfs derived from the
+                                        <filename>-e</filename> command-line
+                                        option.
+                            Exactly what those contents and
+                                        filesystem type end up being are dependent
+                                        on the given plugin implementation.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>&dash;&dash;ondisk</filename> or <filename>&dash;&dash;ondrive</filename>:</emphasis>
+                            Forces the partition to be created on a particular
+                            disk.</para></listitem>
+                        <listitem><para><emphasis><filename>&dash;&dash;fstype</filename>:</emphasis>
+                            Sets the file system type for the partition.
+                            Valid values are:
+                            <itemizedlist>
+                                <listitem><para><filename>ext4</filename>
+                                </para></listitem>
+                                <listitem><para><filename>ext3</filename>
+                                </para></listitem>
+                                <listitem><para><filename>ext2</filename>
+                                </para></listitem>
+                                <listitem><para><filename>btrfs</filename>
+                                </para></listitem>
+                                <listitem><para><filename>squashfs</filename>
+                                </para></listitem>
+                                <listitem><para><filename>swap</filename>
+                                </para></listitem>
+                            </itemizedlist></para></listitem>
+                        <listitem><para><emphasis><filename>&dash;&dash;fsoptions</filename>:</emphasis>
+                            Specifies a free-form string of options to be
+                            used when mounting the filesystem.
+                            This string will be copied into the
+                            <filename>/etc/fstab</filename> file of the
+                            installed system and should be enclosed in
+                            quotes.
+                            If not specified, the default string
+                            is "defaults".
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>&dash;&dash;label label</filename>:</emphasis>
+                            Specifies the label to give to the filesystem to
+                            be made on the partition.
+                            If the given label is already in use by another
+                            filesystem, a new label is created for the
+                            partition.</para></listitem>
+                        <listitem><para><emphasis><filename>&dash;&dash;active</filename>:</emphasis>
+                            Marks the partition as active.</para></listitem>
+                        <listitem><para><emphasis><filename>&dash;&dash;align (in KBytes)</filename>:</emphasis>
+                            This option is a <filename>wic</filename>-specific
+                            option that says to start a partition on an
+                            x KBytes boundary.</para></listitem>
+                    </itemizedlist>
+                </para>
+            </section>
+
+            <section id='command-bootloader'>
+                <title>Command: bootloader</title>
+
+                <para>
+                    This command specifies how the boot loader should be
+                    configured and supports the following options:
+                    <note>
+                        Bootloader functionality and boot partitions are
+                        implemented by the various
+                        <filename>&dash;&dash;source</filename>
+                                    plugins that implement bootloader functionality.
+                        The bootloader command essentially provides a means of
+                        modifying bootloader configuration.
+                    </note>
+                    <itemizedlist>
+                        <listitem><para><emphasis><filename>&dash;&dash;timeout</filename>:</emphasis>
+                            Specifies the number of seconds before the
+                            bootloader times out and boots the default option.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>&dash;&dash;append</filename>:</emphasis>
+                            Specifies kernel parameters.
+                            These parameters will be added to the syslinux
+                            <filename>APPEND</filename> or
+                            <filename>grub</filename> kernel command line.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </section>
+        </section>
+    </section>
+
+    <section id='configuring-the-kernel'>
+        <title>Configuring the Kernel</title>
+
+        <para>
+            Configuring the Yocto Project kernel consists of making sure the <filename>.config</filename>
+            file has all the right information in it for the image you are building.
+            You can use the <filename>menuconfig</filename> tool and configuration fragments to
+            make sure your <filename>.config</filename> file is just how you need it.
+            This section describes how to use <filename>menuconfig</filename>, create and use
+            configuration fragments, and how to interactively modify your <filename>.config</filename>
+            file to create the leanest kernel configuration file possible.
+        </para>
+
+        <para>
+            For more information on kernel configuration, see the
+            "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#changing-the-configuration'>Changing the Configuration</ulink>"
+            section in the Yocto Project Linux Kernel Development Manual.
+        </para>
+
+        <section id='using-menuconfig'>
+            <title>Using&nbsp;&nbsp;<filename>menuconfig</filename></title>
+
+            <para>
+                The easiest way to define kernel configurations is to set them through the
+                <filename>menuconfig</filename> tool.
+                This tool provides an interactive method with which
+                to set kernel configurations.
+                For general information on <filename>menuconfig</filename>, see
+                <ulink url='http://en.wikipedia.org/wiki/Menuconfig'></ulink>.
+            </para>
+
+            <para>
+                To use the <filename>menuconfig</filename> tool in the Yocto Project development
+                environment, you must launch it using BitBake.
+                Thus, the environment must be set up using the
+                <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                or
+                <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>
+                script found in the
+                <link linkend='build-directory'>Build Directory</link>.
+                The following commands run <filename>menuconfig</filename> assuming the
+                <link linkend='source-directory'>Source Directory</link>
+                top-level folder is <filename>~/poky</filename>:
+                <literallayout class='monospaced'>
+     $ cd poky
+     $ source oe-init-build-env
+     $ bitbake linux-yocto -c menuconfig
+                </literallayout>
+                Once <filename>menuconfig</filename> comes up, its standard interface allows you to
+                interactively examine and configure all the kernel configuration parameters.
+                After making your changes, simply exit the tool and save your changes to
+                create an updated version of the <filename>.config</filename> configuration file.
+            </para>
+
+            <para>
+                Consider an example that configures the <filename>linux-yocto-3.14</filename>
+                kernel.
+                The OpenEmbedded build system recognizes this kernel as
+                <filename>linux-yocto</filename>.
+                Thus, the following commands from the shell in which you previously sourced the
+                environment initialization script cleans the shared state cache and the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink>
+                directory and then runs <filename>menuconfig</filename>:
+                <literallayout class='monospaced'>
+     $ bitbake linux-yocto -c menuconfig
+                </literallayout>
+            </para>
+
+            <para>
+                Once <filename>menuconfig</filename> launches, use the interface
+                to navigate through the selections to find the configuration settings in
+                which you are interested.
+                For example, consider the <filename>CONFIG_SMP</filename> configuration setting.
+                You can find it at <filename>Processor Type and Features</filename> under
+                the configuration selection <filename>Symmetric Multi-processing Support</filename>.
+                After highlighting the selection, use the arrow keys to select or deselect
+                the setting.
+                When you are finished with all your selections, exit out and save them.
+            </para>
+
+            <para>
+                Saving the selections updates the <filename>.config</filename> configuration file.
+                This is the file that the OpenEmbedded build system uses to configure the
+                kernel during the build.
+                You can find and examine this file in the Build Directory in
+                <filename>tmp/work/</filename>.
+                The actual <filename>.config</filename> is located in the area where the
+                specific kernel is built.
+                For example, if you were building a Linux Yocto kernel based on the
+                Linux 3.14 kernel and you were building a QEMU image targeted for
+                <filename>x86</filename> architecture, the
+                <filename>.config</filename> file would be located here:
+                <literallayout class='monospaced'>
+     poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.14.11+git1+84f...
+        ...656ed30-r1/linux-qemux86-standard-build
+                </literallayout>
+                <note>
+                    The previous example directory is artificially split and many of the characters
+                    in the actual filename are omitted in order to make it more readable.
+                    Also, depending on the kernel you are using, the exact pathname
+                    for <filename>linux-yocto-3.14...</filename> might differ.
+                </note>
+            </para>
+
+            <para>
+                Within the <filename>.config</filename> file, you can see the kernel settings.
+                For example, the following entry shows that symmetric multi-processor support
+                is not set:
+                <literallayout class='monospaced'>
+     # CONFIG_SMP is not set
+                </literallayout>
+            </para>
+
+            <para>
+                A good method to isolate changed configurations is to use a combination of the
+                <filename>menuconfig</filename> tool and simple shell commands.
+                Before changing configurations with <filename>menuconfig</filename>, copy the
+                existing <filename>.config</filename> and rename it to something else,
+                use <filename>menuconfig</filename> to make
+                as many changes as you want and save them, then compare the renamed configuration
+                file against the newly created file.
+                You can use the resulting differences as your base to create configuration fragments
+                to permanently save in your kernel layer.
+                <note>
+                    Be sure to make a copy of the <filename>.config</filename> and don't just
+                    rename it.
+                    The build system needs an existing <filename>.config</filename>
+                    from which to work.
+                </note>
+            </para>
+        </section>
+
+        <section id='creating-config-fragments'>
+            <title>Creating Configuration Fragments</title>
+
+            <para>
+                Configuration fragments are simply kernel options that appear in a file
+                placed where the OpenEmbedded build system can find and apply them.
+                Syntactically, the configuration statement is identical to what would appear
+                in the <filename>.config</filename> file, which is in the
+                <link linkend='build-directory'>Build Directory</link> in
+                <filename>tmp/work/&lt;arch&gt;-poky-linux/linux-yocto-&lt;release-specific-string&gt;/linux-&lt;arch&gt;-&lt;build-type&gt;</filename>.
+            </para>
+
+            <para>
+                It is simple to create a configuration fragment.
+                For example, issuing the following from the shell creates a configuration fragment
+                file named <filename>my_smp.cfg</filename> that enables multi-processor support
+                within the kernel:
+                <literallayout class='monospaced'>
+     $ echo "CONFIG_SMP=y" >> my_smp.cfg
+                </literallayout>
+                <note>
+                    All configuration files must use the <filename>.cfg</filename> extension in order
+                    for the OpenEmbedded build system to recognize them as a configuration fragment.
+                </note>
+            </para>
+
+            <para>
+                Where do you put your configuration files?
+                You can place these configuration files in the same area pointed to by
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>.
+                The OpenEmbedded build system will pick up the configuration and add it to the
+                kernel's configuration.
+                For example, suppose you had a set of configuration options in a file called
+                <filename>myconfig.cfg</filename>.
+                If you put that file inside a directory named <filename>linux-yocto</filename>
+                that resides in the same directory as the kernel's append file and then add
+                a <filename>SRC_URI</filename> statement such as the following to the kernel's append file,
+                those configuration options will be picked up and applied when the kernel is built.
+                <literallayout class='monospaced'>
+     SRC_URI += "file://myconfig.cfg"
+                </literallayout>
+            </para>
+
+            <para>
+                As mentioned earlier, you can group related configurations into multiple files and
+                name them all in the <filename>SRC_URI</filename> statement as well.
+                For example, you could group separate configurations specifically for Ethernet and graphics
+                into their own files and add those by using a <filename>SRC_URI</filename> statement like the
+                following in your append file:
+                <literallayout class='monospaced'>
+     SRC_URI += "file://myconfig.cfg \
+            file://eth.cfg \
+            file://gfx.cfg"
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='fine-tuning-the-kernel-configuration-file'>
+            <title>Fine-Tuning the Kernel Configuration File</title>
+
+            <para>
+                You can make sure the <filename>.config</filename> file is as lean or efficient as
+                possible by reading the output of the kernel configuration fragment audit,
+                noting any issues, making changes to correct the issues, and then repeating.
+            </para>
+
+            <para>
+                As part of the kernel build process, the
+                <filename>do_kernel_configcheck</filename> task runs.
+                This task validates the kernel configuration by checking the final
+                <filename>.config</filename> file against the input files.
+                During the check, the task produces warning messages for the following
+                issues:
+                <itemizedlist>
+                    <listitem><para>Requested options that did not make the final
+                        <filename>.config</filename> file.</para></listitem>
+                    <listitem><para>Configuration items that appear twice in the same
+                        configuration fragment.</para></listitem>
+                    <listitem><para>Configuration items tagged as "required" that were overridden.
+                        </para></listitem>
+                    <listitem><para>A board overrides a non-board specific option.</para></listitem>
+                    <listitem><para>Listed options not valid for the kernel being processed.
+                        In other words, the option does not appear anywhere.</para></listitem>
+                </itemizedlist>
+                <note>
+                    The <filename>do_kernel_configcheck</filename> task can
+                    also optionally report if an option is overridden during
+                    processing.
+                </note>
+            </para>
+
+            <para>
+                For each output warning, a message points to the file
+                that contains a list of the options and a pointer to the config
+                fragment that defines them.
+                Collectively, the files are the key to streamlining the configuration.
+            </para>
+
+            <para>
+                To streamline the configuration, do the following:
+                <orderedlist>
+                    <listitem><para>Start with a full configuration that you
+                        know works - it builds and boots successfully.
+                        This configuration file will be your baseline.
+                        </para></listitem>
+                    <listitem><para>Separately run the
+                        <filename>do_configme</filename> and
+                        <filename>do_kernel_configcheck</filename> tasks.
+                        </para></listitem>
+                    <listitem><para>Take the resulting list of files from the
+                        <filename>do_kernel_configcheck</filename> task
+                        warnings and do the following:
+                        <itemizedlist>
+                            <listitem><para>
+                                Drop values that are redefined in the fragment
+                                but do not change the final
+                                <filename>.config</filename> file.
+                                </para></listitem>
+                            <listitem><para>
+                                Analyze and potentially drop values from the
+                                <filename>.config</filename> file that override
+                                required configurations.
+                                </para></listitem>
+                            <listitem><para>
+                                Analyze and potentially remove non-board
+                                specific options.
+                                </para></listitem>
+                            <listitem><para>
+                                Remove repeated and invalid options.
+                                </para></listitem>
+                        </itemizedlist></para></listitem>
+                    <listitem><para>
+                        After you have worked through the output of the kernel
+                        configuration audit, you can re-run the
+                        <filename>do_configme</filename> and
+                        <filename>do_kernel_configcheck</filename> tasks to
+                        see the results of your changes.
+                        If you have more issues, you can deal with them as
+                        described in the previous step.
+                        </para></listitem>
+                </orderedlist>
+            </para>
+
+            <para>
+                Iteratively working through steps two through four eventually yields
+                a minimal, streamlined configuration file.
+                Once you have the best <filename>.config</filename>, you can build the Linux
+                Yocto kernel.
+            </para>
+        </section>
+    </section>
+
+    <section id="patching-the-kernel">
+        <title>Patching the Kernel</title>
+
+        <para>
+            Patching the kernel involves changing or adding configurations to an existing kernel,
+            changing or adding recipes to the kernel that are needed to support specific hardware features,
+            or even altering the source code itself.
+            <note>
+                You can use the <filename>yocto-kernel</filename> script
+                found in the <link linkend='source-directory'>Source Directory</link>
+                under <filename>scripts</filename> to manage kernel patches and configuration.
+                See the "<ulink url='&YOCTO_DOCS_BSP_URL;#managing-kernel-patches-and-config-items-with-yocto-kernel'>Managing kernel Patches and Config Items with yocto-kernel</ulink>"
+                section in the Yocto Project Board Support Packages (BSP) Developer's Guide for
+                more information.</note>
+        </para>
+
+        <para>
+            This example creates a simple patch by adding some QEMU emulator console
+            output at boot time through <filename>printk</filename> statements in the kernel's
+            <filename>calibrate.c</filename> source code file.
+            Applying the patch and booting the modified image causes the added
+            messages to appear on the emulator's console.
+        </para>
+
+        <para>
+            The example assumes a clean build exists for the <filename>qemux86</filename>
+            machine in a
+            <link linkend='source-directory'>Source Directory</link>
+            named <filename>poky</filename>.
+            Furthermore, the <link linkend='build-directory'>Build Directory</link> is
+            <filename>build</filename> and is located in <filename>poky</filename> and
+            the kernel is based on the Linux 3.4 kernel.
+            For general information on how to configure the most efficient build, see the
+            "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" section
+            in the Yocto Project Quick Start.
+        </para>
+
+        <para>
+            Also, for more information on patching the kernel, see the
+            "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#applying-patches'>Applying Patches</ulink>"
+            section in the Yocto Project Linux Kernel Development Manual.
+        </para>
+
+        <section id='create-a-layer-for-your-changes'>
+            <title>Create a Layer for your Changes</title>
+
+            <para>
+                The first step is to create a layer so you can isolate your
+                changes.
+                Rather than use the <filename>yocto-layer</filename> script
+                to create the layer, this example steps through the process
+                by hand.
+                If you want information on the script that creates a general
+                layer, see the
+                "<link linkend='creating-a-general-layer-using-the-yocto-layer-script'>Creating a General Layer Using the yocto-layer Script</link>"
+                section.
+            </para>
+
+            <para>
+                These two commands create a directory you can use for your
+                layer:
+                <literallayout class='monospaced'>
+     $ cd ~/poky
+     $ mkdir meta-mylayer
+                </literallayout>
+                Creating a directory that follows the Yocto Project layer naming
+                conventions sets up the layer for your changes.
+                The layer is where you place your configuration files, append
+                files, and patch files.
+                To learn more about creating a layer and filling it with the
+                files you need, see the "<link linkend='understanding-and-creating-layers'>Understanding
+                and Creating Layers</link>" section.
+            </para>
+        </section>
+
+        <section id='finding-the-kernel-source-code'>
+            <title>Finding the Kernel Source Code</title>
+
+            <para>
+                Each time you build a kernel image, the kernel source code is fetched
+                and unpacked into the following directory:
+                <literallayout class='monospaced'>
+     ${S}/linux
+                </literallayout>
+                See the "<link linkend='finding-the-temporary-source-code'>Finding the Temporary Source Code</link>"
+                section and the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink> variable
+                for more information about where source is kept during a build.
+            </para>
+
+            <para>
+                For this example, we are going to patch the
+                <filename>init/calibrate.c</filename> file
+                by adding some simple console <filename>printk</filename> statements that we can
+                see when we boot the image using QEMU.
+            </para>
+        </section>
+
+        <section id='creating-the-patch'>
+            <title>Creating the Patch</title>
+
+            <para>
+                Two methods exist by which you can create the patch:
+                <link linkend='using-a-git-workflow'>Git workflow</link> and
+                <link linkend='using-a-quilt-workflow'>Quilt workflow</link>.
+                For kernel patches, the Git workflow is more appropriate.
+                This section assumes the Git workflow and shows the steps specific to
+                this example.
+                <orderedlist>
+                    <listitem><para><emphasis>Change the working directory</emphasis>:
+                        Change to where the kernel source code is before making
+                        your edits to the <filename>calibrate.c</filename> file:
+                        <literallayout class='monospaced'>
+     $ cd ~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-${PV}-${PR}/linux
+                        </literallayout>
+                        Because you are working in an established Git repository,
+                        you must be in this directory in order to commit your changes
+                        and create the patch file.
+                        <note>The <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink> and
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink> variables
+                            represent the version and revision for the
+                            <filename>linux-yocto</filename> recipe.
+                            The <filename>PV</filename> variable includes the Git meta and machine
+                            hashes, which make the directory name longer than you might
+                            expect.
+                        </note></para></listitem>
+                    <listitem><para><emphasis>Edit the source file</emphasis>:
+                        Edit the <filename>init/calibrate.c</filename> file to have the
+                        following changes:
+                        <literallayout class='monospaced'>
+     void calibrate_delay(void)
+     {
+         unsigned long lpj;
+         static bool printed;
+         int this_cpu = smp_processor_id();
+
+         printk("*************************************\n");
+         printk("*                                   *\n");
+         printk("*        HELLO YOCTO KERNEL         *\n");
+         printk("*                                   *\n");
+         printk("*************************************\n");
+
+        if (per_cpu(cpu_loops_per_jiffy, this_cpu)) {
+               .
+               .
+               .
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Stage and commit your changes</emphasis>:
+                        These Git commands display the modified file, stage it, and then
+                        commit the file:
+                        <literallayout class='monospaced'>
+     $ git status
+     $ git add init/calibrate.c
+     $ git commit -m "calibrate: Add printk example"
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Generate the patch file</emphasis>:
+                        This Git command creates the a patch file named
+                        <filename>0001-calibrate-Add-printk-example.patch</filename>
+                        in the current directory.
+                        <literallayout class='monospaced'>
+     $ git format-patch -1
+                        </literallayout>
+                        </para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+
+        <section id='set-up-your-layer-for-the-build'>
+            <title>Set Up Your Layer for the Build</title>
+
+            <para>These steps get your layer set up for the build:
+                <orderedlist>
+                    <listitem><para><emphasis>Create additional structure</emphasis>:
+                        Create the additional layer structure:
+                        <literallayout class='monospaced'>
+     $ cd ~/poky/meta-mylayer
+     $ mkdir conf
+     $ mkdir recipes-kernel
+     $ mkdir recipes-kernel/linux
+     $ mkdir recipes-kernel/linux/linux-yocto
+                         </literallayout>
+                         The <filename>conf</filename> directory holds your configuration files, while the
+                         <filename>recipes-kernel</filename> directory holds your append file and
+                         your patch file.</para></listitem>
+                    <listitem><para><emphasis>Create the layer configuration file</emphasis>:
+                        Move to the <filename>meta-mylayer/conf</filename> directory and create
+                        the <filename>layer.conf</filename> file as follows:
+                        <literallayout class='monospaced'>
+     # We have a conf and classes directory, add to BBPATH
+     BBPATH .= ":${LAYERDIR}"
+
+     # We have recipes-* directories, add to BBFILES
+     BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
+                 ${LAYERDIR}/recipes-*/*/*.bbappend"
+
+     BBFILE_COLLECTIONS += "mylayer"
+     BBFILE_PATTERN_mylayer = "^${LAYERDIR}/"
+     BBFILE_PRIORITY_mylayer = "5"
+                         </literallayout>
+                         Notice <filename>mylayer</filename> as part of the last three
+                         statements.</para></listitem>
+                    <listitem><para><emphasis>Create the kernel recipe append file</emphasis>:
+                        Move to the <filename>meta-mylayer/recipes-kernel/linux</filename> directory and create
+                        the <filename>linux-yocto_3.4.bbappend</filename> file as follows:
+                        <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+     SRC_URI += "file://0001-calibrate-Add-printk-example.patch"
+                        </literallayout>
+                        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
+                        "<link linkend='using-bbappend-files'>Using .bbappend Files</link>"
+                        section.
+                        </para></listitem>
+                    <listitem><para><emphasis>Put the patch file in your layer</emphasis>:
+                        Move the <filename>0001-calibrate-Add-printk-example.patch</filename> file to
+                        the <filename>meta-mylayer/recipes-kernel/linux/linux-yocto</filename>
+                        directory.</para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+
+        <section id='set-up-for-the-build'>
+            <title>Set Up for the Build</title>
+
+            <para>
+                Do the following to make sure the build parameters are set up for the example.
+                Once you set up these build parameters, they do not have to change unless you
+                change the target architecture of the machine you are building:
+                <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
+                        <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
+                        <filename>qemux86</filename>, which specifies a 32-bit
+                        <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
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink>
+                        variable in the
+                        <filename>bblayers.conf</filename> file found in the
+                        <filename>poky/build/conf</filename> directory needs to have the path to your local
+                        <filename>meta-mylayer</filename> layer.
+                        By default, the <filename>BBLAYERS</filename> variable contains paths to
+                        <filename>meta</filename>, <filename>meta-yocto</filename>, and
+                        <filename>meta-yocto-bsp</filename> in the
+                        <filename>poky</filename> Git repository.
+                        Add the path to your <filename>meta-mylayer</filename> location:
+                        <literallayout class='monospaced'>
+     BBLAYERS ?= " \
+       $HOME/poky/meta \
+       $HOME/poky/meta-yocto \
+       $HOME/poky/meta-yocto-bsp \
+       $HOME/poky/meta-mylayer \
+       "
+
+     BBLAYERS_NON_REMOVABLE ?= " \
+       $HOME/poky/meta \
+       $HOME/poky/meta-yocto \
+       "
+                        </literallayout></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='build-the-modified-qemu-kernel-image'>
+            <title>Build the Modified QEMU Kernel Image</title>
+
+            <para>
+                The following steps build your modified kernel image:
+                <orderedlist>
+                    <listitem><para><emphasis>Be sure your build environment is initialized</emphasis>:
+                        Your environment should be set up since you previously sourced
+                        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>.
+                        <literallayout class='monospaced'>
+     $ cd ~/poky
+     $ source &OE_INIT_FILE;
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para><emphasis>Clean up</emphasis>:
+                        Be sure to clean the shared state out by using BitBake
+                        to run from within the Build Directory the
+                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-cleansstate'><filename>do_cleansstate</filename></ulink>
+                        task as follows:
+                        <literallayout class='monospaced'>
+     $ bitbake -c cleansstate linux-yocto
+                        </literallayout></para>
+                        <para>
+                           <note>
+                               Never remove any files by hand from the
+                               <filename>tmp/deploy</filename>
+                               directory inside the
+                               <link linkend='build-directory'>Build Directory</link>.
+                               Always use the various BitBake clean tasks to
+                               clear out previous build artifacts.
+                               For information on the clean tasks, see the
+                               "<ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-clean'><filename>do_clean</filename></ulink>",
+                               "<ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-cleanall'><filename>do_cleanall</filename></ulink>",
+                               and
+                               "<ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-cleansstate'><filename>do_cleansstate</filename></ulink>"
+                               sections all in the Yocto Project Reference
+                               Manual.
+                           </note>
+                        </para></listitem>
+                    <listitem><para><emphasis>Build the image</emphasis>:
+                        Next, build the kernel image using this command:
+                        <literallayout class='monospaced'>
+     $ bitbake -k linux-yocto
+                        </literallayout></para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+
+        <section id='boot-the-image-and-verify-your-changes'>
+            <title>Boot the Image and Verify Your Changes</title>
+
+            <para>
+                These steps boot the image and allow you to see the changes
+                <orderedlist>
+                    <listitem><para><emphasis>Boot the image</emphasis>:
+                        Boot the modified image in the QEMU emulator
+                        using this command:
+                        <literallayout class='monospaced'>
+     $ runqemu qemux86
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Verify the changes</emphasis>:
+                        Log into the machine using <filename>root</filename> with no password and then
+                        use the following shell command to scroll through the console's boot output.
+                        <literallayout class='monospaced'>
+     # dmesg | less
+                        </literallayout>
+                        You should see the results of your <filename>printk</filename> statements
+                        as part of the output.</para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+    </section>
+
+    <section id='making-images-more-secure'>
+        <title>Making Images More Secure</title>
+
+        <para>
+            Security is of increasing concern for embedded devices.
+            Consider the issues and problems discussed in just this
+            sampling of work found across the Internet:
+            <itemizedlist>
+                <listitem><para><emphasis>
+                    "<ulink url='https://www.schneier.com/blog/archives/2014/01/security_risks_9.html'>Security Risks of Embedded Systems</ulink>"</emphasis>
+                    by Bruce Schneier
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    "<ulink url='http://internetcensus2012.bitbucket.org/paper.html'>Internet Census 2012</ulink>"</emphasis>
+                    by Carna Botnet</para></listitem>
+                <listitem><para><emphasis>
+                    "<ulink url='http://elinux.org/images/6/6f/Security-issues.pdf'>Security Issues for Embedded Devices</ulink>"</emphasis>
+                    by Jake Edge
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    "<ulink url='https://www.nccgroup.com/media/18475/exploiting_security_gateways_via_their_web_interfaces.pdf'>They ought to know better: Exploiting Security
+Gateways via their Web Interfaces</ulink>"</emphasis>
+                    by Ben Williams
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            When securing your image is of concern, there are steps, tools,
+            and variables that you can consider to help you reach the
+            security goals you need for your particular device.
+            Not all situations are identical when it comes to making an
+            image secure.
+            Consequently, this section provides some guidance and suggestions
+            for consideration when you want to make your image more secure.
+            <note>
+                Because the security requirements and risks are
+                different for every type of device, this section cannot
+                provide a complete reference on securing your custom OS.
+                It is strongly recommended that you also consult other sources
+                of information on embedded Linux system hardening and on
+                security.
+            </note>
+        </para>
+
+        <section id='general-considerations'>
+            <title>General Considerations</title>
+
+            <para>
+                General considerations exist that help you create more
+                secure images.
+                You should consider the following suggestions to help
+                make your device more secure:
+                <itemizedlist>
+                    <listitem><para>
+                        Scan additional code you are adding to the system
+                        (e.g. application code) by using static analysis
+                        tools.
+                        Look for buffer overflows and other potential
+                        security problems.
+                    </para></listitem>
+                    <listitem><para>
+                        Pay particular attention to the security for
+                        any web-based administration interface.
+                        </para>
+                        <para>Web interfaces typically need to perform
+                        administrative functions and tend to need to run with
+                        elevated privileges.
+                        Thus, the consequences resulting from the interface's
+                        security becoming compromised can be serious.
+                        Look for common web vulnerabilities such as
+                        cross-site-scripting (XSS), unvalidated inputs,
+                        and so forth.</para>
+                        <para>As with system passwords, the default credentials
+                        for accessing a web-based interface should not be the
+                        same across all devices.
+                        This is particularly true if the interface is enabled
+                        by default as it can be assumed that many end-users
+                        will not change the credentials.
+                    </para></listitem>
+                    <listitem><para>
+                        Ensure you can update the software on the device to
+                        mitigate vulnerabilities discovered in the future.
+                        This consideration especially applies when your
+                        device is network-enabled.
+                    </para></listitem>
+                    <listitem><para>
+                        Ensure you remove or disable debugging functionality
+                        before producing the final image.
+                        For information on how to do this, see the
+                        "<link linkend='considerations-specific-to-the-openembedded-build-system'>Considerations Specific to the OpenEmbedded Build System</link>"
+                        section.
+                        </para></listitem>
+                    <listitem><para>
+                        Ensure you have no network services listening that
+                        are not needed.
+                    </para></listitem>
+                    <listitem><para>
+                        Remove any software from the image that is not needed.
+                    </para></listitem>
+                    <listitem><para>
+                        Enable hardware support for secure boot functionality
+                        when your device supports this functionality.
+                    </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='security-flags'>
+            <title>Security Flags</title>
+
+            <para>
+                The Yocto Project has security flags that you can enable that
+                help make your build output more secure.
+                The security flags are in the
+                <filename>meta/conf/distro/include/security_flags.inc</filename>
+                file in your
+                <link linkend='source-directory'>Source Directory</link>
+                (e.g. <filename>poky</filename>).
+                <note>
+                    Depending on the recipe, certain security flags are enabled
+                    and disabled by default.
+                </note>
+            </para>
+
+            <para>
+<!--
+                The GCC/LD flags in <filename>security_flags.inc</filename>
+                enable more secure code generation.
+                By including the <filename>security_flags.inc</filename>
+                file, you enable flags to the compiler and linker that cause
+                them to generate more secure code.
+                <note>
+                    The GCC/LD flags are enabled by default in the
+                    <filename>poky-lsb</filename> distribution.
+                </note>
+-->
+                Use the following line in your
+                <filename>local.conf</filename> file or in your custom
+                distribution configuration file to enable the security
+                compiler and linker flags for your build:
+                <literallayout class='monospaced'>
+     require conf/distro/include/security_flags.inc
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='considerations-specific-to-the-openembedded-build-system'>
+            <title>Considerations Specific to the OpenEmbedded Build System</title>
+
+            <para>
+                You can take some steps that are specific to the
+                OpenEmbedded build system to make your images more secure:
+                <itemizedlist>
+                    <listitem><para>
+                        Ensure "debug-tweaks" is not one of your selected
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></ulink>.
+                        When creating a new project, the default is to provide you
+                        with an initial <filename>local.conf</filename> file that
+                        enables this feature using the
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGE_FEATURES'><filename>EXTRA_IMAGE_FEATURES</filename></ulink> variable with the line:
+                <literallayout class='monospaced'>
+     EXTRA_IMAGE_FEATURES = "debug-tweaks"
+                </literallayout>
+                        To disable that feature, simply comment out that line in your
+                        <filename>local.conf</filename> file, or
+                        make sure <filename>IMAGE_FEATURES</filename> does not contain
+                        "debug-tweaks" before producing your final image.
+                        Among other things, leaving this in place sets the
+                        root password as blank, which makes logging in for
+                        debugging or inspection easy during
+                        development but also means anyone can easily log in
+                        during production.
+                        </para></listitem>
+                    <listitem><para>
+                        It is possible to set a root password for the image
+                        and also to set passwords for any extra users you might
+                        add (e.g. administrative or service type users).
+                        When you set up passwords for multiple images or
+                        users, you should not duplicate passwords.
+                        </para>
+                        <para>
+                        To set up passwords, use the
+                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-extrausers'><filename>extrausers</filename></ulink>
+                        class, which is the preferred method.
+                        For an example on how to set up both root and user
+                        passwords, see the
+                        "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-extrausers'><filename>extrausers.bbclass</filename></ulink>"
+                        section.
+                        <note>
+                            When adding extra user accounts or setting a
+                            root password, be cautious about setting the
+                            same password on every device.
+                            If you do this, and the password you have set
+                            is exposed, then every device is now potentially
+                            compromised.
+                            If you need this access but want to ensure
+                            security, consider setting a different,
+                            random password for each device.
+                            Typically, you do this as a separate step after
+                            you deploy the image onto the device.
+                        </note>
+                        </para></listitem>
+                    <listitem><para>
+                        Consider enabling a Mandatory Access Control (MAC)
+                        framework such as SMACK or SELinux and tuning it
+                        appropriately for your device's usage.
+                        You can find more information in the
+                        <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/'><filename>meta-selinux</filename></ulink>
+                        layer.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+            </para>
+        </section>
+
+        <section id='tools-for-hardening-your-image'>
+            <title>Tools for Hardening Your Image</title>
+
+            <para>
+                The Yocto Project provides tools for making your image
+                more secure.
+                You can find these tools in the
+                <filename>meta-security</filename> layer of the
+                <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'>Yocto Project Source Repositories</ulink>.
+            </para>
+        </section>
+    </section>
+
+    <section id='creating-your-own-distribution'>
+        <title>Creating Your Own Distribution</title>
+
+        <para>
+            When you build an image using the Yocto Project and
+            do not alter any distribution
+            <link linkend='metadata'>Metadata</link>, you are creating a
+            Poky distribution.
+            If you wish to gain more control over package alternative
+            selections, compile-time options, and other low-level
+            configurations, you can create your own distribution.
+        </para>
+
+        <para>
+            To create your own distribution, the basic steps consist of
+            creating your own distribution layer, creating your own
+            distribution configuration file, and then adding any needed
+            code and Metadata to the layer.
+            The following steps provide some more detail:
+            <itemizedlist>
+                <listitem><para><emphasis>Create a layer for your new distro:</emphasis>
+                    Create your distribution layer so that you can keep your
+                    Metadata and code for the distribution separate.
+                    It is strongly recommended that you create and use your own
+                    layer for configuration and code.
+                    Using your own layer as compared to just placing
+                    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
+                    "<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>
+                <listitem><para><emphasis>Create the distribution configuration file:</emphasis>
+                    The distribution configuration file needs to be created in
+                    the <filename>conf/distro</filename> directory of your
+                    layer.
+                    You need to name it using your distribution name
+                    (e.g. <filename>mydistro.conf</filename>).
+                    <note>
+                        The
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO'><filename>DISTRO</filename></ulink>
+                        variable in your
+                        <filename>local.conf</filename> file determines the
+                        name of your distribution.
+                    </note></para>
+                    <para>You can split out parts of your configuration file
+                    into include files and then "require" them from within
+                    your distribution configuration file.
+                    Be sure to place the include files in the
+                    <filename>conf/distro/include</filename> directory of
+                    your layer.
+                    A common example usage of include files would be to
+                    separate out the selection of desired version and revisions
+                    for individual recipes.
+</para>
+                    <para>Your configuration file needs to set the following
+                    required variables:
+                    <literallayout class='monospaced'>
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_NAME'><filename>DISTRO_NAME</filename></ulink>
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_VERSION'><filename>DISTRO_VERSION</filename></ulink>
+                    </literallayout>
+                    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>
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_EXTRA_RDEPENDS'><filename>DISTRO_EXTRA_RDEPENDS</filename></ulink>
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_EXTRA_RRECOMMENDS'><filename>DISTRO_EXTRA_RRECOMMENDS</filename></ulink>
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-TCLIBC'><filename>TCLIBC</filename></ulink>
+                    </literallayout>
+                    <tip>
+                        If you want to base your distribution configuration file
+                        on the very basic configuration from OE-Core, you
+                        can use
+                        <filename>conf/distro/defaultsetup.conf</filename> as
+                        a reference and just include variables that differ
+                        as compared to <filename>defaultsetup.conf</filename>.
+                        Alternatively, you can create a distribution
+                        configuration file from scratch using the
+                        <filename>defaultsetup.conf</filename> file
+                        or configuration files from other distributions
+                        such as Poky or Angstrom as references.
+                    </tip></para></listitem>
+                <listitem><para><emphasis>Provide miscellaneous variables:</emphasis>
+                    Be sure to define any other variables for which you want to
+                    create a default or enforce as part of the distribution
+                    configuration.
+                    You can include nearly any variable from the
+                    <filename>local.conf</filename> file.
+                    The variables you use are not limited to the list in the
+                    previous bulleted item.</para></listitem>
+                <listitem><para><emphasis>Point to Your distribution configuration file:</emphasis>
+                    In your <filename>local.conf</filename> file in the
+                    <link linkend='build-directory'>Build Directory</link>,
+                    set your
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO'><filename>DISTRO</filename></ulink>
+                    variable to point to your distribution's configuration file.
+                    For example, if your distribution's configuration file is
+                    named <filename>mydistro.conf</filename>, then you point
+                    to it as follows:
+                    <literallayout class='monospaced'>
+     DISTRO = "mydistro"
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Add more to the layer if necessary:</emphasis>
+                    Use your layer to hold other information needed for the
+                    distribution:
+                    <itemizedlist>
+                        <listitem><para>Add recipes for installing
+                            distro-specific configuration files that are not
+                            already installed by another recipe.
+                            If you have distro-specific configuration files
+                            that are included by an existing recipe, you should
+                            add an append file (<filename>.bbappend</filename>)
+                            for those.
+                            For general information and recommendations
+                            on how to add recipes to your layer, see the
+                            "<link linkend='creating-your-own-layer'>Creating Your Own Layer</link>"
+                            and
+                            "<link linkend='best-practices-to-follow-when-creating-layers'>Best Practices to Follow When Creating Layers</link>"
+                            sections.</para></listitem>
+                        <listitem><para>Add any image recipes that are specific
+                            to your distribution.</para></listitem>
+                        <listitem><para>Add a <filename>psplash</filename>
+                            append file for a branded splash screen.
+                            For information on append files, see the
+                            "<link linkend='using-bbappend-files'>Using .bbappend Files</link>"
+                            section.</para></listitem>
+                        <listitem><para>Add any other append files to make
+                            custom changes that are specific to individual
+                            recipes.</para></listitem>
+                    </itemizedlist></para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='creating-a-custom-template-configuration-directory'>
+        <title>Creating a Custom Template Configuration Directory</title>
+
+        <para>
+            If you are producing your own customized version
+            of the build system for use by other users, you might
+            want to customize the message shown by the setup script or
+            you might want to change the template configuration files (i.e.
+            <filename>local.conf</filename> and
+            <filename>bblayers.conf</filename>) that are created in
+            a new build directory.
+        </para>
+
+        <para>
+            The OpenEmbedded build system uses the environment variable
+            <filename>TEMPLATECONF</filename> to locate the directory
+            from which it gathers configuration information that ultimately
+            ends up in the
+            <link linkend='build-directory'>Build Directory's</link>
+            <filename>conf</filename> directory.
+            By default, <filename>TEMPLATECONF</filename> is set as
+            follows in the <filename>poky</filename> repository:
+            <literallayout class='monospaced'>
+     TEMPLATECONF=${TEMPLATECONF:-meta-yocto/conf}
+            </literallayout>
+            This is the directory used by the build system to find templates
+            from which to build some key configuration files.
+            If you look at this directory, you will see the
+            <filename>bblayers.conf.sample</filename>,
+            <filename>local.conf.sample</filename>, and
+            <filename>conf-notes.txt</filename> files.
+            The build system uses these files to form the respective
+            <filename>bblayers.conf</filename> file,
+            <filename>local.conf</filename> file, and display the list of
+            BitBake targets when running the setup script.
+        </para>
+
+        <para>
+            To override these default configuration files with
+            configurations you want used within every new
+            Build Directory, simply set the
+            <filename>TEMPLATECONF</filename> variable to your directory.
+            The <filename>TEMPLATECONF</filename> variable is set in the
+            <filename>.templateconf</filename> file, which is in the
+            top-level
+            <link linkend='source-directory'>Source Directory</link>
+            folder (e.g. <filename>poky</filename>).
+            Edit the <filename>.templateconf</filename> so that it can locate
+            your directory.
+        </para>
+
+        <para>
+            Best practices dictate that you should keep your
+            template configuration directory in your custom distribution layer.
+            For example, suppose you have a layer named
+            <filename>meta-mylayer</filename> located in your home directory
+            and you want your template configuration directory named
+            <filename>myconf</filename>.
+            Changing the <filename>.templateconf</filename> as follows
+            causes the OpenEmbedded build system to look in your directory
+            and base its configuration files on the
+            <filename>*.sample</filename> configuration files it finds.
+            The final configuration files (i.e.
+            <filename>local.conf</filename> and
+            <filename>bblayers.conf</filename> ultimately still end up in
+            your Build Directory, but they are based on your
+            <filename>*.sample</filename> files.
+            <literallayout class='monospaced'>
+     TEMPLATECONF=${TEMPLATECONF:-meta-mylayer/myconf}
+            </literallayout>
+        </para>
+
+        <para>
+            Aside from the <filename>*.sample</filename> configuration files,
+            the <filename>conf-notes.txt</filename> also resides in the
+            default <filename>meta-yocto/conf</filename> directory.
+            The scripts that set up the build environment
+            (i.e.
+            <ulink url="&YOCTO_DOCS_REF_URL;#structure-core-script"><filename>&OE_INIT_FILE;</filename></ulink>
+            and
+            <ulink url="&YOCTO_DOCS_REF_URL;#structure-memres-core-script"><filename>oe-init-build-env-memres</filename></ulink>)
+            use this file to display BitBake targets as part of the script
+            output.
+            Customizing this <filename>conf-notes.txt</filename> file is a
+            good way to make sure your list of custom targets appears
+            as part of the script's output.
+        </para>
+
+        <para>
+            Here is the default list of targets displayed as a result of
+            running either of the setup scripts:
+            <literallayout class='monospaced'>
+     You can now run 'bitbake &lt;target&gt;'
+
+     Common targets are:
+         core-image-minimal
+         core-image-sato
+         meta-toolchain
+         adt-installer
+         meta-ide-support
+            </literallayout>
+        </para>
+
+        <para>
+            Changing the listed common targets is as easy as editing your
+            version of <filename>conf-notes.txt</filename> in your
+            custom template configuration directory and making sure you
+            have <filename>TEMPLATECONF</filename> set to your directory.
+        </para>
+    </section>
+
+    <section id='building-a-tiny-system'>
+        <title>Building a Tiny System</title>
+
+        <para>
+            Very small distributions have some significant advantages such
+            as requiring less on-die or in-package memory (cheaper), better
+            performance through efficient cache usage, lower power requirements
+            due to less memory, faster boot times, and reduced development
+            overhead.
+            Some real-world examples where a very small distribution gives
+            you distinct advantages are digital cameras, medical devices,
+            and small headless systems.
+        </para>
+
+        <para>
+            This section presents information that shows you how you can
+            trim your distribution to even smaller sizes than the
+            <filename>poky-tiny</filename> distribution, which is around
+            5 Mbytes, that can be built out-of-the-box using the Yocto Project.
+        </para>
+
+        <section id='tiny-system-overview'>
+            <title>Overview</title>
+
+            <para>
+                The following list presents the overall steps you need to
+                consider and perform to create distributions with smaller
+                root filesystems, achieve faster boot times, maintain your critical
+                functionality, and avoid initial RAM disks:
+                <itemizedlist>
+                    <listitem><para>
+                        <link linkend='goals-and-guiding-principles'>Determine your goals and guiding principles.</link>
+                        </para></listitem>
+                    <listitem><para>
+                        <link linkend='understand-what-gives-your-image-size'>Understand what contributes to your image size.</link>
+                        </para></listitem>
+                    <listitem><para>
+                        <link linkend='trim-the-root-filesystem'>Reduce the size of the root filesystem.</link>
+                        </para></listitem>
+                    <listitem><para>
+                        <link linkend='trim-the-kernel'>Reduce the size of the kernel.</link>
+                        </para></listitem>
+                    <listitem><para>
+                        <link linkend='remove-package-management-requirements'>Eliminate packaging requirements.</link>
+                        </para></listitem>
+                    <listitem><para>
+                        <link linkend='look-for-other-ways-to-minimize-size'>Look for other ways to minimize size.</link>
+                        </para></listitem>
+                    <listitem><para>
+                        <link linkend='iterate-on-the-process'>Iterate on the process.</link>
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='goals-and-guiding-principles'>
+            <title>Goals and Guiding Principles</title>
+
+            <para>
+                Before you can reach your destination, you need to know
+                where you are going.
+                Here is an example list that you can use as a guide when
+                creating very small distributions:
+                <itemizedlist>
+                    <listitem><para>Determine how much space you need
+                        (e.g. a kernel that is 1 Mbyte or less and
+                        a root filesystem that is 3 Mbytes or less).
+                        </para></listitem>
+                    <listitem><para>Find the areas that are currently
+                        taking 90% of the space and concentrate on reducing
+                        those areas.
+                        </para></listitem>
+                    <listitem><para>Do not create any difficult "hacks"
+                        to achieve your goals.</para></listitem>
+                    <listitem><para>Leverage the device-specific
+                        options.</para></listitem>
+                    <listitem><para>Work in a separate layer so that you
+                        keep changes isolated.
+                        For information on how to create layers, see
+                        the "<link linkend='understanding-and-creating-layers'>Understanding and Creating Layers</link>" section.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='understand-what-gives-your-image-size'>
+            <title>Understand What Contributes to Your Image Size</title>
+
+            <para>
+                It is easiest to have something to start with when creating
+                your own distribution.
+                You can use the Yocto Project out-of-the-box to create the
+                <filename>poky-tiny</filename> distribution.
+                Ultimately, you will want to make changes in your own
+                distribution that are likely modeled after
+                <filename>poky-tiny</filename>.
+                <note>
+                    To use <filename>poky-tiny</filename> in your build,
+                    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"
+                    as described in the
+                    "<link linkend='creating-your-own-distribution'>Creating Your Own Distribution</link>"
+                    section.
+                </note>
+            </para>
+
+            <para>
+                Understanding some memory concepts will help you reduce the
+                system size.
+                Memory consists of static, dynamic, and temporary memory.
+                Static memory is the TEXT (code), DATA (initialized data
+                in the code), and BSS (uninitialized data) sections.
+                Dynamic memory represents memory that is allocated at runtime:
+                stacks, hash tables, and so forth.
+                Temporary memory is recovered after the boot process.
+                This memory consists of memory used for decompressing
+                the kernel and for the <filename>__init__</filename>
+                functions.
+            </para>
+
+            <para>
+                To help you see where you currently are with kernel and root
+                filesystem sizes, you can use two tools found in the
+                <link linkend='source-directory'>Source Directory</link> in
+                the <filename>scripts/tiny/</filename> directory:
+                <itemizedlist>
+                    <listitem><para><filename>ksize.py</filename>: Reports
+                        component sizes for the kernel build objects.
+                        </para></listitem>
+                    <listitem><para><filename>dirsize.py</filename>: Reports
+                        component sizes for the root filesystem.</para></listitem>
+                </itemizedlist>
+                This next tool and command help you organize configuration
+                fragments and view file dependencies in a human-readable form:
+                <itemizedlist>
+                    <listitem><para><filename>merge_config.sh</filename>:
+                        Helps you manage configuration files and fragments
+                        within the kernel.
+                        With this tool, you can merge individual configuration
+                        fragments together.
+                        The tool allows you to make overrides and warns you
+                        of any missing configuration options.
+                        The tool is ideal for allowing you to iterate on
+                        configurations, create minimal configurations, and
+                        create configuration files for different machines
+                        without having to duplicate your process.</para>
+                        <para>The <filename>merge_config.sh</filename> script is
+                        part of the Linux Yocto kernel Git repositories
+                        (i.e. <filename>linux-yocto-3.14</filename>,
+                        <filename>linux-yocto-3.10</filename>,
+                        <filename>linux-yocto-3.8</filename>, and so forth)
+                        in the
+                        <filename>scripts/kconfig</filename> directory.</para>
+                        <para>For more information on configuration fragments,
+                        see the
+                        "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#generating-configuration-files'>Generating Configuration Files</ulink>"
+                        section of the Yocto Project Linux Kernel Development
+                        Manual and the "<link linkend='creating-config-fragments'>Creating Configuration Fragments</link>"
+                        section, which is in this manual.</para></listitem>
+                    <listitem><para><filename>bitbake -u depexp -g <replaceable>bitbake_target</replaceable></filename>:
+                        Using the BitBake command with these options brings up
+                        a Dependency Explorer from which you can view file
+                        dependencies.
+                        Understanding these dependencies allows you to make
+                        informed decisions when cutting out various pieces of the
+                        kernel and root filesystem.</para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='trim-the-root-filesystem'>
+            <title>Trim the Root Filesystem</title>
+
+            <para>
+                The root filesystem is made up of packages for booting,
+                libraries, and applications.
+                To change things, you can configure how the packaging happens,
+                which changes the way you build them.
+                You can also modify the filesystem itself or select a different
+                filesystem.
+            </para>
+
+            <para>
+                First, find out what is hogging your root filesystem by running the
+                <filename>dirsize.py</filename> script from your root directory:
+                <literallayout class='monospaced'>
+     $ cd <replaceable>root-directory-of-image</replaceable>
+     $ dirsize.py 100000 > dirsize-100k.log
+     $ cat dirsize-100k.log
+                </literallayout>
+                You can apply a filter to the script to ignore files under
+                a certain size.
+                The previous example filters out any files below 100 Kbytes.
+                The sizes reported by the tool are uncompressed, and thus
+                will be smaller by a relatively constant factor in a
+                compressed root filesystem.
+                When you examine your log file, you can focus on areas of the
+                root filesystem that take up large amounts of memory.
+            </para>
+
+            <para>
+                You need to be sure that what you eliminate does not cripple
+                the functionality you need.
+                One way to see how packages relate to each other is by using
+                the Dependency Explorer UI with the BitBake command:
+                <literallayout class='monospaced'>
+     $ cd <replaceable>image-directory</replaceable>
+     $ bitbake -u depexp -g <replaceable>image</replaceable>
+                </literallayout>
+                Use the interface to select potential packages you wish to
+                eliminate and see their dependency relationships.
+            </para>
+
+            <para>
+                When deciding how to reduce the size, get rid of packages that
+                result in minimal impact on the feature set.
+                For example, you might not need a VGA display.
+                Or, you might be able to get by with <filename>devtmpfs</filename>
+                and <filename>mdev</filename> instead of
+                <filename>udev</filename>.
+            </para>
+
+            <para>
+                Use your <filename>local.conf</filename> file to make changes.
+                For example, to eliminate <filename>udev</filename> and
+                <filename>glib</filename>, set the following in the
+                local configuration file:
+                <literallayout class='monospaced'>
+     VIRTUAL-RUNTIME_dev_manager = ""
+                </literallayout>
+            </para>
+
+            <para>
+                Finally, you should consider exactly the type of root
+                filesystem you need to meet your needs while also reducing
+                its size.
+                For example, consider <filename>cramfs</filename>,
+                <filename>squashfs</filename>, <filename>ubifs</filename>,
+                <filename>ext2</filename>, or an <filename>initramfs</filename>
+                using <filename>initramfs</filename>.
+                Be aware that <filename>ext3</filename> requires a 1 Mbyte
+                journal.
+                If you are okay with running read-only, you do not need this
+                journal.
+            </para>
+
+            <note>
+                After each round of elimination, you need to rebuild your
+                system and then use the tools to see the effects of your
+                reductions.
+            </note>
+
+
+        </section>
+
+        <section id='trim-the-kernel'>
+            <title>Trim the Kernel</title>
+
+            <para>
+                The kernel is built by including policies for hardware-independent
+                aspects.
+                What subsystems do you enable?
+                For what architecture are you building?
+                Which drivers do you build by default?
+                <note>You can modify the kernel source if you want to help
+                    with boot time.
+                </note>
+            </para>
+
+            <para>
+                Run the <filename>ksize.py</filename> script from the top-level
+                Linux build directory to get an idea of what is making up
+                the kernel:
+                <literallayout class='monospaced'>
+     $ cd <replaceable>top-level-linux-build-directory</replaceable>
+     $ ksize.py > ksize.log
+     $ cat ksize.log
+                </literallayout>
+                When you examine the log, you will see how much space is
+                taken up with the built-in <filename>.o</filename> files for
+                drivers, networking, core kernel files, filesystem, sound,
+                and so forth.
+                The sizes reported by the tool are uncompressed, and thus
+                will be smaller by a relatively constant factor in a compressed
+                kernel image.
+                Look to reduce the areas that are large and taking up around
+                the "90% rule."
+            </para>
+
+            <para>
+                To examine, or drill down, into any particular area, use the
+                <filename>-d</filename> option with the script:
+                <literallayout class='monospaced'>
+     $ ksize.py -d > ksize.log
+                </literallayout>
+                Using this option breaks out the individual file information
+                for each area of the kernel (e.g. drivers, networking, and
+                so forth).
+            </para>
+
+            <para>
+                Use your log file to see what you can eliminate from the kernel
+                based on features you can let go.
+                For example, if you are not going to need sound, you do not
+                need any drivers that support sound.
+            </para>
+
+            <para>
+                After figuring out what to eliminate, you need to reconfigure
+                the kernel to reflect those changes during the next build.
+                You could run <filename>menuconfig</filename> and make all your
+                changes at once.
+                However, that makes it difficult to see the effects of your
+                individual eliminations and also makes it difficult to replicate
+                the changes for perhaps another target device.
+                A better method is to start with no configurations using
+                <filename>allnoconfig</filename>, create configuration
+                fragments for individual changes, and then manage the
+                fragments into a single configuration file using
+                <filename>merge_config.sh</filename>.
+                The tool makes it easy for you to iterate using the
+                configuration change and build cycle.
+            </para>
+
+            <para>
+                Each time you make configuration changes, you need to rebuild
+                the kernel and check to see what impact your changes had on
+                the overall size.
+            </para>
+        </section>
+
+        <section id='remove-package-management-requirements'>
+            <title>Remove Package Management Requirements</title>
+
+            <para>
+                Packaging requirements add size to the image.
+                One way to reduce the size of the image is to remove all the
+                packaging requirements from the image.
+                This reduction includes both removing the package manager
+                and its unique dependencies as well as removing the package
+                management data itself.
+            </para>
+
+            <para>
+                To eliminate all the packaging requirements for an image,
+                be sure that "package-management" is not part of your
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></ulink>
+                statement for the image.
+                When you remove this feature, you are removing the package
+                manager as well as its dependencies from the root filesystem.
+            </para>
+        </section>
+
+        <section id='look-for-other-ways-to-minimize-size'>
+            <title>Look for Other Ways to Minimize Size</title>
+
+            <para>
+                Depending on your particular circumstances, other areas that you
+                can trim likely exist.
+                The key to finding these areas is through tools and methods
+                described here combined with experimentation and iteration.
+                Here are a couple of areas to experiment with:
+                <itemizedlist>
+                    <listitem><para><filename>glibc</filename>:
+                        In general, follow this process:
+                        <orderedlist>
+                            <listitem><para>Remove <filename>glibc</filename>
+                                features from
+                                <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></ulink>
+                                that you think you do not need.</para></listitem>
+                            <listitem><para>Build your distribution.
+                                </para></listitem>
+                            <listitem><para>If the build fails due to missing
+                                symbols in a package, determine if you can
+                                reconfigure the package to not need those
+                                features.
+                                For example, change the configuration to not
+                                support wide character support as is done for
+                                <filename>ncurses</filename>.
+                                Or, if support for those characters is needed,
+                                determine what <filename>glibc</filename>
+                                features provide the support and restore the
+                                configuration.
+                                </para></listitem>
+                            <listitem><para>Rebuild and repeat the process.
+                                </para></listitem>
+                        </orderedlist></para></listitem>
+                    <listitem><para><filename>busybox</filename>:
+                        For BusyBox, use a process similar as described for
+                        <filename>glibc</filename>.
+                        A difference is you will need to boot the resulting
+                        system to see if you are able to do everything you
+                        expect from the running system.
+                        You need to be sure to integrate configuration fragments
+                        into Busybox because BusyBox handles its own core
+                        features and then allows you to add configuration
+                        fragments on top.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='iterate-on-the-process'>
+            <title>Iterate on the Process</title>
+
+            <para>
+                If you have not reached your goals on system size, you need
+                to iterate on the process.
+                The process is the same.
+                Use the tools and see just what is taking up 90% of the root
+                filesystem and the kernel.
+                Decide what you can eliminate without limiting your device
+                beyond what you need.
+            </para>
+
+            <para>
+                Depending on your system, a good place to look might be
+                Busybox, which provides a stripped down
+                version of Unix tools in a single, executable file.
+                You might be able to drop virtual terminal services or perhaps
+                ipv6.
+            </para>
+        </section>
+    </section>
+
+    <section id='working-with-packages'>
+        <title>Working with Packages</title>
+
+        <para>
+            This section describes a few tasks that involve packages:
+            <itemizedlist>
+                <listitem><para>
+                    <link linkend='excluding-packages-from-an-image'>Excluding packages from an image</link>
+                    </para></listitem>
+                <listitem><para>
+                    <link linkend='incrementing-a-package-revision-number'>Incrementing a package revision number</link>
+                    </para></listitem>
+                <listitem><para>
+                    <link linkend='usingpoky-configuring-DISTRO_PN_ALIAS'>Handling a package name alias</link>
+                    </para></listitem>
+                <listitem><para>
+                    <link linkend='handling-optional-module-packaging'>Handling optional module packaging</link>
+                    </para></listitem>
+                <listitem><para>
+                    <link linkend='using-runtime-package-management'>Using Runtime Package Management</link>
+                    </para></listitem>
+                <listitem><para>
+                    <link linkend='testing-packages-with-ptest'>Setting up and running package test (ptest)</link>
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+
+        <section id='excluding-packages-from-an-image'>
+            <title>Excluding Packages from an Image</title>
+
+            <para>
+                You might find it necessary to prevent specific packages
+                from being installed into an image.
+                If so, you can use several variables to direct the build
+                system to essentially ignore installing recommended packages
+                or to not install a package at all.
+            </para>
+
+            <para>
+                The following list introduces variables you can use to
+                prevent packages from being installed into your image.
+                Each of these variables only works with IPK and RPM
+                package types.
+                Support for Debian packages does not exist.
+                Also, you can use these variables from your
+                <filename>local.conf</filename> file or attach them to a
+                specific image recipe by using a recipe name override.
+                For more detail on the variables, see the descriptions in the
+                Yocto Project Reference Manual's glossary chapter.
+                <itemizedlist>
+                    <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-BAD_RECOMMENDATIONS'><filename>BAD_RECOMMENDATIONS</filename></ulink>:
+                        Use this variable to specify "recommended-only"
+                        packages that you do not want installed.
+                        </para></listitem>
+                    <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-NO_RECOMMENDATIONS'><filename>NO_RECOMMENDATIONS</filename></ulink>:
+                        Use this variable to prevent all "recommended-only"
+                        packages from being installed.
+                        </para></listitem>
+                    <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_EXCLUDE'><filename>PACKAGE_EXCLUDE</filename></ulink>:
+                        Use this variable to prevent specific packages from
+                        being installed regardless of whether they are
+                        "recommended-only" or not.
+                        You need to realize that the build process could
+                        fail with an error when you
+                        prevent the installation of a package whose presence
+                        is required by an installed package.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='incrementing-a-package-revision-number'>
+            <title>Incrementing a Package Revision Number</title>
+
+            <para>
+                If a committed change results in changing the package output,
+                then the value of the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>
+                variable needs to be increased (or "bumped").
+                Increasing <filename>PR</filename> occurs one of two ways:
+                <itemizedlist>
+                    <listitem><para>Automatically using a Package Revision
+                        Service (PR Service).</para></listitem>
+                    <listitem><para>Manually incrementing the
+                        <filename>PR</filename> variable.</para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                Given that one of the challenges any build system and its
+                users face is how to maintain a package feed that is compatible
+                with existing package manager applications such as
+                RPM, APT, and OPKG, using an automated system is much
+                preferred over a manual system.
+                In either system, the main requirement is that version
+                numbering increases in a linear fashion and that a number of
+                version components exist that support that linear progression.
+            </para>
+
+            <para>
+                The following two sections provide information on the PR Service
+                and on manual <filename>PR</filename> bumping.
+            </para>
+
+            <section id='working-with-a-pr-service'>
+                <title>Working With a PR Service</title>
+
+                <para>
+                    As mentioned, attempting to maintain revision numbers in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                    is error prone, inaccurate, and causes problems for people
+                    submitting recipes.
+                    Conversely, the PR Service automatically generates
+                    increasing numbers, particularly the revision field,
+                    which removes the human element.
+                    <note>
+                        For additional information on using a PR Service, you
+                        can see the
+                        <ulink url='&YOCTO_WIKI_URL;/wiki/PR_Service'>PR Service</ulink>
+                        wiki page.
+                    </note>
+                </para>
+
+                <para>
+                    The Yocto Project uses variables in order of
+                    decreasing priority to facilitate revision numbering (i.e.
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PE'><filename>PE</filename></ulink>,
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>, and
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>
+                    for epoch, version, and revision, respectively).
+                    The values are highly dependent on the policies and
+                    procedures of a given distribution and package feed.
+                </para>
+
+                <para>
+                    Because the OpenEmbedded build system uses
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#checksums'>signatures</ulink>",
+                    which are unique to a given build, the build system
+                    knows when to rebuild packages.
+                    All the inputs into a given task are represented by a
+                    signature, which can trigger a rebuild when different.
+                    Thus, the build system itself does not rely on the
+                    <filename>PR</filename> numbers to trigger a rebuild.
+                    The signatures, however, can be used to generate
+                    <filename>PR</filename> values.
+                </para>
+
+                <para>
+                    The PR Service works with both
+                    <filename>OEBasic</filename> and
+                    <filename>OEBasicHash</filename> generators.
+                    The value of <filename>PR</filename> bumps when the
+                    checksum changes and the different generator mechanisms
+                    change signatures under different circumstances.
+                </para>
+
+                <para>
+                    As implemented, the build system includes values from
+                    the PR Service into the <filename>PR</filename> field as
+                    an addition using the form "<filename>.x</filename>" so
+                    <filename>r0</filename> becomes <filename>r0.1</filename>,
+                    <filename>r0.2</filename> and so forth.
+                    This scheme allows existing <filename>PR</filename> values
+                    to be used for whatever reasons, which include manual
+                    <filename>PR</filename> bumps, should it be necessary.
+                </para>
+
+                <para>
+                    By default, the PR Service is not enabled or running.
+                    Thus, the packages generated are just "self consistent".
+                    The build system adds and removes packages and
+                    there are no guarantees about upgrade paths but images
+                    will be consistent and correct with the latest changes.
+                </para>
+
+                <para>
+                    The simplest form for a PR Service is for it to exist
+                    for a single host development system that builds the
+                    package feed (building system).
+                    For this scenario, you can enable a local PR Service by
+                    setting
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PRSERV_HOST'><filename>PRSERV_HOST</filename></ulink>
+                    in your <filename>local.conf</filename> file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
+                    <literallayout class='monospaced'>
+     PRSERV_HOST = "localhost:0"
+                    </literallayout>
+                    Once the service is started, packages will automatically
+                    get increasing <filename>PR</filename> values and
+                    BitBake will take care of starting and stopping the server.
+                </para>
+
+                <para>
+                    If you have a more complex setup where multiple host
+                    development systems work against a common, shared package
+                    feed, you have a single PR Service running and it is
+                    connected to each building system.
+                    For this scenario, you need to start the PR Service using
+                    the <filename>bitbake-prserv</filename> command:
+                    <literallayout class='monospaced'>
+     bitbake-prserv &dash;&dash;host <replaceable>ip</replaceable> &dash;&dash;port <replaceable>port</replaceable> &dash;&dash;start
+                    </literallayout>
+                    In addition to hand-starting the service, you need to
+                    update the <filename>local.conf</filename> file of each
+                    building system as described earlier so each system
+                    points to the server and port.
+                </para>
+
+                <para>
+                    It is also recommended you use build history, which adds
+                    some sanity checks to package versions, in conjunction with
+                    the server that is running the PR Service.
+                    To enable build history, add the following to each building
+                    system's <filename>local.conf</filename> file:
+                    <literallayout class='monospaced'>
+     # It is recommended to activate "buildhistory" for testing the PR service
+     INHERIT += "buildhistory"
+     BUILDHISTORY_COMMIT = "1"
+                    </literallayout>
+                    For information on build history, see the
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#maintaining-build-output-quality'>Maintaining Build Output Quality</ulink>"
+                    section in the Yocto Project Reference Manual.
+                </para>
+
+                <note>
+                    <para>The OpenEmbedded build system does not maintain
+                    <filename>PR</filename> information as part of the
+                    shared state (sstate) packages.
+                    If you maintain an sstate feed, its expected that either
+                    all your building systems that contribute to the sstate
+                    feed use a shared PR Service, or you do not run a PR
+                    Service on any of your building systems.
+                    Having some systems use a PR Service while others do
+                    not leads to obvious problems.</para>
+                    <para>For more information on shared state, see the
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#shared-state-cache'>Shared State Cache</ulink>"
+                    section in the Yocto Project Reference Manual.</para>
+                </note>
+            </section>
+
+            <section id='manually-bumping-pr'>
+                <title>Manually Bumping PR</title>
+
+                <para>
+                    The alternative to setting up a PR Service is to manually
+                    bump the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>
+                    variable.
+                </para>
+
+                <para>
+                    If a committed change results in changing the package output,
+                    then the value of the PR variable needs to be increased
+                    (or "bumped") as part of that commit.
+                    For new recipes you should add the <filename>PR</filename>
+                    variable and set its initial value equal to "r0", which is the default.
+                    Even though the default value is "r0", the practice of adding it to a new recipe makes
+                    it harder to forget to bump the variable when you make changes
+                    to the recipe in future.
+                </para>
+
+                <para>
+                    If you are sharing a common <filename>.inc</filename> file with multiple recipes,
+                    you can also use the
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-INC_PR'>INC_PR</ulink></filename>
+                    variable to ensure that
+                    the recipes sharing the <filename>.inc</filename> file are rebuilt when the
+                    <filename>.inc</filename> file itself is changed.
+                    The <filename>.inc</filename> file must set <filename>INC_PR</filename>
+                    (initially to "r0"), and all recipes referring to it should set <filename>PR</filename>
+                    to "$(INC_PR).0" initially, incrementing the last number when the recipe is changed.
+                    If the <filename>.inc</filename> file is changed then its
+                    <filename>INC_PR</filename> should be incremented.
+                </para>
+
+                <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
+                    <filename>INC_PR</filename>).
+                </para>
+
+                <para>
+                    Usually, version increases occur only to packages.
+                    However, if for some reason <filename>PV</filename> changes but does not
+                    increase, you can increase the
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PE'>PE</ulink></filename>
+                    variable (Package Epoch).
+                    The <filename>PE</filename> variable defaults to "0".
+                </para>
+
+                <para>
+                    Version numbering strives to follow the
+                    <ulink url='http://www.debian.org/doc/debian-policy/ch-controlfields.html'>
+                    Debian Version Field Policy Guidelines</ulink>.
+                    These guidelines define how versions are compared and what "increasing" a version means.
+                </para>
+            </section>
+        </section>
+
+        <section id="usingpoky-configuring-DISTRO_PN_ALIAS">
+            <title>Handling a Package Name Alias</title>
+            <para>
+                Sometimes a package name you are using might exist under
+                an alias or as a similarly named package in a different
+                distribution.
+                The OpenEmbedded build system implements a
+                <filename>do_distro_check</filename>
+                task that automatically connects to major distributions
+                and checks for these situations.
+                If the package exists under a different name in a different
+                distribution, you get a <filename>distro_check</filename>
+                mismatch.
+                You can resolve this problem by defining a per-distro recipe
+                name alias using the
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_PN_ALIAS'>DISTRO_PN_ALIAS</ulink></filename>
+                variable.
+            </para>
+
+            <para>
+                Following is an example that shows how you specify the <filename>DISTRO_PN_ALIAS</filename>
+                variable:
+                <literallayout class='monospaced'>
+     DISTRO_PN_ALIAS_pn-PACKAGENAME = "distro1=package_name_alias1 \
+                                       distro2=package_name_alias2 \
+                                       distro3=package_name_alias3 \
+                                       ..."
+                </literallayout>
+            </para>
+
+            <para>
+                If you have more than one distribution alias, separate them with a space.
+                Note that the build system currently automatically checks the
+                Fedora, OpenSUSE, Debian, Ubuntu,
+                and Mandriva distributions for source package recipes without having to specify them
+                using the <filename>DISTRO_PN_ALIAS</filename> variable.
+                For example, the following command generates a report that lists the Linux distributions
+                that include the sources for each of the recipes.
+                <literallayout class='monospaced'>
+     $ 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
+                <link linkend='source-directory'>Source Directory</link>.
+            </para>
+        </section>
+
+        <section id='handling-optional-module-packaging'>
+            <title>Handling Optional Module Packaging</title>
+
+            <para>
+                Many pieces of software split functionality into optional
+                modules (or plug-ins) and the plug-ins that are built
+                might depend on configuration options.
+                To avoid having to duplicate the logic that determines what
+                modules are available in your recipe or to avoid having
+                to package each module by hand, the OpenEmbedded build system
+                provides functionality to handle module packaging dynamically.
+            </para>
+
+            <para>
+                To handle optional module packaging, you need to do two things:
+                <itemizedlist>
+                    <listitem><para>Ensure the module packaging is actually
+                        done.</para></listitem>
+                    <listitem><para>Ensure that any dependencies on optional
+                        modules from other recipes are satisfied by your recipe.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <section id='making-sure-the-packaging-is-done'>
+                <title>Making Sure the Packaging is Done</title>
+
+                <para>
+                    To ensure the module packaging actually gets done, you use
+                    the <filename>do_split_packages</filename> function within
+                    the <filename>populate_packages</filename> Python function
+                    in your recipe.
+                    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
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>
+                    variable and setting the appropriate values for
+                    <filename>FILES_packagename</filename>,
+                    <filename>RDEPENDS_packagename</filename>,
+                    <filename>DESCRIPTION_packagename</filename>, and so forth.
+                    Here is an example from the <filename>lighttpd</filename>
+                    recipe:
+                    <literallayout class='monospaced'>
+     python populate_packages_prepend () {
+         lighttpd_libdir = d.expand('${libdir}')
+         do_split_packages(d, lighttpd_libdir, '^mod_(.*)\.so$',
+                          'lighttpd-module-%s', 'Lighttpd module for %s',
+                           extra_depends='')
+     }
+                    </literallayout>
+                    The previous example specifies a number of things in the
+                    call to <filename>do_split_packages</filename>.
+                    <itemizedlist>
+                        <listitem><para>A directory within the files installed
+                            by your recipe through <filename>do_install</filename>
+                            in which to search.</para></listitem>
+                        <listitem><para>A regular expression used to match module
+                            files in that directory.
+                            In the example, note the parentheses () that mark
+                            the part of the expression from which the module
+                            name should be derived.</para></listitem>
+                        <listitem><para>A pattern to use for the package names.
+                            </para></listitem>
+                        <listitem><para>A description for each package.
+                            </para></listitem>
+                        <listitem><para>An empty string for
+                            <filename>extra_depends</filename>, which disables
+                            the default dependency on the main
+                            <filename>lighttpd</filename> package.
+                            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
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-DESCRIPTION'><filename>DESCRIPTION</filename></ulink>
+                            is set to "Lighttpd module for alias".</para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    Often, packaging modules is as simple as the previous
+                    example.
+                    However, more advanced options exist that you can use
+                    within <filename>do_split_packages</filename> to modify its
+                    behavior.
+                    And, if you need to, you can add more logic by specifying
+                    a hook function that is called for each package.
+                    It is also perfectly acceptable to call
+                    <filename>do_split_packages</filename> multiple times if
+                    you have more than one set of modules to package.
+                </para>
+
+                <para>
+                    For more examples that show how to use
+                    <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>
+                    <link linkend='yocto-project-repositories'>source repository</link>.
+                    You can also find examples in
+                    <filename>meta/classes/kernel.bbclass</filename>.
+                 </para>
+
+                 <para>
+                     Following is a reference that shows
+                     <filename>do_split_packages</filename> mandatory and
+                     optional arguments:
+                     <literallayout class='monospaced'>
+     Mandatory arguments
+
+     root
+        The path in which to search
+     file_regex
+        Regular expression to match searched files.
+        Use parentheses () to mark the part of this
+        expression that should be used to derive the
+        module name (to be substituted where %s is
+        used in other function arguments as noted below)
+     output_pattern
+        Pattern to use for the package names. Must
+        include %s.
+     description
+        Description to set for each package. Must
+        include %s.
+
+     Optional arguments
+
+     postinst
+        Postinstall script to use for all packages
+        (as a string)
+     recursive
+        True to perform a recursive search - default
+        False
+     hook
+        A hook function to be called for every match.
+        The function will be called with the following
+        arguments (in the order listed):
+
+        f
+           Full path to the file/directory match
+        pkg
+           The package name
+        file_regex
+           As above
+        output_pattern
+           As above
+        modulename
+           The module name derived using file_regex
+
+     extra_depends
+        Extra runtime dependencies (RDEPENDS) to be
+        set for all packages. The default value of None
+        causes a dependency on the main package
+        (${PN}) - if you do not want this, pass empty
+        string '' for this parameter.
+     aux_files_pattern
+        Extra item(s) to be added to FILES for each
+        package. Can be a single string item or a list
+        of strings for multiple items. Must include %s.
+     postrm
+        postrm script to use for all packages (as a
+        string)
+     allow_dirs
+        True to allow directories to be matched -
+        default False
+     prepend
+        If True, prepend created packages to PACKAGES
+        instead of the default False which appends them
+     match_path
+        match file_regex on the whole relative path to
+        the root rather than just the file name
+     aux_files_pattern_verbatim
+        Extra item(s) to be added to FILES for each
+        package, using the actual derived module name
+        rather than converting it to something legal
+        for a package name. Can be a single string item
+        or a list of strings for multiple items. Must
+        include %s.
+     allow_links
+        True to allow symlinks to be matched - default
+        False
+     summary
+        Summary to set for each package. Must include %s;
+        defaults to description if not set.
+                     </literallayout>
+                 </para>
+            </section>
+
+            <section id='satisfying-dependencies'>
+                <title>Satisfying Dependencies</title>
+
+                <para>
+                    The second part for handling optional module packaging
+                    is to ensure that any dependencies on optional modules
+                    from other recipes are satisfied by your recipe.
+                    You can be sure these dependencies are satisfied by
+                    using the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES_DYNAMIC'><filename>PACKAGES_DYNAMIC</filename></ulink> variable.
+                    Here is an example that continues with the
+                    <filename>lighttpd</filename> recipe shown earlier:
+                    <literallayout class='monospaced'>
+     PACKAGES_DYNAMIC = "lighttpd-module-.*"
+                    </literallayout>
+                    The name specified in the regular expression can of
+                    course be anything.
+                    In this example, it is <filename>lighttpd-module-</filename>
+                    and is specified as the prefix to ensure that any
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-RDEPENDS'><filename>RDEPENDS</filename></ulink>
+                    and <ulink url='&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS'><filename>RRECOMMENDS</filename></ulink>
+                    on a package name starting with the prefix are satisfied
+                    during build time.
+                    If you are using <filename>do_split_packages</filename>
+                    as described in the previous section, the value you put in
+                    <filename>PACKAGES_DYNAMIC</filename> should correspond to
+                    the name pattern specified in the call to
+                    <filename>do_split_packages</filename>.
+                </para>
+            </section>
+        </section>
+
+        <section id='using-runtime-package-management'>
+            <title>Using Runtime Package Management</title>
+
+            <para>
+                During a build, BitBake always transforms a recipe into one or
+                more packages.
+                For example, BitBake takes the <filename>bash</filename> recipe
+                and currently produces the <filename>bash-dbg</filename>,
+                <filename>bash-staticdev</filename>,
+                <filename>bash-dev</filename>, <filename>bash-doc</filename>,
+                <filename>bash-locale</filename>, and
+                <filename>bash</filename> packages.
+                Not all generated packages are included in an image.
+            </para>
+
+            <para>
+                In several situations, you might need to update, add, remove,
+                or query the packages on a target device at runtime
+                (i.e. without having to generate a new image).
+                Examples of such situations include:
+                <itemizedlist>
+                    <listitem><para>
+                        You want to provide in-the-field updates to deployed
+                        devices (e.g. security updates).
+                        </para></listitem>
+                    <listitem><para>
+                        You want to have a fast turn-around development cycle
+                        for one or more applications that run on your device.
+                        </para></listitem>
+                    <listitem><para>
+                        You want to temporarily install the "debug" packages
+                        of various applications on your device so that
+                        debugging can be greatly improved by allowing
+                        access to symbols and source debugging.
+                        </para></listitem>
+                    <listitem><para>
+                        You want to deploy a more minimal package selection of
+                        your device but allow in-the-field updates to add a
+                        larger selection for customization.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                In all these situations, you have something similar to a more
+                traditional Linux distribution in that in-field devices
+                are able to receive pre-compiled packages from a server for
+                installation or update.
+                Being able to install these packages on a running,
+                in-field device is what is termed "runtime package
+                management".
+            </para>
+
+            <para>
+                In order to use runtime package management, you
+                need a host/server machine that serves up the pre-compiled
+                packages plus the required metadata.
+                You also need package manipulation tools on the target.
+                The build machine is a likely candidate to act as the server.
+                However, that machine does not necessarily have to be the
+                package server.
+                The build machine could push its artifacts to another machine
+                that acts as the server (e.g. Internet-facing).
+            </para>
+
+            <para>
+                A simple build that targets just one device produces
+                more than one package database.
+                In other words, the packages produced by a build are separated
+                out into a couple of different package groupings based on
+                criteria such as the target's CPU architecture, the target
+                board, or the C library used on the target.
+                For example, a build targeting the <filename>qemuarm</filename>
+                device produces the following three package databases:
+                <filename>all</filename>, <filename>armv5te</filename>, and
+                <filename>qemuarm</filename>.
+                If you wanted your <filename>qemuarm</filename> device to be
+                aware of all the packages that were available to it,
+                you would need to point it to each of these databases
+                individually.
+                In a similar way, a traditional Linux distribution usually is
+                configured to be aware of a number of software repositories
+                from which it retrieves packages.
+            </para>
+
+            <para>
+                Using runtime package management is completely optional and
+                not required for a successful build or deployment in any
+                way.
+                But if you want to make use of runtime package management,
+                you need to do a couple things above and beyond the basics.
+                The remainder of this section describes what you need to do.
+            </para>
+
+            <section id='runtime-package-management-build'>
+                <title>Build Considerations</title>
+
+                <para>
+                    This section describes build considerations that you need
+                    to be aware of in order to provide support for runtime
+                    package management.
+                </para>
+
+                <para>
+                    When BitBake generates packages it needs to know
+                    what format or formats to use.
+                    In your configuration, you use the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink>
+                    variable to specify the format.
+                    <note>
+                        You can choose to have more than one format but you must
+                        provide at least one.
+                    </note>
+                </para>
+
+                <para>
+                    If you would like your image to start off with a basic
+                    package database of the packages in your current build
+                    as well as have the relevant tools available on the
+                    target for runtime package management, you can include
+                    "package-management" in the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></ulink>
+                    variable.
+                    Including "package-management" in this
+                    configuration variable ensures that when the image
+                    is assembled for your target, the image includes
+                    the currently-known package databases as well as
+                    the target-specific tools required for runtime
+                    package management to be performed on the target.
+                    However, this is not strictly necessary.
+                    You could start your image off without any databases
+                    but only include the required on-target package
+                    tool(s).
+                    As an example, you could include "opkg" in your
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></ulink>
+                    variable if you are using the IPK package format.
+                    You can then initialize your target's package database(s)
+                    later once your image is up and running.
+                </para>
+
+                <para>
+                    Whenever you perform any sort of build step that can
+                    potentially generate a package or modify an existing
+                    package, it is always a good idea to re-generate the
+                    package index with:
+                    <literallayout class='monospaced'>
+    $ bitbake package-index
+                    </literallayout>
+                    Realize that it is not sufficient to simply do the
+                    following:
+                    <literallayout class='monospaced'>
+    $ bitbake <replaceable>some-package</replaceable> package-index
+                    </literallayout>
+                    This is because BitBake does not properly schedule the
+                    <filename>package-index</filename> target fully after any
+                    other target has completed.
+                    Thus, be sure to run the package update step separately.
+                </para>
+
+                <para>
+                    As described below in the
+                    "<link linkend='runtime-package-management-target-ipk'>Using IPK</link>"
+                    section, if you are using IPK as your package format, you
+                    can make use of the
+                    <filename>distro-feed-configs</filename> recipe provided
+                    by <filename>meta-oe</filename> in order to configure your
+                    target to use your IPK databases.
+                </para>
+
+                <para>
+                    When your build is complete, your packages reside in the
+                    <filename>${TMPDIR}/deploy/<replaceable>package-format</replaceable></filename>
+                    directory.
+                    For example, if <filename>${TMPDIR}</filename>
+                    is <filename>tmp</filename> and your selected package type
+                    is IPK, then your IPK packages are available in
+                    <filename>tmp/deploy/ipk</filename>.
+                </para>
+            </section>
+
+            <section id='runtime-package-management-server'>
+                <title>Host or Server Machine Setup</title>
+
+                <para>
+                    Typically, packages are served from a server using
+                    HTTP.
+                    However, other protocols are possible.
+                    If you want to use HTTP, then setup and configure a
+                    web server, such as Apache 2 or lighttpd, on the machine
+                    serving the packages.
+                </para>
+
+                <para>
+                    As previously mentioned, the build machine can act as the
+                    package server.
+                    In the following sections that describe server machine
+                    setups, the build machine is assumed to also be the server.
+                </para>
+
+                <section id='package-server-apache'>
+                    <title>Serving Packages via Apache 2</title>
+
+                    <para>
+                        This example assumes you are using the Apache 2
+                        server:
+                        <orderedlist>
+                            <listitem><para>
+                                Add the directory to your Apache
+                                configuration, which you can find at
+                                <filename>/etc/httpd/conf/httpd.conf</filename>.
+                                Use commands similar to these on the
+                                development system.
+                                These example commands assume a top-level
+                                <link linkend='source-directory'>Source Directory</link>
+                                named <filename>poky</filename> in your home
+                                directory.
+                                The example also assumes an RPM package type.
+                                If you are using a different package type, such
+                                as IPK, use "ipk" in the pathnames:
+                                <literallayout class='monospaced'>
+     &lt;VirtualHost *:80&gt;
+       ....
+         Alias /rpm ~/poky/build/tmp/deploy/rpm
+         &lt;Directory "~/poky/build/tmp/deploy/rpm"&gt;
+           Options +Indexes
+         &lt;/Directory&gt;
+     &lt;/VirtualHost&gt;
+                                </literallayout></para></listitem>
+                            <listitem><para>
+                                Reload the Apache configuration as described
+                                in this step.
+                                For all commands, be sure you have root
+                                privileges.
+                                </para>
+
+                                <para>
+                                If your development system is using Fedora or
+                                CentOS, use the following:
+                                <literallayout class='monospaced'>
+     # service httpd reload
+                                </literallayout>
+                                For Ubuntu and Debian, use the following:
+                                <literallayout class='monospaced'>
+     # /etc/init.d/apache2 reload
+                                </literallayout>
+                                For OpenSUSE, use the following:
+                                <literallayout class='monospaced'>
+     # /etc/init.d/apache2 reload
+                                </literallayout></para></listitem>
+                            <listitem><para>
+                                If you are using Security-Enhanced Linux
+                                (SELinux), you need to label the files as
+                                being accessible through Apache.
+                                Use the following command from the development
+                                host.
+                                This example assumes RPM package types:
+                                <literallayout class='monospaced'>
+     # chcon -R -h -t httpd_sys_content_t tmp/deploy/rpm
+                                </literallayout></para></listitem>
+                        </orderedlist>
+                    </para>
+                </section>
+
+                <section id='package-server-lighttpd'>
+                    <title>Serving Packages via lighttpd</title>
+
+                    <para>
+                        If you are using lighttpd, all you need
+                        to do is to provide a link from your
+                        <filename>${TMPDIR}/deploy/<replaceable>package-format</replaceable></filename>
+                        directory to lighttpd's document-root.
+                        You can determine the specifics of your lighttpd
+                        installation by looking through its configuration file,
+                        which is usually found at:
+                        <filename>/etc/lighttpd/lighttpd.conf</filename>.
+                    </para>
+
+                    <para>
+                        For example, if you are using IPK, lighttpd's
+                        document-root is set to
+                        <filename>/var/www/lighttpd</filename>, and you had
+                        packages for a target named "BOARD",
+                        then you might create a link from your build location
+                        to lighttpd's document-root as follows:
+                        <literallayout class='monospaced'>
+    # ln -s $(PWD)/tmp/deploy/ipk /var/www/lighttpd/BOARD-dir
+                        </literallayout>
+                    </para>
+
+                    <para>
+                        At this point, you need to start the lighttpd server.
+                        The method used to start the server varies by
+                        distribution.
+                        However, one basic method that starts it by hand is:
+                        <literallayout class='monospaced'>
+    # lighttpd -f /etc/lighttpd/lighttpd.conf
+                        </literallayout>
+                    </para>
+                </section>
+            </section>
+
+            <section id='runtime-package-management-target'>
+                <title>Target Setup</title>
+
+                <para>
+                    Setting up the target differs depending on the
+                    package management system.
+                    This section provides information for RPM and IPK.
+                </para>
+
+                <section id='runtime-package-management-target-rpm'>
+                    <title>Using RPM</title>
+
+                    <para>
+                        The application for performing runtime package
+                        management of RPM packages on the target is called
+                        <filename>smart</filename>.
+                    </para>
+
+                    <para>
+                        On the target machine, you need to inform
+                        <filename>smart</filename> of every package database
+                        you want to use.
+                        As an example, suppose your target device can use the
+                        following three package databases from a server named
+                        <filename>server.name</filename>:
+                        <filename>all</filename>, <filename>i586</filename>,
+                        and <filename>qemux86</filename>.
+                        Given this example, issue the following commands on the
+                        target:
+                        <literallayout class='monospaced'>
+     # smart channel &dash;&dash;add all type=rpm-md baseurl=http://server.name/rpm/all
+     # smart channel &dash;&dash;add i585 type=rpm-md baseurl=http://server.name/rpm/i586
+     # smart channel &dash;&dash;add qemux86 type=rpm-md baseurl=http://server.name/rpm/qemux86
+                        </literallayout>
+                        Also from the target machine, fetch the repository
+                        information using this command:
+                        <literallayout class='monospaced'>
+     # smart update
+                        </literallayout>
+                        You can now use the <filename>smart query</filename>
+                        and <filename>smart install</filename> commands to
+                        find and install packages from the repositories.
+                    </para>
+                </section>
+
+                <section id='runtime-package-management-target-ipk'>
+                    <title>Using IPK</title>
+
+                    <para>
+                        The application for performing runtime package
+                        management of IPK packages on the target is called
+                        <filename>opkg</filename>.
+                    </para>
+
+                    <para>
+                        In order to inform <filename>opkg</filename> of the
+                        package databases you want to use, simply create one
+                        or more <filename>*.conf</filename> files in the
+                        <filename>/etc/opkg</filename> directory on the target.
+                        The <filename>opkg</filename> application uses them
+                        to find its available package databases.
+                        As an example, suppose you configured your HTTP server
+                        on your machine named
+                        <filename>www.mysite.com</filename> to serve files
+                        from a <filename>BOARD-dir</filename> directory under
+                        its document-root.
+                        In this case, you might create a configuration
+                        file on the target called
+                        <filename>/etc/opkg/base-feeds.conf</filename> that
+                        contains:
+                        <literallayout class='monospaced'>
+     src/gz all http://www.mysite.com/BOARD-dir/all
+     src/gz armv7a http://www.mysite.com/BOARD-dir/armv7a
+     src/gz beaglebone http://www.mysite.com/BOARD-dir/beaglebone
+                        </literallayout>
+                    </para>
+
+                    <para>
+                        As a way of making it easier to generate and make
+                        these IPK configuration files available on your
+                        target, simply define
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-FEED_DEPLOYDIR_BASE_URI'><filename>FEED_DEPLOYDIR_BASE_URI</filename></ulink>
+                        to point to your server and the location within the
+                        document-root which contains the databases.
+                        For example: if you are serving your packages over
+                        HTTP, your server's IP address is 192.168.7.1, and
+                        your databases are located in a directory called
+                        <filename>BOARD-dir</filename> underneath your HTTP
+                        server's document-root, you need to set
+                        <filename>FEED_DEPLOYDIR_BASE_URI</filename> to
+                        <filename>http://192.168.7.1/BOARD-dir</filename> and
+                        a set of configuration files will be generated for you
+                        in your target to work with this feed.
+                    </para>
+
+                    <para>
+                        On the target machine, fetch (or refresh) the
+                        repository information using this command:
+                        <literallayout class='monospaced'>
+     # opkg update
+                        </literallayout>
+                        You can now use the <filename>opkg list</filename> and
+                        <filename>opkg install</filename> commands to find and
+                        install packages from the repositories.
+                    </para>
+                </section>
+            </section>
+        </section>
+
+        <section id='testing-packages-with-ptest'>
+            <title>Testing Packages With ptest</title>
+
+            <para>
+                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 shell script (<filename>run-ptest</filename>) that starts
+                the test.
+                The shell script that starts the test must not contain
+                the actual test - the script only starts the test.
+                On the other hand, the test can be anything from a simple
+                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
+                Automake:
+                <literallayout class='monospaced'>
+     <replaceable>result</replaceable>: <replaceable>testname</replaceable>
+                </literallayout>
+                where the result can be <filename>PASS</filename>,
+                <filename>FAIL</filename>, or <filename>SKIP</filename>,
+                and the testname can be any identifying string.
+            </para>
+
+            <para>
+                For a list of Yocto Project recipes that are already
+                enabled with ptest, see the
+                <ulink url='https://wiki.yoctoproject.org/wiki/Ptest'>Ptest</ulink>
+                wiki page.
+                <note>
+                    A recipe is "ptest-enabled" if it inherits the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-ptest'><filename>ptest</filename></ulink>
+                    class.
+                </note>
+            </para>
+
+            <section id='adding-ptest-to-your-build'>
+                <title>Adding ptest to Your Build</title>
+
+                <para>
+                    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
+                    <link linkend='build-directory'>Build Directory</link>:
+                    <literallayout class='monospaced'>
+     DISTRO_FEATURES_append = " ptest"
+     EXTRA_IMAGE_FEATURES += "ptest-pkgs"
+                    </literallayout>
+                    Once your build is complete, the ptest files are installed
+                    into the
+                    <filename>/usr/lib/<replaceable>package</replaceable>/ptest</filename>
+                    directory within the image, where
+                    <filename><replaceable>package</replaceable></filename>
+                    is the name of the package.
+                </para>
+            </section>
+
+            <section id='running-ptest'>
+                <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.
+                    Consequently, you might want to add this package to
+                    your image.
+                </para>
+            </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
+                    you want to test.
+                    Here is what you have to do for each recipe:
+                    <itemizedlist>
+                        <listitem><para><emphasis>Be sure the recipe
+                            inherits the
+                            <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-ptest'><filename>ptest</filename></ulink>
+                            class:</emphasis>
+                            Include the following line in each recipe:
+                            <literallayout class='monospaced'>
+     inherit ptest
+                            </literallayout>
+                            </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
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>.
+                            Here is an example that starts a test for
+                            <filename>dbus</filename>:
+                            <literallayout class='monospaced'>
+     #!/bin/sh
+     cd test
+     make -k runtest-TESTS
+                            </literallayout>
+                            </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
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink>
+                            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
+                            dependency on "make":
+                            <literallayout class='monospaced'>
+     RDEPENDS_${PN}-ptest += "make"
+                            </literallayout>
+                            </para></listitem>
+                        <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
+                            cross-compilation function to the package.
+                            </para>
+                            <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
+                            on the host but executed on the target.
+                            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,
+                            patched version of <filename>make check</filename>
+                            automatically cross-compiles.</para>
+                            <para>Regardless, 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
+                            recipe:
+                            <literallayout class='monospaced'>
+     do_compile_ptest() {
+        oe_runmake buildtest-TESTS
+     }
+                            </literallayout>
+                            </para></listitem>
+                       <listitem><para><emphasis>Ensure special configurations
+                            are set:</emphasis>
+                            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
+                            suite:</emphasis>
+                            The <filename>ptest</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
+                            "make install-ptest" completes.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </section>
+        </section>
+    </section>
+
+    <section id='working-with-source-files'>
+        <title>Working with Source Files</title>
+
+        <para>
+            The OpenEmbedded build system works with source files located
+            through the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+            variable.
+            When you build something using BitBake, a big part of the operation
+            is locating and downloading all the source tarballs.
+            For images, downloading all the source for various packages can
+            take a significant amount of time.
+        </para>
+
+        <para>
+            This section presents information for working with source
+            files that can lead to more efficient use of resources and
+            time.
+        </para>
+
+        <section id='setting-up-effective-mirrors'>
+            <title>Setting up Effective Mirrors</title>
+
+            <para>
+                As mentioned, a good deal that goes into a Yocto Project
+                build is simply downloading all of the source tarballs.
+                Maybe you have been working with another build system
+                (OpenEmbedded or Angstrom) for which you have built up a
+                sizable directory of source tarballs.
+                Or, perhaps someone else has such a directory for which you
+                have read access.
+                If so, you can save time by adding statements to your
+                configuration file so that the build process checks local
+                directories first for existing tarballs before checking the
+                Internet.
+            </para>
+
+            <para>
+                Here is an efficient way to set it up in your
+                <filename>local.conf</filename> file:
+                <literallayout class='monospaced'>
+     SOURCE_MIRROR_URL ?= "file:///home/you/your-download-dir/"
+     INHERIT += "own-mirrors"
+     BB_GENERATE_MIRROR_TARBALLS = "1"
+     # BB_NO_NETWORK = "1"
+                </literallayout>
+            </para>
+
+            <para>
+                In the previous example, the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></ulink>
+                variable causes the OpenEmbedded build system to generate
+                tarballs of the Git repositories and store them in the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-DL_DIR'><filename>DL_DIR</filename></ulink>
+                directory.
+                Due to performance reasons, generating and storing these
+                tarballs is not the build system's default behavior.
+            </para>
+
+            <para>
+                You can also use the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PREMIRRORS'><filename>PREMIRRORS</filename></ulink>
+                variable.
+                For an example, see the variable's glossary entry in the
+                Yocto Project Reference Manual.
+            </para>
+        </section>
+
+        <section id='getting-source-files-and-suppressing-the-build'>
+            <title>Getting Source Files and Suppressing the Build</title>
+
+            <para>
+                Another technique you can use to ready yourself for a
+                successive string of build operations, is to pre-fetch
+                all the source files without actually starting a build.
+                This technique lets you work through any download issues
+                and ultimately gathers all the source files into your
+                download directory
+                <ulink url='&YOCTO_DOCS_REF_URL;#structure-build-downloads'><filename>build/downloads</filename></ulink>,
+                which is located with
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-DL_DIR'><filename>DL_DIR</filename></ulink>.
+            </para>
+
+            <para>
+                Use the following BitBake command form to fetch all the
+                necessary sources without starting the build:
+                <literallayout class='monospaced'>
+     $ bitbake -c fetchall <replaceable>target</replaceable>
+                </literallayout>
+                This variation of the BitBake command guarantees that you
+                have all the sources for that BitBake target should you
+                disconnect from the Internet and want to do the build
+                later offline.
+            </para>
+        </section>
+    </section>
+
+    <section id="building-software-from-an-external-source">
+        <title>Building Software from an External Source</title>
+
+        <para>
+            By default, the OpenEmbedded build system uses the
+            <link linkend='build-directory'>Build Directory</link> when
+            building source code.
+            The build process involves fetching the source files, unpacking
+            them, and then patching them if necessary before the build takes
+            place.
+        </para>
+
+        <para>
+            Situations exist where you might want to build software from source
+            files that are external to and thus outside of the
+            OpenEmbedded build system.
+            For example, suppose you have a project that includes a new BSP with
+            a heavily customized kernel.
+            And, you want to minimize exposing the build system to the
+            development team so that they can focus on their project and
+            maintain everyone's workflow as much as possible.
+            In this case, you want a kernel source directory on the development
+            machine where the development occurs.
+            You want the recipe's
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+            variable to point to the external directory and use it as is, not
+            copy it.
+        </para>
+
+        <para>
+            To build from software that comes from an external source, all you
+            need to do is inherit the
+            <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-externalsrc'><filename>externalsrc</filename></ulink>
+            class and then set the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTERNALSRC'><filename>EXTERNALSRC</filename></ulink>
+            variable to point to your external source code.
+            Here are the statements to put in your
+            <filename>local.conf</filename> file:
+            <literallayout class='monospaced'>
+     INHERIT += "externalsrc"
+     EXTERNALSRC_pn-<replaceable>myrecipe</replaceable> = "<replaceable>path-to-your-source-tree</replaceable>"
+            </literallayout>
+        </para>
+
+        <para>
+            This next example shows how to accomplish the same thing by setting
+            <filename>EXTERNALSRC</filename> in the recipe itself or in the
+            recipe's append file:
+            <literallayout class='monospaced'>
+     EXTERNALSRC = "<replaceable>path</replaceable>"
+     EXTERNALSRC_BUILD = "<replaceable>path</replaceable>"
+            </literallayout>
+            <note>
+                In order for these settings to take effect, you must globally
+                or locally inherit the
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-externalsrc'><filename>externalsrc</filename></ulink>
+                class.
+            </note>
+        </para>
+
+        <para>
+            By default, <filename>externalsrc.bbclass</filename> builds
+            the source code in a directory separate from the external source
+            directory as specified by
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTERNALSRC'><filename>EXTERNALSRC</filename></ulink>.
+            If you need to have the source built in the same directory in
+            which it resides, or some other nominated directory, you can set
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTERNALSRC_BUILD'><filename>EXTERNALSRC_BUILD</filename></ulink>
+            to point to that directory:
+            <literallayout class='monospaced'>
+     EXTERNALSRC_BUILD_pn-<replaceable>myrecipe</replaceable> = "<replaceable>path-to-your-source-tree</replaceable>"
+            </literallayout>
+        </para>
+    </section>
+
+    <section id="selecting-an-initialization-manager">
+        <title>Selecting an Initialization Manager</title>
+
+        <para>
+            By default, the Yocto Project uses SysVinit as the initialization
+            manager.
+            However, support also exists for systemd,
+            which is a full replacement for init with
+            parallel starting of services, reduced shell overhead and other
+            features that are used by many distributions.
+        </para>
+
+        <para>
+            If you want to use SysVinit, you do
+            not have to do anything.
+            But, if you want to use systemd, you must
+            take some steps as described in the following sections.
+        </para>
+
+        <section id='using-systemd-exclusively'>
+            <title>Using systemd Exclusively</title>
+
+            <para>
+                Set the these variables in your distribution configuration
+                file as follows:
+                <literallayout class='monospaced'>
+     DISTRO_FEATURES_append = " systemd"
+     VIRTUAL-RUNTIME_init_manager = "systemd"
+                </literallayout>
+                You can also prevent the SysVinit
+                distribution feature from
+                being automatically enabled as follows:
+                <literallayout class='monospaced'>
+     DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
+                </literallayout>
+                Doing so removes any redundant SysVinit scripts.
+            </para>
+
+            <para>
+                To remove  initscripts from your image altogether,
+                set this variable also:
+                <literallayout class='monospaced'>
+     VIRTUAL-RUNTIME_initscripts = ""
+                </literallayout>
+            </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>.
+            </para>
+        </section>
+
+        <section id='using-systemd-for-the-main-image-and-using-sysvinit-for-the-rescue-image'>
+            <title>Using systemd for the Main Image and Using SysVinit for the Rescue Image</title>
+
+            <para>
+                Set these variables in your distribution configuration
+                file as follows:
+                <literallayout class='monospaced'>
+     DISTRO_FEATURES_append = " systemd"
+     VIRTUAL-RUNTIME_init_manager = "systemd"
+                </literallayout>
+                Doing so causes your main image to use the
+                <filename>packagegroup-core-boot.bb</filename> recipe and
+                systemd.
+                The rescue/minimal image cannot use this package group.
+                However, it can install SysVinit
+                and the appropriate packages will have support for both
+                systemd and SysVinit.
+            </para>
+        </section>
+    </section>
+
+    <section id="platdev-appdev-srcrev">
+        <title>Using an External SCM</title>
+
+        <para>
+            If you're working on a recipe that pulls from an external Source
+            Code Manager (SCM), it is possible to have the OpenEmbedded build
+            system notice new recipe changes added to the SCM and then build
+            the resulting packages that depend on the new recipes by using
+            the latest versions.
+            This only works for SCMs from which it is possible to get a
+            sensible revision number for changes.
+            Currently, you can do this with Apache Subversion (SVN), Git, and
+            Bazaar (BZR) repositories.
+        </para>
+
+        <para>
+            To enable this behavior, the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>
+            of the recipe needs to reference
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-SRCPV'><filename>SRCPV</filename></ulink>.
+            Here is an example:
+            <literallayout class='monospaced'>
+     PV = "1.2.3+git${SRCPV}
+            </literallayout>
+            Then, you can add the following to your
+            <filename>local.conf</filename>:
+            <literallayout class='monospaced'>
+     SRCREV_pn-<replaceable>PN</replaceable> = "${AUTOREV}"
+            </literallayout>
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink>
+            is the name of the recipe for which you want to enable automatic source
+            revision updating.
+        </para>
+
+        <para>
+            If you do not want to update your local configuration file, you can
+            add the following directly to the recipe to finish enabling
+            the feature:
+            <literallayout class='monospaced'>
+     SRCREV = "${AUTOREV}"
+            </literallayout>
+        </para>
+
+        <para>
+            The Yocto Project provides a distribution named
+            <filename>poky-bleeding</filename>, whose configuration
+            file contains the line:
+            <literallayout class='monospaced'>
+     require conf/distro/include/poky-floating-revisions.inc
+            </literallayout>
+            This line pulls in the listed include file that contains
+            numerous lines of exactly that form:
+            <literallayout class='monospaced'>
+     SRCREV_pn-gconf-dbus ?= "${AUTOREV}"
+     SRCREV_pn-matchbox-common ?= "${AUTOREV}"
+     SRCREV_pn-matchbox-config-gtk ?= "${AUTOREV}"
+     SRCREV_pn-matchbox-desktop ?= "${AUTOREV}"
+     SRCREV_pn-matchbox-keyboard ?= "${AUTOREV}"
+     SRCREV_pn-matchbox-panel ?= "${AUTOREV}"
+     SRCREV_pn-matchbox-panel-2 ?= "${AUTOREV}"
+     SRCREV_pn-matchbox-themes-extra ?= "${AUTOREV}"
+     SRCREV_pn-matchbox-terminal ?= "${AUTOREV}"
+     SRCREV_pn-matchbox-wm ?= "${AUTOREV}"
+     SRCREV_pn-matchbox-wm-2 ?= "${AUTOREV}"
+     SRCREV_pn-settings-daemon ?= "${AUTOREV}"
+     SRCREV_pn-screenshot ?= "${AUTOREV}"
+     SRCREV_pn-libfakekey ?= "${AUTOREV}"
+     SRCREV_pn-oprofileui ?= "${AUTOREV}"
+          .
+          .
+          .
+            </literallayout>
+            These lines allow you to experiment with building a
+            distribution that tracks the latest development source
+            for numerous packages.
+            <note><title>Caution</title>
+                The <filename>poky-bleeding</filename> distribution
+                is not tested on a regular basis.
+                Keep this in mind if you use it.
+            </note>
+        </para>
+    </section>
+
+    <section id='creating-a-read-only-root-filesystem'>
+        <title>Creating a Read-Only Root Filesystem</title>
+
+        <para>
+            Suppose, for security reasons, you need to disable
+            your target device's root filesystem's write permissions
+            (i.e. you need a read-only root filesystem).
+            Or, perhaps you are running the device's operating system
+            from a read-only storage device.
+            For either case, you can customize your image for
+            that behavior.
+        </para>
+
+        <note>
+            Supporting a read-only root filesystem requires that the system and
+            applications do not try to write to the root filesystem.
+            You must configure all parts of the target system to write
+            elsewhere, or to gracefully fail in the event of attempting to
+            write to the root filesystem.
+        </note>
+
+        <section id='creating-the-root-filesystem'>
+            <title>Creating the Root Filesystem</title>
+
+            <para>
+                To create the read-only root filesystem, simply add the
+                "read-only-rootfs" feature to your image.
+                Using either of the following statements in your
+                image recipe or from within the
+                <filename>local.conf</filename> file found in the
+                <link linkend='build-directory'>Build Directory</link>
+                causes the build system to create a read-only root filesystem:
+                <literallayout class='monospaced'>
+     IMAGE_FEATURES = "read-only-rootfs"
+                </literallayout>
+                or
+                <literallayout class='monospaced'>
+     EXTRA_IMAGE_FEATURES += "read-only-rootfs"
+                </literallayout>
+            </para>
+
+            <para>
+                For more information on how to use these variables, see the
+                "<link linkend='usingpoky-extend-customimage-imagefeatures'>Customizing Images Using Custom <filename>IMAGE_FEATURES</filename> and <filename>EXTRA_IMAGE_FEATURES</filename></link>"
+                section.
+                For information on the variables, see
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></ulink>
+                and <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGE_FEATURES'><filename>EXTRA_IMAGE_FEATURES</filename></ulink>.
+            </para>
+        </section>
+
+        <section id='post-installation-scripts'>
+            <title>Post-Installation Scripts</title>
+
+            <para>
+                It is very important that you make sure all
+                post-Installation (<filename>pkg_postinst</filename>) scripts
+                for packages that are installed into the image can be run
+                at the time when the root filesystem is created during the
+                build on the host system.
+                These scripts cannot attempt to run during first-boot on the
+                target device.
+                With the "read-only-rootfs" feature enabled,
+                the build system checks during root filesystem creation to make
+                sure all post-installation scripts succeed.
+                If any of these scripts still need to be run after the root
+                filesystem is created, the build immediately fails.
+                These build-time checks ensure that the build fails
+                rather than the target device fails later during its
+                initial boot operation.
+            </para>
+
+            <para>
+                Most of the common post-installation scripts generated by the
+                build system for the out-of-the-box Yocto Project are engineered
+                so that they can run during root filesystem creation
+                (e.g. post-installation scripts for caching fonts).
+                However, if you create and add custom scripts, you need
+                to be sure they can be run during this file system creation.
+            </para>
+
+            <para>
+                Here are some common problems that prevent
+                post-installation scripts from running during root filesystem
+                creation:
+                <itemizedlist>
+                    <listitem><para>
+                        <emphasis>Not using $D in front of absolute
+                        paths:</emphasis>
+                        The build system defines
+                        <filename>$</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-D'><filename>D</filename></ulink>
+                        when the root filesystem is created.
+                        Furthermore, <filename>$D</filename> is blank when the
+                        script is run on the target device.
+                        This implies two purposes for <filename>$D</filename>:
+                        ensuring paths are valid in both the host and target
+                        environments, and checking to determine which
+                        environment is being used as a method for taking
+                        appropriate actions.
+                        </para></listitem>
+                    <listitem><para>
+                        <emphasis>Attempting to run processes that are
+                        specific to or dependent on the target
+                        architecture:</emphasis>
+                        You can work around these attempts by using native
+                        tools to accomplish the same tasks, or
+                        by alternatively running the processes under QEMU,
+                        which has the <filename>qemu_run_binary</filename>
+                        function.
+                        For more information, see the
+                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-qemu'><filename>qemu</filename></ulink>
+                        class.</para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='areas-with-write-access'>
+            <title>Areas With Write Access</title>
+
+            <para>
+                With the "read-only-rootfs" feature enabled,
+                any attempt by the target to write to the root filesystem at
+                runtime fails.
+                Consequently, you must make sure that you configure processes
+                and applications that attempt these types of writes do so
+                to directories with write access (e.g.
+                <filename>/tmp</filename> or <filename>/var/run</filename>).
+            </para>
+        </section>
+    </section>
+
+    <section id="performing-automated-runtime-testing">
+        <title>Performing Automated Runtime Testing</title>
+
+        <para>
+            The OpenEmbedded build system makes available a series of automated
+            tests for images to verify runtime functionality.
+            You can run these tests on either QEMU or actual target hardware.
+            Tests are written in Python making use of the
+            <filename>unittest</filename> module, and the majority of them
+            run commands on the target system over SSH.
+            This section describes how you set up the environment to use these
+            tests, run available tests, and write and add your own tests.
+        </para>
+
+        <section id='enabling-tests'>
+            <title>Enabling Tests</title>
+
+            <para>
+                Depending on whether you are planning to run tests using
+                QEMU or on the hardware, you have to take
+                different steps to enable the tests.
+                See the following subsections for information on how to
+                enable both types of tests.
+            </para>
+
+            <section id='qemu-image-enabling-tests'>
+                <title>Enabling Runtime Tests on QEMU</title>
+
+                <para>
+                    In order to run tests, you need to do the following:
+                    <itemizedlist>
+                        <listitem><para><emphasis>Set up to avoid interaction
+                            with <filename>sudo</filename> for networking:</emphasis>
+                            To accomplish this, you must do one of the
+                            following:
+                            <itemizedlist>
+                                <listitem><para>Add
+                                    <filename>NOPASSWD</filename> for your user
+                                    in <filename>/etc/sudoers</filename> either for
+                                    all commands or just for
+                                    <filename>runqemu-ifup</filename>.
+                                    You must provide the full path as that can
+                                    change if you are using multiple clones of the
+                                    source repository.
+                                    <note>
+                                        On some distributions, you also need to
+                                        comment out "Defaults requiretty" in
+                                        <filename>/etc/sudoers</filename>.
+                                    </note></para></listitem>
+                                <listitem><para>Manually configure a tap interface
+                                    for your system.</para></listitem>
+                                <listitem><para>Run as root the script in
+                                    <filename>scripts/runqemu-gen-tapdevs</filename>,
+                                    which should generate a list of tap devices.
+                                    This is the option typically chosen for
+                                    Autobuilder-type environments.
+                                    </para></listitem>
+                            </itemizedlist></para></listitem>
+                        <listitem><para><emphasis>Set the
+                            <filename>DISPLAY</filename> variable:</emphasis>
+                            You need to set this variable so that you have an X
+                            server available (e.g. start
+                            <filename>vncserver</filename> for a headless machine).
+                            </para></listitem>
+                        <listitem><para><emphasis>Be sure your host's firewall
+                            accepts incoming connections from
+                            192.168.7.0/24:</emphasis>
+                            Some of the tests (in particular smart tests) start an
+                            HTTP server on a random high number port, which is
+                            used to serve files to the target.
+                            The smart module serves
+                            <filename>${DEPLOY_DIR}/rpm</filename> so it can run
+                            smart channel commands. That means your host's firewall
+                            must accept incoming connections from 192.168.7.0/24,
+                            which is the default IP range used for tap devices
+                            by <filename>runqemu</filename>.</para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    Once you start running the tests, the following happens:
+                    <orderedlist>
+                        <listitem><para>A copy of the root filesystem is written
+                            to <filename>${WORKDIR}/testimage</filename>.
+                            </para></listitem>
+                        <listitem><para>The image is booted under QEMU using the
+                            standard <filename>runqemu</filename> script.
+                            </para></listitem>
+                        <listitem><para>A default timeout of 500 seconds occurs
+                            to allow for the boot process to reach the login prompt.
+                            You can change the timeout period by setting
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-TEST_QEMUBOOT_TIMEOUT'><filename>TEST_QEMUBOOT_TIMEOUT</filename></ulink>
+                            in the <filename>local.conf</filename> file.
+                            </para></listitem>
+                        <listitem><para>Once the boot process is reached and the
+                            login prompt appears, the tests run.
+                            The full boot log is written to
+                            <filename>${WORKDIR}/testimage/qemu_boot_log</filename>.
+                            </para></listitem>
+                        <listitem><para>Each test module loads in the order found
+                            in <filename>TEST_SUITES</filename>.
+                            You can find the full output of the commands run over
+                            SSH in
+                            <filename>${WORKDIR}/testimgage/ssh_target_log</filename>.
+                            </para></listitem>
+                        <listitem><para>If no failures occur, the task running the
+                            tests ends successfully.
+                            You can find the output from the
+                            <filename>unittest</filename> in the task log at
+                            <filename>${WORKDIR}/temp/log.do_testimage</filename>.
+                            </para></listitem>
+                    </orderedlist>
+                </para>
+            </section>
+
+            <section id='hardware-image-enabling-tests'>
+                <title>Enabling Runtime Tests on Hardware</title>
+
+                <para>
+                    The OpenEmbedded build system can run tests on real
+                    hardware, and for certain devices it can also deploy
+                    the image to be tested onto the device beforehand.
+                </para>
+
+                <para>
+                    For automated deployment, a "master image" is installed
+                    onto the hardware once as part of setup.
+                    Then, each time tests are to be run, the following
+                    occurs:
+                    <orderedlist>
+                        <listitem><para>The master image is booted into and
+                            used to write the image to be tested to
+                            a second partition.
+                            </para></listitem>
+                        <listitem><para>The device is then rebooted using an
+                            external script that you need to provide.
+                            </para></listitem>
+                        <listitem><para>The device boots into the image to be
+                            tested.
+                            </para></listitem>
+                    </orderedlist>
+                </para>
+
+                <para>
+                    When running tests (independent of whether the image
+                    has been deployed automatically or not), the device is
+                    expected to be connected to a network on a
+                    pre-determined IP address.
+                    You can either use static IP addresses written into
+                    the image, or set the image to use DHCP and have your
+                    DHCP server on the test network assign a known IP address
+                    based on the MAC address of the device.
+                </para>
+
+                <para>
+                    In order to run tests on hardware, you need to set
+                    <filename>TEST_TARGET</filename> to an appropriate value.
+                    For QEMU, you do not have to change anything, the default
+                    value is "QemuTarget".
+                    For running tests on hardware, the following options exist:
+                    <itemizedlist>
+                        <listitem><para><emphasis>"SimpleRemoteTarget":</emphasis>
+                            Choose "SimpleRemoteTarget" if you are going to
+                            run tests on a target system that is already
+                            running the image to be tested and is available
+                            on the network.
+                            You can use "SimpleRemoteTarget" in conjunction
+                            with either real hardware or an image running
+                            within a separately started QEMU or any
+                            other virtual machine manager.
+                            </para></listitem>
+                        <listitem><para><emphasis>"GummibootTarget":</emphasis>
+                            Choose "GummibootTarget" if your hardware is
+                            an EFI-based machine with
+                            <filename>gummiboot</filename> as bootloader and
+                            <filename>core-image-testmaster</filename>
+                            (or something similar) is installed.
+                            Also, your hardware under test must be in a
+                            DHCP-enabled network that gives it the same IP
+                            address for each reboot.</para>
+                            <para>If you choose "GummibootTarget", there are
+                            additional requirements and considerations.
+                            See the
+                            "<link linkend='selecting-gummiboottarget'>Selecting GummibootTarget</link>"
+                            section, which follows, for more information.
+                            </para></listitem>
+                        <listitem><para><emphasis>"BeagleBoneTarget":</emphasis>
+                            Choose "BeagleBoneTarget" if you are deploying
+                            images and running tests on the BeagleBone
+                            "Black" or original "White" hardware.
+                            For information on how to use these tests, see the
+                            comments at the top of the BeagleBoneTarget
+                            <filename>meta-yocto-bsp/lib/oeqa/controllers/beaglebonetarget.py</filename>
+                            file.
+                            </para></listitem>
+                        <listitem><para><emphasis>"EdgeRouterTarget":</emphasis>
+                            Choose "EdgeRouterTarget" is you are deploying
+                            images and running tests on the Ubiquiti Networks
+                            EdgeRouter Lite.
+                            For information on how to use these tests, see the
+                            comments at the top of the EdgeRouterTarget
+                            <filename>meta-yocto-bsp/lib/oeqa/controllers/edgeroutertarget.py</filename>
+                            file.
+                            </para></listitem>
+                        <listitem><para><emphasis>"GrubTarget":</emphasis>
+                            Choose the "supports deploying images and running
+                            tests on any generic PC that boots using GRUB.
+                            For information on how to use these tests, see the
+                            comments at the top of the GrubTarget
+                            <filename>meta-yocto-bsp/lib/oeqa/controllers/grubtarget.py</filename>
+                            file.
+                            </para></listitem>
+                        <listitem><para><emphasis>"<replaceable>your-target</replaceable>":</emphasis>
+                            Create your own custom target if you want to run
+                            tests when you are deploying images and running
+                            tests on a custom machine within your BSP layer.
+                            To do this, you need to add a Python unit that
+                            defines the target class under
+                            <filename>lib/oeqa/controllers/</filename> within
+                            your layer.
+                            You must also provide an empty
+                            <filename>__init__.py</filename>.
+                            For examples, see files in
+                            <filename>meta-yocto-bsp/lib/oeqa/controllers/</filename>.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </section>
+
+            <section id='selecting-gummiboottarget'>
+                <title>Selecting GummibootTarget</title>
+
+                <para>
+                    If you did not set <filename>TEST_TARGET</filename> to
+                    "GummibootTarget", then you do not need any information
+                    in this section.
+                    You can skip down to the
+                    "<link linkend='qemu-image-running-tests'>Running Tests</link>"
+                    section.
+                </para>
+
+                <para>
+                    If you did set <filename>TEST_TARGET</filename> to
+                    "GummibootTarget", you also need to perform a one-time
+                    setup of your master image by doing the following:
+                    <orderedlist>
+                        <listitem><para><emphasis>Set <filename>EFI_PROVIDER</filename>:</emphasis>
+                            Be sure that <filename>EFI_PROVIDER</filename>
+                            is as follows:
+                            <literallayout class='monospaced'>
+     EFI_PROVIDER = "gummiboot"
+                            </literallayout>
+                            </para></listitem>
+                        <listitem><para><emphasis>Build the master image:</emphasis>
+                            Build the <filename>core-image-testmaster</filename>
+                            image.
+                            The <filename>core-image-testmaster</filename>
+                            recipe is provided as an example for a
+                            "master" image and you can customize the image
+                            recipe as you would any other recipe.
+                            </para>
+                            <para>Here are the image recipe requirements:
+                            <itemizedlist>
+                                <listitem><para>Inherits
+                                    <filename>core-image</filename>
+                                    so that kernel modules are installed.
+                                    </para></listitem>
+                                <listitem><para>Installs normal linux utilities
+                                    not busybox ones (e.g.
+                                    <filename>bash</filename>,
+                                    <filename>coreutils</filename>,
+                                    <filename>tar</filename>,
+                                    <filename>gzip</filename>, and
+                                    <filename>kmod</filename>).
+                                    </para></listitem>
+                                <listitem><para>Uses a custom
+                                    Initial RAM Disk (initramfs) image with a
+                                    custom installer.
+                                    A normal image that you can install usually
+                                    creates a single rootfs partition.
+                                    This image uses another installer that
+                                    creates a specific partition layout.
+                                    Not all Board Support Packages (BSPs)
+                                    can use an installer.
+                                    For such cases, you need to manually create
+                                    the following partition layout on the
+                                    target:
+                                    <itemizedlist>
+                                        <listitem><para>First partition mounted
+                                            under <filename>/boot</filename>,
+                                            labeled "boot".
+                                            </para></listitem>
+                                        <listitem><para>The main rootfs
+                                            partition where this image gets
+                                            installed, which is mounted under
+                                            <filename>/</filename>.
+                                            </para></listitem>
+                                        <listitem><para>Another partition
+                                            labeled "testrootfs" where test
+                                            images get deployed.
+                                            </para></listitem>
+                                    </itemizedlist>
+                                    </para></listitem>
+                            </itemizedlist>
+                            </para></listitem>
+                        <listitem><para><emphasis>Install image:</emphasis>
+                            Install the image that you just built on the target
+                            system.
+                            </para></listitem>
+                    </orderedlist>
+                </para>
+
+                <para>
+                    The final thing you need to do when setting
+                    <filename>TEST_TARGET</filename> to "GummibootTarget" is
+                    to set up the test image:
+                    <orderedlist>
+                        <listitem><para><emphasis>Set up your <filename>local.conf</filename> file:</emphasis>
+                            Make sure you have the following statements in
+                            your <filename>local.conf</filename> file:
+                            <literallayout class='monospaced'>
+     IMAGE_FSTYPES += "tar.gz"
+     INHERIT += "testimage"
+     TEST_TARGET = "GummibootTarget"
+     TEST_TARGET_IP = "192.168.2.3"
+                            </literallayout>
+                            </para></listitem>
+                        <listitem><para><emphasis>Build your test image:</emphasis>
+                            Use BitBake to build the image:
+                            <literallayout class='monospaced'>
+     $ bitbake core-image-sato
+                            </literallayout>
+                            </para></listitem>
+                    </orderedlist>
+                </para>
+            </section>
+
+            <section id='power-control'>
+                <title>Power Control</title>
+
+                <para>
+                    For most hardware targets other than SimpleRemoteTarget,
+                    you can control power:
+                    <itemizedlist>
+                        <listitem><para>
+                            You can use
+                            <filename>TEST_POWERCONTROL_CMD</filename>
+                            together with
+                            <filename>TEST_POWERCONTROL_EXTRA_ARGS</filename>
+                            as a command that runs on the host and does power
+                            cycling.
+                            The test code passes one argument to that command:
+                            off, on or cycle (off then on).
+                            Here is an example that could appear in your
+                            <filename>local.conf</filename> file:
+                            <literallayout class='monospaced'>
+     TEST_POWERCONTROL_CMD = "powercontrol.exp test 10.11.12.1 nuc1"
+                            </literallayout>
+                            In this example, the expect script does the
+                            following:
+                            <literallayout class='monospaced'>
+     ssh test@10.11.12.1 "pyctl nuc1 <replaceable>arg</replaceable>"
+                            </literallayout>
+                            It then runs a Python script that controls power
+                            for a label called <filename>nuc1</filename>.
+                            <note>
+                                You need to customize
+                                <filename>TEST_POWERCONTROL_CMD</filename>
+                                and
+                                <filename>TEST_POWERCONTROL_EXTRA_ARGS</filename>
+                                for your own setup.
+                                The one requirement is that it accepts
+                                "on", "off", and "cycle" as the last argument.
+                            </note>
+                            </para></listitem>
+                        <listitem><para>
+                            When no command is defined, it connects to the
+                            device over SSH and uses the classic reboot command
+                            to reboot the device.
+                            Classic reboot is fine as long as the machine
+                            actually reboots (i.e. the SSH test has not
+                            failed).
+                            It is useful for scenarios where you have a simple
+                            setup, typically with a single board, and where
+                            some manual interaction is okay from time to time.
+                            </para></listitem>
+                    </itemizedlist>
+                    If you have no hardware to automatically perform power
+                    control but still wish to experiment with automated
+                    hardware testing, you can use the dialog-power-control
+                    script that shows a dialog prompting you to perform the
+                    required power action.
+                    This script requires either KDialog or Zenity to be
+                    installed.
+                    To use this script, set the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-TEST_POWERCONTROL_CMD'><filename>TEST_POWERCONTROL_CMD</filename></ulink>
+                    variable as follows:
+                    <literallayout class='monospaced'>
+     TEST_POWERCONTROL_CMD = "${COREBASE}/scripts/contrib/dialog-power-control"
+                    </literallayout>
+                </para>
+            </section>
+
+            <section id='serial-console-connection'>
+                <title>Serial Console Connection</title>
+
+                <para>
+                    For test target classes requiring a serial console
+                    to interact with the bootloader (e.g. BeagleBoneTarget,
+                    EdgeRouterTarget, and GrubTarget), you need to
+                    specify a command to use to connect to the serial console
+                    of the target machine by using the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-TEST_POWERCONTROL_CMD'><filename>TEST_POWERCONTROL_CMD</filename></ulink>
+                    variable and optionally the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-TEST_SERIALCONTROL_EXTRA_ARGS'><filename>TEST_SERIALCONTROL_EXTRA_ARGS</filename></ulink>
+                    variable.
+                </para>
+
+                <para>
+                    These cases could be a serial terminal program if the
+                    machine is connected to a local serial port, or a
+                    <filename>telnet</filename> or
+                    <filename>ssh</filename> command connecting to a remote
+                    console server.
+                    Regardless of the case, the command simply needs to
+                    connect to the serial console and forward that connection
+                    to standard input and output as any normal terminal
+                    program does.
+                    For example, to use the picocom terminal program on
+                    serial device <filename>/dev/ttyUSB0</filename>
+                    at 115200bps, you would set the variable as follows:
+                    <literallayout class='monospaced'>
+     TEST_SERIALCONTROL_CMD = "picocom /dev/ttyUSB0 -b 115200"
+                    </literallayout>
+                    For local devices where the serial port device disappears
+                    when the device reboots, an additional "serdevtry" wrapper
+                    script is provided.
+                    To use this wrapper, simply prefix the terminal command
+                    with
+                    <filename>${COREBASE}/scripts/contrib/serdevtry</filename>:
+                    <literallayout class='monospaced'>
+     TEST_SERIALCONTROL_CMD = "${COREBASE}/scripts/contrib/serdevtry picocom -b
+115200 /dev/ttyUSB0"
+                    </literallayout>
+                </para>
+            </section>
+        </section>
+
+        <section id="qemu-image-running-tests">
+            <title>Running Tests</title>
+
+            <para>
+                You can start the tests automatically or manually:
+                <itemizedlist>
+                    <listitem><para><emphasis>Automatically running tests:</emphasis>
+                        To run the tests automatically after the
+                        OpenEmbedded build system successfully creates an image,
+                        first set the
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-TEST_IMAGE'><filename>TEST_IMAGE</filename></ulink>
+                        variable to "1" in your <filename>local.conf</filename>
+                        file in the
+                        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
+                        <literallayout class='monospaced'>
+     TEST_IMAGE = "1"
+                        </literallayout>
+                        Next, build your image.
+                        If the image successfully builds, the tests will be
+                        run:
+                        <literallayout class='monospaced'>
+     bitbake core-image-sato
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Manually running tests:</emphasis>
+                        To manually run the tests, first globally inherit the
+                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-testimage'><filename>testimage</filename></ulink>
+                        class by editing your <filename>local.conf</filename>
+                        file:
+                        <literallayout class='monospaced'>
+    INHERIT += "testimage"
+                        </literallayout>
+                        Next, use BitBake to run the tests:
+                        <literallayout class='monospaced'>
+     bitbake -c testimage <replaceable>image</replaceable>
+                        </literallayout></para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                All test files reside in
+                <filename>meta/lib/oeqa/runtime</filename> in the
+                <link linkend='source-directory'>Source Directory</link>.
+                A test name maps directly to a Python module.
+                Each test module may contain a number of individual tests.
+                Tests are usually grouped together by the area
+                tested (e.g tests for systemd reside in
+                <filename>meta/lib/oeqa/runtime/systemd.py</filename>).
+            </para>
+
+            <para>
+                You can add tests to any layer provided you place them in the
+                proper area and you extend
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-BBPATH'><filename>BBPATH</filename></ulink>
+                in the <filename>local.conf</filename> file as normal.
+                Be sure that tests reside in
+                <filename><replaceable>layer</replaceable>/lib/oeqa/runtime</filename>.
+                <note>
+                    Be sure that module names do not collide with module names
+                    used in the default set of test modules in
+                    <filename>meta/lib/oeqa/runtime</filename>.
+                </note>
+            </para>
+
+            <para>
+                You can change the set of tests run by appending or overriding
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-TEST_SUITES'><filename>TEST_SUITES</filename></ulink>
+                variable in <filename>local.conf</filename>.
+                Each name in <filename>TEST_SUITES</filename> represents a
+                required test for the image.
+                Test modules named within <filename>TEST_SUITES</filename>
+                cannot be skipped even if a test is not suitable for an image
+                (e.g. running the RPM tests on an image without
+                <filename>rpm</filename>).
+                Appending "auto" to <filename>TEST_SUITES</filename> causes the
+                build system to try to run all tests that are suitable for the
+                image (i.e. each test module may elect to skip itself).
+            </para>
+
+            <para>
+                The order you list tests in <filename>TEST_SUITES</filename>
+                is important and influences test dependencies.
+                Consequently, tests that depend on other tests should be added
+                after the test on which they depend.
+                For example, since the <filename>ssh</filename> test
+                depends on the
+                <filename>ping</filename> test, "ssh" needs to come after
+                "ping" in the list.
+                The test class provides no re-ordering or dependency handling.
+                <note>
+                    Each module can have multiple classes with multiple test
+                    methods.
+                    And, Python <filename>unittest</filename> rules apply.
+                </note>
+            </para>
+
+            <para>
+                Here are some things to keep in mind when running tests:
+                <itemizedlist>
+                    <listitem><para>The default tests for the image are defined
+                        as:
+                        <literallayout class='monospaced'>
+     DEFAULT_TEST_SUITES_pn-<replaceable>image</replaceable> = "ping ssh df connman syslog xorg scp vnc date rpm smart dmesg"
+                        </literallayout></para></listitem>
+                    <listitem><para>Add your own test to the list of the
+                        by using the following:
+                        <literallayout class='monospaced'>
+     TEST_SUITES_append = " mytest"
+                        </literallayout></para></listitem>
+                    <listitem><para>Run a specific list of tests as follows:
+                        <literallayout class='monospaced'>
+     TEST_SUITES = "test1 test2 test3"
+                        </literallayout>
+                        Remember, order is important.
+                        Be sure to place a test that is dependent on another test
+                        later in the order.</para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id="exporting-tests">
+            <title>Exporting Tests</title>
+
+            <para>
+                You can export tests so that they can run independently of
+                the build system.
+                Exporting tests is required if you want to be able to hand
+                the test execution off to a scheduler.
+                You can only export tests that are defined in
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-TEST_SUITES'><filename>TEST_SUITES</filename></ulink>.
+            </para>
+
+            <para>
+                If your image is already built, make sure the following are set
+                in your <filename>local.conf</filename> file.
+                Be sure to provide the IP address you need:
+                <literallayout class='monospaced'>
+     TEST_EXPORT_ONLY = "1"
+     TEST_TARGET = "simpleremote"
+     TEST_TARGET_IP = "192.168.7.2"
+     TEST_SERVER_IP = "192.168.7.1"
+                </literallayout>
+                You can then export the tests with the following:
+                <literallayout class='monospaced'>
+     $ bitbake core-image-sato -c testimage
+                </literallayout>
+                Exporting the tests places them in the
+                <link linkend='build-directory'>Build Directory</link> in
+                <filename>tmp/testimage/core-image-sato</filename>, which
+                is controlled by the
+                <filename>TEST_EXPORT_DIR</filename> variable.
+            </para>
+
+            <para>
+                You can now run the tests outside of the build environment:
+                <literallayout class='monospaced'>
+     $ cd tmp/testimage/core-image-sato
+     $ ./runexported.py testdata.json
+                </literallayout>
+                <note>
+                    This "export" feature does not deploy or boot the target
+                    image.
+                    Your target (be it a Qemu or hardware one)
+                    has to already be up and running when you call
+                    <filename>runexported.py</filename>
+                </note>
+            </para>
+
+            <para>
+                The exported data (i.e. <filename>testdata.json</filename>)
+                contains paths to the Build Directory.
+                Thus, the contents of the directory can be moved
+                to another machine as long as you update some paths in the
+                JSON.
+                Usually, you only care about the
+                <filename>${DEPLOY_DIR}/rpm</filename> directory
+                (assuming the RPM and Smart tests are enabled).
+                Consequently, running the tests on other machine
+                means that you have to move the contents and call
+                <filename>runexported.py</filename> with
+                "&dash;&dash;deploy-dir <replaceable>path</replaceable>" as
+                follows:
+                <literallayout class='monospaced'>
+     ./runexported.py &dash;&dash;deploy-dir /new/path/on/this/machine testdata.json
+                </literallayout>
+                <filename>runexported.py</filename> accepts other arguments
+                as well as described using <filename>&dash;&dash;help</filename>.
+            </para>
+        </section>
+
+        <section id="qemu-image-writing-new-tests">
+            <title>Writing New Tests</title>
+
+            <para>
+                As mentioned previously, all new test files need to be in the
+                proper place for the build system to find them.
+                New tests for additional functionality outside of the core
+                should be added to the layer that adds the functionality, in
+                <filename><replaceable>layer</replaceable>/lib/oeqa/runtime</filename>
+                (as long as
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-BBPATH'><filename>BBPATH</filename></ulink>
+                is extended in the layer's
+                <filename>layer.conf</filename> file as normal).
+                Just remember that filenames need to map directly to test
+                (module) names and that you do not use module names that
+                collide with existing core tests.
+            </para>
+
+            <para>
+                To create a new test, start by copying an existing module
+                (e.g. <filename>syslog.py</filename> or
+                <filename>gcc.py</filename> are good ones to use).
+                Test modules can use code from
+                <filename>meta/lib/oeqa/utils</filename>, which are helper
+                classes.
+            </para>
+
+            <note>
+                Structure shell commands such that you rely on them and they
+                return a single code for success.
+                Be aware that sometimes you will need to parse the output.
+                See the <filename>df.py</filename> and
+                <filename>date.py</filename> modules for examples.
+            </note>
+
+            <para>
+                You will notice that all test classes inherit
+                <filename>oeRuntimeTest</filename>, which is found in
+                <filename>meta/lib/oetest.py</filename>.
+                This base class offers some helper attributes, which are
+                described in the following sections:
+            </para>
+
+            <section id='qemu-image-writing-tests-class-methods'>
+                <title>Class Methods</title>
+
+                <para>
+                    Class methods are as follows:
+                    <itemizedlist>
+                        <listitem><para><emphasis><filename>hasPackage(pkg)</filename>:</emphasis>
+                            Returns "True" if <filename>pkg</filename> is in the
+                            installed package list of the image, which is based
+                            on the manifest file that is generated during the
+                            <filename>do_rootfs</filename> task.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>hasFeature(feature)</filename>:</emphasis>
+                            Returns "True" if the feature is in
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></ulink>
+                            or
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></ulink>.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </section>
+
+            <section id='qemu-image-writing-tests-class-attributes'>
+                <title>Class Attributes</title>
+
+                <para>
+                    Class attributes are as follows:
+                    <itemizedlist>
+                        <listitem><para><emphasis><filename>pscmd</filename>:</emphasis>
+                            Equals "ps -ef" if <filename>procps</filename> is
+                            installed in the image.
+                            Otherwise, <filename>pscmd</filename> equals
+                            "ps" (busybox).
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>tc</filename>:</emphasis>
+                            The called text context, which gives access to the
+                            following attributes:
+                            <itemizedlist>
+                                <listitem><para><emphasis><filename>d</filename>:</emphasis>
+                                    The BitBake datastore, which allows you to
+                                    use stuff such as
+                                    <filename>oeRuntimeTest.tc.d.getVar("VIRTUAL-RUNTIME_init_manager")</filename>.
+                                    </para></listitem>
+                                <listitem><para><emphasis><filename>testslist</filename> and <filename>testsrequired</filename>:</emphasis>
+                                    Used internally.
+                                    The tests do not need these.
+                                    </para></listitem>
+                                <listitem><para><emphasis><filename>filesdir</filename>:</emphasis>
+                                    The absolute path to
+                                    <filename>meta/lib/oeqa/runtime/files</filename>,
+                                    which contains helper files for tests meant
+                                    for copying on the target such as small
+                                    files written in C for compilation.
+                                    </para></listitem>
+                                <listitem><para><emphasis><filename>target</filename>:</emphasis>
+                                    The target controller object used to deploy
+                                    and start an image on a particular target
+                                    (e.g. QemuTarget, SimpleRemote, and
+                                    GummibootTarget).
+                                    Tests usually use the following:
+                                    <itemizedlist>
+                                        <listitem><para><emphasis><filename>ip</filename>:</emphasis>
+                                            The target's IP address.
+                                            </para></listitem>
+                                        <listitem><para><emphasis><filename>server_ip</filename>:</emphasis>
+                                            The host's IP address, which is
+                                            usually used by the "smart" test
+                                            suite.
+                                            </para></listitem>
+                                        <listitem><para><emphasis><filename>run(cmd, timeout=None)</filename>:</emphasis>
+                                            The single, most used method.
+                                            This command is a wrapper for:
+                                            <filename>ssh root@host "cmd"</filename>.
+                                            The command returns a tuple:
+                                            (status, output), which are what
+                                            their names imply - the return code
+                                            of "cmd" and whatever output
+                                            it produces.
+                                            The optional timeout argument
+                                            represents the number of seconds the
+                                            test should wait for "cmd" to
+                                            return.
+                                            If the argument is "None", the
+                                            test uses the default instance's
+                                            timeout period, which is 300
+                                            seconds.
+                                            If the argument is "0", the test
+                                            runs until the command returns.
+                                            </para></listitem>
+                                        <listitem><para><emphasis><filename>copy_to(localpath, remotepath)</filename>:</emphasis>
+                                            <filename>scp localpath root@ip:remotepath</filename>.
+                                            </para></listitem>
+                                        <listitem><para><emphasis><filename>copy_from(remotepath, localpath)</filename>:</emphasis>
+                                            <filename>scp root@host:remotepath localpath</filename>.
+                                            </para></listitem>
+                                    </itemizedlist></para></listitem>
+                            </itemizedlist></para></listitem>
+                    </itemizedlist>
+                </para>
+            </section>
+
+            <section id='qemu-image-writing-tests-instance-attributes'>
+                <title>Instance Attributes</title>
+
+                <para>
+                    A single instance attribute exists, which is
+                    <filename>target</filename>.
+                    The <filename>target</filename> instance attribute is
+                    identical to the class attribute of the same name, which
+                    is described in the previous section.
+                    This attribute exists as both an instance and class
+                    attribute so tests can use
+                    <filename>self.target.run(cmd)</filename> in instance
+                    methods instead of
+                    <filename>oeRuntimeTest.tc.target.run(cmd)</filename>.
+                </para>
+            </section>
+        </section>
+    </section>
+
+    <section id="platdev-gdb-remotedebug">
+        <title>Debugging With the GNU Project Debugger (GDB) Remotely</title>
+
+        <para>
+            GDB allows you to examine running programs, which in turn helps you to understand and fix problems.
+            It also allows you to perform post-mortem style analysis of program crashes.
+            GDB is available as a package within the Yocto Project and is
+            installed in SDK images by default.
+            See the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter
+            in the Yocto Project Reference Manual for a description of these images.
+            You can find information on GDB at <ulink url="http://sourceware.org/gdb/"/>.
+        </para>
+
+        <tip>
+            For best results, install debug (<filename>-dbg</filename>) packages
+            for the applications you are going to debug.
+            Doing so makes extra debug symbols available that give you more
+            meaningful output.
+        </tip>
+
+        <para>
+            Sometimes, due to memory or disk space constraints, it is not possible
+            to use GDB directly on the remote target to debug applications.
+            These constraints arise because GDB needs to load the debugging information and the
+            binaries of the process being debugged.
+            Additionally, GDB needs to perform many computations to locate information such as function
+            names, variable names and values, stack traces and so forth - even before starting the
+            debugging process.
+            These extra computations place more load on the target system and can alter the
+            characteristics of the program being debugged.
+        </para>
+
+        <para>
+            To help get past the previously mentioned constraints, you can use Gdbserver.
+            Gdbserver runs on the remote target and does not load any debugging information
+            from the debugged process.
+            Instead, a GDB instance processes the debugging information that is run on a
+            remote computer - the host GDB.
+            The host GDB then sends control commands to Gdbserver to make it stop or start the debugged
+            program, as well as read or write memory regions of that debugged program.
+            All the debugging information loaded and processed as well
+            as all the heavy debugging is done by the host GDB.
+            Offloading these processes gives the Gdbserver running on the target a chance to remain
+            small and fast.
+            <note>
+                By default, source files are part of the
+                <filename>*-dbg</filename> packages in order to enable GDB
+                to show source lines in its output.
+                You can save further space on the target by setting the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_DEBUG_SPLIT_STYLE'><filename>PACKAGE_DEBUG_SPLIT_STYLE</filename></ulink>
+                variable to "debug-without-src" so that these packages do not
+                include the source files.
+            </note>
+        </para>
+
+        <para>
+            Because the host GDB is responsible for loading the debugging information and
+            for doing the necessary processing to make actual debugging happen,
+            you have to make sure the host can access the unstripped binaries complete
+            with their debugging information and also be sure the target is compiled with no optimizations.
+            The host GDB must also have local access to all the libraries used by the
+            debugged program.
+            Because Gdbserver does not need any local debugging information, the binaries on
+            the remote target can remain stripped.
+            However, the binaries must also be compiled without optimization
+            so they match the host's binaries.
+        </para>
+
+        <para>
+            To remain consistent with GDB documentation and terminology, the binary being debugged
+            on the remote target machine is referred to as the "inferior" binary.
+            For documentation on GDB see the
+            <ulink url="http://sourceware.org/gdb/documentation/">GDB site</ulink>.
+        </para>
+
+        <para>
+            The remainder of this section describes the steps you need to take
+            to debug using the GNU project debugger.
+        </para>
+
+        <section id='platdev-gdb-remotedebug-setup'>
+            <title>Set Up the Cross-Development Debugging Environment</title>
+
+            <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.
+                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
+                your environment.
+            </para>
+        </section>
+
+        <section id="platdev-gdb-remotedebug-launch-gdbserver">
+            <title>Launch Gdbserver on the Target</title>
+
+            <para>
+                Make sure Gdbserver is installed on the target.
+                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
+                "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
+                the host computer.
+                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>.
+            </para>
+        </section>
+
+        <section id="platdev-gdb-remotedebug-launch-gdb">
+            <title>Launch GDB on the Host Computer</title>
+
+            <para>
+                Running GDB on the host computer takes a number of stages, which
+                this section describes.
+            </para>
+
+            <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
+                    remote target.
+                    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
+                    <filename>/opt/poky/&DISTRO;</filename>:
+                    <literallayout class='monospaced'>
+     /opt/poky/&DISTRO;/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
+                    and <filename>linux-gnueabi</filename> is the target ABI.
+                </para>
+
+                <para>
+                    Alternatively, you can use BitBake to build the
+                    <filename>gdb-cross</filename> binary.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     $ bitbake gdb-cross
+                    </literallayout>
+                    Once the binary is built, you can find it here:
+                    <literallayout class='monospaced'>
+     tmp/sysroots/<replaceable>host-arch</replaceable>/usr/bin/<replaceable>target-platform</replaceable>/<replaceable>target-abi</replaceable>-gdb
+                    </literallayout>
+                </para>
+            </section>
+
+            <section id='create-the-gdb-initialization-file'>
+                <title>Create the GDB Initialization File and Point to Your Root Filesystem</title>
+
+                <para>
+                    Aside from the GDB cross-binary, you also need a GDB
+                    initialization file in the same top directory in which
+                    your binary resides.
+                    When you start GDB on your host development system, GDB
+                    finds this initialization file and executes all the
+                    commands within.
+                    For information on the <filename>.gdbinit</filename>, see
+                    "<ulink url='http://sourceware.org/gdb/onlinedocs/gdb/'>Debugging with GDB</ulink>",
+                    which is maintained by
+                    <ulink url='http://www.sourceware.org'>sourceware.org</ulink>.
+                </para>
+
+                <para>
+                    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
+                    an ARM-based target device:
+                    <literallayout class='monospaced'>
+     set sysroot ~/sysroot_arm
+                    </literallayout>
+                </para>
+            </section>
+
+            <section id="platdev-gdb-remotedebug-launch-gdb-launchhost">
+                <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>
+                    and begins with the string "environment-setup".
+                    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
+                    Guide.
+                </para>
+
+                <para>
+                    Finally, switch to the directory where the binary resides
+                    and run the <filename>cross-gdb</filename> binary.
+                    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
+                    debugging information:
+                    <literallayout class='monospaced'>
+     $ arm-poky-linux-gnuabi-gdb helloworld
+                    </literallayout>
+                    The commands in your <filename>.gdbinit</filename> execute
+                    and the GDB prompt appears.
+                </para>
+            </section>
+        </section>
+
+        <section id='platdev-gdb-connect-to-the-remote-gdb-server'>
+            <title>Connect to the Remote GDB Server</title>
+
+            <para>
+                From the target, you need to connect to the remote GDB
+                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'>
+     target remote 192.168.7.2:2345
+                </literallayout>
+            </para>
+        </section>
+
+        <section id="platdev-gdb-remotedebug-launch-gdb-using">
+            <title>Use the Debugger</title>
+
+            <para>
+                You can now proceed with debugging as normal - as if you were debugging
+                on the local machine.
+                For example, to instruct GDB to break in the "main" function and then
+                continue with execution of the inferior binary use the following commands
+                from within GDB:
+                <literallayout class='monospaced'>
+     (gdb) break main
+     (gdb) continue
+                </literallayout>
+            </para>
+
+            <para>
+                For more information about using GDB, see the project's online documentation at
+                <ulink url="http://sourceware.org/gdb/download/onlinedocs/"/>.
+            </para>
+        </section>
+    </section>
+
+    <section id='debugging-parallel-make-races'>
+        <title>Debugging Parallel Make Races</title>
+
+        <para>
+            A parallel <filename>make</filename> race occurs when the build
+            consists of several parts that are run simultaneously and
+            a situation occurs when the output or result of one
+            part is not ready for use with a different part of the build that
+            depends on that output.
+            Parallel make races are annoying and can sometimes be difficult
+            to reproduce and fix.
+            However, some simple tips and tricks exist that can help
+            you debug and fix them.
+            This section presents a real-world example of an error encountered
+            on the Yocto Project autobuilder and the process used to fix it.
+        </para>
+
+        <section id='the-failure'>
+            <title>The Failure</title>
+
+            <para>
+                For this example, assume that you are building an image that
+                depends on the "neard" package.
+                And, during the build, BitBake runs into problems and
+                creates the following output.
+                <note>
+                    This example log file has longer lines artificially
+                    broken to make the listing easier to read.
+                </note>
+                If you examine the output or the log file, you see the
+                failure during <filename>make</filename>:
+                <literallayout class='monospaced'>
+     | DEBUG: SITE files ['endian-little', 'bit-32', 'ix86-common', 'common-linux', 'common-glibc', 'i586-linux', 'common']
+     | DEBUG: Executing shell function do_compile
+     | NOTE: make -j 16
+     | make &dash;&dash;no-print-directory all-am
+     | /bin/mkdir -p include/near
+     | /bin/mkdir -p include/near
+     | /bin/mkdir -p include/near
+     | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
+       0.14-r0/neard-0.14/include/types.h include/near/types.h
+     | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
+       0.14-r0/neard-0.14/include/log.h include/near/log.h
+     | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
+       0.14-r0/neard-0.14/include/plugin.h include/near/plugin.h
+     | /bin/mkdir -p include/near
+     | /bin/mkdir -p include/near
+     | /bin/mkdir -p include/near
+     | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
+       0.14-r0/neard-0.14/include/tag.h include/near/tag.h
+     | /bin/mkdir -p include/near
+     | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
+       0.14-r0/neard-0.14/include/adapter.h include/near/adapter.h
+     | /bin/mkdir -p include/near
+     | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
+       0.14-r0/neard-0.14/include/ndef.h include/near/ndef.h
+     | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
+       0.14-r0/neard-0.14/include/tlv.h include/near/tlv.h
+     | /bin/mkdir -p include/near
+     | /bin/mkdir -p include/near
+     | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
+       0.14-r0/neard-0.14/include/setting.h include/near/setting.h
+     | /bin/mkdir -p include/near
+     | /bin/mkdir -p include/near
+     | /bin/mkdir -p include/near
+     | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
+       0.14-r0/neard-0.14/include/device.h include/near/device.h
+     | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
+       0.14-r0/neard-0.14/include/nfc_copy.h include/near/nfc_copy.h
+     | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
+       0.14-r0/neard-0.14/include/snep.h include/near/snep.h
+     | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
+       0.14-r0/neard-0.14/include/version.h include/near/version.h
+     | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
+       0.14-r0/neard-0.14/include/dbus.h include/near/dbus.h
+     | ./src/genbuiltin nfctype1 nfctype2 nfctype3 nfctype4 p2p > src/builtin.h
+     | i586-poky-linux-gcc  -m32 -march=i586 &dash;&dash;sysroot=/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/
+       build/build/tmp/sysroots/qemux86 -DHAVE_CONFIG_H -I. -I./include -I./src -I./gdbus  -I/home/pokybuild/
+       yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/sysroots/qemux86/usr/include/glib-2.0
+       -I/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/sysroots/qemux86/usr/
+       lib/glib-2.0/include  -I/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/
+       tmp/sysroots/qemux86/usr/include/dbus-1.0 -I/home/pokybuild/yocto-autobuilder/yocto-slave/
+       nightly-x86/build/build/tmp/sysroots/qemux86/usr/lib/dbus-1.0/include  -I/home/pokybuild/yocto-autobuilder/
+       yocto-slave/nightly-x86/build/build/tmp/sysroots/qemux86/usr/include/libnl3
+       -DNEAR_PLUGIN_BUILTIN -DPLUGINDIR=\""/usr/lib/near/plugins"\"
+       -DCONFIGDIR=\""/etc/neard\"" -O2 -pipe -g -feliminate-unused-debug-types -c
+       -o tools/snep-send.o tools/snep-send.c
+     | In file included from tools/snep-send.c:16:0:
+     | tools/../src/near.h:41:23: fatal error: near/dbus.h: No such file or directory
+     |  #include &lt;near/dbus.h&gt;
+     |                        ^
+     | compilation terminated.
+     | make[1]: *** [tools/snep-send.o] Error 1
+     | make[1]: *** Waiting for unfinished jobs....
+     | make: *** [all] Error 2
+     | ERROR: oe_runmake failed
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='reproducing-the-error'>
+            <title>Reproducing the Error</title>
+
+            <para>
+                Because race conditions are intermittent, they do not
+                manifest themselves every time you do the build.
+                In fact, most times the build will complete without problems
+                even though the potential race condition exists.
+                Thus, once the error surfaces, you need a way to reproduce it.
+            </para>
+
+            <para>
+                In this example, compiling the "neard" package is causing the
+                problem.
+                So the first thing to do is build "neard" locally.
+                Before you start the build, set the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></ulink>
+                variable in your <filename>local.conf</filename> file to
+                a high number (e.g. "-j 20").
+                Using a high value for <filename>PARALLEL_MAKE</filename>
+                increases the chances of the race condition showing up:
+                <literallayout class='monospaced'>
+     $ bitbake neard
+                </literallayout>
+            </para>
+
+            <para>
+                Once the local build for "neard" completes, start a
+                <filename>devshell</filename> build:
+                <literallayout class='monospaced'>
+     $ bitbake neard -c devshell
+                </literallayout>
+                For information on how to use a
+                <filename>devshell</filename>, see the
+                "<link linkend='platdev-appdev-devshell'>Using a Development Shell</link>"
+                section.
+            </para>
+
+            <para>
+                In the <filename>devshell</filename>, do the following:
+                <literallayout class='monospaced'>
+     $ make clean
+     $ make tools/snep-send.o
+                </literallayout>
+                The <filename>devshell</filename> commands cause the failure
+                to clearly be visible.
+                In this case, a missing dependency exists for the "neard"
+                Makefile target.
+                Here is some abbreviated, sample output with the
+                missing dependency clearly visible at the end:
+                <literallayout class='monospaced'>
+     i586-poky-linux-gcc  -m32 -march=i586 &dash;&dash;sysroot=/home/scott-lenovo/......
+        .
+        .
+        .
+     tools/snep-send.c
+     In file included from tools/snep-send.c:16:0:
+     tools/../src/near.h:41:23: fatal error: near/dbus.h: No such file or directory
+      #include &lt;near/dbus.h&gt;
+                       ^
+     compilation terminated.
+     make: *** [tools/snep-send.o] Error 1
+     $
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='creating-a-patch-for-the-fix'>
+            <title>Creating a Patch for the Fix</title>
+
+            <para>
+                Because there is a missing dependency for the Makefile
+                target, you need to patch the
+                <filename>Makefile.am</filename> file, which is generated
+                from <filename>Makefile.in</filename>.
+                You can use Quilt to create the patch:
+                <literallayout class='monospaced'>
+     $ quilt new parallelmake.patch
+     Patch patches/parallelmake.patch is now on top
+     $ quilt add Makefile.am
+     File Makefile.am added to patch patches/parallelmake.patch
+                </literallayout>
+                For more information on using Quilt, see the
+                "<link linkend='using-a-quilt-workflow'>Using a Quilt Workflow</link>"
+                section.
+            </para>
+
+            <para>
+                At this point you need to make the edits to
+                <filename>Makefile.am</filename> to add the missing
+                dependency.
+                For our example, you have to add the following line
+                to the file:
+                <literallayout class='monospaced'>
+     tools/snep-send.$(OBJEXT): include/near/dbus.h
+                </literallayout>
+            </para>
+
+            <para>
+                Once you have edited the file, use the
+                <filename>refresh</filename> command to create the patch:
+                <literallayout class='monospaced'>
+     $ quilt refresh
+     Refreshed patch patches/parallelmake.patch
+                </literallayout>
+                Once the patch file exists, you need to add it back to the
+                originating recipe folder.
+                Here is an example assuming a top-level
+                <link linkend='source-directory'>Source Directory</link>
+                named <filename>poky</filename>:
+                <literallayout class='monospaced'>
+     $ cp patches/parallelmake.patch poky/meta/recipes-connectivity/neard/neard
+                </literallayout>
+                The final thing you need to do to implement the fix in the
+                build is to update the "neard" recipe (i.e.
+                <filename>neard-0.14.bb</filename>) so that the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                statement includes the patch file.
+                The recipe file is in the folder above the patch.
+                Here is what the edited <filename>SRC_URI</filename>
+                statement would look like:
+                <literallayout class='monospaced'>
+     SRC_URI = "${KERNELORG_MIRROR}/linux/network/nfc/${BPN}-${PV}.tar.xz \
+                file://neard.in \
+                file://neard.service.in \
+                file://parallelmake.patch \
+               "
+                </literallayout>
+            </para>
+
+            <para>
+                With the patch complete and moved to the correct folder and
+                the <filename>SRC_URI</filename> statement updated, you can
+                exit the <filename>devshell</filename>:
+                <literallayout class='monospaced'>
+     $ exit
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='testing-the-build'>
+            <title>Testing the Build</title>
+
+            <para>
+                With everything in place, you can get back to trying the
+                build again locally:
+                <literallayout class='monospaced'>
+     $ bitbake neard
+                </literallayout>
+                This build should succeed.
+            </para>
+
+            <para>
+                Now you can open up a <filename>devshell</filename> again
+                and repeat the clean and make operations as follows:
+                <literallayout class='monospaced'>
+     $ bitbake neard -c devshell
+     $ make clean
+     $ make tools/snep-send.o
+                </literallayout>
+                The build should work without issue.
+            </para>
+
+            <para>
+                As with all solved problems, if they originated upstream, you
+                need to submit the fix for the recipe in OE-Core and upstream
+                so that the problem is taken care of at its source.
+                See the
+                "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
+                section for more information.
+            </para>
+        </section>
+    </section>
+
+    <section id="examining-builds-using-toaster">
+        <title>Examining Builds Using the Toaster API</title>
+
+        <para>
+            Toaster is an Application Programming Interface (API) and
+            web-based interface to the OpenEmbedded build system, which uses
+            BitBake.
+            Both interfaces are based on a Representational State Transfer
+            (REST) API that queries for and returns build information using
+            <filename>GET</filename> and <filename>JSON</filename>.
+            These types of search operations retrieve sets of objects from
+            a datastore used to collect build information.
+            The results contain all the data for the objects being returned.
+            You can order the results of the search by key and the search
+            parameters are consistent for all object types.
+        </para>
+
+        <para>
+            Using the interfaces you can do the following:
+            <itemizedlist>
+                <listitem><para>See information about the tasks executed
+                    and reused during the build.</para></listitem>
+                <listitem><para>See what is built (recipes and
+                    packages) and what packages were installed into the final
+                    image.</para></listitem>
+                <listitem><para>See performance-related information such
+                    as build time, CPU usage, and disk I/O.</para></listitem>
+                <listitem><para>Examine error, warning and trace messages
+                    to aid in debugging.</para></listitem>
+            </itemizedlist>
+        </para>
+
+        <note>
+            <para>This release of Toaster provides you with information
+            about a BitBake run.
+            The tool does not allow you to configure and launch a build.
+            However, future development includes plans to integrate the
+            configuration and build launching capabilities of
+            <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink>.
+            </para>
+            <para>For more information on using Hob to build an image,
+            see the
+            "<link linkend='image-development-using-hob'>Image Development Using Hob</link>"
+            section.</para>
+        </note>
+
+        <para>
+            The remainder of this section describes what you need to have in
+            place to use Toaster, how to start it, use it, and stop it.
+            For additional information on installing and running Toaster, see the
+            "<ulink url='https://wiki.yoctoproject.org/wiki/Toaster#Installation_and_Running'>Installation and Running</ulink>"
+            section of the "Toaster" wiki page.
+            For complete information on the API and its search operation
+            URI, parameters, and responses, see the
+            <ulink url='https://wiki.yoctoproject.org/wiki/REST_API_Contracts'>REST API Contracts</ulink>
+            Wiki page.
+        </para>
+
+        <section id='starting-toaster'>
+            <title>Starting Toaster</title>
+
+            <para>
+                Getting set up to use and start Toaster is simple.
+                First, be sure you have met the following requirements:
+                <itemizedlist>
+                    <listitem><para>You have set up your
+                        <link linkend='source-directory'>Source Directory</link>
+                        by cloning the upstream <filename>poky</filename>
+                        repository.
+                        See the
+                        <link linkend='local-yp-release'>Yocto Project Release</link>
+                        item for information on how to set up the Source
+                        Directory.</para></listitem>
+                    <listitem><para>Be sure your build machine has
+                        <ulink url='http://en.wikipedia.org/wiki/Django_%28web_framework%29'>Django</ulink>
+                        version 1.5 installed.</para></listitem>
+                    <listitem><para>Make sure that port 8000 and 8200 are
+                        free (i.e. they have no servers on them).
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                Once you have met the requirements, follow these steps to
+                start Toaster running in the background of your shell:
+                <orderedlist>
+                    <listitem><para><emphasis>Set up your build environment:</emphasis>
+                        Source a build environment script (i.e.
+                        <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                        or
+                        <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>).
+                        </para></listitem>
+                    <listitem><para><emphasis>Start Toaster:</emphasis>
+                        Start the Toaster service using this
+                        command from within your
+                        <link linkend='build-directory'>Build Directory</link>:
+                        <literallayout class='monospaced'>
+     $ source toaster start
+                        </literallayout></para></listitem>
+                        <note>
+                            The Toaster must be started and running in order
+                            for it to collect data.
+                        </note>
+                </orderedlist>
+            </para>
+
+            <para>
+                When Toaster starts, it creates some additional files in your
+                Build Directory.
+                Deleting these files will cause you to lose data or interrupt
+                Toaster:
+                <itemizedlist>
+                    <listitem><para><emphasis><filename>toaster.sqlite</filename>:</emphasis>
+                        Toaster's database file.</para></listitem>
+                    <listitem><para><emphasis><filename>toaster_web.log</filename>:</emphasis>
+                        The log file of the web server.</para></listitem>
+                    <listitem><para><emphasis><filename>toaster_ui.log</filename>:</emphasis>
+                        The log file of the user interface component.
+                        </para></listitem>
+                    <listitem><para><emphasis><filename>toastermain.pid</filename>:</emphasis>
+                        The PID of the web server.</para></listitem>
+                    <listitem><para><emphasis><filename>toasterui.pid</filename>:</emphasis>
+                        The PID of the DSI data bridge.</para></listitem>
+                    <listitem><para><emphasis><filename>bitbake-cookerdaemon.log</filename>:</emphasis>
+                        The BitBake server's log file.</para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='using-toaster'>
+            <title>Using Toaster</title>
+
+            <para>
+                Once Toaster is running, it logs information for any BitBake
+                run from your Build Directory.
+                This logging is automatic.
+                All you need to do is access and use the information.
+            </para>
+
+            <para>
+                You access the information one of two ways:
+                <itemizedlist>
+                    <listitem><para>Open a Browser and enter
+                        <filename>http://localhost:8000</filename>
+                        for the URL.
+                        </para></listitem>
+                    <listitem><para>Use the <filename>xdg-open</filename>
+                        tool from the shell and pass it the same URL.
+                        </para></listitem>
+                </itemizedlist>
+                Either method opens the home page for the Toaster interface.
+            </para>
+
+            <note><title>Notes</title>
+                <itemizedlist>
+                    <listitem><para>
+                        For information on how to delete information from the
+                        Toaster database, see the
+                        <ulink url='https://wiki.yoctoproject.org/wiki/Toaster#Deleting_a_Build_from_the_Toaster_Database'>Deleting a Build from the Toaster Database</ulink>
+                        wiki page.
+                        </para></listitem>
+                    <listitem><para>
+                        For information on how to set up an instance of Toaster
+                        on a remote host, see the
+                        <ulink url='https://wiki.yoctoproject.org/wiki/Toaster#Setting_up_a_Toaster_Instance_on_a_Remote_Host'>Setting Up a Toaster Instance on a Remote Host</ulink>
+                        wiki page.
+                        </para></listitem>
+                </itemizedlist>
+            </note>
+        </section>
+
+        <section id='examining-toaster-data'>
+            <title>Examining Toaster Data</title>
+
+            <para>
+                The Toaster database is persistent regardless of whether you
+                start or stop the service.
+            </para>
+
+            <para>
+                Toaster's interface shows you a list of builds
+                (successful and unsuccessful) for which it has data.
+                You can click on any build to see related information.
+                This information includes configuration details, information
+                about tasks, all recipes and packages built and their
+                dependencies, packages and their directory structure as
+                installed in your final image,
+                execution time, CPU usage and disk I/O per task.
+            </para>
+
+            <para>
+                For details on the interface, see the
+                <ulink url='https://www.yoctoproject.org/documentation/toaster-manual'>Toaster Manual</ulink>.
+            </para>
+        </section>
+
+        <section id='stopping-toaster'>
+            <title>Stopping Toaster</title>
+
+            <para>
+                Stop the Toaster service with the following command
+                from with the
+                <link linkend='build-directory'>Build Directory</link>:
+                <literallayout class='monospaced'>
+     $ source toaster stop
+                </literallayout>
+                The service stops but the Toaster database remains persistent.
+            </para>
+        </section>
+    </section>
+
+    <section id="platdev-oprofile">
+        <title>Profiling with OProfile</title>
+
+        <para>
+            <ulink url="http://oprofile.sourceforge.net/">OProfile</ulink> is a
+            statistical profiler well suited for finding performance
+            bottlenecks in both user-space software and in the kernel.
+            This profiler provides answers to questions like "Which functions does my application spend
+            the most time in when doing X?"
+            Because the OpenEmbedded build system is well integrated with OProfile, it makes profiling
+            applications on target hardware straight forward.
+            <note>
+                For more information on how to set up and run OProfile, see the
+                "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-oprofile'>oprofile</ulink>"
+                section in the Yocto Project Profiling and Tracing Manual.
+            </note>
+        </para>
+
+        <para>
+            To use OProfile, you need an image that has OProfile installed.
+            The easiest way to do this is with "tools-profile" in the
+            <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES'>IMAGE_FEATURES</ulink></filename> variable.
+            You also need debugging symbols to be available on the system where the analysis
+            takes place.
+            You can gain access to the symbols by using "dbg-pkgs" in the
+            <filename>IMAGE_FEATURES</filename> variable or by
+            installing the appropriate debug (<filename>-dbg</filename>)
+            packages.
+        </para>
+
+        <para>
+            For successful call graph analysis, the binaries must preserve the frame
+            pointer register and should also be compiled with the
+            <filename>-fno-omit-framepointer</filename> flag.
+            You can achieve this by setting the
+            <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-SELECTED_OPTIMIZATION'>SELECTED_OPTIMIZATION</ulink></filename>
+            variable with the following options:
+            <literallayout class='monospaced'>
+     -fexpensive-optimizations
+     -fno-omit-framepointer
+     -frename-registers
+     -O2
+            </literallayout>
+            You can also achieve it by setting the
+            <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
+            packages large.
+        </para>
+
+        <section id="platdev-oprofile-target">
+            <title>Profiling on the Target</title>
+
+            <para>
+                Using OProfile, you can perform all the profiling work on the target device.
+                A simple OProfile session might look like the following:
+            </para>
+
+            <para>
+                <literallayout class='monospaced'>
+     # opcontrol &dash;&dash;reset
+     # opcontrol &dash;&dash;start &dash;&dash;separate=lib &dash;&dash;no-vmlinux -c 5
+              .
+              .
+        [do whatever is being profiled]
+              .
+              .
+     # opcontrol &dash;&dash;stop
+     $ opreport -cl
+                </literallayout>
+            </para>
+
+            <para>
+                In this example, the <filename>reset</filename> command clears any previously profiled data.
+                The next command starts OProfile.
+                The options used when starting the profiler separate dynamic library data
+                within applications, disable kernel profiling, and enable callgraphing up to
+                five levels deep.
+                <note>
+                    To profile the kernel, you would specify the
+                    <filename>&dash;&dash;vmlinux=/path/to/vmlinux</filename> option.
+                    The <filename>vmlinux</filename> file is usually in the source directory in the
+                    <filename>/boot/</filename> directory and must match the running kernel.
+                </note>
+            </para>
+
+            <para>
+                After you perform your profiling tasks, the next command stops the profiler.
+                After that, you can view results with the <filename>opreport</filename> command with options
+                to see the separate library symbols and callgraph information.
+            </para>
+
+            <para>
+                Callgraphing logs information about time spent in functions and about a function's
+                calling function (parent) and called functions (children).
+                The higher the callgraphing depth, the more accurate the results.
+                However, higher depths also increase the logging overhead.
+                Consequently, you should take care when setting the callgraphing depth.
+                <note>
+                    On ARM, binaries need to have the frame pointer enabled for callgraphing to work.
+                    To accomplish this use the <filename>-fno-omit-framepointer</filename> option
+                    with <filename>gcc</filename>.
+                </note>
+            </para>
+
+            <para>
+                For more information on using OProfile, see the OProfile
+                online documentation at
+                <ulink url="http://oprofile.sourceforge.net/docs/"/>.
+            </para>
+        </section>
+
+        <section id="platdev-oprofile-oprofileui">
+            <title>Using OProfileUI</title>
+
+            <para>
+                A graphical user interface for OProfile is also available.
+                You can download and build this interface from the Yocto Project at
+                <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
+                "<ulink url='&YOCTO_DOCS_REF_URL;#ref-features-image'>Image Features</ulink>"
+                section in the Yocto Project Reference Manual.
+            </para>
+
+            <para>
+                Even though the source directory usually includes all needed patches on the target device, you
+                might find you need other OProfile patches for recent OProfileUI features.
+                If so, see the <ulink url='&YOCTO_GIT_URL;/cgit.cgi/oprofileui/tree/README'>
+                OProfileUI README</ulink> for the most recent information.
+            </para>
+
+            <section id="platdev-oprofile-oprofileui-online">
+                <title>Online Mode</title>
+
+                <para>
+                    Using OProfile in online mode assumes a working network connection with the target
+                    hardware.
+                    With this connection, you just need to run "oprofile-server" on the device.
+                    By default, OProfile listens on port 4224.
+                    <note>
+                        You can change the port using the <filename>&dash;&dash;port</filename> command-line
+                        option.
+                    </note>
+                </para>
+
+                <para>
+                    The client program is called <filename>oprofile-viewer</filename> and its UI is relatively
+                    straight forward.
+                    You access key functionality through the buttons on the toolbar, which
+                    are duplicated in the menus.
+                    Here are the buttons:
+                    <itemizedlist>
+                        <listitem><para><emphasis>Connect:</emphasis> Connects to the remote host.
+                            You can also supply the IP address or hostname.</para></listitem>
+                        <listitem><para><emphasis>Disconnect:</emphasis> Disconnects from the target.
+                            </para></listitem>
+                        <listitem><para><emphasis>Start:</emphasis> Starts profiling on the device.
+                            </para></listitem>
+                        <listitem><para><emphasis>Stop:</emphasis> Stops profiling on the device and
+                            downloads the data to the local host.
+                            Stopping the profiler generates the profile and displays it in the viewer.
+                            </para></listitem>
+                        <listitem><para><emphasis>Download:</emphasis> Downloads the data from the
+                            target and generates the profile, which appears in the viewer.</para></listitem>
+                        <listitem><para><emphasis>Reset:</emphasis> Resets the sample data on the device.
+                            Resetting the data removes sample information collected from previous
+                            sampling runs.
+                            Be sure you reset the data if you do not want to include old sample information.
+                            </para></listitem>
+                        <listitem><para><emphasis>Save:</emphasis> Saves the data downloaded from the
+                            target to another directory for later examination.</para></listitem>
+                        <listitem><para><emphasis>Open:</emphasis> Loads previously saved data.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    The client downloads the complete profile archive from
+                    the target to the host for processing.
+                    This archive is a directory that contains the sample data, the object files,
+                    and the debug information for the object files.
+                    The archive is then converted using the <filename>oparchconv</filename> script, which is
+                    included in this distribution.
+                    The script uses <filename>opimport</filename> to convert the archive from
+                    the target to something that can be processed on the host.
+                </para>
+
+                <para>
+                    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>
+
+                <para>
+                    If you wish to perform kernel profiling, you need to be sure
+                    a <filename>vmlinux</filename> file that matches the running kernel is available.
+                    In the source directory, that file is usually located in
+                    <filename>/boot/vmlinux-<replaceable>kernelversion</replaceable></filename>, where
+                    <filename><replaceable>kernelversion</replaceable></filename> is the version of the kernel.
+                    The OpenEmbedded build system generates separate <filename>vmlinux</filename>
+                    packages for each kernel it builds.
+                    Thus, it should just be a question of making sure a matching package is
+                    installed (e.g. <filename>opkg install kernel-vmlinux</filename>).
+                    The files are automatically installed into development and profiling images
+                    alongside OProfile.
+                    A configuration option exists within the OProfileUI settings page that you can use to
+                    enter the location of the <filename>vmlinux</filename> file.
+                </para>
+
+                <para>
+                    Waiting for debug symbols to transfer from the device can be slow, and it
+                    is not always necessary to actually have them on the device for OProfile use.
+                    All that is needed is a copy of the filesystem with the debug symbols present
+                    on the viewer system.
+                    The "<link linkend='platdev-gdb-remotedebug-launch-gdb'>Launch GDB on the Host Computer</link>"
+                    section covers how to create such a directory within
+                    the source directory and how to use the OProfileUI Settings
+                    Dialog to specify the location.
+                    If you specify the directory, it will be used when the file checksums
+                    match those on the system you are profiling.
+                </para>
+            </section>
+
+            <section id="platdev-oprofile-oprofileui-offline">
+                <title>Offline Mode</title>
+
+                <para>
+                    If network access to the target is unavailable, you can generate
+                    an archive for processing in <filename>oprofile-viewer</filename> as follows:
+                    <literallayout class='monospaced'>
+     # opcontrol &dash;&dash;reset
+     # opcontrol &dash;&dash;start &dash;&dash;separate=lib &dash;&dash;no-vmlinux -c 5
+            .
+            .
+     [do whatever is being profiled]
+            .
+            .
+     # opcontrol &dash;&dash;stop
+     # oparchive -o my_archive
+                    </literallayout>
+                </para>
+
+                <para>
+                    In the above example, <filename>my_archive</filename> is the name of the
+                    archive directory where you would like the profile archive to be kept.
+                    After the directory is created, you can copy it to another host and load it
+                    using <filename>oprofile-viewer</filename> open functionality.
+                    If necessary, the archive is converted.
+                </para>
+            </section>
+        </section>
+    </section>
+
+    <section id='maintaining-open-source-license-compliance-during-your-products-lifecycle'>
+        <title>Maintaining Open Source License Compliance During Your Product's Lifecycle</title>
+
+        <para>
+            One of the concerns for a development organization using open source
+            software is how to maintain compliance with various open source
+            licensing during the lifecycle of the product.
+            While this section does not provide legal advice or
+            comprehensively cover all scenarios, it does
+            present methods that you can use to
+            assist you in meeting the compliance requirements during a software
+            release.
+        </para>
+
+        <para>
+            With hundreds of different open source licenses that the Yocto
+            Project tracks, it is difficult to know the requirements of each
+            and every license.
+            However, the requirements of the major FLOSS licenses can begin
+            to be covered by
+            assuming that three main areas of concern exist:
+            <itemizedlist>
+                <listitem><para>Source code must be provided.</para></listitem>
+                <listitem><para>License text for the software must be
+                    provided.</para></listitem>
+                <listitem><para>Compilation scripts and modifications to the
+                    source code must be provided.
+                    </para></listitem>
+            </itemizedlist>
+            There are other requirements beyond the scope of these
+            three and the methods described in this section
+            (e.g. the mechanism through which source code is distributed).
+        </para>
+
+        <para>
+            As different organizations have different methods of complying with
+            open source licensing, this section is not meant to imply that
+            there is only one single way to meet your compliance obligations,
+            but rather to describe one method of achieving compliance.
+            The remainder of this section describes methods supported to meet the
+            previously mentioned three requirements.
+            Once you take steps to meet these requirements,
+            and prior to releasing images, sources, and the build system,
+            you should audit all artifacts to ensure completeness.
+            <note>
+                The Yocto Project generates a license manifest during
+                image creation that is located
+                in <filename>${DEPLOY_DIR}/licenses/<replaceable>image_name-datestamp</replaceable></filename>
+                to assist with any audits.
+            </note>
+        </para>
+
+        <section id='providing-the-source-code'>
+            <title>Providing the Source Code</title>
+
+            <para>
+                Compliance activities should begin before you generate the
+                final image.
+                The first thing you should look at is the requirement that
+                tops the list for most compliance groups - providing
+                the source.
+                The Yocto Project has a few ways of meeting this
+                requirement.
+            </para>
+
+            <para>
+                One of the easiest ways to meet this requirement is
+                to provide the entire
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-DL_DIR'><filename>DL_DIR</filename></ulink>
+                used by the build.
+                This method, however, has a few issues.
+                The most obvious is the size of the directory since it includes
+                all sources used in the build and not just the source used in
+                the released image.
+                It will include toolchain source, and other artifacts, which
+                you would not generally release.
+                However, the more serious issue for most companies is accidental
+                release of proprietary software.
+                The Yocto Project provides an
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-archiver'><filename>archiver</filename></ulink>
+                class to help avoid some of these concerns.
+            </para>
+
+            <para>
+                Before you employ <filename>DL_DIR</filename> or the
+                archiver class, you need to decide how you choose to
+                provide source.
+                The source archiver class can generate tarballs and SRPMs
+                and can create them with various levels of compliance in mind.
+            </para>
+
+            <para>
+                One way of doing this (but certainly not the only way) is to
+                release just the source as a tarball.
+                You can do this by adding the following to the
+                <filename>local.conf</filename> file found in the
+                <link linkend='build-directory'>Build Directory</link>:
+                <literallayout class='monospaced'>
+     INHERIT += "archiver"
+     ARCHIVER_MODE[src] = "original"
+                </literallayout>
+                During the creation of your image, the source from all
+                recipes that deploy packages to the image is placed within
+                subdirectories of
+                <filename>DEPLOY_DIR/sources</filename> based on the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE'><filename>LICENSE</filename></ulink>
+                for each recipe.
+                Releasing the entire directory enables you to comply with
+                requirements concerning providing the unmodified source.
+                It is important to note that the size of the directory can
+                get large.
+            </para>
+
+            <para>
+                A way to help mitigate the size issue is to only release
+                tarballs for licenses that require the release of
+                source.
+                Let us assume you are only concerned with GPL code as
+                identified with the following:
+                <literallayout class='monospaced'>
+     $ cd poky/build/tmp/deploy/sources
+     $ mkdir ~/gpl_source_release
+     $ for dir in */*GPL*; do cp -r $dir ~/gpl_source_release; done
+                </literallayout>
+                At this point, you could create a tarball from the
+                <filename>gpl_source_release</filename> directory and
+                provide that to the end user.
+                This method would be a step toward achieving compliance
+                with section 3a of GPLv2 and with section 6 of GPLv3.
+            </para>
+        </section>
+
+        <section id='providing-license-text'>
+            <title>Providing License Text</title>
+
+            <para>
+                One requirement that is often overlooked is inclusion
+                of license text.
+                This requirement also needs to be dealt with prior to
+                generating the final image.
+                Some licenses require the license text to accompany
+                the binary.
+                You can achieve this by adding the following to your
+                <filename>local.conf</filename> file:
+                <literallayout class='monospaced'>
+     COPY_LIC_MANIFEST = "1"
+     COPY_LIC_DIRS = "1"
+                </literallayout>
+                Adding these statements to the configuration file ensures
+                that the licenses collected during package generation
+                are included on your image.
+                As the source archiver has already archived the original
+                unmodified source that contains the license files,
+                you would have already met the requirements for inclusion
+                of the license information with source as defined by the GPL
+                and other open source licenses.
+            </para>
+        </section>
+
+        <section id='providing-compilation-scripts-and-source-code-modifications'>
+            <title>Providing Compilation Scripts and Source Code Modifications</title>
+
+            <para>
+                At this point, we have addressed all we need to address
+                prior to generating the image.
+                The next two requirements are addressed during the final
+                packaging of the release.
+            </para>
+
+            <para>
+                By releasing the version of the OpenEmbedded build system
+                and the layers used during the build, you will be providing both
+                compilation scripts and the source code modifications in one
+                step.
+            </para>
+
+            <para>
+                If the deployment team has a
+                <ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP layer</ulink>
+                and a distro layer, and those those layers are used to patch,
+                compile, package, or modify (in any way) any open source
+                software included in your released images, you
+                might be required to to release those layers under section 3 of
+                GPLv2 or section 1 of GPLv3.
+                One way of doing that is with a clean
+                checkout of the version of the Yocto Project and layers used
+                during your build.
+                Here is an example:
+                <literallayout class='monospaced'>
+     # We built using the &DISTRO_NAME; branch of the poky repo
+     $ git clone -b &DISTRO_NAME; git://git.yoctoproject.org/poky
+     $ cd poky
+     # We built using the release_branch for our layers
+     $ git clone -b release_branch git://git.mycompany.com/meta-my-bsp-layer
+     $ git clone -b release_branch git://git.mycompany.com/meta-my-software-layer
+     # clean up the .git repos
+     $ find . -name ".git" -type d -exec rm -rf {} \;
+                </literallayout>
+                One thing a development organization might want to consider
+                for end-user convenience is to modify
+                <filename>meta-yocto/conf/bblayers.conf.sample</filename> to
+                ensure that when the end user utilizes the released build
+                system to build an image, the development organization's
+                layers are included in the <filename>bblayers.conf</filename>
+                file automatically:
+                <literallayout class='monospaced'>
+     # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
+     # changes incompatibly
+     LCONF_VERSION = "6"
+
+     BBPATH = "${TOPDIR}"
+     BBFILES ?= ""
+
+     BBLAYERS ?= " \
+       ##OEROOT##/meta \
+       ##OEROOT##/meta-yocto \
+       ##OEROOT##/meta-yocto-bsp \
+       ##OEROOT##/meta-mylayer \
+       "
+
+     BBLAYERS_NON_REMOVABLE ?= " \
+       ##OEROOT##/meta \
+       ##OEROOT##/meta-yocto \
+       "
+                </literallayout>
+                Creating and providing an archive of the
+                <link linkend='metadata'>Metadata</link> layers
+                (recipes, configuration files, and so forth)
+                enables you to meet your
+                requirements to include the scripts to control compilation
+                as well as any modifications to the original source.
+            </para>
+        </section>
+    </section>
+
+    <section id='using-the-error-reporting-tool'>
+        <title>Using the Error Reporting Tool</title>
+
+        <para>
+            The error reporting tool allows you to
+            submit errors encountered during builds to a central database.
+            Outside of the build environment, you can use a web interface to
+            browse errors, view statistics, and query for errors.
+            The tool works using a client-server system where the client
+            portion is integrated with the installed Yocto Project
+            <link linkend='source-directory'>Source Directory</link>
+            (e.g. <filename>poky</filename>).
+            The server receives the information collected and saves it in a
+            database.
+        </para>
+
+        <para>
+            A live instance of the error reporting server exists at
+            <ulink url='http://errors.yoctoproject.org'></ulink>.
+            This server exists so that when you want to get help with
+            build failures, you can submit all of the information on the
+            failure easily and then point to the URL in your bug report
+            or send an email to the mailing list.
+            <note>
+                If you send error reports to this server, the reports become
+                publicly visible.
+            </note>
+        </para>
+
+        <section id='enabling-and-using-the-tool'>
+            <title>Enabling and Using the Tool</title>
+
+            <para>
+                By default, the error reporting tool is disabled.
+                You can enable it by inheriting the
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-report-error'><filename>report-error</filename></ulink>
+                class by adding the following statement to the end of
+                your <filename>local.conf</filename> file in your
+                <link linkend='build-directory'>Build Directory</link>.
+                <literallayout class='monospaced'>
+     INHERIT += "report-error"
+                </literallayout>
+            </para>
+
+            <para>
+                By default, the error reporting feature stores information in
+                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-LOG_DIR'><filename>LOG_DIR</filename></ulink><filename>}/error-report</filename>.
+                However, you can specify a directory to use by adding the following
+                to your <filename>local.conf</filename> file:
+                <literallayout class='monospaced'>
+     ERR_REPORT_DIR = "path"
+                </literallayout>
+                Enabling error reporting causes the build process to collect
+                the errors and store them in a file as previously described.
+                When the build system encounters an error, it includes a command
+                as part of the console output.
+                You can run the command to send the error file to the server.
+                For example, the following command sends the errors to an upstream
+                server:
+                <literallayout class='monospaced'>
+     send-error-report /home/brandusa/project/poky/build/tmp/log/error-report/error_report_201403141617.txt [server]
+                </literallayout>
+                In the above example, the <filename>server</filename> parameter is
+                optional.
+                By default, the errors are sent to a database used by the entire
+                community.
+                If you specify a particular server, you can send them to a different
+                database.
+            </para>
+
+            <para>
+                When sending the error file, you receive a link that corresponds
+                to your entry in the database.
+                For example, here is a typical link:
+                <literallayout class='monospaced'>
+     http://localhost:8000/Errors/Search/1/158
+                </literallayout>
+                Following the link takes you to a web interface where you can
+                browse, query the errors, and view statistics.
+             </para>
+        </section>
+
+        <section id='disabling-the-tool'>
+            <title>Disabling the Tool</title>
+
+            <para>
+                To disable the error reporting feature, simply remove or comment
+                out the following statement from the end of your
+                <filename>local.conf</filename> file in your
+                <link linkend='build-directory'>Build Directory</link>.
+                <literallayout class='monospaced'>
+     INHERIT += "report-error"
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='setting-up-your-own-error-reporting-server'>
+            <title>Setting Up Your Own Error Reporting Server</title>
+
+            <para>
+                If you want to set up your own error reporting server, you
+                can obtain the code from the Git repository at
+                <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/error-report-web/'></ulink>.
+                Instructions on how to set it up are in the README document.
+            </para>
+        </section>
+     </section>
+</chapter>
+
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/dev-manual/dev-manual-customization.xsl b/documentation/dev-manual/dev-manual-customization.xsl
new file mode 100644
index 0000000000..5dd425c810
--- /dev/null
+++ b/documentation/dev-manual/dev-manual-customization.xsl
@@ -0,0 +1,19 @@
+<?xml version='1.0'?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
+
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
+
+  <xsl:include href="../template/permalinks.xsl"/>
+  <xsl:include href="../template/section.title.xsl"/>
+  <xsl:include href="../template/component.title.xsl"/>
+  <xsl:include href="../template/division.title.xsl"/>
+  <xsl:include href="../template/formal.object.heading.xsl"/>
+
+  <xsl:param name="html.stylesheet" select="'dev-style.css'" />
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="appendix.autolabel" select="A" />
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+  <xsl:param name="generate.id.attributes" select="1" />
+
+</xsl:stylesheet>
diff --git a/documentation/dev-manual/dev-manual-eclipse-customization.xsl b/documentation/dev-manual/dev-manual-eclipse-customization.xsl
new file mode 100644
index 0000000000..8ac4c18f25
--- /dev/null
+++ b/documentation/dev-manual/dev-manual-eclipse-customization.xsl
@@ -0,0 +1,27 @@
+<?xml version='1.0'?>
+<xsl:stylesheet
+        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+        xmlns="http://www.w3.org/1999/xhtml"
+        xmlns:fo="http://www.w3.org/1999/XSL/Format"
+        version="1.0">
+
+  <xsl:import
+          href="http://docbook.sourceforge.net/release/xsl/current/eclipse/eclipse3.xsl" />
+
+  <xsl:param name="chunker.output.indent" select="'yes'"/>
+  <xsl:param name="chunk.quietly" select="1"/>
+  <xsl:param name="chunk.first.sections" select="1"/>
+  <xsl:param name="chunk.section.depth" select="10"/>
+  <xsl:param name="use.id.as.filename" select="1"/>
+  <xsl:param name="ulink.target" select="'_self'" />
+  <xsl:param name="base.dir" select="'html/dev-manual/'"/>
+  <xsl:param name="html.stylesheet" select="'../book.css'"/>
+  <xsl:param name="eclipse.manifest" select="0"/>
+  <xsl:param name="create.plugin.xml" select="0"/>
+  <xsl:param name="suppress.navigation" select="1"/>
+  <xsl:param name="generate.index" select="0"/>
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="appendix.autolabel" select="1" />
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+</xsl:stylesheet>
diff --git a/documentation/dev-manual/dev-manual-intro.xml b/documentation/dev-manual/dev-manual-intro.xml
new file mode 100644
index 0000000000..21fba29670
--- /dev/null
+++ b/documentation/dev-manual/dev-manual-intro.xml
@@ -0,0 +1,240 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='dev-manual-intro'>
+
+<title>The Yocto Project Development Manual</title>
+    <section id='intro'>
+        <title>Introduction</title>
+
+        <para>
+            Welcome to the Yocto Project Development Manual!
+            This manual provides information on how to use the Yocto Project to
+            develop embedded Linux images and user-space applications that
+            run on targeted devices.
+            The manual provides an overview of image, kernel, and
+            user-space application development using the Yocto Project.
+            Because much of the information in this manual is general, it
+            contains many references to other sources where you can find more
+            detail.
+            For example, you can find detailed information on Git, repositories,
+            and open source in general in many places on the Internet.
+            Another example specific to the Yocto Project is how to quickly
+            set up your host development system and build an image, which you
+            find in the
+            <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>.
+        </para>
+
+        <para>
+            The Yocto Project Development Manual does, however, provide
+            guidance and examples on how to change the kernel source code,
+            reconfigure the kernel, and develop an application using the
+            popular <trademark class='trade'>Eclipse</trademark> IDE.
+        </para>
+
+        <note>
+            By default, using the Yocto Project creates a Poky distribution.
+            However, you can create your own distribution by providing key
+            <link linkend='metadata'>Metadata</link>.
+            A good example is Angstrom, which has had a distribution
+            based on the Yocto Project since its inception.
+            Other examples include commercial distributions like
+            <ulink url='https://www.yoctoproject.org/organization/wind-river-systems'>Wind River Linux</ulink>,
+            <ulink url='https://www.yoctoproject.org/organization/mentor-graphics'>Mentor Embedded Linux</ulink>,
+            <ulink url='https://www.yoctoproject.org/organization/enea-ab'>ENEA Linux</ulink>
+            and <ulink url='https://www.yoctoproject.org/ecosystem/member-organizations'>others</ulink>.
+            See the "<link linkend='creating-your-own-distribution'>Creating Your Own Distribution</link>"
+            section for more information.
+        </note>
+    </section>
+
+    <section id='what-this-manual-provides'>
+        <title>What This Manual Provides</title>
+
+        <para>
+            The following list describes what you can get from this manual:
+            <itemizedlist>
+                <listitem><para>Information that lets you get set
+                    up to develop using the Yocto Project.</para></listitem>
+                <listitem><para>Information to help developers who are new to
+                    the open source environment and to the distributed revision
+                    control system Git, which the Yocto Project uses.
+                    </para></listitem>
+                <listitem><para>An understanding of common end-to-end
+                    development models and tasks.</para></listitem>
+                <listitem><para>Information about common development tasks
+                    generally used during image development for
+                    embedded devices.
+                    </para></listitem>
+                <listitem><para>Information on using the Yocto Project
+                    integration of the QuickEMUlator (QEMU), which lets you
+                    simulate running on hardware an image you have built using
+                    the OpenEmbedded build system.
+                    </para></listitem>
+                <listitem><para>Many references to other sources of related
+                    information.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='what-this-manual-does-not-provide'>
+        <title>What this Manual Does Not Provide</title>
+
+        <para>
+            This manual will not give you the following:
+            <itemizedlist>
+                <listitem><para><emphasis>Step-by-step instructions when those instructions exist in other Yocto
+                    Project documentation:</emphasis>
+                    For example, the Yocto Project Application Developer's Guide contains detailed
+                    instructions on how to run the
+                    <ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>ADT Installer</ulink>,
+                    which is used to set up a cross-development environment.</para></listitem>
+                <listitem><para><emphasis>Reference material:</emphasis>
+                    This type of material resides in an appropriate reference manual.
+                    For example, system variables are documented in the
+                    <ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink>.</para></listitem>
+                <listitem><para><emphasis>Detailed public information that is not specific to the Yocto Project:</emphasis>
+                    For example, exhaustive information on how to use Git is covered better through the
+                    Internet than in this manual.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='other-information'>
+        <title>Other Information</title>
+
+        <para>
+            Because this manual presents overview information for many different
+            topics, supplemental information is recommended for full
+            comprehension.
+            The following list presents other sources of information you might find helpful:
+            <itemizedlist>
+                <listitem><para><emphasis><ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>:
+                    </emphasis> The home page for the Yocto Project provides lots of information on the project
+                    as well as links to software and documentation.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>:</emphasis>
+                    This short document lets you get started
+                    with the Yocto Project and quickly begin building an image.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink>:</emphasis>
+                    This manual is a reference
+                    guide to the OpenEmbedded build system, which is based on BitBake.
+                    The build system is sometimes referred to as "Poky".
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>:</emphasis>
+                    This guide provides information that lets you get going with the Application
+                    Development Toolkit (ADT) and stand-alone cross-development toolchains to
+                    develop projects using the Yocto Project.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>:</emphasis>
+                    This guide defines the structure for BSP components.
+                    Having a commonly understood structure encourages standardization.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>:</emphasis>
+                    This manual describes how to work with Linux Yocto kernels as well as provides a bit
+                    of conceptual information on the construction of the Yocto Linux kernel tree.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Profiling and Tracing Manual</ulink>:</emphasis>
+                    This manual presents a set of common and generally useful tracing and
+                    profiling schemes along with their applications (as appropriate) to each tool.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='http://www.youtube.com/watch?v=3ZlOu-gLsh0'>
+                    Eclipse IDE Yocto Plug-in</ulink>:</emphasis>
+                    A step-by-step instructional video that
+                    demonstrates how an application developer uses Yocto Plug-in features within
+                    the Eclipse IDE.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='&YOCTO_WIKI_URL;/wiki/FAQ'>FAQ</ulink>:</emphasis>
+                    A list of commonly asked questions and their answers.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='&YOCTO_RELEASE_NOTES;'>Release Notes</ulink>:</emphasis>
+                    Features, updates and known issues for the current
+                    release of the Yocto Project.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink>:</emphasis>
+                    A graphical user interface for BitBake.
+                    Hob's primary goal is to enable a user to perform common tasks more easily.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/toaster'>Toaster</ulink>:</emphasis>
+                    An Application Programming Interface (API) and web-based
+                    interface to the OpenEmbedded build system, which uses
+                    BitBake, that reports build information.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/build-appliance'>Build Appliance</ulink>:</emphasis>
+                    A virtual machine that
+                    enables you to build and boot a custom embedded Linux image
+                    with the Yocto Project using a non-Linux development system.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='&YOCTO_BUGZILLA_URL;'>Bugzilla</ulink>:</emphasis>
+                    The bug tracking application the Yocto Project uses.
+                    If you find problems with the Yocto Project, you should report them using this
+                    application.
+                    </para></listitem>
+                <listitem><para><emphasis>Yocto Project Mailing Lists:</emphasis>
+                    To subscribe to the Yocto Project mailing
+                    lists, click on the following URLs and follow the instructions:
+                    <itemizedlist>
+                        <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'></ulink>
+                            for a Yocto Project Discussions mailing list.
+                            </para></listitem>
+                        <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink>
+                            for a Yocto Project Discussions mailing list about the
+                            OpenEmbedded build system (Poky).
+                            </para></listitem>
+                        <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto-announce'></ulink>
+                            for a mailing list to receive official Yocto Project announcements
+                            as well as Yocto Project milestones.
+                            </para></listitem>
+                        <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo'></ulink>
+                            for a listing of all public mailing lists on
+                            <filename>lists.yoctoproject.org</filename>.
+                            </para></listitem>
+                    </itemizedlist></para></listitem>
+                <listitem><para><emphasis>Internet Relay Chat (IRC):</emphasis>
+                    Two IRC channels on freenode are available
+                    for Yocto Project and Poky discussions: <filename>#yocto</filename> and
+                    <filename>#poky</filename>, respectively.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:</emphasis>
+                    The build system used by the Yocto Project.
+                    This project is the upstream, generic, embedded distribution
+                    from which the Yocto Project derives its build system (Poky)
+                    and to which it contributes.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='http://www.openembedded.org/wiki/BitBake'>BitBake</ulink>:</emphasis>
+                    The tool used by the OpenEmbedded build system
+                    to process project metadata.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual:</ulink></emphasis>
+                    A comprehensive guide to the BitBake tool.
+                    If you want information on BitBake, see this manual.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='http://wiki.qemu.org/Index.html'>Quick EMUlator (QEMU)</ulink>:</emphasis>
+                    An open-source machine emulator and virtualizer.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/dev-manual/dev-manual-model.xml b/documentation/dev-manual/dev-manual-model.xml
new file mode 100644
index 0000000000..43c31b8405
--- /dev/null
+++ b/documentation/dev-manual/dev-manual-model.xml
@@ -0,0 +1,2112 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='dev-manual-model'>
+
+<title>Common Development Models</title>
+
+<para>
+    Many development models exist for which you can use the Yocto Project.
+    This chapter overviews simple methods that use tools provided by the
+    Yocto Project:
+    <itemizedlist>
+        <listitem><para><emphasis>System Development:</emphasis>
+             System Development covers Board Support Package (BSP) development and kernel
+             modification or configuration.
+             For an example on how to create a BSP, see the
+             "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>"
+             section in the Yocto Project Board Support Package (BSP) Developer's Guide.
+             For more complete information on how to work with the kernel, see the
+             <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>.
+             </para></listitem>
+         <listitem><para><emphasis>User Application Development:</emphasis>
+             User Application Development covers development of applications that you intend
+             to run on target hardware.
+             For information on how to set up your host development system for user-space
+             application development, see the
+             <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>.
+             For a simple example of user-space application development using the
+             <trademark class='trade'>Eclipse</trademark> IDE, see the
+             "<link linkend='application-development-workflow'>Application
+             Development Workflow</link>" section.
+             </para></listitem>
+         <listitem><para><emphasis>Temporary Source Code Modification:</emphasis>
+             Direct modification of temporary source code is a convenient development model
+             to quickly iterate and develop towards a solution.
+             Once you implement the solution, you should of course take steps to
+             get the changes upstream and applied in the affected recipes.</para></listitem>
+         <listitem><para><emphasis>Image Development using Hob:</emphasis>
+             You can use the <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink> to build
+             custom operating system images within the build environment.
+             Hob provides an efficient interface to the OpenEmbedded build system.</para></listitem>
+         <listitem><para><emphasis>Using a Development Shell:</emphasis>
+             You can use a <filename>devshell</filename> to efficiently debug commands or simply
+             edit packages.
+             Working inside a development shell is a quick way to set up the OpenEmbedded build
+             environment to work on parts of a project.</para></listitem>
+     </itemizedlist>
+</para>
+
+<section id='system-development-model'>
+    <title>System Development Workflow</title>
+
+    <para>
+        System development involves modification or creation of an image that you want to run on
+        a specific hardware target.
+        Usually, when you want to create an image that runs on embedded hardware, the image does
+        not require the same number of features that a full-fledged Linux distribution provides.
+        Thus, you can create a much smaller image that is designed to use only the
+        features for your particular hardware.
+    </para>
+
+    <para>
+        To help you understand how system development works in the Yocto Project, this section
+        covers two types of image development:  BSP creation and kernel modification or
+        configuration.
+    </para>
+
+    <section id='developing-a-board-support-package-bsp'>
+        <title>Developing a Board Support Package (BSP)</title>
+
+        <para>
+            A BSP is a collection of recipes that, when applied during a build, results in
+            an image that you can run on a particular board.
+            Thus, the package when compiled into the new image, supports the operation of the board.
+        </para>
+
+        <note>
+            For a brief list of terms used when describing the development process in the Yocto Project,
+            see the "<link linkend='yocto-project-terms'>Yocto Project Terms</link>" section.
+        </note>
+
+        <para>
+            The remainder of this section presents the basic
+            steps used to create a BSP using the Yocto Project's
+            <ulink url='&YOCTO_DOCS_BSP_URL;#using-the-yocto-projects-bsp-tools'>BSP Tools</ulink>.
+            Although not required for BSP creation, the
+            <filename>meta-intel</filename> repository, which contains
+            many BSPs supported by the Yocto Project, is part of the example.
+        </para>
+
+        <para>
+            For an example that shows how to create a new layer using the tools, see the
+            "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>"
+             section in the Yocto Project Board Support Package (BSP) Developer's Guide.
+        </para>
+
+        <para>
+            The following illustration and list summarize the BSP creation general workflow.
+        </para>
+
+        <para>
+            <imagedata fileref="figures/bsp-dev-flow.png" width="6in" depth="7in" align="center" scalefit="1" />
+        </para>
+
+        <para>
+            <orderedlist>
+                <listitem><para><emphasis>Set up your host development system to support
+                    development using the Yocto Project</emphasis>:  See the
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distribution</ulink>"
+                    and the
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both
+                    in the Yocto Project Quick Start for requirements.</para></listitem>
+                <listitem><para><emphasis>Establish a local copy of the project files on your
+                    system</emphasis>:  You need this <link linkend='source-directory'>Source
+                    Directory</link> available on your host system.
+                    Having these files on your system gives you access to the build
+                    process and to the tools you need.
+                    For information on how to set up the Source Directory,
+                    see the
+                    "<link linkend='getting-setup'>Getting Set Up</link>" section.</para></listitem>
+                <listitem><para><emphasis>Establish the <filename>meta-intel</filename>
+                    repository on your system</emphasis>:  Having local copies
+                    of these supported BSP layers on your system gives you
+                    access to layers you might be able to build on or modify
+                    to create your BSP.
+                    For information on how to get these files, see the
+                    "<link linkend='getting-setup'>Getting Set Up</link>" section.</para></listitem>
+                <listitem><para><emphasis>Create your own BSP layer using the
+                    <ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'><filename>yocto-bsp</filename></ulink> script</emphasis>:
+                    Layers are ideal for
+                    isolating and storing work for a given piece of hardware.
+                    A layer is really just a location or area in which you place
+                    the recipes and configurations for your BSP.
+                    In fact, a BSP is, in itself, a special type of layer.
+                    The simplest way to create a new BSP layer that is compliant with the
+                    Yocto Project is to use the <filename>yocto-bsp</filename> script.
+                    For information about that script, see the
+                    "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>"
+                    section in the Yocto Project Board Support (BSP) Developer's Guide.
+                    </para>
+                    <para>
+                    Another example that illustrates a layer is an application.
+                    Suppose you are creating an application that has library or other dependencies in
+                    order for it to compile and run.
+                    The layer, in this case, would be where all the recipes that define those dependencies
+                    are kept.
+                    The key point for a layer is that it is an isolated area that contains
+                    all the relevant information for the project that the OpenEmbedded build
+                    system knows about.
+                    For more information on layers, see the
+                    "<link linkend='understanding-and-creating-layers'>Understanding and Creating Layers</link>"
+                    section.
+                    For more information on BSP layers, see the
+                    "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>" section in the
+                    Yocto Project Board Support Package (BSP) Developer's Guide.</para>
+                    <note>Five BSPs exist that are part of the
+                    Yocto Project release: <filename>genericx86</filename>, <filename>genericx86-64</filename>,
+                    <filename>beaglebone</filename> (ARM),
+                    <filename>mpc8315e</filename> (PowerPC),
+                    and <filename>edgerouter</filename> (MIPS).
+                    The recipes and configurations for these five BSPs are located and dispersed
+                    within the <link linkend='source-directory'>Source Directory</link>.
+                    On the other hand, the <filename>meta-intel</filename> layer
+                    contains BSP layers for many supported BSPs (e.g.
+                    Crystal Forest, Emenlow, Fish River Island 2, Haswell,
+                    Jasper Forest, and so forth).
+                    Aside from the BSPs in the <filename>meta-intel</filename>
+                    layer, the
+                    <ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink>
+                    contain additional BSP layers such as
+                    <filename>meta-minnow</filename> and
+                    <filename>meta-raspberrypi</filename>.</note>
+                    <para>When you set up a layer for a new BSP, you should follow a standard layout.
+                    This layout is described in the
+                    "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout'>Example Filesystem Layout</ulink>"
+                    section of the Board Support Package (BSP) Development Guide.
+                    In the standard layout, you will notice a suggested structure for recipes and
+                    configuration information.
+                    You can see the standard layout for a BSP by examining
+                    any supported BSP found in the <filename>meta-intel</filename> layer inside
+                    the Source Directory.</para></listitem>
+                <listitem><para><emphasis>Make configuration changes to your new BSP
+                    layer</emphasis>:  The standard BSP layer structure organizes the files you need
+                    to edit in <filename>conf</filename> and several <filename>recipes-*</filename>
+                    directories within the BSP layer.
+                    Configuration changes identify where your new layer is on the local system
+                    and identify which kernel you are going to use.
+                    When you run the <filename>yocto-bsp</filename> script, you are able to interactively
+                    configure many things for the BSP (e.g. keyboard, touchscreen, and so forth).
+                    </para></listitem>
+                <listitem><para><emphasis>Make recipe changes to your new BSP layer</emphasis>:  Recipe
+                    changes include altering recipes (<filename>.bb</filename> files), removing
+                    recipes you do not use, and adding new recipes or append files
+                    (<filename>.bbappend</filename>) that you need to support your hardware.
+                    </para></listitem>
+                <listitem><para><emphasis>Prepare for the build</emphasis>:  Once you have made all the
+                    changes to your BSP layer, there remains a few things
+                    you need to do for the OpenEmbedded build system in order for it to create your image.
+                    You need to get the build environment ready by sourcing an environment setup script
+                    (i.e. <filename>oe-init-build-env</filename> or
+                    <filename>oe-init-build-env-memres</filename>)
+                    and you need to be sure two key configuration files are configured appropriately:
+                    the <filename>conf/local.conf</filename> and the
+                    <filename>conf/bblayers.conf</filename> file.
+                    You must make the OpenEmbedded build system aware of your new layer.
+                    See the
+                    "<link linkend='enabling-your-layer'>Enabling Your Layer</link>" section
+                    for information on how to let the build system know about your new layer.</para>
+                    <para>The entire process for building an image is overviewed in the section
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" section
+                    of the Yocto Project Quick Start.
+                    You might want to reference this information.</para></listitem>
+                <listitem><para><emphasis>Build the image</emphasis>:  The OpenEmbedded build system
+                    uses the BitBake tool to build images based on the type of image you want to create.
+                    You can find more information about BitBake in the
+                    <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
+                    </para>
+                    <para>The build process supports several types of images to satisfy different needs.
+                    See the
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter
+                    in the Yocto Project Reference Manual for information on
+                    supported images.</para></listitem>
+            </orderedlist>
+        </para>
+
+        <para>
+            You can view a video presentation on "Building Custom Embedded Images with Yocto"
+            at <ulink url='http://free-electrons.com/blog/elc-2011-videos'>Free Electrons</ulink>.
+            After going to the page, just search for "Embedded".
+            You can also find supplemental information in the
+            <ulink url='&YOCTO_DOCS_BSP_URL;'>
+            Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
+            Finally, there is a wiki page write up of the example also located
+            <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>
+            here</ulink> that you might find helpful.
+       </para>
+    </section>
+
+    <section id='modifying-the-kernel'>
+        <title><anchor id='kernel-spot' />Modifying the Kernel</title>
+
+        <para>
+            Kernel modification involves changing the Yocto Project kernel, which could involve changing
+            configuration options as well as adding new kernel recipes.
+            Configuration changes can be added in the form of configuration fragments, while recipe
+            modification comes through the kernel's <filename>recipes-kernel</filename> area
+            in a kernel layer you create.
+        </para>
+
+        <para>
+            The remainder of this section presents a high-level overview of the Yocto Project
+            kernel architecture and the steps to modify the kernel.
+            You can reference the
+            "<link linkend='patching-the-kernel'>Patching the Kernel</link>" section
+            for an example that changes the source code of the kernel.
+            For information on how to configure the kernel, see the
+            "<link linkend='configuring-the-kernel'>Configuring the Kernel</link>" section.
+            For more information on the kernel and on modifying the kernel, see the
+            <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>.
+        </para>
+
+        <section id='kernel-overview'>
+            <title>Kernel Overview</title>
+
+            <para>
+                Traditionally, when one thinks of a patched kernel, they think of a base kernel
+                source tree and a fixed structure that contains kernel patches.
+                The Yocto Project, however, employs mechanisms that, in a sense, result in a kernel source
+                generator.
+                By the end of this section, this analogy will become clearer.
+            </para>
+
+            <para>
+                You can find a web interface to the Yocto Project kernel source repositories at
+                <ulink url='&YOCTO_GIT_URL;'></ulink>.
+                If you look at the interface, you will see to the left a grouping of
+                Git repositories titled "Yocto Linux Kernel."
+                Within this group, you will find several kernels supported by
+                the Yocto Project:
+                <itemizedlist>
+                    <listitem><para><emphasis>
+                        <filename>linux-yocto-3.8</filename></emphasis> - The
+                        stable Yocto Project kernel to use with the Yocto
+                        Project Release 1.4. This kernel is based on the
+                        Linux 3.8 released kernel.
+                        </para></listitem>
+                    <listitem><para><emphasis>
+                        <filename>linux-yocto-3.10</filename></emphasis> - The
+                        stable Yocto Project kernel to use with the Yocto
+                        Project Release 1.5.
+                        This kernel is based on the Linux 3.10 released kernel.
+                        </para></listitem>
+                    <listitem><para><emphasis>
+                        <filename>linux-yocto-3.14</filename></emphasis> - The
+                        stable Yocto Project kernel to use with the Yocto
+                        Project Releases 1.6 and 1.7.
+                        This kernel is based on the Linux 3.14 released kernel.
+                        </para></listitem>
+                    <listitem><para><emphasis>
+                        <filename>linux-yocto-3.17</filename></emphasis> - An
+                        additional Yocto Project kernel used with the Yocto
+                        Project Release 1.7.
+                        This kernel is based on the Linux 3.17 released kernel.
+                        </para></listitem>
+                    <listitem><para><emphasis>
+                        <filename>linux-yocto-dev</filename></emphasis> - A
+                        development kernel based on the latest upstream release
+                        candidate available.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                The kernels are maintained using the Git revision control system
+                that structures them using the familiar "tree", "branch", and "leaf" scheme.
+                Branches represent diversions from general code to more specific code, while leaves
+                represent the end-points for a complete and unique kernel whose source files,
+                when gathered from the root of the tree to the leaf, accumulate to create the files
+                necessary for a specific piece of hardware and its features.
+                The following figure displays this concept:
+            <para>
+                <imagedata fileref="figures/kernel-overview-1.png"
+                    width="6in" depth="6in" align="center" scale="100" />
+            </para>
+
+            <para>
+                Within the figure, the "Kernel.org Branch Point" represents the point in the tree
+                where a supported base kernel is modified from the Linux kernel.
+                For example, this could be the branch point for the <filename>linux-yocto-3.4</filename>
+                kernel.
+                Thus, everything further to the right in the structure is based on the
+                <filename>linux-yocto-3.4</filename> kernel.
+                Branch points to the right in the figure represent where the
+                <filename>linux-yocto-3.4</filename> kernel is modified for specific hardware
+                or types of kernels, such as real-time kernels.
+                Each leaf thus represents the end-point for a kernel designed to run on a specific
+                targeted device.
+            </para>
+
+            <para>
+                The overall result is a Git-maintained repository from which all the supported
+                kernel types can be derived for all the supported devices.
+                A big advantage to this scheme is the sharing of common features by keeping them in
+                "larger" branches within the tree.
+                This practice eliminates redundant storage of similar features shared among kernels.
+            </para>
+
+            <note>
+                Keep in mind the figure does not take into account all the supported Yocto
+                Project kernel types, but rather shows a single generic kernel just for conceptual purposes.
+                Also keep in mind that this structure represents the Yocto Project source repositories
+                that are either pulled from during the build or established on the host development system
+                prior to the build by either cloning a particular kernel's Git repository or by
+                downloading and unpacking a tarball.
+            </note>
+
+            <para>
+                Upstream storage of all the available kernel source code is one thing, while
+                representing and using the code on your host development system is another.
+                Conceptually, you can think of the kernel source repositories as all the
+                source files necessary for all the supported kernels.
+                As a developer, you are just interested in the source files for the kernel on
+                which you are working.
+                And, furthermore, you need them available on your host system.
+            </para>
+
+            <para>
+                Kernel source code is available on your host system a couple of different
+                ways.
+                If you are working in the kernel all the time, you probably would want
+                to set up your own local Git repository of the kernel tree.
+                If you just need to make some patches to the kernel, you can access
+                temporary kernel source files that were extracted and used
+                during a build.
+                We will just talk about working with the temporary source code.
+                For more information on how to get kernel source code onto your
+                host system, see the
+                "<link linkend='local-kernel-files'>Yocto Project Kernel</link>"
+                bulleted item earlier in the manual.
+            </para>
+
+            <para>
+                What happens during the build?
+                When you build the kernel on your development system, all files needed for the build
+                are taken from the source repositories pointed to by the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> variable
+                and gathered in a temporary work area
+                where they are subsequently used to create the unique kernel.
+                Thus, in a sense, the process constructs a local source tree specific to your
+                kernel to generate the new kernel image - a source generator if you will.
+            </para>
+                The following figure shows the temporary file structure
+                created on your host system when the build occurs.
+                This
+                <link linkend='build-directory'>Build Directory</link> contains all the
+                source files used during the build.
+            </para>
+
+            <para>
+                <imagedata fileref="figures/kernel-overview-2-generic.png"
+                    width="6in" depth="5in" align="center" scale="100" />
+            </para>
+
+            <para>
+                Again, for additional information on the Yocto Project kernel's
+                architecture and its branching strategy, see the
+                <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>.
+                You can also reference the
+                "<link linkend='patching-the-kernel'>Patching the Kernel</link>"
+                section for a detailed example that modifies the kernel.
+            </para>
+        </section>
+
+        <section id='kernel-modification-workflow'>
+            <title>Kernel Modification Workflow</title>
+
+            <para>
+                This illustration and the following list summarizes the kernel modification general workflow.
+            </para>
+
+            <para>
+                <imagedata fileref="figures/kernel-dev-flow.png"
+                    width="6in" depth="5in" align="center" scalefit="1" />
+            </para>
+
+            <para>
+                <orderedlist>
+                    <listitem><para><emphasis>Set up your host development system to support
+                        development using the Yocto Project</emphasis>:  See
+                        "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distribution</ulink>" and
+                        "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both
+                        in the Yocto Project Quick Start for requirements.</para></listitem>
+                    <listitem><para><emphasis>Establish a local copy of project files on your
+                        system</emphasis>:  Having the <link linkend='source-directory'>Source
+                        Directory</link> on your system gives you access to the build process and tools
+                        you need.
+                        For information on how to get these files, see the bulleted item
+                        "<link linkend='local-yp-release'>Yocto Project Release</link>" earlier in this manual.
+                        </para></listitem>
+                    <listitem><para><emphasis>Establish the temporary kernel source files</emphasis>:
+                        Temporary kernel source files are kept in the
+                        <link linkend='build-directory'>Build Directory</link>
+                        created by the
+                        OpenEmbedded build system when you run BitBake.
+                        If you have never built the kernel in which you are
+                        interested, you need to run an initial build to
+                        establish local kernel source files.</para>
+                        <para>If you are building an image for the first time, you need to get the build
+                        environment ready by sourcing an environment setup script
+                        (i.e. <filename>oe-init-build-env</filename> or
+                        <filename>oe-init-build-env-memres</filename>).
+                        You also need to be sure two key configuration files
+                        (<filename>local.conf</filename> and <filename>bblayers.conf</filename>)
+                        are configured appropriately.</para>
+                        <para>The entire process for building an image is overviewed in the
+                        "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>"
+                        section of the Yocto Project Quick Start.
+                        You might want to reference this information.
+                        You can find more information on BitBake in the
+                        <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
+                        </para>
+                        <para>The build process supports several types of images to satisfy different needs.
+                        See the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter in
+                        the Yocto Project Reference Manual for information on supported images.
+                        </para></listitem>
+                    <listitem><para><emphasis>Make changes to the kernel source code if
+                        applicable</emphasis>:  Modifying the kernel does not always mean directly
+                        changing source files.
+                        However, if you have to do this, you make the changes to the files in the
+                        Build Directory.</para></listitem>
+                    <listitem><para><emphasis>Make kernel configuration changes
+                        if applicable</emphasis>:
+                        If your situation calls for changing the kernel's configuration, you can
+                        use the <filename>yocto-kernel</filename> script or <filename>menuconfig</filename>
+                        to enable and disable kernel configurations.
+                        Using the script lets you interactively set up kernel configurations.
+                        Using <filename>menuconfig</filename> allows you to interactively develop and test the
+                        configuration changes you are making to the kernel.
+                        When saved, changes using <filename>menuconfig</filename> update the kernel's
+                        <filename>.config</filename> file.
+                        Try to resist the temptation of directly editing the <filename>.config</filename>
+                        file found in the Build Directory at
+                        <filename>tmp/sysroots/&lt;machine-name&gt;/kernel</filename>.
+                        Doing so, can produce unexpected results when the OpenEmbedded build system
+                        regenerates the configuration file.</para>
+                        <para>Once you are satisfied with the configuration changes made using
+                        <filename>menuconfig</filename>, you can directly compare the
+                        <filename>.config</filename> file against a saved original and gather those
+                        changes into a config fragment to be referenced from within the kernel's
+                        <filename>.bbappend</filename> file.</para></listitem>
+                    <listitem><para><emphasis>Rebuild the kernel image with your changes</emphasis>:
+                        Rebuilding the kernel image applies your changes.</para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+    </section>
+</section>
+
+<section id='application-development-workflow'>
+    <title>Application Development Workflow</title>
+
+    <para>
+        Application development involves creating an application that you want
+        to run on your target hardware, which is running a kernel image created using the
+        OpenEmbedded build system.
+        The Yocto Project provides an
+        <ulink url='&YOCTO_DOCS_ADT_URL;#adt-intro'>Application Development Toolkit (ADT)</ulink>
+        and stand-alone
+        <ulink url='&YOCTO_DOCS_ADT_URL;#the-cross-development-toolchain'>cross-development toolchains</ulink>
+        that facilitate quick development and integration of your application into its runtime environment.
+        Using the ADT and toolchains, you can compile and link your application.
+        You can then deploy your application to the actual hardware or to the QEMU emulator for testing.
+        If you are familiar with the popular <trademark class='trade'>Eclipse</trademark> IDE,
+        you can use an Eclipse Yocto Plug-in to
+        allow you to develop, deploy, and test your application all from within Eclipse.
+    </para>
+
+    <para>
+        While we strongly suggest using the ADT to develop your application, this option might not
+        be best for you.
+        If this is the case, you can still use pieces of the Yocto Project for your development process.
+        However, because the process can vary greatly, this manual does not provide detail on the process.
+    </para>
+
+    <section id='workflow-using-the-adt-and-eclipse'>
+        <title>Workflow Using the ADT and <trademark class='trade'>Eclipse</trademark></title>
+
+        <para>
+            To help you understand how application development works using the ADT, this section
+            provides an overview of the general development process and a detailed example of the process
+            as it is used from within the Eclipse IDE.
+        </para>
+
+        <para>
+            The following illustration and list summarize the application development general workflow.
+        </para>
+
+        <para>
+            <imagedata fileref="figures/app-dev-flow.png"
+                width="7in" depth="8in" align="center" scale="100" />
+        </para>
+
+        <para>
+            <orderedlist>
+                <listitem><para><emphasis>Prepare the host system for the Yocto Project</emphasis>:
+                    See
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>"
+                    and
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-host-development-system'>Required Packages for the Host Development System</ulink>" sections both
+                    in the Yocto Project Reference Manual for requirements.
+                    In particular, be sure your host system has the
+                    <filename>xterm</filename> package installed.
+                    </para></listitem>
+                <listitem><para><emphasis>Secure the Yocto Project kernel target image</emphasis>:
+                    You must have a target kernel image that has been built using the OpenEmbedded
+                    build system.</para>
+                    <para>Depending on whether the Yocto Project has a pre-built image that matches your target
+                    architecture and where you are going to run the image while you develop your application
+                    (QEMU or real hardware), the area from which you get the image differs.
+                        <itemizedlist>
+                            <listitem><para>Download the image from
+                                <ulink url='&YOCTO_MACHINES_DL_URL;'><filename>machines</filename></ulink>
+                                if your target architecture is supported and you are going to develop
+                                and test your application on actual hardware.</para></listitem>
+                            <listitem><para>Download the image from
+                                <ulink url='&YOCTO_QEMU_DL_URL;'>
+                                <filename>machines/qemu</filename></ulink> if your target architecture is supported
+                                and you are going to develop and test your application using the QEMU
+                                emulator.</para></listitem>
+                            <listitem><para>Build your image if you cannot find a pre-built image that matches
+                                your target architecture.
+                                If your target architecture is similar to a supported architecture, you can
+                                modify the kernel image before you build it.
+                                See the
+                                "<link linkend='patching-the-kernel'>Patching the Kernel</link>"
+                                section for an example.</para></listitem>
+                        </itemizedlist></para>
+                    <para>For information on pre-built kernel image naming schemes for images
+                    that can run on the QEMU emulator, see the
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#downloading-the-pre-built-linux-kernel'>Downloading the Pre-Built Linux Kernel</ulink>"
+                    section in the Yocto Project Quick Start.</para></listitem>
+                <listitem><para><emphasis>Install the ADT</emphasis>:
+                    The ADT provides a target-specific cross-development toolchain, the root filesystem,
+                    the QEMU emulator, and other tools that can help you develop your application.
+                    While it is possible to get these pieces separately, the ADT Installer provides an
+                    easy, inclusive method.
+                    You can get these pieces by running an ADT installer script, which is configurable.
+                    For information on how to install the ADT, see the
+                    "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Using the ADT Installer</ulink>"
+                    section
+                    in the Yocto Project Application Developer's Guide.</para></listitem>
+                <listitem><para><emphasis>If applicable, secure the target root filesystem
+                    and the Cross-development toolchain</emphasis>:
+                    If you choose not to install the ADT using the ADT Installer,
+                    you need to find and download the appropriate root filesystem and
+                    the cross-development toolchain.</para>
+                    <para>You can find the tarballs for the root filesystem in the same area used
+                    for the kernel image.
+                    Depending on the type of image you are running, the root filesystem you need differs.
+                    For example, if you are developing an application that runs on an image that
+                    supports Sato, you need to get a root filesystem that supports Sato.</para>
+                    <para>You can find the cross-development toolchains at
+                    <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'><filename>toolchains</filename></ulink>.
+                    Be sure to get the correct toolchain for your development host and your
+                    target architecture.
+                    See the "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>"
+                    section in the Yocto Project Application Developer's Guide for information
+                    and the
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#installing-the-toolchain'>Installing the Toolchain</ulink>"
+                    in the Yocto Project Quick Start for information on finding and installing
+                    the correct toolchain based on your host development system and your target
+                    architecture.
+                    </para></listitem>
+                <listitem><para><emphasis>Create and build your application</emphasis>:
+                    At this point, you need to have source files for your application.
+                    Once you have the files, you can use the Eclipse IDE to import them and build the
+                    project.
+                    If you are not using Eclipse, you need to use the cross-development tools you have
+                    installed to create the image.</para></listitem>
+                <listitem><para><emphasis>Deploy the image with the application</emphasis>:
+                    If you are using the Eclipse IDE, you can deploy your image to the hardware or to
+                    QEMU through the project's preferences.
+                    If you are not using the Eclipse IDE, then you need to deploy the application
+                    to the hardware using other methods.
+                    Or, if you are using QEMU, you need to use that tool and
+                    load your image in for testing.
+                    See the
+                    "<link linkend='dev-manual-qemu'>Using the Quick EMUlator (QEMU)</link>"
+                    chapter for information on using QEMU.
+                    </para></listitem>
+                <listitem><para><emphasis>Test and debug the application</emphasis>:
+                    Once your application is deployed, you need to test it.
+                    Within the Eclipse IDE, you can use the debugging environment along with the
+                    set of user-space tools installed along with the ADT to debug your application.
+                    Of course, the same user-space tools are available separately if you choose
+                    not to use the Eclipse IDE.</para></listitem>
+           </orderedlist>
+        </para>
+    </section>
+
+    <section id='adt-eclipse'>
+        <title>Working Within Eclipse</title>
+
+        <para>
+            The Eclipse IDE is a popular development environment and it fully
+            supports development using the Yocto Project.
+            <note>
+                This release of the Yocto Project supports both the Kepler
+                and Juno versions of the Eclipse IDE.
+                Thus, the following information provides setup information for
+                both versions.
+            </note>
+        </para>
+
+        <para>
+            When you install and configure the Eclipse Yocto Project Plug-in
+            into the Eclipse IDE, you maximize your Yocto Project experience.
+            Installing and configuring the Plug-in results in an environment
+            that has extensions specifically designed to let you more easily
+            develop software.
+            These extensions allow for cross-compilation, deployment, and
+            execution of your output into a QEMU emulation session as well as
+            actual target hardware.
+            You can also perform cross-debugging and profiling.
+            The environment also supports a suite of tools that allows you
+            to perform remote profiling, tracing, collection of power data,
+            collection of latency data, and collection of performance data.
+        </para>
+
+        <para>
+            This section describes how to install and configure the Eclipse IDE
+            Yocto Plug-in and how to use it to develop your application.
+        </para>
+
+        <section id='setting-up-the-eclipse-ide'>
+            <title>Setting Up the Eclipse IDE</title>
+
+            <para>
+                To develop within the Eclipse IDE, you need to do the following:
+                <orderedlist>
+                    <listitem><para>Install the optimal version of the Eclipse
+                       IDE.</para></listitem>
+                    <listitem><para>Configure the Eclipse IDE.
+                       </para></listitem>
+                    <listitem><para>Install the Eclipse Yocto Plug-in.
+                       </para></listitem>
+                    <listitem><para>Configure the Eclipse Yocto Plug-in.
+                       </para></listitem>
+                </orderedlist>
+                <note>
+                    Do not install Eclipse from your distribution's package
+                    repository.
+                    Be sure to install Eclipse from the official Eclipse
+                    download site as directed in the next section.
+                </note>
+            </para>
+
+            <section id='installing-eclipse-ide'>
+                <title>Installing the Eclipse IDE</title>
+
+                <para>
+                    It is recommended that you have the Kepler 4.3.2 version of
+                    the Eclipse IDE installed on your development system.
+                    However, if you currently have the Juno 4.2 version
+                    installed and you do not want to upgrade the IDE, you can
+                    configure Juno to work with the Yocto Project.
+                </para>
+
+                <para>
+                    If you do not have the Kepler 4.3.2 Eclipse IDE installed,
+                    you can find the tarball at
+                    <ulink url='&ECLIPSE_MAIN_URL;'></ulink>.
+                    From that site, choose the Eclipse Standard 4.3.2 version
+                    particular to your development host.
+                    This version contains the Eclipse Platform, the Java
+                    Development Tools (JDT), and the Plug-in Development
+                    Environment.
+                </para>
+
+                <para>
+                    Once you have downloaded the tarball, extract it into a
+                    clean directory.
+                    For example, the following commands unpack and install the
+                    downloaded Eclipse IDE tarball into a clean directory
+                    using the default name <filename>eclipse</filename>:
+                    <literallayout class='monospaced'>
+     $ cd ~
+     $ tar -xzvf ~/Downloads/eclipse-standard-kepler-SR2-linux-gtk-x86_64.tar.gz
+                    </literallayout>
+                </para>
+            </section>
+
+            <section id='configuring-the-eclipse-ide'>
+                <title>Configuring the Eclipse IDE</title>
+
+                <para>
+                    This section presents the steps needed to configure the
+                    Eclipse IDE.
+                </para>
+
+                <para>
+                    Before installing and configuring the Eclipse Yocto Plug-in,
+                    you need to configure the Eclipse IDE.
+                    Follow these general steps:
+                    <orderedlist>
+                        <listitem><para>Start the Eclipse IDE.</para></listitem>
+                        <listitem><para>Make sure you are in your Workbench and
+                            select "Install New Software" from the "Help"
+                            pull-down menu.</para></listitem>
+                        <listitem><para>Select
+                            <filename>Kepler - &ECLIPSE_KEPLER_URL;</filename>
+                            from the "Work with:" pull-down menu.
+                            <note>
+                                For Juno, select
+                                <filename>Juno - &ECLIPSE_JUNO_URL;</filename>
+                            </note>
+                            </para></listitem>
+                        <listitem><para>Expand the box next to "Linux Tools"
+                            and select the
+                            <filename>LTTng - Linux Tracing Toolkit</filename>
+                            boxes.</para></listitem>
+                        <listitem><para>Expand the box next to "Mobile and
+                            Device Development" and select the following boxes:
+                            <itemizedlist>
+                                <listitem><para><filename>C/C++ Remote Launch (Requires RSE Remote System Explorer)</filename></para></listitem>
+                                <listitem><para><filename>Remote System Explorer End-user Runtime</filename></para></listitem>
+                                <listitem><para><filename>Remote System Explorer User Actions</filename></para></listitem>
+                                <listitem><para><filename>Target Management Terminal</filename></para></listitem>
+                                <listitem><para><filename>TCF Remote System Explorer add-in</filename></para></listitem>
+                                <listitem><para><filename>TCF Target Explorer</filename></para></listitem>
+                            </itemizedlist></para></listitem>
+                        <listitem><para>Expand the box next to "Programming
+                            Languages" and select the
+                            <filename>C/C++ Autotools Support</filename>
+                            and <filename>C/C++ Development Tools</filename>
+                            boxes.</para></listitem>
+                        <listitem><para>Complete the installation and restart
+                            the Eclipse IDE.</para></listitem>
+                    </orderedlist>
+                </para>
+            </section>
+
+            <section id='installing-the-eclipse-yocto-plug-in'>
+                <title>Installing or Accessing the Eclipse Yocto Plug-in</title>
+
+                <para>
+                    You can install the Eclipse Yocto Plug-in into the Eclipse
+                    IDE one of two ways:  use the Yocto Project's Eclipse
+                    Update site to install the pre-built plug-in or build and
+                    install the plug-in from the latest source code.
+                </para>
+
+                <section id='new-software'>
+                    <title>Installing the Pre-built Plug-in from the Yocto Project Eclipse Update Site</title>
+
+                    <para>
+                        To install the Eclipse Yocto Plug-in from the update
+                        site, follow these steps:
+                        <orderedlist>
+                            <listitem><para>Start up the Eclipse IDE.
+                                </para></listitem>
+                            <listitem><para>In Eclipse, select "Install New
+                                Software" from the "Help" menu.
+                                </para></listitem>
+                            <listitem><para>Click "Add..." in the "Work with:"
+                                area.</para></listitem>
+                           <listitem><para>Enter
+                                <filename>&ECLIPSE_DL_PLUGIN_URL;/kepler</filename>
+                                in the URL field and provide a meaningful name
+                                in the "Name" field.
+                                <note>
+                                    If you are using Juno, use
+                                    <filename>&ECLIPSE_DL_PLUGIN_URL;/juno</filename>
+                                    in the URL field.
+                                </note></para></listitem>
+                            <listitem><para>Click "OK" to have the entry added
+                                to the "Work with:" drop-down list.
+                                </para></listitem>
+                            <listitem><para>Select the entry for the plug-in
+                                from the "Work with:" drop-down list.
+                                </para></listitem>
+                            <listitem><para>Check the boxes next to
+                                <filename>Yocto Project ADT Plug-in</filename>,
+                                <filename>Yocto Project Bitbake Commander Plug-in</filename>,
+                                and
+                                <filename>Yocto Project Documentation plug-in</filename>.
+                                </para></listitem>
+                            <listitem><para>Complete the remaining software
+                                installation steps and then restart the Eclipse
+                                IDE to finish the installation of the plug-in.
+                                </para></listitem>
+                        </orderedlist>
+                    </para>
+                </section>
+
+               <section id='zip-file-method'>
+                   <title>Installing the Plug-in Using the Latest Source Code</title>
+
+                   <para>
+                        To install the Eclipse Yocto Plug-in from the latest
+                        source code, follow these steps:
+                        <orderedlist>
+                            <listitem><para>Be sure your development system
+                                is not using OpenJDK to build the plug-in
+                                by doing the following:
+                                <orderedlist>
+                                    <listitem><para>Use the Oracle JDK.
+                                        If you don't have that, go to
+                                        <ulink url='http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html'></ulink>
+                                        and download the appropriate tarball
+                                        for your development system and
+                                        extract it into your home directory.
+                                        </para></listitem>
+                                    <listitem><para>In the shell you are going
+                                        to do your work, export the location of
+                                        the Oracle Java as follows:
+                                        <literallayout class='monospaced'>
+     export PATH=~/jdk1.7.0_40/bin:$PATH
+                                        </literallayout></para></listitem>
+                                </orderedlist></para></listitem>
+                            <listitem><para>In the same shell, create a Git
+                                repository with:
+                                <literallayout class='monospaced'>
+     $ cd ~
+     $ git clone git://git.yoctoproject.org/eclipse-poky-kepler
+                                </literallayout>
+                                <note>
+                                    If you are using Juno, the repository is
+                                    located at
+                                    <filename>git://git.yoctoproject.org/eclipse-poky-juno</filename>.
+                                </note>
+                                For this example, the repository is named
+                                <filename>~/eclipse-poky-kepler</filename>.
+                                </para></listitem>
+                            <listitem><para>Change to the directory where you
+                                set up the Git repository:
+                                <literallayout class='monospaced'>
+     $ cd ~/eclipse-poky-kepler
+                                </literallayout></para></listitem>
+                            <listitem><para>Be sure you are in the right branch
+                                for your Git repository.
+                                For this release set the branch to
+                                <filename>&DISTRO_NAME;</filename>:
+                                <literallayout class='monospaced'>
+     $ git checkout &DISTRO_NAME;
+                                </literallayout></para></listitem>
+                            <listitem><para>Change to the
+                                <filename>scripts</filename>
+                                directory within the Git repository:
+                                <literallayout class='monospaced'>
+     $ cd scripts
+                                </literallayout></para></listitem>
+                            <listitem><para>Set up the local build environment
+                                by running the setup script:
+                                <literallayout class='monospaced'>
+     $ ./setup.sh
+                                </literallayout></para></listitem>
+                            <listitem><para>When the script finishes execution,
+                                it prompts you with instructions on how to run
+                                the <filename>build.sh</filename> script, which
+                                is also in the <filename>scripts</filename>
+                                directory of
+                                the Git repository created earlier.
+                                </para></listitem>
+                            <listitem><para>Run the <filename>build.sh</filename> script
+                                as directed.
+                                Be sure to provide the name of the Git branch
+                                along with the Yocto Project release you are
+                                using.
+                                Here is an example that uses the
+                                <filename>&DISTRO_NAME;</filename> branch:
+                                <literallayout class='monospaced'>
+     $ ECLIPSE_HOME=/home/scottrif/eclipse-poky-kepler/scripts/eclipse ./build.sh &DISTRO_NAME; &DISTRO_NAME;
+                                </literallayout>
+                                After running the script, the file
+                                <filename>org.yocto.sdk-&lt;release&gt;-&lt;date&gt;-archive.zip</filename>
+                                is in the current directory.</para></listitem>
+                            <listitem><para>If necessary, start the Eclipse IDE
+                                and be sure you are in the Workbench.
+                                </para></listitem>
+                            <listitem><para>Select "Install New Software" from the "Help" pull-down menu.
+                                </para></listitem>
+                            <listitem><para>Click "Add".</para></listitem>
+                            <listitem><para>Provide anything you want in the
+                                "Name" field.</para></listitem>
+                            <listitem><para>Click "Archive" and browse to the
+                                ZIP file you built in step eight.
+                                This ZIP file should not be "unzipped", and must
+                                be the <filename>*archive.zip</filename> file
+                                created by running the
+                                <filename>build.sh</filename> script.
+                                </para></listitem>
+                            <listitem><para>Click through the "Okay" buttons.
+                                </para></listitem>
+                            <listitem><para>Check the boxes
+                                in the installation window and complete
+                                the installation.</para></listitem>
+                            <listitem><para>Restart the Eclipse IDE if
+                                necessary.</para></listitem>
+                        </orderedlist>
+                    </para>
+
+                    <para>
+                        At this point you should be able to configure the
+                        Eclipse Yocto Plug-in as described in the
+                        "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse Yocto Plug-in</link>"
+                        section.</para>
+                </section>
+            </section>
+
+            <section id='configuring-the-eclipse-yocto-plug-in'>
+                <title>Configuring the Eclipse Yocto Plug-in</title>
+
+                <para>
+                    Configuring the Eclipse Yocto Plug-in involves setting the
+                    Cross Compiler options and the Target options.
+                    The configurations you choose become the default settings
+                    for all projects.
+                    You do have opportunities to change them later when
+                    you configure the project (see the following section).
+                </para>
+
+                <para>
+                    To start, you need to do the following from within the
+                    Eclipse IDE:
+                    <itemizedlist>
+                        <listitem><para>Choose "Preferences" from the
+                            "Windows" menu to display the Preferences Dialog.
+                            </para></listitem>
+                        <listitem><para>Click "Yocto Project ADT".
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <section id='configuring-the-cross-compiler-options'>
+                    <title>Configuring the Cross-Compiler Options</title>
+
+                    <para>
+                        To configure the Cross Compiler Options, you must select
+                        the type of toolchain, point to the toolchain, specify
+                        the sysroot location, and select the target
+                        architecture.
+                        <itemizedlist>
+                            <listitem><para><emphasis>Selecting the Toolchain Type:</emphasis>
+                                Choose between
+                                <filename>Standalone pre-built toolchain</filename>
+                                and
+                                <filename>Build system derived toolchain</filename>
+                                for Cross Compiler Options.
+                                    <itemizedlist>
+                                        <listitem><para><emphasis>
+                                            <filename>Standalone Pre-built Toolchain:</filename></emphasis>
+                                            Select this mode when you are using
+                                            a stand-alone cross-toolchain.
+                                            For example, suppose you are an
+                                            application developer and do not
+                                            need to build a target image.
+                                            Instead, you just want to use an
+                                            architecture-specific toolchain on
+                                            an existing kernel and target root
+                                            filesystem.</para></listitem>
+                                       <listitem><para><emphasis>
+                                            <filename>Build System Derived Toolchain:</filename></emphasis>
+                                            Select this mode if the
+                                            cross-toolchain has been installed
+                                            and built as part of the
+                                            <link linkend='build-directory'>Build Directory</link>.
+                                            When you select
+                                            <filename>Build system derived toolchain</filename>,
+                                            you are using the toolchain bundled
+                                            inside the Build Directory.
+                                            </para></listitem>
+                                    </itemizedlist>
+                                </para></listitem>
+                            <listitem><para><emphasis>Point to the Toolchain:</emphasis>
+                                If you are using a stand-alone pre-built
+                                toolchain, you should be pointing to where it is
+                                installed.
+                                If you used the ADT Installer script and
+                                accepted the default installation directory, the
+                                toolchain will be installed in the
+                                <filename>&YOCTO_ADTPATH_DIR;</filename>
+                                directory.
+                                Sections "<ulink url='&YOCTO_DOCS_ADT_URL;#configuring-and-running-the-adt-installer-script'>Configuring and Running the ADT Installer Script</ulink>"
+                                and
+                                "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>"
+                                in the Yocto Project Application Developer's
+                                Guide describe how to install a stand-alone
+                                cross-toolchain.</para>
+                                <para>If you are using a system-derived
+                                toolchain, the path you provide for the
+                                <filename>Toolchain Root Location</filename>
+                                field is the
+                                <link linkend='build-directory'>Build Directory</link>.
+                                See the
+                                "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-toolchain-from-within-the-build-tree'>Using BitBake and the Build Directory</ulink>"
+                                section in the Yocto Project Application
+                                Developer's Guide for information on how to
+                                install the toolchain into the Build
+                                Directory.</para></listitem>
+                            <listitem><para><emphasis>Specify the Sysroot Location:</emphasis>
+                                This location is where the root filesystem for
+                                the target hardware resides.
+                                If you used the ADT Installer script and
+                                accepted the default installation directory,
+                                then the location is
+                                <filename>/opt/poky/&DISTRO;</filename>.
+                                Additionally, when you use the ADT Installer
+                                script, the same location is used for the QEMU
+                                user-space tools and the NFS boot process.
+                                </para>
+                                <para>If you used either of the other two
+                                methods to install the toolchain or did not
+                                accept the ADT Installer script's default
+                                installation directory, then the location of
+                                the sysroot filesystem depends on where you
+                                separately extracted and installed the
+                                filesystem.</para>
+                                <para>For information on how to install the
+                                toolchain and on how to extract and install the
+                                sysroot filesystem, see the
+                                "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
+                                section in the Yocto Project Application
+                                Developer's Guide.
+                                </para></listitem>
+                            <listitem><para><emphasis>Select the Target Architecture:</emphasis>
+                                The target architecture is the type of hardware
+                                you are going to use or emulate.
+                                Use the pull-down
+                                <filename>Target Architecture</filename> menu
+                                to make your selection.
+                                The pull-down menu should have the supported
+                                architectures.
+                                If the architecture you need is not listed in
+                                the menu, you will need to build the image.
+                                See the
+                                "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>"
+                                section of the Yocto Project Quick Start for
+                                more information.</para></listitem>
+                        </itemizedlist>
+                    </para>
+                </section>
+
+                <section id='configuring-the-target-options'>
+                    <title>Configuring the Target Options</title>
+
+                    <para>
+                        You can choose to emulate hardware using the QEMU
+                        emulator, or you can choose to run your image on actual
+                        hardware.
+                        <itemizedlist>
+                            <listitem><para><emphasis>QEMU:</emphasis>
+                                Select this option if you will be using the
+                                QEMU emulator.
+                                If you are using the emulator, you also need to
+                                locate the kernel and specify any custom
+                                options.</para>
+                                <para>If you selected
+                                <filename>Build system derived toolchain</filename>,
+                                the target kernel you built will be located in
+                                the Build Directory in
+                                <filename>tmp/deploy/images/<replaceable>machine</replaceable></filename>
+                                directory.
+                                If you selected
+                                <filename>Standalone pre-built toolchain</filename>,
+                                the pre-built image you downloaded is located
+                                in the directory you specified when you
+                                downloaded the image.</para>
+                                <para>Most custom options are for advanced QEMU
+                                users to further customize their QEMU instance.
+                                These options are specified between paired
+                                angled brackets.
+                                Some options must be specified outside the
+                                brackets.
+                                In particular, the options
+                                <filename>serial</filename>,
+                                <filename>nographic</filename>, and
+                                <filename>kvm</filename> must all be outside the
+                                brackets.
+                                Use the <filename>man qemu</filename> command
+                                to get help on all the options and their use.
+                                The following is an example:
+                               <literallayout class='monospaced'>
+    serial ‘&lt;-m 256 -full-screen&gt;’
+                                </literallayout></para>
+                                <para>
+                                Regardless of the mode, Sysroot is already
+                                defined as part of the Cross-Compiler Options
+                                configuration in the
+                                <filename>Sysroot Location:</filename> field.
+                                </para></listitem>
+                            <listitem><para><emphasis>External HW:</emphasis>
+                                Select this option if you will be using actual
+                                hardware.</para></listitem>
+                        </itemizedlist>
+                    </para>
+
+                    <para>
+                        Click the "OK" to save your plug-in configurations.
+                    </para>
+                </section>
+            </section>
+        </section>
+
+        <section id='creating-the-project'>
+            <title>Creating the Project</title>
+
+            <para>
+                You can create two types of projects:  Autotools-based, or
+                Makefile-based.
+                This section describes how to create Autotools-based projects
+                from within the Eclipse IDE.
+                For information on creating Makefile-based projects in a
+                terminal window, see the section
+                "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-command-line'>Using the Command Line</ulink>"
+                in the Yocto Project Application Developer's Guide.
+                <note>
+                    Do not use special characters in project names
+                    (e.g. spaces, underscores, etc.).  Doing so can
+                    cause configuration to fail.
+                </note>
+            </para>
+
+            <para>
+                To create a project based on a Yocto template and then display
+                the source code, follow these steps:
+                <orderedlist>
+                    <listitem><para>Select "Project" from the "File -> New" menu.
+                        </para></listitem>
+                    <listitem><para>Double click <filename>CC++</filename>.
+                        </para></listitem>
+                    <listitem><para>Double click <filename>C Project</filename>
+                        to create the project.</para></listitem>
+                    <listitem><para>Expand <filename>Yocto Project ADT Project</filename>.
+                        </para></listitem>
+                    <listitem><para>Select <filename>Hello World ANSI C Autotools Project</filename>.
+                        This is an Autotools-based project based on a Yocto
+                        template.</para></listitem>
+                    <listitem><para>Put a name in the <filename>Project name:</filename>
+                        field.
+                        Do not use hyphens as part of the name.
+                        </para></listitem>
+                    <listitem><para>Click "Next".</para></listitem>
+                    <listitem><para>Add information in the
+                        <filename>Author</filename> and
+                        <filename>Copyright notice</filename> fields.
+                        </para></listitem>
+                    <listitem><para>Be sure the <filename>License</filename>
+                        field is correct.</para></listitem>
+                    <listitem><para>Click "Finish".</para></listitem>
+                    <listitem><para>If the "open perspective" prompt appears,
+                        click "Yes" so that you in the C/C++ perspective.
+                        </para></listitem>
+                    <listitem><para>The left-hand navigation pane shows your
+                        project.
+                        You can display your source by double clicking the
+                        project's source file.</para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+
+        <section id='configuring-the-cross-toolchains'>
+            <title>Configuring the Cross-Toolchains</title>
+
+            <para>
+                The earlier section,
+                "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse Yocto Plug-in</link>",
+                sets up the default project configurations.
+                You can override these settings for a given project by following
+                these steps:
+                <orderedlist>
+                    <listitem><para>Select "Change Yocto Project Settings" from
+                        the "Project" menu.
+                        This selection brings up the Yocto Project Settings
+                        Dialog and allows you to make changes specific to an
+                        individual project.</para>
+                        <para>By default, the Cross Compiler Options and Target
+                        Options for a project are inherited from settings you
+                        provided using the Preferences Dialog as described
+                        earlier in the
+                        "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse Yocto Plug-in</link>" section.
+                        The Yocto Project Settings Dialog allows you to override
+                        those default settings for a given project.
+                        </para></listitem>
+                    <listitem><para>Make your configurations for the project
+                        and click "OK".
+                        If you are running the Juno version of Eclipse, you can
+                        skip down to the next section where you build the
+                        project.
+                        If you are not working with Juno, you need to reconfigure the
+                        project as described in the next step.
+                        </para></listitem>
+                    <listitem><para>Select "Reconfigure Project" from the
+                        "Project" menu.
+                        This selection reconfigures the project by running
+                        <filename>autogen.sh</filename> in the workspace for
+                        your project.
+                        The script also runs <filename>libtoolize</filename>,
+                        <filename>aclocal</filename>,
+                        <filename>autoconf</filename>,
+                        <filename>autoheader</filename>,
+                        <filename>automake --a</filename>, and
+                        <filename>./configure</filename>.
+                        Click on the "Console" tab beneath your source code to
+                        see the results of reconfiguring your project.
+                        </para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+
+        <section id='building-the-project'>
+            <title>Building the Project</title>
+
+            <para>
+                To build the project in Juno, right click on the project in
+                the navigator pane and select "Build Project".
+                If you are not running Juno, select "Build Project" from the
+                "Project" menu.
+                The console should update and you can note the cross-compiler
+                you are using.
+            </para>
+        </section>
+
+        <section id='starting-qemu-in-user-space-nfs-mode'>
+            <title>Starting QEMU in User-Space NFS Mode</title>
+
+            <para>
+                To start the QEMU emulator from within Eclipse, follow these
+                steps:
+                <note>
+                    See the
+                    "<link linkend='dev-manual-qemu'>Using the Quick EMUlator (QEMU)</link>"
+                    chapter for more information on using QEMU.
+                </note>
+                <orderedlist>
+                    <listitem><para>Expose and select "External Tools" from
+                        the "Run" menu.
+                        Your image should appear as a selectable menu item.
+                        </para></listitem>
+                    <listitem><para>Select your image from the menu to launch
+                        the emulator in a new window.</para></listitem>
+                    <listitem><para>If needed, enter your host root password in
+                        the shell window at the prompt.
+                        This sets up a <filename>Tap 0</filename> connection
+                        needed for running in user-space NFS mode.
+                        </para></listitem>
+                    <listitem><para>Wait for QEMU to launch.</para></listitem>
+                    <listitem><para>Once QEMU launches, you can begin operating
+                        within that environment.
+                        For example, you could determine the IP Address
+                       for the user-space NFS by using the
+                       <filename>ifconfig</filename> command.</para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+
+        <section id='deploying-and-debugging-the-application'>
+            <title>Deploying and Debugging the Application</title>
+
+            <para>
+                Once the QEMU emulator is running the image, you can deploy
+                your application using the Eclipse IDE and then use
+                the emulator to perform debugging.
+                Follow these steps to deploy the application.
+                <orderedlist>
+                    <listitem><para>Select "Debug Configurations..." from the
+                        "Run" menu.</para></listitem>
+                    <listitem><para>In the left area, expand
+                        <filename>C/C++Remote Application</filename>.
+                        </para></listitem>
+                    <listitem><para>Locate your project and select it to bring
+                        up a new tabbed view in the Debug Configurations Dialog.
+                        </para></listitem>
+                    <listitem><para>Enter the absolute path into which you want
+                        to deploy the application.
+                        Use the "Remote Absolute File Path for
+                        C/C++Application:" field.
+                        For example, enter
+                        <filename>/usr/bin/&lt;programname&gt;</filename>.
+                        </para></listitem>
+                    <listitem><para>Click on the "Debugger" tab to see the
+                        cross-tool debugger you are using.</para></listitem>
+                    <listitem><para>Click on the "Main" tab.</para></listitem>
+                    <listitem><para>Create a new connection to the QEMU instance
+                        by clicking on "new".</para></listitem>
+                    <listitem><para>Select <filename>TCF</filename>, which means
+                        Target Communication Framework.</para></listitem>
+                    <listitem><para>Click "Next".</para></listitem>
+                    <listitem><para>Clear out the "host name" field and enter
+                        the IP Address determined earlier.</para></listitem>
+                    <listitem><para>Click "Finish" to close the
+                        New Connections Dialog.</para></listitem>
+                    <listitem><para>Use the drop-down menu now in the
+                        "Connection" field and pick the IP Address you entered.
+                         </para></listitem>
+                    <listitem><para>Click "Run" to bring up a login screen
+                        and login.</para></listitem>
+                    <listitem><para>Accept the debug perspective.
+                        </para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+
+        <section id='running-user-space-tools'>
+            <title>Running User-Space Tools</title>
+
+            <para>
+                As mentioned earlier in the manual, several tools exist that
+                enhance your development experience.
+                These tools are aids in developing and debugging applications
+                and images.
+                You can run these user-space tools from within the Eclipse
+                IDE through the "YoctoTools" menu.
+            </para>
+
+            <para>
+                Once you pick a tool, you need to configure it for the remote
+                target.
+                Every tool needs to have the connection configured.
+                You must select an existing TCF-based RSE connection to the
+                remote target.
+                If one does not exist, click "New" to create one.
+            </para>
+
+            <para>
+                Here are some specifics about the remote tools:
+                <itemizedlist>
+                    <listitem><para><emphasis><filename>OProfile</filename>:</emphasis>
+                        Selecting this tool causes the
+                        <filename>oprofile-server</filename> on the remote
+                        target to launch on the local host machine.
+                        The <filename>oprofile-viewer</filename> must be
+                        installed on the local host machine and the
+                        <filename>oprofile-server</filename> must be installed
+                        on the remote target, respectively, in order to use.
+                        You must compile and install the
+                        <filename>oprofile-viewer</filename> from the source
+                        code on your local host machine.
+                        Furthermore, in order to convert the target's sample
+                        format data into a form that the host can use, you must
+                        have OProfile version 0.9.4 or greater installed on the
+                        host.</para>
+                        <para>You can locate both the viewer and server from
+                        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/oprofileui/'></ulink>.
+                        You can also find more information on setting up and
+                        using this tool in the
+                        "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-oprofile'>oprofile</ulink>"
+                        section of the Yocto Project Profiling and Tracing
+                        Manual.
+                        <note>The <filename>oprofile-server</filename> is
+                        installed by default on the
+                        <filename>core-image-sato-sdk</filename> image.</note>
+                        </para></listitem>
+                    <listitem><para><emphasis><filename>Lttng2.0 ust trace import</filename>:</emphasis>
+                        Selecting this tool transfers the remote target's
+                        <filename>Lttng</filename> tracing data back to the
+                        local host machine and uses the Lttng Eclipse plug-in
+                        to graphically display the output.
+                        For information on how to use Lttng to trace an
+                        application,
+                        see <ulink url='http://lttng.org/documentation'></ulink>
+                        and the
+                        "<ulink url='&YOCTO_DOCS_PROF_URL;#lttng-linux-trace-toolkit-next-generation'>LTTng (Linux Trace Toolkit, next generation)</ulink>"
+                        section, which is in the Yocto Project Profiling and
+                        Tracing Manual.
+                        <note>Do not use
+                            <filename>Lttng-user space (legacy)</filename> tool.
+                            This tool no longer has any upstream support.</note>
+                        </para>
+                        <para>Before you use the
+                        <filename>Lttng2.0 ust trace import</filename> tool,
+                        you need to setup the Lttng Eclipse plug-in and create a
+                        Tracing project.
+                        Do the following:
+                        <orderedlist>
+                            <listitem><para>Select "Open Perspective" from the
+                                "Window" menu and then select "Tracing".
+                                </para></listitem>
+                            <listitem><para>Click "OK" to change the Eclipse
+                                perspective into the Tracing perspective.
+                                </para></listitem>
+                            <listitem><para>Create a new Tracing project by
+                                selecting "Project" from the "File -> New" menu.
+                                </para></listitem>
+                            <listitem><para>Choose "Tracing Project" from the
+                                "Tracing" menu.
+                                </para></listitem>
+                            <listitem><para>Generate your tracing data on the
+                                remote target.</para></listitem>
+                            <listitem><para>Select "Lttng2.0 ust trace import"
+                                from the "Yocto Project Tools" menu to
+                                start the data import process.</para></listitem>
+                            <listitem><para>Specify your remote connection name.
+                                </para></listitem>
+                            <listitem><para>For the Ust directory path, specify
+                                the location of your remote tracing data.
+                                Make sure the location ends with
+                                <filename>ust</filename> (e.g.
+                                <filename>/usr/mysession/ust</filename>).
+                                </para></listitem>
+                            <listitem><para>Click "OK" to complete the import
+                                process.
+                                The data is now in the local tracing project
+                                you created.</para></listitem>
+                            <listitem><para>Right click on the data and then use
+                                the menu to Select "Generic CTF Trace" from the
+                                "Trace Type... -> Common Trace Format" menu to
+                                map the tracing type.</para></listitem>
+                            <listitem><para>Right click the mouse and select
+                                "Open" to bring up the Eclipse Lttng Trace
+                                Viewer so you view the tracing data.
+                                </para></listitem>
+                        </orderedlist></para></listitem>
+                    <listitem><para><emphasis><filename>PowerTOP</filename>:</emphasis>
+                        Selecting this tool runs PowerTOP on the remote target
+                        machine and displays the results in a new view called
+                        PowerTOP.</para>
+                        <para>The "Time to gather data(sec):" field is the time
+                        passed in seconds before data is gathered from the
+                        remote target for analysis.</para>
+                        <para>The "show pids in wakeups list:" field corresponds
+                        to the <filename>-p</filename> argument passed to
+                        <filename>PowerTOP</filename>.</para></listitem>
+                    <listitem><para><emphasis><filename>LatencyTOP and Perf</filename>:</emphasis>
+                        LatencyTOP identifies system latency, while
+                        Perf monitors the system's performance counter
+                        registers.
+                        Selecting either of these tools causes an RSE terminal
+                        view to appear from which you can run the tools.
+                        Both tools refresh the entire screen to display results
+                        while they run.
+                        For more information on setting up and using
+                        <filename>perf</filename>, see the
+                        "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-perf'>perf</ulink>"
+                        section in the Yocto Project Profiling and Tracing
+                        Manual.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='customizing-an-image-using-a-bitbake-commander-project-and-hob'>
+            <title>Customizing an Image Using a BitBake Commander Project and Hob</title>
+
+            <para>
+                Within the Eclipse IDE, you can create a Yocto BitBake Commander
+                project, edit the <link linkend='metadata'>Metadata</link>, and
+                then use
+                <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink> to build a customized image all within one IDE.
+            </para>
+
+            <section id='creating-the-yocto-bitbake-commander-project'>
+                <title>Creating the Yocto BitBake Commander Project</title>
+
+                <para>
+                    To create a Yocto BitBake Commander project, follow these
+                    steps:
+                    <orderedlist>
+                        <listitem><para>Select "Other" from the
+                            "Window -> Open Perspective" menu
+                            and then choose "Bitbake Commander".
+                            </para></listitem>
+                        <listitem><para>Click "OK" to change the perspective to
+                            Bitbake Commander.</para></listitem>
+                        <listitem><para>Select "Project" from the "File -> New"
+                            menu to create a new Yocto
+                            Bitbake Commander project.</para></listitem>
+                        <listitem><para>Choose "New Yocto Project" from the
+                            "Yocto Project Bitbake Commander" menu and click
+                            "Next".</para></listitem>
+                        <listitem><para>Enter the Project Name and choose the
+                            Project Location.
+                            The Yocto project's Metadata files will be put under
+                            the directory
+                            <filename><replaceable>project_location</replaceable>/<replaceable>project_name</replaceable></filename>.
+                            If that directory does not exist, you need to check
+                            the "Clone from Yocto Git Repository" box, which
+                            would execute a <filename>git clone</filename>
+                            command to get the project's Metadata files.
+                            <note>
+                                Do not specify your BitBake Commander project
+                                location as your Eclipse workspace.
+                                Doing so causes an error indicating that the
+                                current project overlaps the location of
+                                another project.
+                                This error occurs even if no such project exits.
+                            </note></para></listitem>
+                        <listitem><para>Select <filename>Finish</filename> to
+                            create the project.</para></listitem>
+                    </orderedlist>
+                </para>
+            </section>
+
+            <section id='editing-the-metadata'>
+                <title>Editing the Metadata</title>
+
+                <para>
+                    After you create the Yocto Bitbake Commander project, you
+                    can modify the <link linkend='metadata'>Metadata</link>
+                    files by opening them in the project.
+                    When editing recipe files (<filename>.bb</filename> files),
+                    you can view BitBake variable values and information by
+                    hovering the mouse pointer over the variable name and
+                    waiting a few seconds.
+                </para>
+
+                <para>
+                    To edit the Metadata, follow these steps:
+                    <orderedlist>
+                        <listitem><para>Select your Yocto Bitbake Commander
+                            project.</para></listitem>
+                        <listitem><para>Select "BitBake Recipe" from the
+                        "File -> New -> Yocto BitBake Commander" menu
+                            to open a new recipe wizard.</para></listitem>
+                        <listitem><para>Point to your source by filling in the
+                            "SRC_URL" field.
+                            For example, you can add a recipe to your
+                            <link linkend='source-directory'>Source Directory</link>
+                            by defining "SRC_URL" as follows:
+                            <literallayout class='monospaced'>
+     ftp://ftp.gnu.org/gnu/m4/m4-1.4.9.tar.gz
+                            </literallayout></para></listitem>
+                        <listitem><para>Click "Populate" to calculate the
+                            archive md5, sha256, license checksum values and to
+                            auto-generate the recipe filename.</para></listitem>
+                        <listitem><para>Fill in the "Description" field.
+                            </para></listitem>
+                        <listitem><para>Be sure values for all required
+                            fields exist.</para></listitem>
+                        <listitem><para>Click "Finish".</para></listitem>
+                    </orderedlist>
+                </para>
+            </section>
+
+            <section id='biding-and-customizing-the-image-using-hob'>
+                <title>Building and Customizing the Image Using Hob</title>
+
+                <para>
+                    To build and customize the image using Hob from within the
+                    Eclipse IDE, follow these steps:
+                    <orderedlist>
+                        <listitem><para>Select your Yocto Bitbake Commander
+                            project.</para></listitem>
+                        <listitem><para>Select "Launch Hob" from the "Project"
+                            menu.</para></listitem>
+                        <listitem><para>Enter the
+                            <link linkend='build-directory'>Build Directory</link>
+                            where you want to put your final images.
+                            </para></listitem>
+                        <listitem><para>Click "OK" to launch Hob.
+                            </para></listitem>
+                        <listitem><para>Use Hob to customize and build your own
+                            images.
+                            For information on Hob, see the
+                            <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob Project Page</ulink>
+                            on the Yocto Project website.</para></listitem>
+                    </orderedlist>
+                </para>
+            </section>
+        </section>
+    </section>
+
+    <section id='workflow-using-stand-alone-cross-development-toolchains'>
+        <title>Workflow Using Stand-Alone Cross-Development Toolchains</title>
+
+        <para>
+            If you want to develop an application without prior installation
+            of the ADT, you still can employ the
+            <link linkend='cross-development-toolchain'>Cross Development Toolchain</link>,
+            the QEMU emulator, and a number of supported  target image files.
+            You just need to follow these general steps:
+            <orderedlist>
+                <listitem><para><emphasis>Install the cross-development
+                    toolchain for your target hardware:</emphasis>
+                    For information on how to install the toolchain, see the
+                    "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>"
+                    section in the Yocto Project Application Developer's
+                    Guide.</para></listitem>
+                <listitem><para><emphasis>Download the Target Image:</emphasis>
+                    The Yocto Project supports several target architectures
+                    and has many pre-built kernel images and root filesystem
+                    images.</para>
+                    <para>If you are going to develop your application on
+                    hardware, go to the
+                    <ulink url='&YOCTO_MACHINES_DL_URL;'><filename>machines</filename></ulink>
+                    download area and choose a target machine area
+                    from which to download the kernel image and root filesystem.
+                    This download area could have several files in it that
+                    support development using actual hardware.
+                    For example, the area might contain
+                    <filename>.hddimg</filename> files that combine the
+                    kernel image with the filesystem, boot loaders, and
+                    so forth.
+                    Be sure to get the files you need for your particular
+                    development process.</para>
+                    <para>If you are going to develop your application and
+                    then run and test it using the QEMU emulator, go to the
+                    <ulink url='&YOCTO_QEMU_DL_URL;'><filename>machines/qemu</filename></ulink>
+                    download area.
+                    From this area, go down into the directory for your
+                    target architecture (e.g. <filename>qemux86_64</filename>
+                    for an <trademark class='registered'>Intel</trademark>-based
+                    64-bit architecture).
+                    Download kernel, root filesystem, and any other files you
+                    need for your process.
+                    <note>In order to use the root filesystem in QEMU, you
+                    need to extract it.
+                    See the
+                    "<ulink url='&YOCTO_DOCS_ADT_URL;#extracting-the-root-filesystem'>Extracting the Root Filesystem</ulink>"
+                    section for information on how to extract the root
+                    filesystem.</note></para></listitem>
+                <listitem><para><emphasis>Develop and Test your
+                    Application:</emphasis>  At this point, you have the tools
+                    to develop your application.
+                    If you need to separately install and use the QEMU
+                    emulator, you can go to
+                    <ulink url='http://wiki.qemu.org/Main_Page'>QEMU Home Page</ulink>
+                    to download and learn about the emulator.
+                    You can see the
+                    "<link linkend='dev-manual-qemu'>Using the Quick EMUlator (QEMU)</link>"
+                    chapter for information on using QEMU within the Yocto
+                    Project.</para></listitem>
+            </orderedlist>
+        </para>
+    </section>
+</section>
+
+<section id="modifying-temporary-source-code">
+    <title>Modifying Temporary Source Code</title>
+
+    <para>
+        You might
+        find it helpful during development to modify the temporary source code used by recipes
+        to build packages.
+        For example, suppose you are developing a patch and you need to experiment a bit
+        to figure out your solution.
+        After you have initially built the package, you can iteratively tweak the
+        source code, which is located in the
+        <link linkend='build-directory'>Build Directory</link>, and then
+        you can force a re-compile and quickly test your altered code.
+        Once you settle on a solution, you can then preserve your changes in the form of
+        patches.
+        You can accomplish these steps all within either a
+        <ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink> or
+        <link linkend='git'>Git</link> workflow.
+    </para>
+
+    <section id='finding-the-temporary-source-code'>
+        <title>Finding the Temporary Source Code</title>
+
+        <para>
+            During a build, the unpacked temporary source code used by recipes
+            to build packages is available in the Build Directory as
+            defined by the
+            <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-S'>S</ulink></filename> variable.
+            Below is the default value for the <filename>S</filename> variable as defined in the
+            <filename>meta/conf/bitbake.conf</filename> configuration file in the
+            <link linkend='source-directory'>Source Directory</link>:
+            <literallayout class='monospaced'>
+     S = "${WORKDIR}/${BP}"
+            </literallayout>
+            You should be aware that many recipes override the <filename>S</filename> variable.
+            For example, recipes that fetch their source from Git usually set
+            <filename>S</filename> to <filename>${WORKDIR}/git</filename>.
+            <note>
+                The
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-BP'><filename>BP</filename></ulink>
+                represents the base recipe name, which consists of the name and version:
+                <literallayout class='monospaced'>
+     BP = "${BPN}-${PV}"
+                </literallayout>
+            </note>
+        </para>
+
+        <para>
+            The path to the work directory for the recipe
+            (<ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink>)
+            is defined as follows:
+            <literallayout class='monospaced'>
+     ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}
+            </literallayout>
+            The actual directory depends on several things:
+            <itemizedlist>
+                <listitem><ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink>:
+                    The top-level build output directory</listitem>
+                <listitem><ulink url='&YOCTO_DOCS_REF_URL;#var-MULTIMACH_TARGET_SYS'><filename>MULTIMACH_TARGET_SYS</filename></ulink>:
+                    The target system identifier</listitem>
+                <listitem><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink>:
+                    The recipe name</listitem>
+                <listitem><ulink url='&YOCTO_DOCS_REF_URL;#var-EXTENDPE'><filename>EXTENDPE</filename></ulink>:
+                    The epoch - (if
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PE'><filename>PE</filename></ulink>
+                    is not specified, which is usually the case for most
+                    recipes, then <filename>EXTENDPE</filename> is blank)</listitem>
+                <listitem><ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>:
+                    The recipe version</listitem>
+                <listitem><ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>:
+                    The recipe revision</listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            As an example, assume a Source Directory top-level folder
+            name <filename>poky</filename>, a default Build Directory at
+            <filename>poky/build</filename>, and a
+            <filename>qemux86-poky-linux</filename> machine target
+            system.
+            Furthermore, suppose your recipe is named
+            <filename>foo_1.3.0.bb</filename>.
+            In this case, the work directory the build system uses to
+            build the package would be as follows:
+            <literallayout class='monospaced'>
+     poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
+            </literallayout>
+        </para>
+
+        <para>
+            Now that you know where to locate the directory that has the temporary source code,
+            you can use a Quilt or Git workflow to make your edits, test the changes,
+            and preserve the changes in the form of patches.
+        </para>
+    </section>
+
+    <section id="using-a-quilt-workflow">
+        <title>Using a Quilt Workflow</title>
+
+        <para>
+            <ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink>
+            is a powerful tool that allows you to capture source code changes without having
+            a clean source tree.
+            This section outlines the typical workflow you can use to modify temporary source code,
+            test changes, and then preserve the changes in the form of a patch all using Quilt.
+        </para>
+
+        <para>
+            Follow these general steps:
+            <orderedlist>
+                <listitem><para><emphasis>Find the Source Code:</emphasis>
+                    The temporary source code used by the OpenEmbedded build system is kept in the
+                    Build Directory.
+                    See the
+                    "<link linkend='finding-the-temporary-source-code'>Finding the Temporary Source Code</link>"
+                    section to learn how to locate the directory that has the temporary source code for a
+                    particular package.</para></listitem>
+                <listitem><para><emphasis>Change Your Working Directory:</emphasis>
+                    You need to be in the directory that has the temporary source code.
+                    That directory is defined by the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink>
+                    variable.</para></listitem>
+                <listitem><para><emphasis>Create a New Patch:</emphasis>
+                    Before modifying source code, you need to create a new patch.
+                    To create a new patch file, use <filename>quilt new</filename> as below:
+                    <literallayout class='monospaced'>
+     $ quilt new my_changes.patch
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Notify Quilt and Add Files:</emphasis>
+                    After creating the patch, you need to notify Quilt about the files
+                    you plan to edit.
+                    You notify Quilt by adding the files to the patch you just created:
+                    <literallayout class='monospaced'>
+     $ quilt add file1.c file2.c file3.c
+                    </literallayout>
+                    </para></listitem>
+                <listitem><para><emphasis>Edit the Files:</emphasis>
+                    Make your changes in the temporary source code to the files you added
+                    to the patch.</para></listitem>
+                <listitem><para><emphasis>Test Your Changes:</emphasis>
+                    Once you have modified the source code, the easiest way to
+                    your changes is by calling the
+                    <filename>do_compile</filename> task as shown in the
+                    following example:
+                    <literallayout class='monospaced'>
+     $ bitbake -c compile -f <replaceable>name_of_package</replaceable>
+                    </literallayout>
+                    The <filename>-f</filename> or <filename>--force</filename>
+                    option forces the specified task to execute.
+                    If you find problems with your code, you can just keep editing and
+                    re-testing iteratively until things work as expected.
+                    <note>All the modifications you make to the temporary source code
+                    disappear once you run the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-clean'><filename>do_clean</filename></ulink>
+                    or
+                    <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-cleanall'><filename>do_cleanall</filename></ulink>
+                    tasks using BitBake (i.e.
+                    <filename>bitbake -c clean <replaceable>name_of_package</replaceable></filename>
+                    and
+                    <filename>bitbake -c cleanall <replaceable>name_of_package</replaceable></filename>).
+                    Modifications will also disappear if you use the <filename>rm_work</filename>
+                    feature as described in the
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>"
+                    section of the Yocto Project Quick Start.
+                    </note></para></listitem>
+                <listitem><para><emphasis>Generate the Patch:</emphasis>
+                    Once your changes work as expected, you need to use Quilt to generate the final patch that
+                    contains all your modifications.
+                    <literallayout class='monospaced'>
+     $ quilt refresh
+                    </literallayout>
+                    At this point, the <filename>my_changes.patch</filename> file has all your edits made
+                    to the <filename>file1.c</filename>, <filename>file2.c</filename>, and
+                    <filename>file3.c</filename> files.</para>
+                    <para>You can find the resulting patch file in the <filename>patches/</filename>
+                    subdirectory of the source (<filename>S</filename>) directory.</para></listitem>
+                <listitem><para><emphasis>Copy the Patch File:</emphasis>
+                    For simplicity, copy the patch file into a directory named <filename>files</filename>,
+                    which you can create in the same directory that holds the recipe
+                    (<filename>.bb</filename>) file or the
+                    append (<filename>.bbappend</filename>) file.
+                    Placing the patch here guarantees that the OpenEmbedded build system will find
+                    the patch.
+                    Next, add the patch into the
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'>SRC_URI</ulink></filename>
+                    of the recipe.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     SRC_URI += "file://my_changes.patch"
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Increment the Recipe Revision Number:</emphasis>
+                    Finally, don't forget to 'bump' the
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PR'>PR</ulink></filename>
+                    value in the recipe since the resulting packages have changed.</para></listitem>
+            </orderedlist>
+        </para>     </section>
+
+    <section id='using-a-git-workflow'>
+        <title>Using a Git Workflow</title>
+        <para>
+            Git is an even more powerful tool that allows you to capture source code changes without having
+            a clean source tree.
+            This section outlines the typical workflow you can use to modify temporary source code,
+            test changes, and then preserve the changes in the form of a patch all using Git.
+            For general information on Git as it is used in the Yocto Project, see the
+            "<link linkend='git'>Git</link>" section.
+        </para>
+
+        <note>
+            This workflow uses Git only for its ability to manage local changes to the source code
+            and produce patches independent of any version control system used with the Yocto Project.
+        </note>
+
+        <para>
+            Follow these general steps:
+            <orderedlist>
+                <listitem><para><emphasis>Find the Source Code:</emphasis>
+                    The temporary source code used by the OpenEmbedded build system is kept in the
+                    Build Directory.
+                    See the
+                    "<link linkend='finding-the-temporary-source-code'>Finding the Temporary Source Code</link>"
+                    section to learn how to locate the directory that has the temporary source code for a
+                    particular package.</para></listitem>
+                <listitem><para><emphasis>Change Your Working Directory:</emphasis>
+                    You need to be in the directory that has the temporary source code.
+                    That directory is defined by the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink>
+                    variable.</para></listitem>
+                <listitem><para><emphasis>If needed, initialize a Git Repository:</emphasis>
+                    If the recipe you are working with does not use a Git fetcher,
+                    you need to set up a Git repository as follows:
+                    <literallayout class='monospaced'>
+     $ git init
+     $ git add *
+     $ git commit -m "initial revision"
+                    </literallayout>
+                    The above Git commands initialize a Git repository that is based on the
+                    files in your current working directory, stage all the files, and commit
+                    the files.
+                    At this point, your Git repository is aware of all the source code files.
+                    Any edits you now make to files can be committed later and will be tracked by
+                    Git.</para></listitem>
+                <listitem><para><emphasis>Edit the Files:</emphasis>
+                    Make your changes to the temporary source code.</para></listitem>
+                <listitem><para><emphasis>Test Your Changes:</emphasis>
+                    Once you have modified the source code, the easiest way
+                    to test your changes is by calling the
+                    <filename>do_compile</filename> task as shown in the
+                    following example:
+                    <literallayout class='monospaced'>
+     $ bitbake -c compile -f <replaceable>name_of_package</replaceable>
+                    </literallayout>
+                    The <filename>-f</filename> or <filename>--force</filename>
+                    option forces the specified task to execute.
+                    If you find problems with your code, you can just keep editing and
+                    re-testing iteratively until things work as expected.
+                    <note>All the modifications you make to the temporary source code
+                    disappear once you <filename>-c clean</filename>, <filename>-c cleansstate</filename>,
+                    or <filename>-c cleanall</filename> with BitBake for the package.
+                    Modifications will also disappear if you use the <filename>rm_work</filename>
+                    feature as described in the
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>"
+                    section of the Yocto Project Quick Start.
+                    </note></para></listitem>
+                <listitem><para><emphasis>See the List of Files You Changed:</emphasis>
+                    Use the <filename>git status</filename> command to see what files you have actually edited.
+                    The ability to have Git track the files you have changed is an advantage that this
+                    workflow has over the Quilt workflow.
+                    Here is the Git command to list your changed files:
+                    <literallayout class='monospaced'>
+     $ git status
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Stage the Modified Files:</emphasis>
+                    Use the <filename>git add</filename> command to stage the changed files so they
+                    can be committed as follows:
+                    <literallayout class='monospaced'>
+     $ git add file1.c file2.c file3.c
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Commit the Staged Files and View Your Changes:</emphasis>
+                    Use the <filename>git commit</filename> command to commit the changes to the
+                    local repository.
+                    Once you have committed the files, you can use the <filename>git log</filename>
+                    command to see your changes:
+                    <literallayout class='monospaced'>
+     $ git commit -m "<replaceable>commit-summary-message</replaceable>"
+     $ git log
+                    </literallayout>
+                    <note>The name of the patch file created in the next step is based on your
+                        <replaceable>commit-summary-message</replaceable>.</note></para></listitem>
+                <listitem><para><emphasis>Generate the Patch:</emphasis>
+                    Once the changes are committed, use the <filename>git format-patch</filename>
+                    command to generate a patch file:
+                    <literallayout class='monospaced'>
+     $ git format-patch -1
+                    </literallayout>
+                    Specifying "-1" causes Git to generate the
+                    patch file for the most recent commit.</para>
+                    <para>At this point, the patch file has all your edits made
+                    to the <filename>file1.c</filename>, <filename>file2.c</filename>, and
+                    <filename>file3.c</filename> files.
+                    You can find the resulting patch file in the current directory and it
+                    is named according to the <filename>git commit</filename> summary line.
+                    The patch file ends with <filename>.patch</filename>.</para></listitem>
+                <listitem><para><emphasis>Copy the Patch File:</emphasis>
+                    For simplicity, copy the patch file into a directory named <filename>files</filename>,
+                    which you can create in the same directory that holds the recipe
+                    (<filename>.bb</filename>) file or the
+                    append (<filename>.bbappend</filename>) file.
+                    Placing the patch here guarantees that the OpenEmbedded build system will find
+                    the patch.
+                    Next, add the patch into the
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'>SRC_URI</ulink></filename>
+                    of the recipe.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     SRC_URI += "file://0001-<replaceable>commit-summary-message</replaceable>.patch"
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Increment the Recipe Revision Number:</emphasis>
+                    Finally, don't forget to 'bump' the
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PR'>PR</ulink></filename>
+                    value in the recipe since the resulting packages have changed.</para></listitem>
+            </orderedlist>
+        </para>
+    </section>
+</section>
+
+<section id='image-development-using-hob'>
+    <title>Image Development Using Hob</title>
+
+    <para>
+        The <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink> is a graphical user interface for the
+        OpenEmbedded build system, which is based on BitBake.
+        You can use the Hob to build custom operating system images within the Yocto Project build environment.
+        Hob simply provides a friendly interface over the build system used during development.
+        In other words, building images with the Hob lets you take care of common build tasks more easily.
+    </para>
+
+    <para>
+        For a better understanding of Hob, see the project page at
+        <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'></ulink>
+        on the Yocto Project website.
+        If you follow the "Documentation" link from the Hob page, you will
+        find a short introductory training video on Hob.
+        The following lists some features of Hob:
+        <itemizedlist>
+            <listitem><para>You can setup and run Hob using these commands:
+            <literallayout class='monospaced'>
+     $ source oe-init-build-env
+     $ hob
+            </literallayout></para></listitem>
+            <listitem><para>You can set the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
+                for which you are building the image.</para></listitem>
+            <listitem><para>You can modify various policy settings such as the
+                package format with which to build,
+                the parallelism BitBake uses, whether or not to build an
+                external toolchain, and which host to build against.
+                </para></listitem>
+            <listitem><para>You can manage
+                <link linkend='understanding-and-creating-layers'>layers</link>.</para></listitem>
+            <listitem><para>You can select a base image and then add extra packages for your custom build.
+                </para></listitem>
+            <listitem><para>You can launch and monitor the build from within Hob.</para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id="platdev-appdev-devshell">
+    <title>Using a Development Shell</title>
+
+    <para>
+        When debugging certain commands or even when just editing packages,
+        <filename>devshell</filename> can be a useful tool.
+        When you invoke <filename>devshell</filename>, source files are
+        extracted into your working directory and patches are applied.
+        Then, a new terminal is opened and you are placed in the working directory.
+        In the new terminal, all the OpenEmbedded build-related environment variables are
+        still defined so you can use commands such as <filename>configure</filename> and
+        <filename>make</filename>.
+        The commands execute just as if the OpenEmbedded build system were executing them.
+        Consequently, working this way can be helpful when debugging a build or preparing
+        software to be used with the OpenEmbedded build system.
+    </para>
+
+    <para>
+        Following is an example that uses <filename>devshell</filename> on a target named
+        <filename>matchbox-desktop</filename>:
+        <literallayout class='monospaced'>
+     $ bitbake matchbox-desktop -c devshell
+        </literallayout>
+    </para>
+
+    <para>
+        This command spawns a terminal with a shell prompt within the OpenEmbedded build environment.
+        The <ulink url='&YOCTO_DOCS_REF_URL;#var-OE_TERMINAL'><filename>OE_TERMINAL</filename></ulink>
+        variable controls what type of shell is opened.
+    </para>
+
+    <para>
+        For spawned terminals, the following occurs:
+        <itemizedlist>
+            <listitem><para>The <filename>PATH</filename> variable includes the
+                cross-toolchain.</para></listitem>
+            <listitem><para>The <filename>pkgconfig</filename> variables find the correct
+                <filename>.pc</filename> files.</para></listitem>
+                <listitem><para>The <filename>configure</filename> command finds the
+                Yocto Project site files as well as any other necessary files.</para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        Within this environment, you can run configure or compile
+        commands as if they were being run by
+        the OpenEmbedded build system itself.
+        As noted earlier, the working directory also automatically changes to the
+        Source Directory (<ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink>).
+    </para>
+
+    <para>
+        When you are finished, you just exit the shell or close the terminal window.
+    </para>
+
+    <note>
+        <para>
+            It is worth remembering that when using <filename>devshell</filename>
+            you need to use the full compiler name such as <filename>arm-poky-linux-gnueabi-gcc</filename>
+            instead of just using <filename>gcc</filename>.
+            The same applies to other applications such as <filename>binutils</filename>,
+            <filename>libtool</filename> and so forth.
+            BitBake sets up environment variables such as <filename>CC</filename>
+            to assist applications, such as <filename>make</filename> to find the correct tools.
+        </para>
+
+        <para>
+            It is also worth noting that <filename>devshell</filename> still works over
+            X11 forwarding and similar situations.
+        </para>
+    </note>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml
new file mode 100644
index 0000000000..2385187f4d
--- /dev/null
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -0,0 +1,1692 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='dev-manual-newbie'>
+
+<title>The Yocto Project Open Source Development Environment</title>
+
+<para>
+    This chapter helps you understand the Yocto Project as an open source development project.
+    In general, working in an open source environment is very different from working in a
+    closed, proprietary environment.
+    Additionally, the Yocto Project uses specific tools and constructs as part of its development
+    environment.
+    This chapter specifically addresses open source philosophy, using the
+    Yocto Project in a team environment, source repositories, Yocto Project
+    terms, licensing, the open source distributed version control system Git,
+    workflows, bug tracking, and how to submit changes.
+</para>
+
+<section id='open-source-philosophy'>
+    <title>Open Source Philosophy</title>
+
+    <para>
+        Open source philosophy is characterized by software development directed by peer production
+        and collaboration through an active community of developers.
+        Contrast this to the more standard centralized development models used by commercial software
+        companies where a finite set of developers produces a product for sale using a defined set
+        of procedures that ultimately result in an end product whose architecture and source material
+        are closed to the public.
+    </para>
+
+    <para>
+        Open source projects conceptually have differing concurrent agendas, approaches, and production.
+        These facets of the development process can come from anyone in the public (community) that has a
+        stake in the software project.
+        The open source environment contains new copyright, licensing, domain, and consumer issues
+        that differ from the more traditional development environment.
+        In an open source environment, the end product, source material, and documentation are
+        all available to the public at no cost.
+    </para>
+
+    <para>
+        A benchmark example of an open source project is the Linux kernel, which was initially conceived
+        and created by Finnish computer science student Linus Torvalds in 1991.
+        Conversely, a good example of a non-open source project is the
+        <trademark class='registered'>Windows</trademark> family of operating
+        systems developed by <trademark class='registered'>Microsoft</trademark> Corporation.
+    </para>
+
+    <para>
+        Wikipedia has a good historical description of the Open Source Philosophy
+        <ulink url='http://en.wikipedia.org/wiki/Open_source'>here</ulink>.
+        You can also find helpful information on how to participate in the Linux Community
+        <ulink url='http://ldn.linuxfoundation.org/book/how-participate-linux-community'>here</ulink>.
+    </para>
+</section>
+
+<section id="usingpoky-changes-collaborate">
+    <title>Using the Yocto Project in a Team Environment</title>
+
+    <para>
+        It might not be immediately clear how you can use the Yocto
+        Project in a team environment, or scale it for a large team of
+        developers.
+        One of the strengths of the Yocto Project is that it is extremely
+        flexible.
+        Thus, you can adapt it to many different use cases and scenarios.
+        However, these characteristics can cause a struggle if you are trying
+        to create a working setup that scales across a large team.
+    </para>
+
+    <para>
+        To help with these types of situations, this section presents
+        some of the project's most successful experiences,
+        practices, solutions, and available technologies that work well.
+        Keep in mind, the information here is a starting point.
+        You can build off it and customize it to fit any
+        particular working environment and set of practices.
+    </para>
+
+    <section id='best-practices-system-configurations'>
+        <title>System Configurations</title>
+
+        <para>
+            Systems across a large team should meet the needs of
+            two types of developers: those working on the contents of the
+            operating system image itself and those developing applications.
+            Regardless of the type of developer, their workstations must
+            be both reasonably powerful and run Linux.
+        </para>
+
+        <section id='best-practices-application-development'>
+            <title>Application Development</title>
+
+            <para>
+                For developers who mainly do application level work
+                on top of an existing software stack,
+                here are some practices that work best:
+                <itemizedlist>
+                    <listitem><para>Use a pre-built toolchain that
+                        contains the software stack itself.
+                        Then, develop the application code on top of the
+                        stack.
+                        This method works well for small numbers of relatively
+                        isolated applications.</para></listitem>
+                    <listitem><para>When possible, use the Yocto Project
+                        plug-in for the <trademark class='trade'>Eclipse</trademark> IDE
+                        and other pieces of Application Development
+                        Technology (ADT).
+                        For more information, see the
+                        "<link linkend='application-development-workflow'>Application
+                        Development Workflow</link>" section as well as the
+                        <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>.
+                        </para></listitem>
+                    <listitem><para>Keep your cross-development toolchains
+                        updated.
+                        You can do this through provisioning either as new
+                        toolchain downloads or as updates through a package
+                        update mechanism using <filename>opkg</filename>
+                        to provide updates to an existing toolchain.
+                        The exact mechanics of how and when to do this are a
+                        question for local policy.</para></listitem>
+                    <listitem><para>Use multiple toolchains installed locally
+                        into different locations to allow development across
+                        versions.</para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='best-practices-core-system-development'>
+            <title>Core System Development</title>
+
+            <para>
+                For core system development, it is often best to have the
+                build system itself available on the developer workstations
+                so developers can run their own builds and directly
+                rebuild the software stack.
+                You should keep the core system unchanged as much as
+                possible and do your work in layers on top of the core system.
+                Doing so gives you a greater level of portability when
+                upgrading to new versions of the core system or Board
+                Support Packages (BSPs).
+                You can share layers amongst the developers of a particular
+                project and contain the policy configuration that defines
+                the project.
+            </para>
+
+            <para>
+                Aside from the previous best practices, there exists a number
+                of tips and tricks that can help speed up core development
+                projects:
+                <itemizedlist>
+                    <listitem><para>Use a
+                        <ulink url='&YOCTO_DOCS_REF_URL;#shared-state-cache'>Shared State Cache</ulink>
+                        (sstate) among groups of developers who are on a
+                        fast network.
+                        The best way to share sstate is through a
+                        Network File System (NFS) share.
+                        The first user to build a given component for the
+                        first time contributes that object to the sstate,
+                        while subsequent builds from other developers then
+                        reuse the object rather than rebuild it themselves.
+                        </para>
+                        <para>Although it is possible to use other protocols for the
+                        sstate such as HTTP and FTP, you should avoid these.
+                        Using HTTP limits the sstate to read-only and
+                        FTP provides poor performance.
+                        </para></listitem>
+                    <listitem><para>Have autobuilders contribute to the sstate
+                        pool similarly to how the developer workstations
+                        contribute.
+                        For information, see the
+                        "<link linkend='best-practices-autobuilders'>Autobuilders</link>"
+                        section.</para></listitem>
+                    <listitem><para>Build stand-alone tarballs that contain
+                        "missing" system requirements if for some reason
+                        developer workstations do not meet minimum system
+                        requirements such as latest Python versions,
+                        <filename>chrpath</filename>, or other tools.
+                        You can install and relocate the tarball exactly as you
+                        would the usual cross-development toolchain so that
+                        all developers can meet minimum version requirements
+                        on most distributions.</para></listitem>
+                    <listitem><para>Use a small number of shared,
+                        high performance systems for testing purposes
+                        (e.g. dual, six-core Xeons with 24 Gbytes of RAM
+                        and plenty of disk space).
+                        Developers can use these systems for wider, more
+                        extensive testing while they continue to develop
+                        locally using their primary development system.
+                        </para></listitem>
+                    <listitem><para>Enable the PR Service when package feeds
+                        need to be incremental with continually increasing
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'>PR</ulink>
+                        values.
+                        Typically, this situation occurs when you use or
+                        publish package feeds and use a shared state.
+                        You should enable the PR Service for all users who
+                        use the shared state pool.
+                        For more information on the PR Service, see the
+                        "<link linkend='working-with-a-pr-service'>Working With a PR Service</link>".
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+    </section>
+
+    <section id='best-practices-source-control-management'>
+        <title>Source Control Management (SCM)</title>
+
+        <para>
+            Keeping your
+            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+            and any software you are developing under the
+            control of an SCM system that is compatible
+            with the OpenEmbedded build system is advisable.
+            Of the SCMs BitBake supports, the
+            Yocto Project team strongly recommends using
+            <link linkend='git'>Git</link>.
+            Git is a distributed system that is easy to backup,
+            allows you to work remotely, and then connects back to the
+            infrastructure.
+            <note>
+                For information about BitBake, see the
+                <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
+            </note>
+        </para>
+
+        <para>
+            It is relatively easy to set up Git services and create
+            infrastructure like
+            <ulink url='&YOCTO_GIT_URL;'>http://git.yoctoproject.org</ulink>,
+            which is based on server software called
+            <filename>gitolite</filename> with <filename>cgit</filename>
+            being used to generate the web interface that lets you view the
+            repositories.
+            The <filename>gitolite</filename> software identifies users
+            using SSH keys and allows branch-based
+            access controls to repositories that you can control as little
+            or as much as necessary.
+        </para>
+
+        <note>
+            The setup of these services is beyond the scope of this manual.
+            However, sites such as these exist that describe how to perform
+            setup:
+            <itemizedlist>
+                <listitem><para><ulink url='http://git-scm.com/book/ch4-8.html'>Git documentation</ulink>:
+                    Describes how to install <filename>gitolite</filename>
+                    on the server.</para></listitem>
+                <listitem><para><ulink url='http://sitaramc.github.com/gitolite/master-toc.html'>The <filename>gitolite</filename> master index</ulink>:
+                    All topics for <filename>gitolite</filename>.
+                    </para></listitem>
+                <listitem><para><ulink url='https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools'>Interfaces, frontends, and tools</ulink>:
+                    Documentation on how to create interfaces and frontends
+                    for Git.</para></listitem>
+            </itemizedlist>
+        </note>
+    </section>
+
+    <section id='best-practices-autobuilders'>
+        <title>Autobuilders</title>
+
+        <para>
+            Autobuilders are often the core of a development project.
+            It is here that changes from individual developers are brought
+            together and centrally tested and subsequent decisions about
+            releases can be made.
+            Autobuilders also allow for "continuous integration" style
+            testing of software components and regression identification
+            and tracking.
+        </para>
+
+        <para>
+            See "<ulink url='http://autobuilder.yoctoproject.org'>Yocto Project Autobuilder</ulink>"
+            for more information and links to buildbot.
+            The Yocto Project team has found this implementation
+            works well in this role.
+            A public example of this is the Yocto Project
+            Autobuilders, which we use to test the overall health of the
+            project.
+        </para>
+
+        <para>
+            The features of this system are:
+            <itemizedlist>
+                <listitem><para>Highlights when commits break the build.
+                    </para></listitem>
+                <listitem><para>Populates an sstate cache from which
+                    developers can pull rather than requiring local
+                    builds.</para></listitem>
+                <listitem><para>Allows commit hook triggers,
+                    which trigger builds when commits are made.
+                    </para></listitem>
+                <listitem><para>Allows triggering of automated image booting
+                    and testing under the QuickEMUlator (QEMU).
+                    </para></listitem>
+                <listitem><para>Supports incremental build testing and
+                    from-scratch builds.</para></listitem>
+                <listitem><para>Shares output that allows developer
+                    testing and historical regression investigation.
+                    </para></listitem>
+                <listitem><para>Creates output that can be used for releases.
+                    </para></listitem>
+                <listitem><para>Allows scheduling of builds so that resources
+                    can be used efficiently.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='best-practices-policies-and-change-flow'>
+        <title>Policies and Change Flow</title>
+
+        <para>
+            The Yocto Project itself uses a hierarchical structure and a
+            pull model.
+            Scripts exist to create and send pull requests
+            (i.e. <filename>create-pull-request</filename> and
+            <filename>send-pull-request</filename>).
+            This model is in line with other open source projects where
+            maintainers are responsible for specific areas of the project
+            and a single maintainer handles the final "top-of-tree" merges.
+        </para>
+
+        <note>
+            You can also use a more collective push model.
+            The <filename>gitolite</filename> software supports both the
+            push and pull models quite easily.
+        </note>
+
+        <para>
+            As with any development environment, it is important
+            to document the policy used as well as any main project
+            guidelines so they are understood by everyone.
+            It is also a good idea to have well structured
+            commit messages, which are usually a part of a project's
+            guidelines.
+            Good commit messages are essential when looking back in time and
+            trying to understand why changes were made.
+        </para>
+
+        <para>
+            If you discover that changes are needed to the core layer of the
+            project, it is worth sharing those with the community as soon
+            as possible.
+            Chances are if you have discovered the need for changes, someone
+            else in the community needs them also.
+        </para>
+    </section>
+
+    <section id='best-practices-summary'>
+        <title>Summary</title>
+
+        <para>
+            This section summarizes the key recommendations described in the
+            previous sections:
+            <itemizedlist>
+                <listitem><para>Use <link linkend='git'>Git</link>
+                    as the source control system.</para></listitem>
+                <listitem><para>Maintain your Metadata in layers that make sense
+                    for your situation.
+                    See the "<link linkend='understanding-and-creating-layers'>Understanding
+                    and Creating Layers</link>" section for more information on
+                    layers.</para></listitem>
+                <listitem><para>
+                    Separate the project's Metadata and code by using
+                    separate Git repositories.
+                    See the
+                    "<link linkend='yocto-project-repositories'>Yocto Project Source Repositories</link>"
+                    section for information on these repositories.
+                    See the
+                    "<link linkend='getting-setup'>Getting Set Up</link>"
+                    section for information on how to set up local Git
+                    repositories for related upstream Yocto Project
+                    Git repositories.
+                    </para></listitem>
+                <listitem><para>Set up the directory for the shared state cache
+                    (<ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_DIR'><filename>SSTATE_DIR</filename></ulink>)
+                    where it makes sense.
+                    For example, set up the sstate cache on a system used
+                    by developers in the same organization and share the
+                    same source directories on their machines.
+                    </para></listitem>
+                <listitem><para>Set up an Autobuilder and have it populate the
+                    sstate cache and source directories.</para></listitem>
+                <listitem><para>The Yocto Project community encourages you
+                    to send patches to the project to fix bugs or add features.
+                    If you do submit patches, follow the project commit
+                    guidelines for writing good commit messages.
+                    See the "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
+                    section.</para></listitem>
+                <listitem><para>Send changes to the core sooner than later
+                    as others are likely to run into the same issues.
+                    For some guidance on mailing lists to use, see the list in the
+                    "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
+                    section.
+                    For a description of the available mailing lists, see the
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing Lists</ulink>"
+                    section in the Yocto Project Reference Manual.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
+
+<section id='yocto-project-repositories'>
+    <title>Yocto Project Source Repositories</title>
+
+    <para>
+        The Yocto Project team maintains complete source repositories for all
+        Yocto Project files at
+        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'></ulink>.
+        This web-based source code browser is organized into categories by
+        function such as IDE Plugins, Matchbox, Poky, Yocto Linux Kernel, and
+        so forth.
+        From the interface, you can click on any particular item in the "Name"
+        column and see the URL at the bottom of the page that you need to clone
+        a Git repository for that particular item.
+        Having a local Git repository of the
+        <link linkend='source-directory'>Source Directory</link>, which is
+        usually named "poky", allows
+        you to make changes, contribute to the history, and ultimately enhance
+        the Yocto Project's tools, Board Support Packages, and so forth.
+    </para>
+
+    <para>
+        For any supported release of Yocto Project, you can also go to the
+        <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink> and
+        select the "Downloads" tab and get a released tarball of the
+        <filename>poky</filename> repository or any supported BSP tarballs.
+        Unpacking these tarballs gives you a snapshot of the released
+        files.
+        <note><title>Notes</title>
+            <itemizedlist>
+                <listitem><para>
+                    The recommended method for setting up the Yocto Project
+                    <link linkend='source-directory'>Source Directory</link>
+                    and the files for supported BSPs
+                    (e.g., <filename>meta-intel</filename>) is to use
+                    <link linkend='git'>Git</link> to create a local copy of
+                    the upstream repositories.
+                    </para></listitem>
+                <listitem><para>
+                    Be sure to always work in matching branches for both
+                    the selected BSP repository and the
+                    <link linkend='source-directory'>Source Directory</link>
+                    (i.e. <filename>poky</filename>) repository.
+                    For example, if you have checked out the "master" branch
+                    of <filename>poky</filename> and you are going to use
+                    <filename>meta-intel</filename>, be sure to checkout the
+                    "master" branch of <filename>meta-intel</filename>.
+                    </para></listitem>
+            </itemizedlist>
+        </note>
+    </para>
+
+    <para>
+        In summary, here is where you can get the project files needed for development:
+        <itemizedlist>
+            <listitem><para id='source-repositories'><emphasis><ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'>Source Repositories:</ulink></emphasis>
+                This area contains IDE Plugins, Matchbox, Poky, Poky Support, Tools, Yocto Linux Kernel, and Yocto
+                Metadata Layers.
+                You can create local copies of Git repositories for each of these areas.</para>
+                <para>
+                <imagedata fileref="figures/source-repos.png" align="center" width="6in" depth="4in" />
+                </para></listitem>
+            <listitem><para><anchor id='index-downloads' /><emphasis><ulink url='&YOCTO_DL_URL;/releases/'>Index of /releases:</ulink></emphasis>
+                This is an index of releases such as
+                the <trademark class='trade'>Eclipse</trademark>
+                Yocto Plug-in, miscellaneous support, Poky, Pseudo, installers for cross-development toolchains,
+                and all released versions of Yocto Project in the form of images or tarballs.
+                Downloading and extracting these files does not produce a local copy of the
+                Git repository but rather a snapshot of a particular release or image.</para>
+                <para>
+                <imagedata fileref="figures/index-downloads.png" align="center" width="6in" depth="3.5in" />
+                </para></listitem>
+            <listitem><para><emphasis>"Downloads" page for the
+                <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>:</emphasis>
+                Access this page by going to the website and then selecting
+                the "Downloads" tab.
+                This page allows you to download any Yocto Project
+                release or Board Support Package (BSP) in tarball form.
+                The tarballs are similar to those found in the
+                <ulink url='&YOCTO_DL_URL;/releases/'>Index of /releases:</ulink> area.</para>
+                <para>
+                <imagedata fileref="figures/yp-download.png" align="center" width="6in" depth="4in" />
+            </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='yocto-project-terms'>
+    <title>Yocto Project Terms</title>
+
+    <para>
+        Following is a list of terms and definitions users new to the Yocto Project development
+        environment might find helpful.
+        While some of these terms are universal, the list includes them just in case:
+        <itemizedlist>
+            <listitem><para><emphasis>Append Files:</emphasis> Files that append build information to
+                a recipe file.
+                Append files are known as BitBake append files and <filename>.bbappend</filename> files.
+                The OpenEmbedded build system expects every append file to have a corresponding
+                recipe (<filename>.bb</filename>) file.
+                Furthermore, the append file and corresponding recipe file
+                must use the same root filename.
+                The filenames can differ only in the file type suffix used (e.g.
+                <filename>formfactor_0.0.bb</filename> and <filename>formfactor_0.0.bbappend</filename>).
+                </para>
+                <para>Information in append files extends or overrides the
+                information in the similarly-named recipe file.
+                For an example of an append file in use, see the
+                "<link linkend='using-bbappend-files'>Using .bbappend Files</link>" section.
+                <note>
+                    Append files can also use wildcard patterns in their version numbers
+                    so they can be applied to more than one version of the underlying recipe file.
+                </note>
+                </para></listitem>
+            <listitem><para id='bitbake-term'><emphasis>BitBake:</emphasis>
+                The task executor and scheduler used by the OpenEmbedded build
+                system to build images.
+                For more information on BitBake, see the
+                <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
+                </para></listitem>
+            <listitem>
+                <para id='build-directory'><emphasis>Build Directory:</emphasis>
+                This term refers to the area used by the OpenEmbedded build
+                system for builds.
+                The area is created when you <filename>source</filename> the
+                setup environment script that is found in the Source Directory
+                (i.e. <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                or
+                <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>).
+                The <ulink url='&YOCTO_DOCS_REF_URL;#var-TOPDIR'><filename>TOPDIR</filename></ulink>
+                variable points to the Build Directory.</para>
+
+                <para>
+                    You have a lot of flexibility when creating the Build
+                    Directory.
+                    Following are some examples that show how to create the
+                    directory.
+                    The examples assume your
+                    <link linkend='source-directory'>Source Directory</link> is
+                    named <filename>poky</filename>:
+                   <itemizedlist>
+                        <listitem><para>Create the Build Directory inside your
+                            Source Directory and let the name of the Build
+                            Directory default to <filename>build</filename>:
+                            <literallayout class='monospaced'>
+     $ cd $HOME/poky
+     $ source &OE_INIT_FILE;
+                            </literallayout></para></listitem>
+                        <listitem><para>Create the Build Directory inside your
+                            home directory and specifically name it
+                            <filename>test-builds</filename>:
+                            <literallayout class='monospaced'>
+     $ cd $HOME
+     $ source poky/&OE_INIT_FILE; test-builds
+                            </literallayout></para></listitem>
+                        <listitem><para>
+                            Provide a directory path and
+                            specifically name the Build Directory.
+                            Any intermediate folders in the pathname must
+                            exist.
+                            This next example creates a Build Directory named
+                            <filename>YP-&POKYVERSION;</filename>
+                            in your home directory within the existing
+                            directory <filename>mybuilds</filename>:
+                            <literallayout class='monospaced'>
+     $cd $HOME
+     $ source $HOME/poky/&OE_INIT_FILE; $HOME/mybuilds/YP-&POKYVERSION;
+                            </literallayout></para></listitem>
+                    </itemizedlist>
+                    <note>
+                        By default, the Build Directory contains
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink>,
+                        which is a temporary directory the build system uses for
+                        its work.
+                        <filename>TMPDIR</filename> cannot be under NFS.
+                        Thus, by default, the Build Directory cannot be under NFS.
+                        However, if you need the Build Directory to be under NFS,
+                        you can set this up by setting <filename>TMPDIR</filename>
+                        in your <filename>local.conf</filename> file
+                        to use a local drive.
+                        Doing so effectively separates <filename>TMPDIR</filename>
+                        from <filename>TOPDIR</filename>, which is the Build
+                        Directory.
+                    </note>
+                    </para></listitem>
+            <listitem><para id='build-system-term'><emphasis>Build System:</emphasis>
+                In the context of the Yocto Project,
+                this term refers to the OpenEmbedded build system used by the project.
+                This build system is based on the project known as "Poky."
+                For some historical information about Poky, see the
+                <link linkend='poky'>Poky</link> term.
+                </para></listitem>
+            <listitem><para><emphasis>Classes:</emphasis> Files that provide for logic encapsulation
+                and inheritance so that commonly used patterns can be defined once and then easily used
+                in multiple recipes.
+                For reference information on the Yocto Project classes, see the
+                "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes'>Classes</ulink>" chapter of the
+                Yocto Project Reference Manual.
+                Class files end with the <filename>.bbclass</filename> filename extension.
+                </para></listitem>
+            <listitem><para><emphasis>Configuration File:</emphasis>
+                Configuration information in various <filename>.conf</filename>
+                files provides global definitions of variables.
+                The <filename>conf/local.conf</filename> configuration file in
+                the
+                <link linkend='build-directory'>Build Directory</link>
+                contains user-defined variables that affect every build.
+                The <filename>meta-yocto/conf/distro/poky.conf</filename>
+                configuration file defines Yocto "distro" configuration
+                variables used only when building with this policy.
+                Machine configuration files, which
+                are located throughout the
+                <link linkend='source-directory'>Source Directory</link>, define
+                variables for specific hardware and are only used when building
+                for that target (e.g. the
+                <filename>machine/beaglebone.conf</filename> configuration
+                file defines variables for the Texas Instruments ARM Cortex-A8
+                development board).
+                Configuration files end with a <filename>.conf</filename>
+                filename extension.
+                </para></listitem>
+            <listitem><para id='cross-development-toolchain'>
+                <emphasis>Cross-Development Toolchain:</emphasis>
+                    In general, a cross-development toolchain is a collection of
+                    software development tools and utilities that run on one
+                    architecture and allow you to develop software for a
+                    different, or targeted, architecture.
+                    These toolchains contain cross-compilers, linkers, and
+                    debuggers that are specific to the target architecture.
+                </para>
+
+                <para>The Yocto Project supports two different cross-development
+                    toolchains:
+                    <itemizedlist>
+                        <listitem><para>A toolchain only used by and within
+                            BitBake when building an image for a target
+                            architecture.</para></listitem>
+                        <listitem><para>A relocatable toolchain used outside of
+                            BitBake by developers when developing applications
+                            that will run on a targeted device.
+                            Sometimes this relocatable cross-development
+                            toolchain is referred to as the meta-toolchain.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    Creation of these toolchains is simple and automated.
+                    For information on toolchain concepts as they apply to the
+                    Yocto Project, see the
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#cross-development-toolchain-generation'>Cross-Development Toolchain Generation</ulink>"
+                    section in the Yocto Project Reference Manual.
+                    You can also find more information on using the
+                    relocatable toolchain in the
+                    <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project
+                    Application Developer's Guide</ulink>.
+                </para></listitem>
+            <listitem><para><emphasis>Image:</emphasis>
+                An image is an artifact of the BitBake build process given
+                a collection of recipes and related Metadata.
+                Images are the binary output that run on specific hardware or
+                QEMU and are used for specific use-cases.
+                For a list of the supported image types that the Yocto Project provides, see the
+                "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>"
+                chapter in the Yocto Project Reference Manual.</para></listitem>
+            <listitem><para id='layer'><emphasis>Layer:</emphasis> A collection of recipes representing the core,
+                a BSP, or an application stack.
+                For a discussion specifically on BSP Layers, see the
+                "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
+                section in the Yocto Project Board Support Packages (BSP)
+                Developer's Guide.</para></listitem>
+            <listitem><para id='meta-toolchain'><emphasis>Meta-Toolchain:</emphasis>
+                A term sometimes used for
+                <link linkend='cross-development-toolchain'>Cross-Development Toolchain</link>.
+                </para></listitem>
+            <listitem><para id='metadata'><emphasis>Metadata:</emphasis>
+                The files that BitBake parses when building an image.
+                In general, Metadata includes recipes, classes, and
+                configuration files.
+                In the context of the kernel ("kernel Metadata"),
+                it refers to Metadata in the <filename>meta</filename>
+                branches of the kernel source Git repositories.
+                </para></listitem>
+            <listitem><para id='oe-core'><emphasis>OE-Core:</emphasis> A core set of Metadata originating
+                with OpenEmbedded (OE) that is shared between OE and the Yocto Project.
+                This Metadata is found in the <filename>meta</filename> directory of the
+                <link linkend='source-directory'>Source Directory</link>.</para></listitem>
+            <listitem><para><emphasis>Package:</emphasis>
+                In the context of the Yocto Project, this term refers to a
+                recipe's packaged output produced by BitBake (i.e. a
+                "baked recipe").
+                A package is generally the compiled binaries produced from the
+                recipe's sources.
+                You "bake" something by running it through BitBake.</para>
+                <para>It is worth noting that the term "package" can, in general, have subtle
+                meanings.  For example, the packages referred to in the
+                "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" section are
+                compiled binaries that, when installed, add functionality to your Linux
+                distribution.</para>
+                <para>Another point worth noting is that historically within the Yocto Project,
+                recipes were referred to as packages - thus, the existence of several BitBake
+                variables that are seemingly mis-named,
+                (e.g. <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>,
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>, and
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PE'><filename>PE</filename></ulink>).
+                </para></listitem>
+            <listitem><para><emphasis>Package Groups:</emphasis>
+                Arbitrary groups of software Recipes.
+                You use package groups to hold recipes that, when built,
+                usually accomplish a single task.
+                For example, a package group could contain the recipes for a
+                company’s proprietary or value-add software.
+                Or, the package group could contain the recipes that enable
+                graphics.
+                A package group is really just another recipe.
+                Because package group files are recipes, they end with the
+                <filename>.bb</filename> filename extension.</para></listitem>
+            <listitem><para id='poky'><emphasis>Poky:</emphasis> The term "poky" can mean several things.
+                In its most general sense, it is an open-source project that was initially developed
+                by OpenedHand.  With OpenedHand, poky was developed off of the existing OpenEmbedded
+                build system becoming a build system for embedded images.
+                After Intel Corporation acquired OpenedHand, the project poky became the basis for
+                the Yocto Project's build system.</para>
+                <para>
+                Within the Yocto Project source repositories, <filename>poky</filename>
+                exists as a separate Git repository
+                that can be cloned to yield a local copy on the host system.
+                Thus, "poky" can refer to the local copy of the Source Directory used to develop within
+                the Yocto Project.</para></listitem>
+            <listitem><para><emphasis>Recipe:</emphasis>
+                A set of instructions for building packages.
+                A recipe describes where you get source code, which patches
+                to apply, how to configure the source, how to compile it and so on.
+                Recipes also describe dependencies for libraries or for other
+                recipes.
+                Recipes represent the logical unit of execution, the software
+                to build, the images to build, and use the
+                <filename>.bb</filename> file extension.
+                </para></listitem>
+            <listitem>
+                <para id='source-directory'><emphasis>Source Directory:</emphasis>
+                This term refers to the directory structure created as a result
+                of creating a local copy of the <filename>poky</filename> Git
+                repository <filename>git://git.yoctoproject.org/poky</filename>
+                or expanding a released <filename>poky</filename> tarball.
+                <note>
+                    Creating a local copy of the <filename>poky</filename>
+                    Git repository is the recommended method for setting up
+                    your Source Directory.
+                </note>
+                Sometimes you might hear the term "poky directory" used to refer
+                to this directory structure.
+                <note>
+                    The OpenEmbedded build system does not support file or
+                    directory names that contain spaces.
+                    Be sure that the Source Directory you use does not contain
+                    these types of names.
+                </note></para>
+
+                <para>The Source Directory contains BitBake, Documentation,
+                Metadata and other files that all support the Yocto Project.
+                Consequently, you must have the Source Directory in place on
+                your development system in order to do any development using
+                the Yocto Project.</para>
+
+                <para>When you create a local copy of the Git repository, you
+                can name the repository anything you like.
+                Throughout much of the documentation, "poky"
+                is used as the name of the top-level folder of the local copy of
+                the poky Git repository.
+                So, for example, cloning the <filename>poky</filename> Git
+                repository results in a local Git repository whose top-level
+                folder is also named "poky".</para>
+
+                <para>While it is not recommended that you use tarball expansion
+                to set up the Source Directory, if you do, the top-level
+                directory name of the Source Directory is derived from the
+                Yocto Project release tarball.
+                For example, downloading and unpacking
+                <filename>&YOCTO_POKY_TARBALL;</filename> results in a
+                Source Directory whose root folder is named
+                <filename>&YOCTO_POKY;</filename>.</para>
+
+                <para>It is important to understand the differences between the
+                Source Directory created by unpacking a released tarball as
+                compared to cloning
+                <filename>git://git.yoctoproject.org/poky</filename>.
+                When you unpack a tarball, you have an exact copy of the files
+                based on the time of release - a fixed release point.
+                Any changes you make to your local files in the Source Directory
+                are on top of the release and will remain local only.
+                On the other hand, when you clone the <filename>poky</filename>
+                Git repository, you have an active development repository with
+                access to the upstream repository's branches and tags.
+                In this case, any local changes you make to the local
+                Source Directory can be later applied to active development
+                branches of the upstream <filename>poky</filename> Git
+                repository.</para>
+
+                <para>For more information on concepts related to Git
+                repositories, branches, and tags, see the
+                "<link linkend='repositories-tags-and-branches'>Repositories, Tags, and Branches</link>"
+                section.</para></listitem>
+            <listitem><para><emphasis>Task:</emphasis>
+                A unit of execution for BitBake (e.g.
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-compile'><filename>do_compile</filename></ulink>,
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-fetch'><filename>do_fetch</filename></ulink>,
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-patch'><filename>do_patch</filename></ulink>,
+                and so forth).
+                </para></listitem>
+            <listitem><para><emphasis>Upstream:</emphasis> A reference to source code or repositories
+                that are not local to the development system but located in a master area that is controlled
+                by the maintainer of the source code.
+                For example, in order for a developer to work on a particular piece of code, they need to
+                first get a copy of it from an "upstream" source.</para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='licensing'>
+    <title>Licensing</title>
+
+    <para>
+        Because open source projects are open to the public, they have different licensing structures in place.
+        License evolution for both Open Source and Free Software has an interesting history.
+        If you are interested in this history, you can find basic information here:
+    <itemizedlist>
+        <listitem><para><ulink url='http://en.wikipedia.org/wiki/Open-source_license'>Open source license history</ulink>
+            </para></listitem>
+        <listitem><para><ulink url='http://en.wikipedia.org/wiki/Free_software_license'>Free software license
+            history</ulink></para></listitem>
+    </itemizedlist>
+    </para>
+
+    <para>
+        In general, the Yocto Project is broadly licensed under the Massachusetts Institute of Technology
+        (MIT) License.
+        MIT licensing permits the reuse of software within proprietary software as long as the
+        license is distributed with that software.
+        MIT is also compatible with the GNU General Public License (GPL).
+        Patches to the Yocto Project follow the upstream licensing scheme.
+        You can find information on the MIT license
+        <ulink url='http://www.opensource.org/licenses/mit-license.php'>here</ulink>.
+        You can find information on the GNU GPL <ulink url='http://www.opensource.org/licenses/LGPL-3.0'>
+        here</ulink>.
+    </para>
+
+    <para>
+        When you build an image using the Yocto Project, the build process uses a
+        known list of licenses to ensure compliance.
+        You can find this list in the
+        <link linkend='source-directory'>Source Directory</link> at
+        <filename>meta/files/common-licenses</filename>.
+        Once the build completes, the list of all licenses found and used during that build are
+        kept in the
+        <link linkend='build-directory'>Build Directory</link> at
+        <filename>tmp/deploy/licenses</filename>.
+    </para>
+
+    <para>
+        If a module requires a license that is not in the base list, the build process
+        generates a warning during the build.
+        These tools make it easier for a developer to be certain of the licenses with which
+        their shipped products must comply.
+        However, even with these tools it is still up to the developer to resolve potential licensing issues.
+    </para>
+
+    <para>
+        The base list of licenses used by the build process is a combination of the Software Package
+        Data Exchange (SPDX) list and the Open Source Initiative (OSI) projects.
+        <ulink url='http://spdx.org'>SPDX Group</ulink> is a working group of the Linux Foundation
+        that maintains a specification
+        for a standard format for communicating the components, licenses, and copyrights
+        associated with a software package.
+        <ulink url='http://opensource.org'>OSI</ulink> is a corporation dedicated to the Open Source
+        Definition and the effort for reviewing and approving licenses that
+        conform to the Open Source Definition (OSD).
+    </para>
+
+    <para>
+        You can find a list of the combined SPDX and OSI licenses that the
+        Yocto Project uses in the
+        <filename>meta/files/common-licenses</filename> directory in your
+        <link linkend='source-directory'>Source Directory</link>.
+    </para>
+
+    <para>
+        For information that can help you maintain compliance with various
+        open source licensing during the lifecycle of a product created using
+        the Yocto Project, see the
+        "<link linkend='maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</link>"
+        section.
+    </para>
+</section>
+
+<section id='git'>
+    <title>Git</title>
+
+    <para>
+        The Yocto Project makes extensive use of Git,
+        which is a free, open source distributed version control system.
+        Git supports distributed development, non-linear development, and can handle large projects.
+        It is best that you have some fundamental understanding of how Git tracks projects and
+        how to work with Git if you are going to use the Yocto Project for development.
+        This section provides a quick overview of how Git works and provides you with a summary
+        of some essential Git commands.
+    </para>
+
+    <para>
+        For more information on Git, see
+        <ulink url='http://git-scm.com/documentation'></ulink>.
+        If you need to download Git, go to <ulink url='http://git-scm.com/download'></ulink>.
+    </para>
+
+    <section id='repositories-tags-and-branches'>
+        <title>Repositories, Tags, and Branches</title>
+
+        <para>
+            As mentioned earlier in the section
+            "<link linkend='yocto-project-repositories'>Yocto Project Source Repositories</link>",
+            the Yocto Project maintains source repositories at
+            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.
+            If you look at this web-interface of the repositories, each item is a separate
+            Git repository.
+        </para>
+
+        <para>
+            Git repositories use branching techniques that track content change (not files)
+            within a project (e.g. a new feature or updated documentation).
+            Creating a tree-like structure based on project divergence allows for excellent historical
+            information over the life of a project.
+            This methodology also allows for an environment from which you can do lots of
+            local experimentation on projects as you develop changes or new features.
+        </para>
+
+        <para>
+            A Git repository represents all development efforts for a given project.
+            For example, the Git repository <filename>poky</filename> contains all changes
+            and developments for Poky over the course of its entire life.
+            That means that all changes that make up all releases are captured.
+            The repository maintains a complete history of changes.
+        </para>
+
+        <para>
+            You can create a local copy of any repository by "cloning" it with the Git
+            <filename>clone</filename> command.
+            When you clone a Git repository, you end up with an identical copy of the
+            repository on your development system.
+            Once you have a local copy of a repository, you can take steps to develop locally.
+            For examples on how to clone Git repositories, see the
+            "<link linkend='getting-setup'>Getting Set Up</link>" section.
+        </para>
+
+        <para>
+            It is important to understand that Git tracks content change and
+            not files.
+            Git uses "branches" to organize different development efforts.
+            For example, the <filename>poky</filename> repository has
+            <filename>denzil</filename>, <filename>danny</filename>,
+            <filename>dylan</filename>, <filename>dora</filename>,
+            <filename>daisy</filename>, and <filename>master</filename> branches
+            among others.
+            You can see all the branches by going to
+            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/'></ulink> and
+            clicking on the
+            <filename><ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/refs/heads'>[...]</ulink></filename>
+            link beneath the "Branch" heading.
+        </para>
+
+        <para>
+            Each of these branches represents a specific area of development.
+            The <filename>master</filename> branch represents the current or most recent
+            development.
+            All other branches represent offshoots of the <filename>master</filename>
+            branch.
+        </para>
+
+        <para>
+            When you create a local copy of a Git repository, the copy has the same set
+            of branches as the original.
+            This means you can use Git to create a local working area (also called a branch)
+            that tracks a specific development branch from the source Git repository.
+            in other words, you can define your local Git environment to work on any development
+            branch in the repository.
+            To help illustrate, here is a set of commands that creates a local copy of the
+            <filename>poky</filename> Git repository and then creates and checks out a local
+            Git branch that tracks the Yocto Project &DISTRO; Release (&DISTRO_NAME;) development:
+            <literallayout class='monospaced'>
+     $ cd ~
+     $ git clone git://git.yoctoproject.org/poky
+     $ cd poky
+     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+            </literallayout>
+            In this example, the name of the top-level directory of your local
+            <link linkend='source-directory'>Source Directory</link>
+            is "poky" and the name of that local working area (local branch)
+            you just created and checked out is "&DISTRO_NAME;".
+            The files in your local repository now reflect the same files that
+            are in the "&DISTRO_NAME;" development branch of the
+            Yocto Project's "poky" upstream repository.
+            It is important to understand that when you create and checkout a
+            local working branch based on a branch name,
+            your local environment matches the "tip" of that development branch
+            at the time you created your local branch, which could be
+            different from the files at the time of a similarly named release.
+            In other words, creating and checking out a local branch based on
+            the "&DISTRO_NAME;" branch name is not the same as
+            cloning and checking out the "master" branch.
+            Keep reading to see how you create a local snapshot of a Yocto
+            Project Release.
+        </para>
+
+        <para>
+            Git uses "tags" to mark specific changes in a repository.
+            Typically, a tag is used to mark a special point such as the final
+            change before a project is released.
+            You can see the tags used with the <filename>poky</filename> Git
+            repository by going to
+            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/'></ulink> and
+            clicking on the
+            <filename><ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/refs/tags'>[...]</ulink></filename>
+            link beneath the "Tag" heading.
+        </para>
+
+        <para>
+            Some key tags are <filename>dylan-9.0.0</filename>,
+            <filename>dora-10.0.0</filename>, <filename>daisy-11.0.0</filename>,
+            and <filename>&DISTRO_NAME;-&POKYVERSION;</filename>.
+            These tags represent Yocto Project releases.
+        </para>
+
+        <para>
+            When you create a local copy of the Git repository, you also have access to all the
+            tags.
+            Similar to branches, you can create and checkout a local working Git branch based
+            on a tag name.
+            When you do this, you get a snapshot of the Git repository that reflects
+            the state of the files when the change was made associated with that tag.
+            The most common use is to checkout a working branch that matches a specific
+            Yocto Project release.
+            Here is an example:
+            <literallayout class='monospaced'>
+     $ cd ~
+     $ git clone git://git.yoctoproject.org/poky
+     $ cd poky
+     $ git checkout -b my-&DISTRO_NAME;-&POKYVERSION; &DISTRO_NAME;-&POKYVERSION;
+            </literallayout>
+            In this example, the name of the top-level directory of your local Yocto Project
+            Files Git repository is <filename>poky</filename>.
+            And, the name of the local branch you have created and checked out is
+            <filename>my-&DISTRO_NAME;-&POKYVERSION;</filename>.
+            The files in your repository now exactly match the Yocto Project &DISTRO;
+            Release tag (<filename>&DISTRO_NAME;-&POKYVERSION;</filename>).
+            It is important to understand that when you create and checkout a local
+            working branch based on a tag, your environment matches a specific point
+            in time and not the entire development branch.
+        </para>
+    </section>
+
+    <section id='basic-commands'>
+        <title>Basic Commands</title>
+
+        <para>
+            Git has an extensive set of commands that lets you manage changes and perform
+            collaboration over the life of a project.
+            Conveniently though, you can manage with a small set of basic operations and workflows
+            once you understand the basic philosophy behind Git.
+            You do not have to be an expert in Git to be functional.
+            A good place to look for instruction on a minimal set of Git commands is
+            <ulink url='http://git-scm.com/documentation'>here</ulink>.
+            If you need to download Git, you can do so
+            <ulink url='http://git-scm.com/download'>here</ulink>.
+        </para>
+
+        <para>
+            If you do not know much about Git, you should educate
+            yourself by visiting the links previously mentioned.
+        </para>
+
+        <para>
+            The following list briefly describes some basic Git operations as a way to get started.
+            As with any set of commands, this list (in most cases) simply shows the base command and
+            omits the many arguments they support.
+            See the Git documentation for complete descriptions and strategies on how to use these commands:
+            <itemizedlist>
+                <listitem><para><emphasis><filename>git init</filename>:</emphasis> Initializes an empty Git repository.
+                    You cannot use Git commands unless you have a <filename>.git</filename> repository.</para></listitem>
+                <listitem><para><emphasis><filename>git clone</filename>:</emphasis>
+                    Creates a local clone of a Git repository.
+                    During collaboration, this command allows you to create a
+                    local Git repository that is on equal footing with a fellow
+                    developer’s Git repository.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>git add</filename>:</emphasis> Stages updated file contents
+                    to the index that
+                    Git uses to track changes.
+                    You must stage all files that have changed before you can commit them.</para></listitem>
+                <listitem><para><emphasis><filename>git commit</filename>:</emphasis> Creates a "commit" that documents
+                    the changes you made.
+                    Commits are used for historical purposes, for determining if a maintainer of a project
+                    will allow the change, and for ultimately pushing the change from your local Git repository
+                    into the project’s upstream (or master) repository.</para></listitem>
+                <listitem><para><emphasis><filename>git status</filename>:</emphasis> Reports any modified files that
+                    possibly need to be staged and committed.</para></listitem>
+                <listitem><para><emphasis><filename>git checkout &lt;branch-name&gt;</filename>:</emphasis> Changes
+                    your working branch.
+                    This command is analogous to "cd".</para></listitem>
+                <listitem><para><emphasis><filename>git checkout –b &lt;working-branch&gt;</filename>:</emphasis> Creates
+                    a working branch on your local machine where you can isolate work.
+                    It is a good idea to use local branches when adding specific features or changes.
+                    This way if you do not like what you have done you can easily get rid of the work.</para></listitem>
+                <listitem><para><emphasis><filename>git branch</filename>:</emphasis> Reports
+                    existing local branches and
+                    tells you the branch in which you are currently working.</para></listitem>
+                <listitem><para><emphasis><filename>git branch -D &lt;branch-name&gt;</filename>:</emphasis>
+                    Deletes an existing local branch.
+                    You need to be in a local branch other than the one you are deleting
+                    in order to delete <filename>&lt;branch-name&gt;</filename>.</para></listitem>
+                <listitem><para><emphasis><filename>git pull</filename>:</emphasis> Retrieves information
+                    from an upstream Git
+                    repository and places it in your local Git repository.
+                    You use this command to make sure you are synchronized with the repository
+                    from which you are basing changes (.e.g. the master branch).</para></listitem>
+                <listitem><para><emphasis><filename>git push</filename>:</emphasis>
+                    Sends all your committed local changes to an upstream Git
+                    repository (e.g. a contribution repository).
+                    The maintainer of the project draws from these repositories
+                    when adding changes to the project’s master repository or
+                    other development branch.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>git merge</filename>:</emphasis> Combines or adds changes from one
+                    local branch of your repository with another branch.
+                    When you create a local Git repository, the default branch is named "master".
+                    A typical workflow is to create a temporary branch for isolated work, make and commit your
+                    changes, switch to your local master branch, merge the changes from the temporary branch into the
+                    local master branch, and then delete the temporary branch.</para></listitem>
+                <listitem><para><emphasis><filename>git cherry-pick</filename>:</emphasis> Choose and apply specific
+                    commits from one branch into another branch.
+                    There are times when you might not be able to merge all the changes in one branch with
+                    another but need to pick out certain ones.</para></listitem>
+                <listitem><para><emphasis><filename>gitk</filename>:</emphasis> Provides a GUI view of the branches
+                    and changes in your local Git repository.
+                    This command is a good way to graphically see where things have diverged in your
+                    local repository.</para></listitem>
+                <listitem><para><emphasis><filename>git log</filename>:</emphasis> Reports a history of your changes to the
+                    repository.</para></listitem>
+                <listitem><para><emphasis><filename>git diff</filename>:</emphasis> Displays line-by-line differences
+                    between your local working files and the same files in the upstream Git repository that your
+                    branch currently tracks.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
+
+<section id='workflows'>
+    <title>Workflows</title>
+
+    <para>
+        This section provides some overview on workflows using Git.
+        In particular, the information covers basic practices that describe roles and actions in a
+        collaborative development environment.
+        Again, if you are familiar with this type of development environment, you might want to just
+        skip this section.
+    </para>
+
+    <para>
+        The Yocto Project files are maintained using Git in a "master" branch whose Git history
+        tracks every change and whose structure provides branches for all diverging functionality.
+        Although there is no need to use Git, many open source projects do so.
+        For the Yocto Project, a key individual called the "maintainer" is responsible for the "master"
+        branch of a given Git repository.
+        The "master" branch is the “upstream” repository where the final builds of the project occur.
+        The maintainer is responsible for accepting changes from other developers and for
+        organizing the underlying branch structure to reflect release strategies and so forth.
+        <note>For information on finding out who is responsible for (maintains)
+            a particular area of code, see the
+            "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
+            section.
+        </note>
+    </para>
+
+    <para>
+        The project also has an upstream contribution Git repository named
+        <filename>poky-contrib</filename>.
+        You can see all the branches in this repository using the web interface
+        of the
+        <ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink> organized
+        within the "Poky Support" area.
+        These branches temporarily hold changes to the project that have been
+        submitted or committed by the Yocto Project development team and by
+        community members who contribute to the project.
+        The maintainer determines if the changes are qualified to be moved
+        from the "contrib" branches into the "master" branch of the Git
+        repository.
+    </para>
+
+    <para>
+        Developers (including contributing community members) create and maintain cloned repositories
+        of the upstream "master" branch.
+        These repositories are local to their development platforms and are used to develop changes.
+        When a developer is satisfied with a particular feature or change, they "push" the changes
+        to the appropriate "contrib" repository.
+    </para>
+
+    <para>
+        Developers are responsible for keeping their local repository up-to-date with "master".
+        They are also responsible for straightening out any conflicts that might arise within files
+        that are being worked on simultaneously by more than one person.
+        All this work is done locally on the developer’s machines before anything is pushed to a
+        "contrib" area and examined at the maintainer’s level.
+    </para>
+
+    <para>
+        A somewhat formal method exists by which developers commit changes and push them into the
+        "contrib" area and subsequently request that the maintainer include them into "master"
+        This process is called “submitting a patch” or "submitting a change."
+        For information on submitting patches and changes, see the
+        "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>" section.
+    </para>
+
+    <para>
+        To summarize the environment:  a single point of entry exists for
+        changes into the project’s "master" branch of the Git repository,
+        which is controlled by the project’s maintainer.
+        And, a set of developers exist who independently develop, test, and
+        submit changes to "contrib" areas for the maintainer to examine.
+        The maintainer then chooses which changes are going to become a
+        permanent part of the project.
+    </para>
+
+    <para>
+        <imagedata fileref="figures/git-workflow.png" width="6in" depth="3in" align="left" scalefit="1" />
+    </para>
+
+    <para>
+        While each development environment is unique, there are some best practices or methods
+        that help development run smoothly.
+        The following list describes some of these practices.
+        For more information about Git workflows, see the workflow topics in the
+        <ulink url='http://book.git-scm.com'>Git Community Book</ulink>.
+        <itemizedlist>
+            <listitem><para><emphasis>Make Small Changes:</emphasis> It is best to keep the changes you commit
+                small as compared to bundling many disparate changes into a single commit.
+                This practice not only keeps things manageable but also allows the maintainer
+                to more easily include or refuse changes.</para>
+                <para>It is also good practice to leave the repository in a state that allows you to
+                still successfully build your project.  In other words, do not commit half of a feature,
+                then add the other half as a separate, later commit.
+                Each commit should take you from one buildable project state to another
+                buildable state.</para></listitem>
+            <listitem><para><emphasis>Use Branches Liberally:</emphasis> It is very easy to create, use, and
+                delete local branches in your working Git repository.
+                You can name these branches anything you like.
+                It is helpful to give them names associated with the particular feature or change
+                on which you are working.
+                Once you are done with a feature or change and have merged it
+                into your local master branch, simply discard the temporary
+                branch.</para></listitem>
+            <listitem><para><emphasis>Merge Changes:</emphasis> The <filename>git merge</filename>
+                command allows you to take the
+                changes from one branch and fold them into another branch.
+                This process is especially helpful when more than a single developer might be working
+                on different parts of the same feature.
+                Merging changes also automatically identifies any collisions or "conflicts"
+                that might happen as a result of the same lines of code being altered by two different
+                developers.</para></listitem>
+            <listitem><para><emphasis>Manage Branches:</emphasis> Because branches are easy to use, you should
+                use a system where branches indicate varying levels of code readiness.
+                For example, you can have a "work" branch to develop in, a "test" branch where the code or
+                change is tested, a "stage" branch where changes are ready to be committed, and so forth.
+                As your project develops, you can merge code across the branches to reflect ever-increasing
+                stable states of the development.</para></listitem>
+            <listitem><para><emphasis>Use Push and Pull:</emphasis> The push-pull workflow is based on the
+                concept of developers "pushing" local commits to a remote repository, which is
+                usually a contribution repository.
+                This workflow is also based on developers "pulling" known states of the project down into their
+                local development repositories.
+                The workflow easily allows you to pull changes submitted by other developers from the
+                upstream repository into your work area ensuring that you have the most recent software
+                on which to develop.
+                The Yocto Project has two scripts named <filename>create-pull-request</filename> and
+                <filename>send-pull-request</filename> that ship with the release to facilitate this
+                workflow.
+                You can find these scripts in the <filename>scripts</filename>
+                folder of the
+                <link linkend='source-directory'>Source Directory</link>.
+                For information on how to use these scripts, see the
+                "<link linkend='pushing-a-change-upstream'>Using Scripts to Push a Change Upstream and Request a Pull</link>" section.
+                </para></listitem>
+            <listitem><para><emphasis>Patch Workflow:</emphasis> This workflow allows you to notify the
+                maintainer through an email that you have a change (or patch) you would like considered
+                for the "master" branch of the Git repository.
+                To send this type of change, you format the patch and then send the email using the Git commands
+                <filename>git format-patch</filename> and <filename>git send-email</filename>.
+                For information on how to use these scripts, see the
+                "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
+                section.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='tracking-bugs'>
+    <title>Tracking Bugs</title>
+
+    <para>
+        The Yocto Project uses its own implementation of
+        <ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink> to track bugs.
+        Implementations of Bugzilla work well for group development because they track bugs and code
+        changes, can be used to communicate changes and problems with developers, can be used to
+        submit and review patches, and can be used to manage quality assurance.
+        The home page for the Yocto Project implementation of Bugzilla is
+        <ulink url='&YOCTO_BUGZILLA_URL;'>&YOCTO_BUGZILLA_URL;</ulink>.
+    </para>
+
+    <para>
+        Sometimes it is helpful to submit, investigate, or track a bug against the Yocto Project itself
+        such as when discovering an issue with some component of the build system that acts contrary
+        to the documentation or your expectations.
+        Following is the general procedure for submitting a new bug using the Yocto Project
+        Bugzilla.
+        You can find more information on defect management, bug tracking, and feature request
+        processes all accomplished through the Yocto Project Bugzilla on the wiki page
+        <ulink url='&YOCTO_WIKI_URL;/wiki/Bugzilla_Configuration_and_Bug_Tracking'>here</ulink>.
+        <orderedlist>
+            <listitem><para>Always use the Yocto Project implementation of Bugzilla to submit
+                a bug.</para></listitem>
+            <listitem><para>When submitting a new bug, be sure to choose the appropriate
+                Classification, Product, and Component for which the issue was found.
+                Defects for the Yocto Project fall into one of seven classifications:
+                Yocto Project Components, Infrastructure, Build System &amp; Metadata,
+                Documentation, QA/Testing, Runtime and Hardware.
+                Each of these Classifications break down into multiple Products and, in some
+                cases, multiple Components.</para></listitem>
+            <listitem><para>Use the bug form to choose the correct Hardware and Architecture
+                for which the bug applies.</para></listitem>
+            <listitem><para>Indicate the Yocto Project version you were using when the issue
+                occurred.</para></listitem>
+            <listitem><para>Be sure to indicate the Severity of the bug.
+                Severity communicates how the bug impacted your work.</para></listitem>
+            <listitem><para>Select the appropriate "Documentation change" item
+                for the bug.
+                Fixing a bug may or may not affect the Yocto Project
+                documentation.</para></listitem>
+            <listitem><para>Provide a brief summary of the issue.
+                Try to limit your summary to just a line or two and be sure to capture the
+                essence of the issue.</para></listitem>
+            <listitem><para>Provide a detailed description of the issue.
+                You should provide as much detail as you can about the context, behavior, output,
+                and so forth that surrounds the issue.
+                You can even attach supporting files for output from logs by
+                using the "Add an attachment" button.</para></listitem>
+            <listitem><para>Be sure to copy the appropriate people in the
+                "CC List" for the bug.
+                See the "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
+                section for information about finding out who is responsible
+                for code.</para></listitem>
+            <listitem><para>Submit the bug by clicking the "Submit Bug" button.</para></listitem>
+        </orderedlist>
+    </para>
+</section>
+
+<section id='how-to-submit-a-change'>
+    <title>How to Submit a Change</title>
+
+    <para>
+        Contributions to the Yocto Project and OpenEmbedded are very welcome.
+        Because the system is extremely configurable and flexible, we recognize that developers
+        will want to extend, configure or optimize it for their specific uses.
+        You should send patches to the appropriate mailing list so that they
+        can be reviewed and merged by the appropriate maintainer.
+    </para>
+
+    <para>
+        Before submitting any change, be sure to find out who you should be
+        notifying.
+        Several methods exist through which you find out who you should be copying
+        or notifying:
+        <itemizedlist>
+            <listitem><para><emphasis>Maintenance File:</emphasis>
+                Examine the <filename>maintainers.inc</filename> file, which is
+                located in the
+                <link linkend='source-directory'>Source Directory</link>
+                at <filename>meta-yocto/conf/distro/include</filename>, to
+                see who is responsible for code.
+                </para></listitem>
+            <listitem><para><emphasis>Board Support Package (BSP) README Files:</emphasis>
+                For BSP maintainers of supported BSPs, you can examine
+                individual BSP <filename>README</filename> files.
+                In addition, some layers (such as the <filename>meta-intel</filename> layer),
+                include a <filename>MAINTAINERS</filename> file which contains
+                a list of all supported BSP maintainers for that layer.
+                </para></listitem>
+            <listitem><para><emphasis>Search by File:</emphasis>
+                Using <link linkend='git'>Git</link>, you can enter the
+                following command to bring up a short list of all commits
+                against a specific file:
+                <literallayout class='monospaced'>
+     git shortlog -- <replaceable>filename</replaceable>
+                </literallayout>
+                Just provide the name of the file for which you are interested.
+                The information returned is not ordered by history but does
+                include a list of all committers grouped by name.
+                From the list, you can see who is responsible for the bulk of
+                the changes against the file.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        For a list of the Yocto Project and related mailing lists, see the
+        "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing lists</ulink>" section in
+        the Yocto Project Reference Manual.
+    </para>
+
+    <para>
+        Here is some guidance on which mailing list to use for what type of change:
+        <itemizedlist>
+            <listitem><para>For changes to the core
+                <link linkend='metadata'>Metadata</link>, send your patch to the
+                <ulink url='&OE_LISTS_URL;/listinfo/openembedded-core'>openembedded-core</ulink> mailing list.
+                For example, a change to anything under the <filename>meta</filename> or
+                <filename>scripts</filename> directories
+                should be sent to this mailing list.</para></listitem>
+            <listitem><para>For changes to BitBake (anything under the <filename>bitbake</filename>
+                directory), send your patch to the
+                <ulink url='&OE_LISTS_URL;/listinfo/bitbake-devel'>bitbake-devel</ulink> mailing list.</para></listitem>
+            <listitem><para>For changes to <filename>meta-yocto</filename>, send your patch to the
+                <ulink url='&YOCTO_LISTS_URL;/listinfo/poky'>poky</ulink> mailing list.</para></listitem>
+            <listitem><para>For changes to other layers hosted on
+                <filename>yoctoproject.org</filename> (unless the
+                layer's documentation specifies otherwise), tools, and Yocto Project
+                documentation, use the
+                <ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'>yocto</ulink> mailing list.</para></listitem>
+            <listitem><para>For additional recipes that do not fit into the core Metadata,
+                you should determine which layer the recipe should go into and submit the
+                change in the manner recommended by the documentation (e.g. README) supplied
+                with the layer. If in doubt, please ask on the
+                <ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'>yocto</ulink> or
+                <ulink url='&OE_LISTS_URL;/listinfo/openembedded-devel'>openembedded-devel</ulink>
+                mailing lists.</para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        When you send a patch, be sure to include a "Signed-off-by:"
+        line in the same style as required by the Linux kernel.
+        Adding this line signifies that you, the submitter, have agreed to the Developer's Certificate of Origin 1.1
+        as follows:
+        <literallayout class='monospaced'>
+     Developer's Certificate of Origin 1.1
+
+     By making a contribution to this project, I certify that:
+
+     (a) The contribution was created in whole or in part by me and I
+         have the right to submit it under the open source license
+         indicated in the file; or
+
+     (b) The contribution is based upon previous work that, to the best
+         of my knowledge, is covered under an appropriate open source
+         license and I have the right under that license to submit that
+         work with modifications, whether created in whole or in part
+         by me, under the same open source license (unless I am
+         permitted to submit under a different license), as indicated
+         in the file; or
+
+     (c) The contribution was provided directly to me by some other
+         person who certified (a), (b) or (c) and I have not modified
+         it.
+
+     (d) I understand and agree that this project and the contribution
+         are public and that a record of the contribution (including all
+         personal information I submit with it, including my sign-off) is
+         maintained indefinitely and may be redistributed consistent with
+         this project or the open source license(s) involved.
+        </literallayout>
+    </para>
+
+    <para>
+        In a collaborative environment, it is necessary to have some sort of standard
+        or method through which you submit changes.
+        Otherwise, things could get quite chaotic.
+        One general practice to follow is to make small, controlled changes.
+        Keeping changes small and isolated aids review, makes merging/rebasing easier
+        and keeps the change history clean when anyone needs to refer to it in future.
+    </para>
+
+    <para>
+        When you make a commit, you must follow certain standards established by the
+        OpenEmbedded and Yocto Project development teams.
+        For each commit, you must provide a single-line summary of the change and you
+        should almost always provide a more detailed description of what you did (i.e.
+        the body of the commit message).
+        The only exceptions for not providing a detailed description would be if your
+        change is a simple, self-explanatory change that needs no further description
+        beyond the summary.
+        Here are the guidelines for composing a commit message:
+        <itemizedlist>
+            <listitem><para>Provide a single-line, short summary of the change.
+                This summary is typically viewable in the "shortlist" of changes.
+                Thus, providing something short and descriptive that gives the reader
+                a summary of the change is useful when viewing a list of many commits.
+                This short description should be prefixed by the recipe name (if changing a recipe), or
+                else the short form path to the file being changed.
+                </para></listitem>
+            <listitem><para>For the body of the commit message, provide detailed information
+                that describes what you changed, why you made the change, and the approach
+                you used. It may also be helpful if you mention how you tested the change.
+                Provide as much detail as you can in the body of the commit message.
+                </para></listitem>
+            <listitem><para>
+                If the change addresses a specific bug or issue that is
+                associated with a bug-tracking ID, include a reference to that
+                ID in your detailed description.
+                For example, the Yocto Project uses a specific convention for
+                bug references - any commit that addresses a specific bug should
+                use the following form for the detailed description:
+                <literallayout class='monospaced'>
+     Fixes [YOCTO #<replaceable>bug-id</replaceable>]
+
+     <replaceable>detailed description of change</replaceable>
+                </literallayout></para></listitem>
+                Where <replaceable>bug-id</replaceable> is replaced with the
+                specific bug ID from the Yocto Project Bugzilla instance.
+        </itemizedlist>
+    </para>
+
+    <para>
+        You can find more guidance on creating well-formed commit messages at this OpenEmbedded
+        wiki page:
+        <ulink url='&OE_HOME_URL;/wiki/Commit_Patch_Message_Guidelines'></ulink>.
+    </para>
+
+    <para>
+        The next two sections describe general instructions for both pushing
+        changes upstream and for submitting changes as patches.
+    </para>
+
+    <section id='pushing-a-change-upstream'>
+        <title>Using Scripts to Push a Change Upstream and Request a Pull</title>
+
+        <para>
+            The basic flow for pushing a change to an upstream "contrib" Git repository is as follows:
+            <itemizedlist>
+                <listitem><para>Make your changes in your local Git repository.</para></listitem>
+                <listitem><para>Stage your changes by using the <filename>git add</filename>
+                    command on each file you changed.</para></listitem>
+                <listitem><para>
+                    Commit the change by using the
+                    <filename>git commit</filename> command.
+                    Be sure to provide a commit message that follows the
+                    project’s commit message standards as described earlier.
+                    </para></listitem>
+                <listitem><para>
+                    Push the change to the upstream "contrib" repository by
+                    using the <filename>git push</filename> command.
+                    </para></listitem>
+                <listitem><para>Notify the maintainer that you have pushed a change by making a pull
+                    request.
+                    The Yocto Project provides two scripts that conveniently let you generate and send
+                    pull requests to the Yocto Project.
+                    These scripts are <filename>create-pull-request</filename> and
+                    <filename>send-pull-request</filename>.
+                    You can find these scripts in the <filename>scripts</filename> directory
+                    within the <link linkend='source-directory'>Source Directory</link>.</para>
+                    <para>Using these scripts correctly formats the requests without introducing any
+                    whitespace or HTML formatting.
+                    The maintainer that receives your patches needs to be able to save and apply them
+                    directly from your emails.
+                    Using these scripts is the preferred method for sending patches.</para>
+                    <para>For help on using these scripts, simply provide the
+                    <filename>-h</filename> argument as follows:
+                    <literallayout class='monospaced'>
+     $ poky/scripts/create-pull-request -h
+     $ poky/scripts/send-pull-request -h
+                    </literallayout></para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            You can find general Git information on how to push a change upstream in the
+            <ulink url='http://book.git-scm.com/3_distributed_workflows.html'>Git Community Book</ulink>.
+        </para>
+    </section>
+
+    <section id='submitting-a-patch'>
+        <title>Using Email to Submit a Patch</title>
+
+        <para>
+            You can submit patches without using the <filename>create-pull-request</filename> and
+            <filename>send-pull-request</filename> scripts described in the previous section.
+            However, keep in mind, the preferred method is to use the scripts.
+        </para>
+
+        <para>
+            Depending on the components changed, you need to submit the email to a specific
+            mailing list.
+            For some guidance on which mailing list to use, see the list in the
+            "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
+            section.
+            For a description of the available mailing lists, see the
+            "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing Lists</ulink>"
+            section in the Yocto Project Reference Manual.
+        </para>
+
+        <para>
+            Here is the general procedure on how to submit a patch through email without using the
+            scripts:
+            <itemizedlist>
+                <listitem><para>Make your changes in your local Git repository.</para></listitem>
+                <listitem><para>Stage your changes by using the <filename>git add</filename>
+                    command on each file you changed.</para></listitem>
+                <listitem><para>Commit the change by using the
+                    <filename>git commit --signoff</filename> command.
+                    Using the <filename>--signoff</filename> option identifies you as the person
+                    making the change and also satisfies the Developer's Certificate of
+                    Origin (DCO) shown earlier.</para>
+                    <para>When you form a commit, you must follow certain standards established by the
+                    Yocto Project development team.
+                    See the earlier section
+                    "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
+                    for Yocto Project commit message standards.</para></listitem>
+                <listitem><para>Format the commit into an email message.
+                    To format commits, use the <filename>git format-patch</filename> command.
+                    When you provide the command, you must include a revision list or a number of patches
+                    as part of the command.
+                    For example, either of these two commands takes your most
+                    recent single commit and formats it as an email message in
+                    the current directory:
+                    <literallayout class='monospaced'>
+     $ git format-patch -1
+                    </literallayout>
+                    or
+                    <literallayout class='monospaced'>
+     $ git format-patch HEAD~
+                    </literallayout></para>
+                    <para>After the command is run, the current directory contains a
+                    numbered <filename>.patch</filename> file for the commit.</para>
+                    <para>If you provide several commits as part of the command,
+                    the <filename>git format-patch</filename> command produces a
+                    series of numbered files in the current directory – one for each commit.
+                    If you have more than one patch, you should also use the
+                    <filename>--cover</filename> option with the command, which generates a
+                    cover letter as the first "patch" in the series.
+                    You can then edit the cover letter to provide a description for
+                    the series of patches.
+                    For information on the <filename>git format-patch</filename> command,
+                    see <filename>GIT_FORMAT_PATCH(1)</filename> displayed using the
+                    <filename>man git-format-patch</filename> command.</para>
+                    <note>If you are or will be a frequent contributor to the Yocto Project
+                    or to OpenEmbedded, you might consider requesting a contrib area and the
+                    necessary associated rights.</note></listitem>
+                <listitem><para>Import the files into your mail client by using the
+                    <filename>git send-email</filename> command.
+                    <note>In order to use <filename>git send-email</filename>, you must have the
+                    the proper Git packages installed.
+                    For Ubuntu, Debian, and Fedora the package is <filename>git-email</filename>.</note></para>
+                    <para>The <filename>git send-email</filename> command sends email by using a local
+                    or remote Mail Transport Agent (MTA) such as
+                    <filename>msmtp</filename>, <filename>sendmail</filename>, or through a direct
+                    <filename>smtp</filename> configuration in your Git <filename>config</filename>
+                    file.
+                    If you are submitting patches through email only, it is very important
+                    that you submit them without any whitespace or HTML formatting that
+                    either you or your mailer introduces.
+                    The maintainer that receives your patches needs to be able to save and
+                    apply them directly from your emails.
+                    A good way to verify that what you are sending will be applicable by the
+                    maintainer is to do a dry run and send them to yourself and then
+                    save and apply them as the maintainer would.</para>
+                    <para>The <filename>git send-email</filename> command is the preferred method
+                    for sending your patches since there is no risk of compromising whitespace
+                    in the body of the message, which can occur when you use your own mail client.
+                    The command also has several options that let you
+                    specify recipients and perform further editing of the email message.
+                    For information on how to use the <filename>git send-email</filename> command,
+                    see <filename>GIT-SEND-EMAIL(1)</filename> displayed using
+                    the <filename>man git-send-email</filename> command.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/dev-manual/dev-manual-qemu.xml b/documentation/dev-manual/dev-manual-qemu.xml
new file mode 100644
index 0000000000..739fd7104b
--- /dev/null
+++ b/documentation/dev-manual/dev-manual-qemu.xml
@@ -0,0 +1,419 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='dev-manual-qemu'>
+
+<title>Using the Quick EMUlator (QEMU)</title>
+
+<para>
+    Quick EMUlator (QEMU) is an Open Source project the Yocto Project uses
+    as part of its development "tool set".
+    As such, the information in this chapter is limited to the
+    Yocto Project integration of QEMU and not QEMU in general.
+    For official information and documentation on QEMU, see the
+    following references:
+    <itemizedlist>
+        <listitem><para><emphasis><ulink url='http://wiki.qemu.org/Main_Page'>QEMU Website</ulink>:</emphasis>
+            The official website for the QEMU Open Source project.
+            </para></listitem>
+        <listitem><para><emphasis><ulink url='http://wiki.qemu.org/Manual'>Documentation</ulink>:</emphasis>
+            The QEMU user manual.
+            </para></listitem>
+    </itemizedlist>
+</para>
+
+<para>
+    This chapter provides an overview of the Yocto Project's integration of
+    QEMU, a description of how you use QEMU and its various options, running
+    under a Network File System (NFS) server, and a few tips and tricks you
+    might find helpful when using QEMU.
+</para>
+
+<section id='qemu-overview'>
+    <title>Overview</title>
+
+    <para>
+        Within the context of the Yocto Project, QEMU is an
+        emulator and virtualization machine that allows you to run a complete
+        image you have built using the Yocto Project as just another task
+        on your build system.
+        QEMU is useful for running and testing images and applications on
+        supported Yocto Project architectures without having actual hardware.
+        Among other things, the Yocto Project uses QEMU to run automated
+        Quality Assurance (QA) tests on final images shipped with each
+        release.
+    </para>
+
+    <para>
+        QEMU is made available with the Yocto Project a number of ways.
+        The easiest and recommended method for getting QEMU is to run the
+        ADT installer.  For more information on how to make sure you have
+        QEMU available, see the
+        "<ulink url='&YOCTO_DOCS_ADT_URL;#the-qemu-emulator'>The QEMU Emulator</ulink>"
+        section in the Yocto Project Application Developer's Guide.
+    </para>
+</section>
+
+<section id='qemu-running-qemu'>
+    <title>Running QEMU</title>
+
+    <para>
+        Running QEMU involves having your build environment set up, having the
+        right artifacts available, and understanding how to use the many
+        options that are available to you when you start QEMU using the
+        <filename>runqemu</filename> command.
+    </para>
+
+    <section id='qemu-setting-up-the-environment'>
+        <title>Setting Up the Environment</title>
+
+        <para>
+            You run QEMU in the same environment from which you run BitBake.
+            This means you need to source a build environment script (i.e.
+            <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+            or
+            <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>).
+        </para>
+    </section>
+
+    <section id='qemu-using-the-runqemu-command'>
+        <title>Using the <filename>runqemu</filename> Command</title>
+
+        <para>
+            The basic <filename>runqemu</filename> command syntax is as
+            follows:
+            <literallayout class='monospaced'>
+     $ runqemu [<replaceable>option</replaceable> ]  [...]
+            </literallayout>
+            Based on what you provide on the command line,
+            <filename>runqemu</filename> does a good job of figuring out what
+            you are trying to do.
+            For example, by default, QEMU looks for the most recently built
+            image according to the timestamp when it needs to look for an
+            image.
+            Minimally, through the use of options, you must provide either
+            a machine name, a virtual machine image
+            (<filename>*.vmdk</filename>), or a kernel image
+            (<filename>*.bin</filename>).
+        </para>
+
+        <para>
+            Following is a description of <filename>runqemu</filename>
+            options you can provide on the command line:
+            <note><title>Tip</title>
+                If you do provide some "illegal" option combination or perhaps
+                you do not provide enough in the way of options,
+                <filename>runqemu</filename> provides appropriate error
+                messaging to help you correct the problem.
+            </note>
+            <itemizedlist>
+                <listitem><para><replaceable>QEMUARCH</replaceable>:
+                    The QEMU machine architecture, which must be "qemux86",
+                    "qemux86-64", "qemuarm", "qemumips", "qemumipsel",
+                    “qemumips64", "qemush4", "qemuppc", "qemumicroblaze",
+                    or "qemuzynq".
+                    </para></listitem>
+                <listitem><para><filename><replaceable>VM</replaceable></filename>:
+                    The virtual machine image, which must be a
+                    <filename>.vmdk</filename> file.
+                    Use this option when you want to boot a
+                    <filename>.vmdk</filename> image.
+                    The image filename you provide must contain one of the
+                    following strings: "qemux86-64", "qemux86", "qemuarm",
+                    "qemumips64", "qemumips", "qemuppc", or "qemush4".
+                    </para></listitem>
+                <listitem><para><replaceable>ROOTFS</replaceable>:
+                    A root filesystem that has one of the following
+                    filetype extensions: "ext2", "ext3", "ext4", "jffs2",
+                    "nfs", or "btrfs".
+                    If the filename you provide for this option uses “nfs”, it
+                    must provide an explicit root filesystem path.
+                    </para></listitem>
+                <listitem><para><replaceable>KERNEL</replaceable>:
+                    A kernel image, which is a <filename>.bin</filename> file.
+                    When you provide a <filename>.bin</filename> file,
+                    <filename>runqemu</filename> detects it and assumes the
+                    file is a kernel image.
+                    </para></listitem>
+                <listitem><para><replaceable>MACHINE</replaceable>:
+                    The architecture of the QEMU machine, which must be one
+                    of the following: "qemux86",
+                    "qemux86-64", "qemuarm", "qemumips", "qemumipsel",
+                    “qemumips64", "qemush4", "qemuppc", "qemumicroblaze",
+                    or "qemuzynq".
+                    The <replaceable>MACHINE</replaceable> and
+                    <replaceable>QEMUARCH</replaceable> options are basically
+                    identical.
+                    If you do not provide a <replaceable>MACHINE</replaceable>
+                    option, <filename>runqemu</filename> tries to determine
+                    it based on other options.
+                    </para></listitem>
+                <listitem><para><filename>ramfs</filename>:
+                    Indicates you are booting an initial RAM disk (initramfs)
+                    image, which means the <filename>FSTYPE</filename> is
+                    <filename>cpio.gz</filename>.
+                    </para></listitem>
+                <listitem><para><filename>iso</filename>:
+                    Indicates you are booting an ISO image, which means the
+                    <filename>FSTYPE</filename> is
+                    <filename>.iso</filename>.
+                    </para></listitem>
+                <listitem><para><filename>nographic</filename>:
+                    Disables the video console, which sets the console to
+                    "ttys0".
+                    </para></listitem>
+                <listitem><para><filename>serial</filename>:
+                    Enables a serial console on
+                    <filename>/dev/ttyS0</filename>.
+                    </para></listitem>
+                <listitem><para><filename>biosdir</filename>:
+                    Establishes a custom directory for BIOS, VGA BIOS and
+                    keymaps.
+                    </para></listitem>
+                <listitem><para><filename>qemuparams=\"<replaceable>xyz</replaceable>\"</filename>:
+                    Specifies custom QEMU parameters.
+                    Use this option to pass options other than the simple
+                    "kvm" and "serial" options.
+                    </para></listitem>
+                <listitem><para><filename>bootparams=\"<replaceable>xyz</replaceable>\"</filename>:
+                    Specifies custom boot parameters for the kernel.
+                    </para></listitem>
+                <listitem><para><filename>audio</filename>:
+                    Enables audio in QEMU.
+                    The <replaceable>MACHINE</replaceable> option must be
+                    either "qemux86" or "qemux86-64" in order for audio to be
+                    enabled.
+                    Additionally, the <filename>snd_intel8x0</filename>
+                    or <filename>snd_ens1370</filename> driver must be
+                    installed in linux guest.
+                    </para></listitem>
+                <listitem><para><filename>slirp</filename>:
+                    Enables "slirp" networking, which is a different way
+                    of networking that does not need root access
+                    but also is not as easy to use or comprehensive
+                    as the default.
+                    </para></listitem>
+                <listitem><para><filename>kvm</filename>:
+                    Enables KVM when running "qemux86" or "qemux86-64"
+                    QEMU architectures.
+                    For KVM to work, all the following conditions must be met:
+                    <itemizedlist>
+                        <listitem><para>
+                            Your <replaceable>MACHINE</replaceable> must be either
+                            "qemux86" or "qemux86-64".
+                            </para></listitem>
+                        <listitem><para>
+                            Your build host has to have the KVM modules
+                            installed, which are
+                            <filename>/dev/kvm</filename>.
+                            </para></listitem>
+                        <listitem><para>
+                            Your build host has to have virtio net device, which
+                            are <filename>/dev/vhost-net</filename>.
+                            </para></listitem>
+                        <listitem><para>
+                            The  build host <filename>/dev/kvm</filename>
+                            directory has to be both writable and readable.
+                            </para></listitem>
+                        <listitem><para>
+                            The build host <filename>/dev/vhost-net</filename>
+                            directory has to be either readable or writable
+                            and “slirp-enabled”.
+                            </para></listitem>
+                    </itemizedlist>
+                    </para></listitem>
+                <listitem><para><filename>publicvnc</filename>:
+                    Enables a VNC server open to all hosts.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            For further understanding regarding option use with
+            <filename>runqemu</filename>, consider some examples.
+        </para>
+
+        <para>
+            This example starts QEMU with
+            <replaceable>MACHINE</replaceable> set to "qemux86".
+            Assuming a standard
+            <link linkend='build-directory'>Build Directory</link>,
+            <filename>runqemu</filename> automatically finds the
+            <filename>bzImage-qemux86.bin</filename> image file and
+            the
+            <filename>core-image-minimal-qemux86-20140707074611.rootfs.ext3</filename>
+            (assuming the current build created a
+            <filename>core-image-minimal</filename> image).
+            <note>
+                When more than one image with the same name exists, QEMU finds
+                and uses the most recently built image according to the
+                timestamp.
+            </note>
+            <literallayout class='monospaced'>
+    $ runqemu qemux86
+            </literallayout>
+            This example produces the exact same results as the
+            previous example.
+            This command, however, specifically provides the image
+            and root filesystem type.
+            <literallayout class='monospaced'>
+     $ runqemu qemux86 core-image-minimal ext3
+            </literallayout>
+            This example specifies to boot an initial RAM disk image
+            and to enable audio in QEMU.
+            For this case, <filename>runqemu</filename> set the
+            internal variable <filename>FSTYPE</filename> to
+            "cpio.gz".
+            Also, for audio to be enabled, an appropriate driver must
+            be installed (see the previous description for the
+            <filename>audio</filename> option for more information).
+            <literallayout class='monospaced'>
+     $ runqemu qemux86 ramfs audio
+            </literallayout>
+            This example does not provide enough information for
+            QEMU to launch.
+            While the command does provide a root filesystem type, it
+            must also minimally provide a
+            <replaceable>MACHINE</replaceable>,
+            <replaceable>KERNEL</replaceable>, or
+            <replaceable>VM</replaceable> option.
+            <literallayout class='monospaced'>
+     $ runqemu ext3
+            </literallayout>
+            This example specifies to boot a virtual machine image
+            (<filename>.vmdk</filename> file).
+            From the <filename>.vmdk</filename>,
+            <filename>runqemu</filename> determines the QEMU
+            architecture (<replaceable>MACHINE</replaceable>) to be
+            "qemux86" and the root filesystem type to be "vmdk".
+            <literallayout class='monospaced'>
+     $ runqemu /home/scott-lenovo/vm/core-image-minimal-qemux86.vmdk
+            </literallayout>
+        </para>
+    </section>
+</section>
+
+<section id='qemu-running-under-a-network-file-system-nfs-server'>
+    <title>Running Under a Network File System (NFS) Server</title>
+
+    <para>
+        One method for running QEMU is to run it on an NFS server.
+        This is useful when you need to access the same file system from both
+        the build and the emulated system at the same time.
+        It is also worth noting that the system does not need root privileges
+        to run.
+        It uses a user space NFS server to avoid that.
+        This section describes how to set up for running QEMU using an NFS
+        server and then how you can start and stop the server.
+    </para>
+
+    <section id='qemu-setting-up-to-use-nfs'>
+        <title>Setting Up to Use NFS</title>
+
+        <para>
+            Once you are able to run QEMU in your environment, you can use the
+            <filename>runqemu-extract-sdk</filename> script, which is located
+            in the <filename>scripts</filename> directory along with
+            <filename>runqemu</filename> script.
+            The <filename>runqemu-extract-sdk</filename> takes a root
+            file system tarball and extracts it into a location that you
+            specify.
+            Then, when you run <filename>runqemu</filename>, you can specify
+            the location that has the file system to pass it to QEMU.
+            Here is an example that takes a file system and extracts it to
+            a directory named <filename>test-nfs</filename>:
+            <literallayout class='monospaced'>
+     runqemu-extract-sdk ./tmp/deploy/images/qemux86/core-image-sato-qemux86.tar.bz2 test-nfs
+            </literallayout>
+            Once you have extracted the file system, you can run
+            <filename>runqemu</filename> normally with the additional
+            location of the file system.
+            You can then also make changes to the files within
+            <filename>./test-nfs</filename> and see those changes appear in the
+            image in real time.
+            Here is an example using the <filename>qemux86</filename> image:
+            <literallayout class='monospaced'>
+     runqemu qemux86 ./test-nfs
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='qemu-starting-and-stopping-nfs'>
+        <title>Starting and Stopping NFS</title>
+
+        <para>
+            You can manually start and stop the NFS share using these
+            commands:
+            <itemizedlist>
+                <listitem><para><emphasis><filename>start</filename>:</emphasis>
+                    Starts the NFS share:
+                    <literallayout class='monospaced'>
+     runqemu-export-rootfs start <replaceable>file-system-location</replaceable>
+                    </literallayout>
+                    </para></listitem>
+                <listitem><para><emphasis><filename>stop</filename>:</emphasis>
+                    Stops the NFS share:
+                    <literallayout class='monospaced'>
+     runqemu-export-rootfs stop <replaceable>file-system-location</replaceable>
+                    </literallayout>
+                    </para></listitem>
+                <listitem><para><emphasis><filename>restart</filename>:</emphasis>
+                    Restarts the NFS share:
+                    <literallayout class='monospaced'>
+     runqemu-export-rootfs restart <replaceable>file-system-location</replaceable>
+                    </literallayout>
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
+
+<section id='qemu-tips-and-tricks'>
+    <title>Tips and Tricks</title>
+
+    <para>
+        The following list describes things you can do to make running QEMU
+        in the context of the Yocto Project a better experience:
+        <itemizedlist>
+            <listitem><para><emphasis>Switching Between Consoles:</emphasis>
+                When booting or running QEMU, you can switch between
+                supported consoles by using
+                Ctrl+Alt+<replaceable>number</replaceable>.
+                For example, Ctrl+Alt+3 switches you to the serial console as
+                long as that console is enabled.
+                Being able to switch consoles is helpful, for example, if the
+                main QEMU console breaks for some reason.
+                <note>
+                    Usually, "2" gets you to the main console and "3" gets you
+                    to the serial console.
+                </note>
+                </para></listitem>
+            <listitem><para><emphasis>Removing the Splash Screen:</emphasis>
+                You can remove the splash screen when QEMU is booting by
+                using Alt+left.
+                Removing the splash screen allows you to see what is happening
+                in the background.
+                </para></listitem>
+            <listitem><para><emphasis>Disabling the Cursor Grab:</emphasis>
+                The default QEMU integration captures the cursor within the
+                main window.
+                It does this since standard mouse devices only provide relative
+                input and not absolute coordinates.
+                You then have to break out of the grab using the "Ctrl+Alt" key
+                combination.
+                However, the Yocto Project's integration of QEMU enables the
+                wacom USB touch pad driver by default to allow input of absolute
+                coordinates.
+                This default means that the mouse can enter and leave the
+                main window without the grab taking effect leading to a better
+                user experience.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/dev-manual/dev-manual-start.xml b/documentation/dev-manual/dev-manual-start.xml
new file mode 100644
index 0000000000..61434ff72c
--- /dev/null
+++ b/documentation/dev-manual/dev-manual-start.xml
@@ -0,0 +1,418 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='dev-manual-start'>
+
+<title>Getting Started with the Yocto Project</title>
+
+<para>
+    This chapter introduces the Yocto Project and gives you an idea of what you need to get started.
+    You can find enough information to set up your development host and build or use images for
+    hardware supported by the Yocto Project by reading the
+    <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>.
+</para>
+
+<para>
+    The remainder of this chapter summarizes what is in the Yocto Project Quick Start and provides
+    some higher-level concepts you might want to consider.
+</para>
+
+<section id='introducing-the-yocto-project'>
+    <title>Introducing the Yocto Project</title>
+
+    <para>
+        The Yocto Project is an open-source collaboration project focused on embedded Linux development.
+        The project currently provides a build system that is
+        referred to as the
+        <link linkend='build-system-term'>OpenEmbedded build system</link>
+        in the Yocto Project documentation.
+        The Yocto Project provides various ancillary tools for the embedded developer
+        and also features the Sato reference User Interface, which is optimized for
+        stylus driven, low-resolution screens.
+    </para>
+
+    <para>
+        You can use the OpenEmbedded build system, which uses
+        <link linkend='bitbake-term'>BitBake</link>, to develop complete Linux
+        images and associated user-space applications for architectures based
+        on ARM, MIPS, PowerPC, x86 and x86-64.
+        <note>
+            By default, using the Yocto Project creates a Poky distribution.
+            However, you can create your own distribution by providing key
+            <link linkend='metadata'>Metadata</link>.
+            See the "<link linkend='creating-your-own-distribution'>Creating Your Own Distribution</link>"
+            section for more information.
+        </note>
+        While the Yocto Project does not provide a strict testing framework,
+        it does provide or generate for you artifacts that let you perform target-level and
+        emulated testing and debugging.
+        Additionally, if you are an <trademark class='trade'>Eclipse</trademark>
+        IDE user, you can install an Eclipse Yocto Plug-in to allow you to
+        develop within that familiar environment.
+    </para>
+</section>
+
+<section id='getting-setup'>
+    <title>Getting Set Up</title>
+
+    <para>
+        Here is what you need to use the Yocto Project:
+        <itemizedlist>
+            <listitem><para><emphasis>Host System:</emphasis>  You should have a reasonably current
+                Linux-based host system.
+                You will have the best results with a recent release of Fedora,
+                openSUSE, Debian, Ubuntu, or CentOS as these releases are frequently tested against the Yocto Project
+                and officially supported.
+                For a list of the distributions under validation and their status, see the
+                "<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>" section
+                in the Yocto Project Reference Manual and the wiki page at
+                <ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution Support</ulink>.</para>
+                <para>
+                You should also have about 50 Gbytes of free disk space for building images.
+                </para></listitem>
+            <listitem><para><emphasis>Packages:</emphasis>  The OpenEmbedded build system
+                requires that certain packages exist on your development system (e.g. Python 2.6 or 2.7).
+                See "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>"
+                section in the Yocto Project Quick Start and the
+                "<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-host-development-system'>Required Packages for the Host Development System</ulink>"
+                section in the Yocto Project Reference Manual for the exact
+                package requirements and the installation commands to install
+                them for the supported distributions.
+                </para></listitem>
+            <listitem id='local-yp-release'><para><emphasis>Yocto Project Release:</emphasis>
+                You need a release of the Yocto Project locally installed on
+                your development system.
+                The documentation refers to this set of locally installed files
+                as the <link linkend='source-directory'>Source Directory</link>.
+                You create your Source Directory by using
+                <link linkend='git'>Git</link> to clone a local copy
+                of the upstream <filename>poky</filename> repository,
+                or by downloading and unpacking a tarball of an official
+                Yocto Project release.
+                The preferred method is to create a clone of the repository.
+                </para>
+                <para>Working from a copy of the upstream repository allows you
+                to contribute back into the Yocto Project or simply work with
+                the latest software on a development branch.
+                Because Git maintains and creates an upstream repository with
+                a complete history of changes and you are working with a local
+                clone of that repository, you have access to all the Yocto
+                Project development branches and tag names used in the upstream
+                repository.</para>
+                <note>You can view the Yocto Project Source Repositories at
+                    <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>
+                </note>
+                <para>The following transcript shows how to clone the
+                <filename>poky</filename> Git repository into the current
+                working directory.
+                The command creates the local repository in a directory
+                named <filename>poky</filename>.
+                For information on Git used within the Yocto Project, see
+                the "<link linkend='git'>Git</link>" section.
+                <literallayout class='monospaced'>
+     $ git clone git://git.yoctoproject.org/poky
+     Cloning into 'poky'...
+     remote: Counting objects: 226790, done.
+     remote: Compressing objects: 100% (57465/57465), done.
+     remote: Total 226790 (delta 165212), reused 225887 (delta 164327)
+     Receiving objects: 100% (226790/226790), 100.98 MiB | 263 KiB/s, done.
+     Resolving deltas: 100% (165212/165212), done.
+                </literallayout></para>
+                <para>For another example of how to set up your own local Git
+                repositories, see this
+                <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
+                wiki page</ulink>, which describes how to create local
+                Git repositories for both
+                <filename>poky</filename> and <filename>meta-intel</filename>.
+                </para></listitem>
+            <listitem id='local-kernel-files'><para><emphasis>Yocto Project Kernel:</emphasis>
+                If you are going to be making modifications to a supported Yocto Project kernel, you
+                need to establish local copies of the source.
+                You can find Git repositories of supported Yocto Project kernels organized under
+                "Yocto Linux Kernel" in the Yocto Project Source Repositories at
+                <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para>
+                <para>This setup can involve creating a bare clone of the Yocto Project kernel and then
+                copying that cloned repository.
+                You can create the bare clone and the copy of the bare clone anywhere you like.
+                For simplicity, it is recommended that you create these structures outside of the
+                Source Directory, which is usually named <filename>poky</filename>.</para>
+                <para>As an example, the following transcript shows how to create the bare clone
+                of the <filename>linux-yocto-3.10</filename> kernel and then create a copy of
+                that clone.
+                <note>When you have a local Yocto Project kernel Git repository, you can
+                reference that repository rather than the upstream Git repository as
+                part of the <filename>clone</filename> command.
+                Doing so can speed up the process.</note></para>
+                <para>In the following example, the bare clone is named
+                <filename>linux-yocto-3.10.git</filename>, while the
+                copy is named <filename>my-linux-yocto-3.10-work</filename>:
+                <literallayout class='monospaced'>
+     $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.10 linux-yocto-3.10.git
+     Cloning into bare repository 'linux-yocto-3.10.git'...
+     remote: Counting objects: 3364487, done.
+     remote: Compressing objects: 100% (507178/507178), done.
+     remote: Total 3364487 (delta 2827715), reused 3364481 (delta 2827709)
+     Receiving objects: 100% (3364487/3364487), 722.95 MiB | 423 KiB/s, done.
+     Resolving deltas: 100% (2827715/2827715), done.
+                </literallayout></para>
+                <para>Now create a clone of the bare clone just created:
+                <literallayout class='monospaced'>
+     $ git clone linux-yocto-3.10.git my-linux-yocto-3.10-work
+     Cloning into 'my-linux-yocto-3.10-work'...
+     done.
+                </literallayout></para></listitem>
+            <listitem id='meta-yocto-kernel-extras-repo'><para><emphasis>
+                The <filename>meta-yocto-kernel-extras</filename> Git Repository</emphasis>:
+                The <filename>meta-yocto-kernel-extras</filename> Git repository contains Metadata needed
+                only if you are modifying and building the kernel image.
+                In particular, it contains the kernel BitBake append (<filename>.bbappend</filename>)
+                files that you
+                edit to point to your locally modified kernel source files and to build the kernel
+                image.
+                Pointing to these local files is much more efficient than requiring a download of the
+                kernel's source files from upstream each time you make changes to the kernel.</para>
+                <para>You can find the <filename>meta-yocto-kernel-extras</filename> Git Repository in the
+                "Yocto Metadata Layers" area of the Yocto Project Source Repositories at
+                <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.
+                It is good practice to create this Git repository inside the Source Directory.</para>
+                <para>Following is an example that creates the <filename>meta-yocto-kernel-extras</filename> Git
+                repository inside the Source Directory, which is named <filename>poky</filename>
+                in this case:
+                <literallayout class='monospaced'>
+     $ cd ~/poky
+     $ git clone git://git.yoctoproject.org/meta-yocto-kernel-extras meta-yocto-kernel-extras
+     Cloning into 'meta-yocto-kernel-extras'...
+     remote: Counting objects: 727, done.
+     remote: Compressing objects: 100% (452/452), done.
+     remote: Total 727 (delta 260), reused 719 (delta 252)
+     Receiving objects: 100% (727/727), 536.36 KiB | 240 KiB/s, done.
+     Resolving deltas: 100% (260/260), done.
+               </literallayout></para></listitem>
+           <listitem><para id='supported-board-support-packages-(bsps)'><emphasis>Supported Board Support Packages (BSPs):</emphasis>
+                The Yocto Project supports many BSPs, which are maintained in
+                their own layers or in layers designed to contain several
+                BSPs.
+                To get an idea of machine support through BSP layers, you can
+                look at the
+                <ulink url='&YOCTO_RELEASE_DL_URL;/machines'>index of machines</ulink>
+                for the release.</para>
+
+                <para>The Yocto Project uses the following BSP layer naming
+                scheme:
+                <literallayout class='monospaced'>
+     meta-<replaceable>bsp_name</replaceable>
+                </literallayout>
+                where <replaceable>bsp_name</replaceable> is the recognized
+                BSP name.
+                Here are some examples:
+                <literallayout class='monospaced'>
+     meta-crownbay
+     meta-emenlow
+     meta-n450
+                </literallayout>
+                See the
+                "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
+                section in the Yocto Project Board Support Package (BSP)
+                Developer's Guide for more information on BSP Layers.</para>
+
+                <para>A useful Git repository released with the Yocto
+                Project is <filename>meta-intel</filename>, which is a
+                parent layer that contains many supported
+                <ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>.
+                You can locate the <filename>meta-intel</filename> Git
+                repository in the "Yocto Metadata Layers" area of the Yocto
+                Project Source Repositories at
+                <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para>
+
+                <para>Using
+                <link linkend='git'>Git</link> to create a local clone of the
+                upstream repository can be helpful if you are working with
+                BSPs.
+                Typically, you set up the <filename>meta-intel</filename>
+                Git repository inside the Source Directory.
+                For example, the following transcript shows the steps to clone
+                <filename>meta-intel</filename>.
+                <note>
+                    Be sure to work in the <filename>meta-intel</filename>
+                    branch that matches your
+                    <link linkend='source-directory'>Source Directory</link>
+                    (i.e. <filename>poky</filename>) branch.
+                    For example, if you have checked out the "master" branch
+                    of <filename>poky</filename> and you are going to use
+                    <filename>meta-intel</filename>, be sure to checkout the
+                    "master" branch of <filename>meta-intel</filename>.
+                </note>
+                <literallayout class='monospaced'>
+     $ cd ~/poky
+     $ git clone git://git.yoctoproject.org/meta-intel.git
+     Cloning into 'meta-intel'...
+     remote: Counting objects: 8844, done.
+     remote: Compressing objects: 100% (2864/2864), done.
+     remote: Total 8844 (delta 4931), reused 8780 (delta 4867)
+     Receiving objects: 100% (8844/8844), 2.48 MiB | 264 KiB/s, done.
+     Resolving deltas: 100% (4931/4931), done.
+                </literallayout></para>
+
+                <para>The same
+                <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>wiki page</ulink>
+                referenced earlier covers how to set up the
+                <filename>meta-intel</filename> Git repository.
+                </para></listitem>
+            <listitem><para><emphasis>Eclipse Yocto Plug-in:</emphasis>  If you are developing
+                applications using the Eclipse Integrated Development Environment (IDE),
+                you will need this plug-in.
+                See the
+                "<link linkend='setting-up-the-eclipse-ide'>Setting up the Eclipse IDE</link>"
+                section for more information.</para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='building-images'>
+    <title>Building Images</title>
+
+    <para>
+        The build process creates an entire Linux distribution, including the toolchain, from source.
+        For more information on this topic, see the
+        "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>"
+        section in the Yocto Project Quick Start.
+    </para>
+
+    <para>
+        The build process is as follows:
+        <orderedlist>
+            <listitem><para>Make sure you have set up the Source Directory described in the
+                previous section.</para></listitem>
+            <listitem><para>Initialize the build environment by sourcing a build
+                environment script (i.e.
+                <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                or
+                <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>).
+                </para></listitem>
+            <listitem><para>Optionally ensure the <filename>conf/local.conf</filename> configuration file,
+                which is found in the
+                <link linkend='build-directory'>Build Directory</link>,
+                is set up how you want it.
+                This file defines many aspects of the build environment including
+                the target machine architecture through the
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'>MACHINE</ulink></filename> variable,
+                the development machine's processor use through the
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</ulink></filename> and
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE'>PARALLEL_MAKE</ulink></filename> variables, and
+                a centralized tarball download directory through the
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-DL_DIR'>DL_DIR</ulink></filename> variable.</para></listitem>
+            <listitem><para>
+                Build the image using the <filename>bitbake</filename> command.
+                If you want information on BitBake, see the
+                <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
+                </para></listitem>
+            <listitem><para>Run the image either on the actual hardware or using the QEMU
+                emulator.</para></listitem>
+        </orderedlist>
+    </para>
+</section>
+
+<section id='using-pre-built-binaries-and-qemu'>
+    <title>Using Pre-Built Binaries and QEMU</title>
+
+    <para>
+        Another option you have to get started is to use pre-built binaries.
+        The Yocto Project provides many types of binaries with each release.
+        See the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>"
+        chapter in the Yocto Project Reference Manual
+        for descriptions of the types of binaries that ship with a Yocto Project
+        release.
+    </para>
+
+    <para>
+        Using a pre-built binary is ideal for developing software applications to run on your
+        target hardware.
+        To do this, you need to be able to access the appropriate cross-toolchain tarball for
+        the architecture on which you are developing.
+        If you are using an SDK type image, the image ships with the complete toolchain native to
+        the architecture.
+        If you are not using an SDK type image, you need to separately download and
+        install the stand-alone Yocto Project cross-toolchain tarball.
+    </para>
+
+    <para>
+        Regardless of the type of image you are using, you need to download the pre-built kernel
+        that you will boot in the QEMU emulator and then download and extract the target root
+        filesystem for your target machine’s architecture.
+        You can get architecture-specific binaries and file systems from
+        <ulink url='&YOCTO_MACHINES_DL_URL;'>machines</ulink>.
+        You can get installation scripts for stand-alone toolchains from
+        <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'>toolchains</ulink>.
+        Once you have all your files, you set up the environment to emulate the hardware
+        by sourcing an environment setup script.
+        Finally, you start the QEMU emulator.
+        You can find details on all these steps in the
+        "<ulink url='&YOCTO_DOCS_QS_URL;#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
+        section of the Yocto Project Quick Start.
+        You can learn more about using QEMU with the Yocto Project in the
+        "<link linkend='dev-manual-qemu'>Using the Quick EMUlator (QEMU)</link>"
+        section.
+    </para>
+
+    <para>
+        Using QEMU to emulate your hardware can result in speed issues
+        depending on the target and host architecture mix.
+        For example, using the <filename>qemux86</filename> image in the emulator
+        on an Intel-based 32-bit (x86) host machine is fast because the target and
+        host architectures match.
+        On the other hand, using the <filename>qemuarm</filename> image on the same Intel-based
+        host can be slower.
+        But, you still achieve faithful emulation of ARM-specific issues.
+    </para>
+
+    <para>
+        To speed things up, the QEMU images support using <filename>distcc</filename>
+        to call a cross-compiler outside the emulated system.
+        If you used <filename>runqemu</filename> to start QEMU, and the
+        <filename>distccd</filename> application is present on the host system, any
+        BitBake cross-compiling toolchain available from the build system is automatically
+        used from within QEMU simply by calling <filename>distcc</filename>.
+        You can accomplish this by defining the cross-compiler variable
+        (e.g. <filename>export CC="distcc"</filename>).
+        Alternatively, if you are using a suitable SDK image or the appropriate
+        stand-alone toolchain is present,
+        the toolchain is also automatically used.
+    </para>
+
+    <note>
+        Several mechanisms exist that let you connect to the system running on the
+        QEMU emulator:
+        <itemizedlist>
+            <listitem><para>QEMU provides a framebuffer interface that makes standard
+                consoles available.</para></listitem>
+            <listitem><para>Generally, headless embedded devices have a serial port.
+                If so, you can configure the operating system of the running image
+                to use that port to run a console.
+                The connection uses standard IP networking.</para></listitem>
+            <listitem><para>
+                SSH servers exist in some QEMU images.
+                The <filename>core-image-sato</filename> QEMU image has a
+                Dropbear secure shell (SSH) server that runs with the root
+                password disabled.
+                The <filename>core-image-full-cmdline</filename> and
+                <filename>core-image-lsb</filename> QEMU images
+                have OpenSSH instead of Dropbear.
+                Including these SSH servers allow you to use standard
+                <filename>ssh</filename> and <filename>scp</filename> commands.
+                The <filename>core-image-minimal</filename> QEMU image,
+                however, contains no SSH server.
+                </para></listitem>
+            <listitem><para>You can use a provided, user-space NFS server to boot the QEMU session
+                using a local copy of the root filesystem on the host.
+                In order to make this connection, you must extract a root filesystem tarball by using the
+                <filename>runqemu-extract-sdk</filename> command.
+                After running the command, you must then point the <filename>runqemu</filename>
+                script to the extracted directory instead of a root filesystem image file.</para></listitem>
+        </itemizedlist>
+    </note>
+</section>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/dev-manual/dev-manual.xml b/documentation/dev-manual/dev-manual.xml
new file mode 100644
index 0000000000..4e498b8201
--- /dev/null
+++ b/documentation/dev-manual/dev-manual.xml
@@ -0,0 +1,124 @@
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<book id='dev-manual' lang='en'
+      xmlns:xi="http://www.w3.org/2003/XInclude"
+      xmlns="http://docbook.org/ns/docbook"
+      >
+    <bookinfo>
+
+        <mediaobject>
+            <imageobject>
+                <imagedata fileref='figures/dev-title.png'
+                    format='SVG'
+                    align='left' scalefit='1' width='100%'/>
+            </imageobject>
+        </mediaobject>
+
+        <title>
+            Yocto Project Development Manual
+        </title>
+
+        <authorgroup>
+            <author>
+                <firstname>Scott</firstname> <surname>Rifenbark</surname>
+                <affiliation>
+                    <orgname>Intel Corporation</orgname>
+                </affiliation>
+                <email>scott.m.rifenbark@intel.com</email>
+            </author>
+        </authorgroup>
+
+        <revhistory>
+            <revision>
+                <revnumber>1.1</revnumber>
+                <date>6 October 2011</date>
+                <revremark>The initial document released with the Yocto Project 1.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.2</revnumber>
+                <date>April 2012</date>
+                <revremark>Released with the Yocto Project 1.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.3</revnumber>
+                <date>October 2012</date>
+                <revremark>Released with the Yocto Project 1.3 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4</revnumber>
+                <date>April 2013</date>
+                <revremark>Released with the Yocto Project 1.4 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5</revnumber>
+                <date>October 2013</date>
+                <revremark>Released with the Yocto Project 1.5 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.1</revnumber>
+                <date>January 2014</date>
+                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.6</revnumber>
+                <date>April 2014</date>
+                <revremark>Released with the Yocto Project 1.6 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7</revnumber>
+                <date>October 2014</date>
+                <revremark>Released with the Yocto Project 1.7 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.1</revnumber>
+                <date>January 2015</date>
+                <revremark>Released with the Yocto Project 1.7.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.2</revnumber>
+                <date>June 2015</date>
+                <revremark>Released with the Yocto Project 1.7.2 Release.</revremark>
+            </revision>
+        </revhistory>
+
+    <copyright>
+     <year>&COPYRIGHT_YEAR;</year>
+      <holder>Linux Foundation</holder>
+    </copyright>
+
+    <legalnotice>
+      <para>
+          Permission is granted to copy, distribute and/or modify this document under
+          the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">
+          Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by
+          Creative Commons.
+      </para>
+
+      <note>
+          For the latest version of this manual associated with this
+          Yocto Project release, see the
+          <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Manual</ulink>
+          from the Yocto Project website.
+      </note>
+    </legalnotice>
+
+    </bookinfo>
+
+    <xi:include href="dev-manual-intro.xml"/>
+
+    <xi:include href="dev-manual-start.xml"/>
+
+    <xi:include href="dev-manual-newbie.xml"/>
+
+    <xi:include href="dev-manual-model.xml"/>
+
+    <xi:include href="dev-manual-common-tasks.xml"/>
+
+    <xi:include href="dev-manual-qemu.xml"/>
+
+</book>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/dev-manual/dev-style.css b/documentation/dev-manual/dev-style.css
new file mode 100644
index 0000000000..b900ffc9b2
--- /dev/null
+++ b/documentation/dev-manual/dev-style.css
@@ -0,0 +1,984 @@
+/*
+   Generic XHTML / DocBook XHTML CSS Stylesheet.
+
+   Browser wrangling and typographic design by
+      Oyvind Kolas / pippin@gimp.org
+
+   Customised for Poky by
+      Matthew Allum / mallum@o-hand.com
+
+   Thanks to:
+     Liam R. E. Quin
+     William Skaggs
+     Jakub Steiner
+
+   Structure
+   ---------
+
+   The stylesheet is divided into the following sections:
+
+       Positioning
+          Margins, paddings, width, font-size, clearing.
+       Decorations
+          Borders, style
+       Colors
+          Colors
+       Graphics
+          Graphical backgrounds
+       Nasty IE tweaks
+          Workarounds needed to make it work in internet explorer,
+          currently makes the stylesheet non validating, but up until
+          this point it is validating.
+       Mozilla extensions
+          Transparency for footer
+          Rounded corners on boxes
+
+*/
+
+
+  /*************** /
+ /  Positioning   /
+/ ***************/
+
+body {
+  font-family: Verdana, Sans, sans-serif;
+
+  min-width: 640px;
+  width: 80%;
+  margin:  0em auto;
+  padding: 2em 5em 5em 5em;
+  color: #333;
+}
+
+h1,h2,h3,h4,h5,h6,h7 {
+  font-family: Arial, Sans;
+  color: #00557D;
+  clear: both;
+}
+
+h1 {
+  font-size: 2em;
+  text-align: left;
+  padding: 0em 0em 0em 0em;
+  margin: 2em 0em 0em 0em;
+}
+
+h2.subtitle {
+  margin: 0.10em 0em 3.0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 1.8em;
+  padding-left: 20%;
+  font-weight: normal;
+  font-style: italic;
+}
+
+h2 {
+  margin: 2em 0em 0.66em 0em;
+  padding: 0.5em 0em 0em 0em;
+  font-size: 1.5em;
+  font-weight: bold;
+}
+
+h3.subtitle {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 142.14%;
+  text-align: right;
+}
+
+h3 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 140%;
+  font-weight: bold;
+}
+
+h4 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 120%;
+  font-weight: bold;
+}
+
+h5 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+h6 {
+  margin: 1em 0em 0em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+.authorgroup {
+  background-color: transparent;
+  background-repeat: no-repeat;
+  padding-top: 256px;
+  background-image: url("figures/dev-title.png");
+  background-position: left top;
+  margin-top: -256px;
+  padding-right: 50px;
+  margin-left: 0px;
+  text-align: right;
+  width: 740px;
+}
+
+h3.author {
+  margin: 0em 0me 0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-weight: normal;
+  font-size: 100%;
+  color: #333;
+  clear: both;
+}
+
+.author tt.email {
+  font-size: 66%;
+}
+
+.titlepage hr {
+  width: 0em;
+  clear: both;
+}
+
+.revhistory {
+  padding-top: 2em;
+  clear: both;
+}
+
+.toc,
+.list-of-tables,
+.list-of-examples,
+.list-of-figures {
+  padding: 1.33em 0em 2.5em 0em;
+  color: #00557D;
+}
+
+.toc p,
+.list-of-tables p,
+.list-of-figures p,
+.list-of-examples p {
+  padding: 0em 0em 0em 0em;
+  padding: 0em 0em 0.3em;
+  margin: 1.5em 0em 0em 0em;
+}
+
+.toc p b,
+.list-of-tables p b,
+.list-of-figures p b,
+.list-of-examples p b{
+  font-size: 100.0%;
+  font-weight: bold;
+}
+
+.toc dl,
+.list-of-tables dl,
+.list-of-figures dl,
+.list-of-examples dl {
+  margin: 0em 0em 0.5em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dt {
+  margin: 0em 0em 0em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dd {
+  margin: 0em 0em 0em 2.6em;
+  padding: 0em 0em 0em 0em;
+}
+
+div.glossary dl,
+div.variablelist dl {
+}
+
+.glossary dl dt,
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  font-weight: normal;
+  width: 20em;
+  text-align: right;
+}
+
+.variablelist dl dt {
+  margin-top: 0.5em;
+}
+
+.glossary dl dd,
+.variablelist dl dd {
+  margin-top: -1em;
+  margin-left: 25.5em;
+}
+
+.glossary dd p,
+.variablelist dd p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+
+div.calloutlist table td {
+  padding: 0em 0em 0em 0em;
+  margin: 0em 0em 0em 0em;
+}
+
+div.calloutlist table td p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+div p.copyright {
+  text-align: left;
+}
+
+div.legalnotice p.legalnotice-title {
+  margin-bottom: 0em;
+}
+
+p {
+  line-height: 1.5em;
+  margin-top: 0em;
+
+}
+
+dl {
+  padding-top: 0em;
+}
+
+hr {
+  border: solid 1px;
+}
+
+
+.mediaobject,
+.mediaobjectco {
+  text-align: center;
+}
+
+img {
+  border: none;
+}
+
+ul {
+  padding: 0em 0em 0em 1.5em;
+}
+
+ul li {
+  padding: 0em 0em 0em 0em;
+}
+
+ul li p {
+  text-align: left;
+}
+
+table {
+  width :100%;
+}
+
+th {
+  padding: 0.25em;
+  text-align: left;
+  font-weight: normal;
+  vertical-align: top;
+}
+
+td {
+  padding: 0.25em;
+  vertical-align: top;
+}
+
+p a[id] {
+  margin: 0px;
+  padding: 0px;
+  display: inline;
+  background-image: none;
+}
+
+a {
+  text-decoration: underline;
+  color: #444;
+}
+
+pre {
+    overflow: auto;
+}
+
+a:hover {
+  text-decoration: underline;
+  /*font-weight: bold;*/
+}
+
+/* This style defines how the permalink character
+   appears by itself and when hovered over with
+   the mouse. */
+
+[alt='Permalink'] { color: #eee; }
+[alt='Permalink']:hover { color: black; }
+
+
+div.informalfigure,
+div.informalexample,
+div.informaltable,
+div.figure,
+div.table,
+div.example {
+  margin: 1em 0em;
+  padding: 1em;
+  page-break-inside: avoid;
+}
+
+
+div.informalfigure p.title b,
+div.informalexample p.title b,
+div.informaltable p.title b,
+div.figure p.title b,
+div.example p.title b,
+div.table p.title b{
+    padding-top: 0em;
+    margin-top: 0em;
+    font-size: 100%;
+    font-weight: normal;
+}
+
+.mediaobject .caption,
+.mediaobject .caption p  {
+  text-align: center;
+  font-size: 80%;
+  padding-top: 0.5em;
+  padding-bottom: 0.5em;
+}
+
+.epigraph {
+  padding-left: 55%;
+  margin-bottom: 1em;
+}
+
+.epigraph p {
+  text-align: left;
+}
+
+.epigraph .quote {
+  font-style: italic;
+}
+.epigraph .attribution {
+  font-style: normal;
+  text-align: right;
+}
+
+span.application {
+  font-style: italic;
+}
+
+.programlisting {
+  font-family: monospace;
+  font-size: 80%;
+  white-space: pre;
+  margin: 1.33em 0em;
+  padding: 1.33em;
+}
+
+.tip,
+.warning,
+.caution,
+.note {
+  margin-top: 1em;
+  margin-bottom: 1em;
+
+}
+
+/* force full width of table within div */
+.tip table,
+.warning table,
+.caution table,
+.note table {
+  border: none;
+  width: 100%;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  padding: 0.8em 0.0em 0.0em 0.0em;
+  margin : 0em 0em 0em 0em;
+}
+
+.tip p,
+.warning p,
+.caution p,
+.note p {
+  margin-top: 0.5em;
+  margin-bottom: 0.5em;
+  padding-right: 1em;
+  text-align: left;
+}
+
+.acronym {
+  text-transform: uppercase;
+}
+
+b.keycap,
+.keycap {
+  padding: 0.09em 0.3em;
+  margin: 0em;
+}
+
+.itemizedlist li {
+  clear: none;
+}
+
+.filename {
+  font-size: medium;
+  font-family: Courier, monospace;
+}
+
+
+div.navheader, div.heading{
+  position: absolute;
+  left: 0em;
+  top: 0em;
+  width: 100%;
+  background-color: #cdf;
+  width: 100%;
+}
+
+div.navfooter, div.footing{
+  position: fixed;
+  left: 0em;
+  bottom: 0em;
+  background-color: #eee;
+  width: 100%;
+}
+
+
+div.navheader td,
+div.navfooter td {
+  font-size: 66%;
+}
+
+div.navheader table th {
+  /*font-family: Georgia, Times, serif;*/
+  /*font-size: x-large;*/
+  font-size: 80%;
+}
+
+div.navheader table {
+  border-left: 0em;
+  border-right: 0em;
+  border-top: 0em;
+  width: 100%;
+}
+
+div.navfooter table {
+  border-left: 0em;
+  border-right: 0em;
+  border-bottom: 0em;
+  width: 100%;
+}
+
+div.navheader table td a,
+div.navfooter table td a {
+  color: #777;
+  text-decoration: none;
+}
+
+/* normal text in the footer */
+div.navfooter table td {
+  color: black;
+}
+
+div.navheader table td a:visited,
+div.navfooter table td a:visited {
+  color: #444;
+}
+
+
+/* links in header and footer */
+div.navheader table td a:hover,
+div.navfooter table td a:hover {
+  text-decoration: underline;
+  background-color: transparent;
+  color: #33a;
+}
+
+div.navheader hr,
+div.navfooter hr {
+  display: none;
+}
+
+
+.qandaset tr.question td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.qandaset tr.answer td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+.answer td {
+  padding-bottom: 1.5em;
+}
+
+.emphasis {
+  font-weight: bold;
+}
+
+
+  /************* /
+ / decorations  /
+/ *************/
+
+.titlepage {
+}
+
+.part .title {
+}
+
+.subtitle {
+    border: none;
+}
+
+/*
+h1 {
+  border: none;
+}
+
+h2 {
+  border-top: solid 0.2em;
+  border-bottom: solid 0.06em;
+}
+
+h3 {
+  border-top: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h4 {
+  border: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h5 {
+  border: 0em;
+}
+*/
+
+.programlisting {
+  border: solid 1px;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example {
+  border: 1px solid;
+}
+
+
+
+.tip,
+.warning,
+.caution,
+.note {
+  border: 1px solid;
+}
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom: 1px solid;
+}
+
+.question td {
+  border-top: 1px solid black;
+}
+
+.answer {
+}
+
+
+b.keycap,
+.keycap {
+  border: 1px solid;
+}
+
+
+div.navheader, div.heading{
+  border-bottom: 1px solid;
+}
+
+
+div.navfooter, div.footing{
+  border-top: 1px solid;
+}
+
+  /********* /
+ /  colors  /
+/ *********/
+
+body {
+  color: #333;
+  background: white;
+}
+
+a {
+  background: transparent;
+}
+
+a:hover {
+  background-color: #dedede;
+}
+
+
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7,
+h8 {
+  background-color: transparent;
+}
+
+hr {
+  border-color: #aaa;
+}
+
+
+.tip, .warning, .caution, .note {
+  border-color: #fff;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom-color: #fff;
+}
+
+
+.warning {
+  background-color: #f0f0f2;
+}
+
+.caution {
+  background-color: #f0f0f2;
+}
+
+.tip {
+  background-color: #f0f0f2;
+}
+
+.note {
+  background-color: #f0f0f2;
+}
+
+.glossary dl dt,
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  color: #044;
+}
+
+div.figure,
+div.table,
+div.example,
+div.informalfigure,
+div.informaltable,
+div.informalexample {
+  border-color: #aaa;
+}
+
+pre.programlisting {
+  color: black;
+  background-color: #fff;
+  border-color: #aaa;
+  border-width: 2px;
+}
+
+.guimenu,
+.guilabel,
+.guimenuitem {
+  background-color: #eee;
+}
+
+
+b.keycap,
+.keycap {
+  background-color: #eee;
+  border-color: #999;
+}
+
+
+div.navheader {
+  border-color: black;
+}
+
+
+div.navfooter {
+  border-color: black;
+}
+
+
+  /*********** /
+ /  graphics  /
+/ ***********/
+
+/*
+body {
+  background-image: url("images/body_bg.jpg");
+  background-attachment: fixed;
+}
+
+.navheader,
+.note,
+.tip {
+  background-image: url("images/note_bg.jpg");
+  background-attachment: fixed;
+}
+
+.warning,
+.caution {
+  background-image: url("images/warning_bg.jpg");
+  background-attachment: fixed;
+}
+
+.figure,
+.informalfigure,
+.example,
+.informalexample,
+.table,
+.informaltable {
+  background-image: url("images/figure_bg.jpg");
+  background-attachment: fixed;
+}
+
+*/
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7{
+}
+
+/*
+Example of how to stick an image as part of the title.
+
+div.article .titlepage .title
+{
+  background-image: url("figures/white-on-black.png");
+  background-position: center;
+  background-repeat: repeat-x;
+}
+*/
+
+div.preface .titlepage .title,
+div.colophon .title,
+div.chapter .titlepage .title,
+div.article .titlepage .title
+{
+}
+
+div.section div.section .titlepage .title,
+div.sect2 .titlepage .title {
+    background: none;
+}
+
+
+h1.title {
+  background-color: transparent;
+  background-repeat: no-repeat;
+  height: 256px;
+  text-indent: -9000px;
+  overflow:hidden;
+}
+
+h2.subtitle {
+  background-color: transparent;
+  text-indent: -9000px;
+  overflow:hidden;
+  width: 0px;
+  display: none;
+}
+
+  /*************************************** /
+ /  pippin.gimp.org specific alterations  /
+/ ***************************************/
+
+/*
+div.heading, div.navheader {
+  color: #777;
+  font-size: 80%;
+  padding: 0;
+  margin: 0;
+  text-align: left;
+  position: absolute;
+  top: 0px;
+  left: 0px;
+  width: 100%;
+  height: 50px;
+  background: url('/gfx/heading_bg.png') transparent;
+  background-repeat: repeat-x;
+  background-attachment: fixed;
+  border: none;
+}
+
+div.heading a {
+  color: #444;
+}
+
+div.footing, div.navfooter {
+  border: none;
+  color: #ddd;
+  font-size: 80%;
+  text-align:right;
+
+  width: 100%;
+  padding-top: 10px;
+  position: absolute;
+  bottom: 0px;
+  left: 0px;
+
+  background: url('/gfx/footing_bg.png') transparent;
+}
+*/
+
+
+
+  /****************** /
+ /  nasty ie tweaks  /
+/ ******************/
+
+/*
+div.heading, div.navheader {
+  width:expression(document.body.clientWidth + "px");
+}
+
+div.footing, div.navfooter {
+  width:expression(document.body.clientWidth + "px");
+  margin-left:expression("-5em");
+}
+body {
+  padding:expression("4em 5em 0em 5em");
+}
+*/
+
+  /**************************************** /
+ / mozilla vendor specific css extensions  /
+/ ****************************************/
+/*
+div.navfooter, div.footing{
+  -moz-opacity: 0.8em;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example,
+.tip,
+.warning,
+.caution,
+.note {
+  -moz-border-radius: 0.5em;
+}
+
+b.keycap,
+.keycap {
+  -moz-border-radius: 0.3em;
+}
+*/
+
+table tr td table tr td {
+  display: none;
+}
+
+
+hr {
+  display: none;
+}
+
+table {
+  border: 0em;
+}
+
+ .photo {
+  float: right;
+  margin-left:   1.5em;
+  margin-bottom: 1.5em;
+  margin-top: 0em;
+  max-width:      17em;
+  border:     1px solid gray;
+  padding:    3px;
+  background: white;
+}
+ .seperator {
+   padding-top: 2em;
+   clear: both;
+  }
+
+  #validators {
+      margin-top: 5em;
+      text-align: right;
+      color: #777;
+  }
+  @media print {
+      body {
+          font-size: 8pt;
+      }
+      .noprint {
+          display: none;
+      }
+  }
+
+
+.tip,
+.note {
+   background: #f0f0f2;
+   color: #333;
+   padding: 20px;
+   margin: 20px;
+}
+
+.tip h3,
+.note h3 {
+   padding: 0em;
+   margin: 0em;
+   font-size: 2em;
+   font-weight: bold;
+   color: #333;
+}
+
+.tip a,
+.note a {
+   color: #333;
+   text-decoration: underline;
+}
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
diff --git a/documentation/dev-manual/figures/app-dev-flow.png b/documentation/dev-manual/figures/app-dev-flow.png
new file mode 100644
index 0000000000..ec93374ee7
--- /dev/null
+++ b/documentation/dev-manual/figures/app-dev-flow.png
diff --git a/documentation/dev-manual/figures/bsp-dev-flow.png b/documentation/dev-manual/figures/bsp-dev-flow.png
new file mode 100644
index 0000000000..540b0abb9f
--- /dev/null
+++ b/documentation/dev-manual/figures/bsp-dev-flow.png
diff --git a/documentation/dev-manual/figures/dev-title.png b/documentation/dev-manual/figures/dev-title.png
new file mode 100644
index 0000000000..d3cac4a7e5
--- /dev/null
+++ b/documentation/dev-manual/figures/dev-title.png
diff --git a/documentation/dev-manual/figures/git-workflow.png b/documentation/dev-manual/figures/git-workflow.png
new file mode 100644
index 0000000000..e401330a12
--- /dev/null
+++ b/documentation/dev-manual/figures/git-workflow.png
diff --git a/documentation/dev-manual/figures/index-downloads.png b/documentation/dev-manual/figures/index-downloads.png
new file mode 100644
index 0000000000..41251d5d18
--- /dev/null
+++ b/documentation/dev-manual/figures/index-downloads.png
diff --git a/documentation/dev-manual/figures/kernel-dev-flow.png b/documentation/dev-manual/figures/kernel-dev-flow.png
new file mode 100644
index 0000000000..009105d122
--- /dev/null
+++ b/documentation/dev-manual/figures/kernel-dev-flow.png
diff --git a/documentation/dev-manual/figures/kernel-overview-1.png b/documentation/dev-manual/figures/kernel-overview-1.png
new file mode 100644
index 0000000000..116c0b9bd4
--- /dev/null
+++ b/documentation/dev-manual/figures/kernel-overview-1.png
diff --git a/documentation/dev-manual/figures/kernel-overview-2-generic.png b/documentation/dev-manual/figures/kernel-overview-2-generic.png
new file mode 100644
index 0000000000..889ff1bf0d
--- /dev/null
+++ b/documentation/dev-manual/figures/kernel-overview-2-generic.png
diff --git a/documentation/dev-manual/figures/recipe-workflow.png b/documentation/dev-manual/figures/recipe-workflow.png
new file mode 100644
index 0000000000..c0e960b13b
--- /dev/null
+++ b/documentation/dev-manual/figures/recipe-workflow.png
diff --git a/documentation/dev-manual/figures/source-repos.png b/documentation/dev-manual/figures/source-repos.png
new file mode 100644
index 0000000000..65c5f29a43
--- /dev/null
+++ b/documentation/dev-manual/figures/source-repos.png
diff --git a/documentation/dev-manual/figures/yp-download.png b/documentation/dev-manual/figures/yp-download.png
new file mode 100644
index 0000000000..5770be6883
--- /dev/null
+++ b/documentation/dev-manual/figures/yp-download.png
diff --git a/documentation/kernel-dev/figures/kernel-architecture-overview.png b/documentation/kernel-dev/figures/kernel-architecture-overview.png
new file mode 100755
index 0000000000..2aad172db3
--- /dev/null
+++ b/documentation/kernel-dev/figures/kernel-architecture-overview.png
diff --git a/documentation/kernel-dev/figures/kernel-dev-title.png b/documentation/kernel-dev/figures/kernel-dev-title.png
new file mode 100644
index 0000000000..7a8dd54372
--- /dev/null
+++ b/documentation/kernel-dev/figures/kernel-dev-title.png
diff --git a/documentation/kernel-dev/kernel-dev-advanced.xml b/documentation/kernel-dev/kernel-dev-advanced.xml
new file mode 100644
index 0000000000..283f483112
--- /dev/null
+++ b/documentation/kernel-dev/kernel-dev-advanced.xml
@@ -0,0 +1,1074 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='kernel-dev-advanced'>
+<title>Working with Advanced Metadata</title>
+
+<section id='kernel-dev-advanced-overview'>
+    <title>Overview</title>
+
+    <para>
+        In addition to supporting configuration fragments and patches, the
+        Yocto Project kernel tools also support rich
+        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> that you can
+        use to define complex policies and Board Support Package (BSP) support.
+        The purpose of the Metadata and the tools that manage it, known as
+        the kern-tools (<filename>kern-tools-native_git.bb</filename>), is
+        to help you manage the complexity of the configuration and sources
+        used to support multiple BSPs and Linux kernel types.
+    </para>
+</section>
+
+<section id='using-kernel-metadata-in-a-recipe'>
+    <title>Using Kernel Metadata in a Recipe</title>
+
+    <para>
+        The kernel sources in the Yocto Project contain kernel Metadata, which is
+        located in the <filename>meta</filename> branches of the kernel source
+        Git repositories.
+        This Metadata defines Board Support Packages (BSPs) that
+        correspond to definitions in linux-yocto recipes for the same BSPs.
+        A BSP consists of an aggregation of kernel policy and hardware-specific
+        feature enablements.
+        The BSP can be influenced from within the linux-yocto recipe.
+        <note>
+            Linux kernel source that contains kernel Metadata is said to be
+            "linux-yocto style" kernel source.
+            A Linux kernel recipe that inherits from the
+            <filename>linux-yocto.inc</filename> include file is said to be a
+            "linux-yocto style" recipe.
+        </note>
+    </para>
+
+    <para>
+        Every linux-yocto style recipe must define the
+        <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>
+        variable.
+        This variable is typically set to the same value as the
+        <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
+        variable, which is used by
+        <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>
+        (e.g. "edgerouter" or "fri2").
+        Multiple BSPs can reuse the same <filename>KMACHINE</filename>
+        name if they are built using the same BSP description.
+        The "fri2" and "fri2-noemgd" BSP combination
+        in the <filename>meta-intel</filename>
+        layer is a good example of two BSPs using the same
+        <filename>KMACHINE</filename> value (i.e. "fri2").
+        See the <link linkend='bsp-descriptions'>BSP Descriptions</link> section
+        for more information.
+    </para>
+
+    <para>
+        The linux-yocto style recipes can optionally define the following
+        variables:
+        <literallayout class='monospaced'>
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-KBRANCH'>KBRANCH</ulink>
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'>KERNEL_FEATURES</ulink>
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-KBRANCH_DEFAULT'>KBRANCH_DEFAULT</ulink>
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_KERNEL_TYPE'>LINUX_KERNEL_TYPE</ulink>
+        </literallayout>
+        <filename>KBRANCH_DEFAULT</filename> defines the Linux kernel source
+        repository's default branch to use to build the Linux kernel.
+        The value is used as the default for <filename>KBRANCH</filename>, which
+        can define an alternate branch typically with a machine override as
+        follows:
+        <literallayout class='monospaced'>
+     KBRANCH_fri2 = "standard/fri2"
+        </literallayout>
+        Unless you specify otherwise, <filename>KBRANCH_DEFAULT</filename>
+        initializes to "master".
+    </para>
+
+    <para>
+        <filename>LINUX_KERNEL_TYPE</filename> defines the kernel type to be
+        used in assembling the configuration.
+        If you do not specify a <filename>LINUX_KERNEL_TYPE</filename>,
+        it defaults to "standard".
+        Together with
+        <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>,
+        <filename>LINUX_KERNEL_TYPE</filename> defines the search
+        arguments used by the kernel tools to find the
+        appropriate description within the kernel Metadata with which to
+        build out the sources and configuration.
+        The linux-yocto recipes define "standard", "tiny", and "preempt-rt"
+        kernel types.
+        See the <link linkend='kernel-types'>Kernel Types</link> section
+        for more information on kernel types.
+    </para>
+
+    <para>
+        During the build, the kern-tools search for the BSP description
+        file that most closely matches the <filename>KMACHINE</filename>
+        and <filename>LINUX_KERNEL_TYPE</filename> variables passed in from the
+        recipe.
+        The tools use the first BSP description it finds that match
+        both variables.
+        If the tools cannot find a match, they issue a warning such as
+        the following:
+        <literallayout class='monospaced'>
+     WARNING: Can't find any BSP hardware or required configuration fragments.
+     WARNING: Looked at meta/cfg/broken/fri2-broken/hdw_frags.txt and
+              meta/cfg/broken/fri2-broken/required_frags.txt in directory:
+              meta/cfg/broken/fri2-broken
+        </literallayout>
+        In this example, <filename>KMACHINE</filename> was set to "fri2-broken"
+        and <filename>LINUX_KERNEL_TYPE</filename> was set to "broken".
+    </para>
+
+    <para>
+        The tools first search for the <filename>KMACHINE</filename> and
+        then for the <filename>LINUX_KERNEL_TYPE</filename>.
+        If the tools cannot find a partial match, they will use the
+        sources from the <filename>KBRANCH</filename> and any configuration
+        specified in the
+        <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>.
+    </para>
+
+    <para>
+        You can use the <filename>KERNEL_FEATURES</filename> variable
+        to include features (configuration fragments, patches, or both) that
+        are not already included by the <filename>KMACHINE</filename> and
+        <filename>LINUX_KERNEL_TYPE</filename> variable combination.
+        For example, to include a feature specified as "features/netfilter.scc",
+        specify:
+        <literallayout class='monospaced'>
+     KERNEL_FEATURES += "features/netfilter.scc"
+        </literallayout>
+        To include a feature called "cfg/sound.scc" just for the
+        <filename>qemux86</filename> machine, specify:
+        <literallayout class='monospaced'>
+     KERNEL_FEATURES_append_qemux86 = "cfg/sound.scc"
+        </literallayout>
+        The value of the entries in <filename>KERNEL_FEATURES</filename>
+        are dependent on their location within the kernel Metadata itself.
+        The examples here are taken from the
+        <filename>linux-yocto-3.4</filename> repository where "features"
+        and "cfg" are subdirectories within the
+        <filename>meta/cfg/kernel-cache</filename> directory.
+        For more information, see the
+        "<link linkend='kernel-metadata-syntax'>Kernel Metadata Syntax</link>" section.
+        <note>
+            The processing of the these variables has evolved some between the
+                0.9 and 1.3 releases of the Yocto Project and associated
+                kern-tools sources.
+            The descriptions in this section are accurate for 1.3 and later
+                releases of the Yocto Project.
+        </note>
+    </para>
+</section>
+
+<section id='kernel-metadata-location'>
+    <title>Kernel Metadata Location</title>
+
+    <para>
+        Kernel Metadata can be defined in either the kernel recipe
+        (recipe-space) or in the kernel tree (in-tree).
+        Where you choose to define the Metadata depends on what you want
+        to do and how you intend to work.
+        Regardless of where you define the kernel Metadata, the syntax used
+        applies equally.
+    </para>
+
+    <para>
+        If you are unfamiliar with the Linux kernel and only wish
+        to apply a configuration and possibly a couple of patches provided to
+        you by others, the recipe-space method is recommended.
+        This method is also a good approach if you are working with Linux kernel
+        sources you do not control or if you just do not want to maintain a
+        Linux kernel Git repository on your own.
+        For partial information on how you can define kernel Metadata in
+        the recipe-space, see the
+        "<link linkend='modifying-an-existing-recipe'>Modifying an Existing Recipe</link>"
+        section.
+    </para>
+
+    <para>
+        Conversely, if you are actively developing a kernel and are already
+        maintaining a Linux kernel Git repository of your own, you might find
+        it more convenient to work with the kernel Metadata in the same
+        repository as the Linux kernel sources.
+        This method can make iterative development of the Linux kernel
+        more efficient outside of the BitBake environment.
+    </para>
+
+    <section id='recipe-space-metadata'>
+        <title>Recipe-Space Metadata</title>
+
+        <para>
+            When stored in recipe-space, the kernel Metadata files reside in a
+            directory hierarchy below
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>.
+            For a linux-yocto recipe or for a Linux kernel recipe derived
+            by copying and modifying
+            <filename>oe-core/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb</filename>
+            to a recipe in your layer, <filename>FILESEXTRAPATHS</filename>
+            is typically set to
+            <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-THISDIR'><filename>THISDIR</filename></ulink><filename>}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>.
+            See the "<link linkend='modifying-an-existing-recipe'>Modifying an Existing Recipe</link>"
+            section for more information.
+        </para>
+
+        <para>
+            Here is an example that shows a trivial tree of kernel Metadata
+            stored in recipe-space within a BSP layer:
+            <literallayout class='monospaced'>
+     meta-<replaceable>my_bsp_layer</replaceable>/
+     `-- recipes-kernel
+         `-- linux
+             `-- linux-yocto
+                 |-- bsp-standard.scc
+                 |-- bsp.cfg
+                 `-- standard.cfg
+            </literallayout>
+        </para>
+
+        <para>
+            When the Metadata is stored in recipe-space, you must take
+            steps to ensure BitBake has the necessary information to decide
+            what files to fetch and when they need to be fetched again.
+            It is only necessary to specify the <filename>.scc</filename>
+            files on the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>.
+            BitBake parses them and fetches any files referenced in the
+            <filename>.scc</filename> files by the <filename>include</filename>,
+            <filename>patch</filename>, or <filename>kconf</filename> commands.
+            Because of this, it is necessary to bump the recipe
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>
+            value when changing the content of files not explicitly listed
+            in the <filename>SRC_URI</filename>.
+        </para>
+    </section>
+
+    <section id='in-tree-metadata'>
+        <title>In-Tree Metadata</title>
+
+        <para>
+            When stored in-tree, the kernel Metadata files reside in the
+            <filename>meta</filename> directory of the Linux kernel sources.
+            The <filename>meta</filename> directory can be present in the
+            same repository branch as the sources,
+            such as "master", or <filename>meta</filename> can be its own
+            orphan branch.
+            <note>
+                An orphan branch in Git is a branch with unique history and
+                content to the other branches in the repository.
+                Orphan branches are useful to track Metadata changes
+                independently from the sources of the Linux kernel, while
+                still keeping them together in the same repository.
+            </note>
+            For the purposes of this document, we will discuss all
+            in-tree Metadata as residing below the
+            <filename>meta/cfg/kernel-cache</filename> directory.
+        </para>
+
+        <para>
+            Following is an example that shows how a trivial tree of Metadata
+            is stored in a custom Linux kernel Git repository:
+            <literallayout class='monospaced'>
+     meta/
+     `-- cfg
+         `-- kernel-cache
+             |-- bsp-standard.scc
+             |-- bsp.cfg
+             `-- standard.cfg
+            </literallayout>
+        </para>
+
+        <para>
+            To use a branch different from where the sources reside,
+            specify the branch in the <filename>KMETA</filename> variable
+            in your Linux kernel recipe.
+            Here is an example:
+            <literallayout class='monospaced'>
+     KMETA = "meta"
+            </literallayout>
+            To use the same branch as the sources, set
+            <filename>KMETA</filename> to an empty string:
+            <literallayout class='monospaced'>
+     KMETA = ""
+            </literallayout>
+            If you are working with your own sources and want to create an
+            orphan <filename>meta</filename> branch, use these commands
+            from within your Linux kernel Git repository:
+            <literallayout class='monospaced'>
+     $ git checkout --orphan meta
+     $ git rm -rf .
+     $ git commit --allow-empty -m "Create orphan meta branch"
+            </literallayout>
+        </para>
+
+        <para>
+            If you modify the Metadata in the linux-yocto
+            <filename>meta</filename> branch, you must not forget to update
+            the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-SRCREV'><filename>SRCREV</filename></ulink>
+            statements in the kernel's recipe.
+            In particular, you need to update the
+            <filename>SRCREV_meta</filename> variable to match the commit in
+            the <filename>KMETA</filename> branch you wish to use.
+            Changing the data in these branches and not updating the
+            <filename>SRCREV</filename> statements to match will cause the
+            build to fetch an older commit.
+        </para>
+    </section>
+</section>
+
+<section id='kernel-metadata-syntax'>
+    <title>Kernel Metadata Syntax</title>
+
+    <para>
+        The kernel Metadata consists of three primary types of files:
+        <filename>scc</filename>
+        <footnote>
+            <para>
+                <filename>scc</filename> stands for Series Configuration
+                Control, but the naming has less significance in the
+                current implementation of the tooling than it had in the
+                past.
+                Consider <filename>scc</filename> files to be description files.
+            </para>
+        </footnote>
+        description files, configuration fragments, and patches.
+        The <filename>scc</filename> files define variables and include or
+        otherwise reference any of the three file types.
+        The description files are used to aggregate all types of kernel
+        Metadata into
+        what ultimately describes the sources and the configuration required
+        to build a Linux kernel tailored to a specific machine.
+    </para>
+
+    <para>
+        The <filename>scc</filename> description files are used to define two
+        fundamental types of kernel Metadata:
+        <itemizedlist>
+            <listitem><para>Features</para></listitem>
+            <listitem><para>Board Support Packages (BSPs)</para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        Features aggregate sources in the form of patches and configuration
+        fragments into a modular reusable unit.
+        You can use features to implement conceptually separate kernel
+        Metadata descriptions such as pure configuration fragments,
+        simple patches, complex features, and kernel types.
+        <link linkend='kernel-types'>Kernel types</link> define general
+        kernel features and policy to be reused in the BSPs.
+    </para>
+
+    <para>
+        BSPs define hardware-specific features and aggregate them with kernel
+        types to form the final description of what will be assembled and built.
+    </para>
+
+    <para>
+        While the kernel Metadata syntax does not enforce any logical
+        separation of configuration fragments, patches, features or kernel
+        types, best practices dictate a logical separation of these types
+        of Metadata.
+        The following Metadata file hierarchy is recommended:
+        <literallayout class='monospaced'>
+     <replaceable>base</replaceable>/
+        bsp/
+        cfg/
+        features/
+        ktypes/
+        patches/
+        </literallayout>
+    </para>
+
+    <para>
+        The <filename>bsp</filename> directory contains the
+        <link linkend='bsp-descriptions'>BSP descriptions</link>.
+        The remaining directories all contain "features".
+        Separating <filename>bsp</filename> from the rest of the structure
+        aids conceptualizing intended usage.
+    </para>
+
+    <para>
+        Use these guidelines to help place your <filename>scc</filename>
+        description files within the structure:
+        <itemizedlist>
+            <listitem><para>If your file contains
+                only configuration fragments, place the file in the
+                <filename>cfg</filename> directory.</para></listitem>
+            <listitem><para>If your file contains
+                only source-code fixes, place the file in the
+                <filename>patches</filename> directory.</para></listitem>
+            <listitem><para>If your file encapsulates
+                a major feature, often combining sources and configurations,
+                place the file in <filename>features</filename> directory.
+                </para></listitem>
+            <listitem><para>If your file aggregates
+                non-hardware configuration and patches in order to define a
+                base kernel policy or major kernel type to be reused across
+                multiple BSPs, place the file in <filename>ktypes</filename>
+                directory.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        These distinctions can easily become blurred - especially as
+        out-of-tree features slowly merge upstream over time.
+        Also, remember that how the description files are placed is
+        a purely logical organization and has no impact on the functionality
+        of the kernel Metadata.
+        There is no impact because all of <filename>cfg</filename>,
+        <filename>features</filename>, <filename>patches</filename>, and
+        <filename>ktypes</filename>, contain "features" as far as the kernel
+        tools are concerned.
+    </para>
+
+    <para>
+        Paths used in kernel Metadata files are relative to
+        <filename>&lt;base&gt;</filename>, which is either
+        <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+        if you are creating Metadata in
+        <link linkend='recipe-space-metadata'>recipe-space</link>,
+        or <filename>meta/cfg/kernel-cache/</filename> if you are creating
+        Metadata <link linkend='in-tree-metadata'>in-tree</link>.
+    </para>
+
+    <section id='configuration'>
+        <title>Configuration</title>
+
+        <para>
+            The simplest unit of kernel Metadata is the configuration-only
+            feature.
+            This feature consists of one or more Linux kernel configuration
+            parameters in a configuration fragment file
+            (<filename>.cfg</filename>) and an <filename>.scc</filename> file
+            that describes the fragment.
+        </para>
+
+        <para>
+            The Symmetric Multi-Processing (SMP) fragment included in the
+            <filename>linux-yocto-3.4</filename> Git repository
+            consists of the following two files:
+            <literallayout class='monospaced'>
+     cfg/smp.scc:
+        define KFEATURE_DESCRIPTION "Enable SMP"
+        kconf hardware smp.cfg
+
+     cfg/smp.cfg:
+        CONFIG_SMP=y
+        CONFIG_SCHED_SMT=y
+            </literallayout>
+            You can find information on configuration fragment files in the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-config-fragments'>Creating Configuration Fragments</ulink>"
+            section of the Yocto Project Development Manual and in
+            the "<link linkend='generating-configuration-files'>Generating Configuration Files</link>"
+            section earlier in this manual.
+        </para>
+
+        <para>
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-KFEATURE_DESCRIPTION'><filename>KFEATURE_DESCRIPTION</filename></ulink>
+            provides a short description of the fragment.
+            Higher level kernel tools use this description.
+        </para>
+
+        <para>
+            The <filename>kconf</filename> command is used to include the
+            actual configuration fragment in an <filename>.scc</filename>
+            file, and the "hardware" keyword identifies the fragment as
+            being hardware enabling, as opposed to general policy,
+            which would use the "non-hardware" keyword.
+            The distinction is made for the benefit of the configuration
+            validation tools, which warn you if a hardware fragment
+            overrides a policy set by a non-hardware fragment.
+            <note>
+                The description file can include multiple
+                <filename>kconf</filename> statements, one per fragment.
+            </note>
+        </para>
+
+        <para>
+            As described in the
+            "<link linkend='generating-configuration-files'>Generating Configuration Files</link>"
+            section, you can use the following BitBake command to audit your
+            configuration:
+            <literallayout class='monospaced'>
+     $ bitbake linux-yocto -c kernel_configcheck -f
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='patches'>
+        <title>Patches</title>
+
+        <para>
+            Patch descriptions are very similar to configuration fragment
+            descriptions, which are described in the previous section.
+            However, instead of a <filename>.cfg</filename> file, these
+            descriptions work with source patches.
+        </para>
+
+        <para>
+            A typical patch includes a description file and the patch itself:
+            <literallayout class='monospaced'>
+     patches/mypatch.scc:
+        patch mypatch.patch
+
+     patches/mypatch.patch:
+        <replaceable>typical-patch</replaceable>
+            </literallayout>
+            You can create the typical <filename>.patch</filename>
+            file using <filename>diff -Nurp</filename> or
+            <filename>git format-patch</filename>.
+        </para>
+
+        <para>
+            The description file can include multiple patch statements,
+            one per patch.
+        </para>
+    </section>
+
+    <section id='features'>
+        <title>Features</title>
+
+        <para>
+            Features are complex kernel Metadata types that consist
+            of configuration fragments (<filename>kconf</filename>), patches
+            (<filename>patch</filename>), and possibly other feature
+            description files (<filename>include</filename>).
+        </para>
+
+        <para>
+            Here is an example that shows a feature description file:
+            <literallayout class='monospaced'>
+     features/myfeature.scc
+        define KFEATURE_DESCRIPTION "Enable myfeature"
+
+        patch 0001-myfeature-core.patch
+        patch 0002-myfeature-interface.patch
+
+        include cfg/myfeature_dependency.scc
+        kconf non-hardware myfeature.cfg
+            </literallayout>
+            This example shows how the <filename>patch</filename> and
+            <filename>kconf</filename> commands are used as well as
+            how an additional feature description file is included.
+        </para>
+
+        <para>
+            Typically, features are less granular than configuration
+            fragments and are more likely than configuration fragments
+            and patches to be the types of things you want to specify
+            in the <filename>KERNEL_FEATURES</filename> variable of the
+            Linux kernel recipe.
+            See the "<link linkend='using-kernel-metadata-in-a-recipe'>Using Kernel Metadata in a Recipe</link>"
+            section earlier in the manual.
+        </para>
+    </section>
+
+    <section id='kernel-types'>
+        <title>Kernel Types</title>
+
+        <para>
+            A kernel type defines a high-level kernel policy by
+            aggregating non-hardware configuration fragments with
+            patches you want to use when building a Linux kernels of a
+            specific type.
+            Syntactically, kernel types are no different than features
+            as described in the "<link linkend='features'>Features</link>"
+            section.
+            The <filename>LINUX_KERNEL_TYPE</filename> variable in the kernel
+            recipe selects the kernel type.
+            See the "<link linkend='using-kernel-metadata-in-a-recipe'>Using Kernel Metadata in a Recipe</link>"
+            section for more information.
+        </para>
+
+        <para>
+            As an example, the <filename>linux-yocto-3.4</filename>
+            tree defines three kernel types: "standard",
+            "tiny", and "preempt-rt":
+            <itemizedlist>
+                <listitem><para>"standard":
+                    Includes the generic Linux kernel policy of the Yocto
+                    Project linux-yocto kernel recipes.
+                    This policy includes, among other things, which file
+                    systems, networking options, core kernel features, and
+                    debugging and tracing options are supported.
+                    </para></listitem>
+                <listitem><para>"preempt-rt":
+                    Applies the <filename>PREEMPT_RT</filename>
+                    patches and the configuration options required to
+                    build a real-time Linux kernel.
+                    This kernel type inherits from the "standard" kernel type.
+                    </para></listitem>
+                <listitem><para>"tiny":
+                    Defines a bare minimum configuration meant to serve as a
+                    base for very small Linux kernels.
+                    The "tiny" kernel type is independent from the "standard"
+                    configuration.
+                    Although the "tiny" kernel type does not currently include
+                    any source changes, it might in the future.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            The "standard" kernel type is defined by
+            <filename>standard.scc</filename>:
+            <literallayout class='monospaced'>
+     # Include this kernel type fragment to get the standard features and
+     # configuration values.
+
+     # Include all standard features
+     include standard-nocfg.scc
+
+     kconf non-hardware standard.cfg
+
+     # individual cfg block section
+     include cfg/fs/devtmpfs.scc
+     include cfg/fs/debugfs.scc
+     include cfg/fs/btrfs.scc
+     include cfg/fs/ext2.scc
+     include cfg/fs/ext3.scc
+     include cfg/fs/ext4.scc
+
+     include cfg/net/ipv6.scc
+     include cfg/net/ip_nf.scc
+     include cfg/net/ip6_nf.scc
+     include cfg/net/bridge.scc
+            </literallayout>
+        </para>
+
+        <para>
+            As with any <filename>.scc</filename> file, a
+            kernel type definition can aggregate other
+            <filename>.scc</filename> files with
+            <filename>include</filename> commands.
+            These definitions can also directly pull in
+            configuration fragments and patches with the
+            <filename>kconf</filename> and <filename>patch</filename>
+            commands, respectively.
+        </para>
+
+        <note>
+            It is not strictly necessary to create a kernel type
+            <filename>.scc</filename> file.
+            The Board Support Package (BSP) file can implicitly define
+            the kernel type using a <filename>define
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-KTYPE'>KTYPE</ulink> myktype</filename>
+            line.
+            See the "<link linkend='bsp-descriptions'>BSP Descriptions</link>"
+            section for more information.
+        </note>
+    </section>
+
+    <section id='bsp-descriptions'>
+        <title>BSP Descriptions</title>
+
+        <para>
+            BSP descriptions combine kernel types with hardware-specific
+            features.
+            The hardware-specific portion is typically defined
+            independently, and then aggregated with each supported kernel
+            type.
+            Consider this simple BSP description that supports the "mybsp"
+            machine:
+            <literallayout class='monospaced'>
+     mybsp.scc:
+        define KMACHINE mybsp
+        define KTYPE standard
+        define KARCH i386
+
+        kconf mybsp.cfg
+            </literallayout>
+            Every BSP description should define the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>,
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-KTYPE'><filename>KTYPE</filename></ulink>,
+            and <ulink url='&YOCTO_DOCS_REF_URL;#var-KARCH'><filename>KARCH</filename></ulink>
+            variables.
+            These variables allow the OpenEmbedded build system to identify
+            the description as meeting the criteria set by the recipe being
+            built.
+            This simple example supports the "mybsp" machine for the "standard"
+            kernel and the "i386" architecture.
+        </para>
+
+        <para>
+            Be aware that a hard link between the
+            <filename>KTYPE</filename> variable and a kernel type
+            description file does not exist.
+            Thus, if you do not have kernel types defined in your kernel
+            Metadata, you only need to ensure that the kernel recipe's
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_KERNEL_TYPE'><filename>LINUX_KERNEL_TYPE</filename></ulink>
+            variable and the <filename>KTYPE</filename> variable in the
+            BSP description file match.
+            <note>
+                Future versions of the tooling make the specification of
+                <filename>KTYPE</filename> in the BSP optional.
+            </note>
+        </para>
+
+        <para>
+            If you did want to separate your kernel policy from your
+            hardware configuration, you could do so by specifying a kernel
+            type, such as "standard" and including that description file
+            in the BSP description file.
+            See the "<link linkend='kernel-types'>Kernel Types</link>" section
+            for more information.
+        </para>
+
+        <para>
+            You might also have multiple hardware configurations that you
+            aggregate into a single hardware description file that you
+            could include in the BSP description file, rather than referencing
+            a single <filename>.cfg</filename> file.
+            Consider the following:
+            <literallayout class='monospaced'>
+     mybsp.scc:
+        define KMACHINE mybsp
+        define KTYPE standard
+        define KARCH i386
+
+        include standard.scc
+        include mybsp-hw.scc
+            </literallayout>
+        </para>
+
+        <para>
+            In the above example, <filename>standard.scc</filename>
+            aggregates all the configuration fragments, patches, and
+            features that make up your standard kernel policy whereas
+            <filename>mybsp-hw.scc</filename> aggregates all those necessary
+            to support the hardware available on the "mybsp" machine.
+            For information on how to break a complete
+            <filename>.config</filename> file into the various
+            configuration fragments, see the
+            "<link linkend='generating-configuration-files'>Generating Configuration Files</link>"
+            section.
+        </para>
+
+        <para>
+            Many real-world examples are more complex.
+            Like any other <filename>.scc</filename> file, BSP
+            descriptions can aggregate features.
+            Consider the Fish River Island 2 (fri2)
+            BSP definition from the <filename>linux-yocto-3.4</filename>
+            Git repository:
+            <literallayout class='monospaced'>
+     fri2.scc:
+        kconf hardware fri2.cfg
+
+        include cfg/x86.scc
+        include features/eg20t/eg20t.scc
+        include cfg/dmaengine.scc
+        include features/ericsson-3g/f5521gw.scc
+        include features/power/intel.scc
+        include cfg/efi.scc
+        include features/usb/ehci-hcd.scc
+        include features/usb/ohci-hcd.scc
+        include features/iwlwifi/iwlwifi.scc
+            </literallayout>
+        </para>
+
+        <para>
+            The <filename>fri2.scc</filename> description file includes
+            a hardware configuration fragment
+            (<filename>fri2.cfg</filename>) specific to the Fish River
+            Island 2 BSP as well as several more general configuration
+            fragments and features enabling hardware found on the
+            machine.
+            This description file is then included in each of the three
+            "fri2" description files for the supported kernel types
+            (i.e. "standard", "preempt-rt", and "tiny").
+            Consider the "fri2" description for the "standard" kernel
+            type:
+            <literallayout class='monospaced'>
+     fri2-standard.scc:
+        define KMACHINE fri2
+        define KTYPE standard
+        define KARCH i386
+
+        include ktypes/standard/standard.scc
+        branch fri2
+
+        git merge emgd-1.14
+
+        include fri2.scc
+
+        # Extra fri2 configs above the minimal defined in fri2.scc
+        include cfg/efi-ext.scc
+        include features/drm-emgd/drm-emgd.scc
+        include cfg/vesafb.scc
+
+        # default policy for standard kernels
+        include cfg/usb-mass-storage.scc
+            </literallayout>
+            The <filename>include</filename> command midway through the file
+            includes the <filename>fri2.scc</filename> description that
+            defines all hardware enablements for the BSP that is common to all
+            kernel types.
+            Using this command significantly reduces duplication.
+        </para>
+
+        <para>
+            This "fri2" standard description introduces a few more variables
+            and commands that are worth further discussion.
+            Notice the <filename>branch fri2</filename> command, which creates
+            a machine-specific branch into which source changes are applied.
+            With this branch set up, the <filename>git merge</filename> command
+            uses Git to merge in a feature branch named "emgd-1.14".
+            You could also handle this with the <filename>patch</filename>
+            command.
+            However, for commonly used features such as this, feature branches
+            are a convenient mechanism.
+            See the "<link linkend='feature-branches'>Feature Branches</link>"
+            section for more information.
+        </para>
+
+        <para>
+            Now consider the "fri2" description for the "tiny" kernel type:
+            <literallayout class='monospaced'>
+     fri2-tiny.scc:
+        define KMACHINE fri2
+        define KTYPE tiny
+        define KARCH i386
+
+        include ktypes/tiny/tiny.scc
+        branch fri2
+
+        include fri2.scc
+            </literallayout>
+            As you might expect, the "tiny" description includes quite a
+            bit less.
+            In fact, it includes only the minimal policy defined by the
+            "tiny" kernel type and the hardware-specific configuration required
+            for booting the machine along with the most basic functionality of
+            the system as defined in the base "fri2" description file.
+        </para>
+
+        <para>
+            Notice again the three critical variables:
+            <filename>KMACHINE</filename>, <filename>KTYPE</filename>,
+            and <filename>KARCH</filename>.
+            Of these variables, only the <filename>KTYPE</filename> has changed.
+            It is now set to "tiny".
+        </para>
+    </section>
+</section>
+
+<section id='organizing-your-source'>
+    <title>Organizing Your Source</title>
+
+    <para>
+        Many recipes based on the <filename>linux-yocto-custom.bb</filename>
+        recipe use Linux kernel sources that have only a single
+        branch - "master".
+        This type of repository structure is fine for linear development
+        supporting a single machine and architecture.
+        However, if you work with multiple boards and architectures,
+        a kernel source repository with multiple branches is more
+        efficient.
+        For example, suppose you need a series of patches for one board to boot.
+        Sometimes, these patches are works-in-progress or fundamentally wrong,
+        yet they are still necessary for specific boards.
+        In these situations, you most likely do not want to include these
+        patches in every kernel you build (i.e. have the patches as part of
+        the lone "master" branch).
+        It is situations like these that give rise to multiple branches used
+        within a Linux kernel sources Git repository.
+    </para>
+
+    <para>
+        Repository organization strategies exist that maximize source reuse,
+        remove redundancy, and logically order your changes.
+        This section presents strategies for the following cases:
+        <itemizedlist>
+            <listitem><para>Encapsulating patches in a feature description
+                and only including the patches in the BSP descriptions of
+                the applicable boards.</para></listitem>
+            <listitem><para>Creating a machine branch in your
+                kernel source repository and applying the patches on that
+                branch only.</para></listitem>
+            <listitem><para>Creating a feature branch in your
+                kernel source repository and merging that branch into your
+                BSP when needed.</para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        The approach you take is entirely up to you
+        and depends on what works best for your development model.
+    </para>
+
+    <section id='encapsulating-patches'>
+        <title>Encapsulating Patches</title>
+
+        <para>
+            if you are reusing patches from an external tree and are not
+            working on the patches, you might find the encapsulated feature
+            to be appropriate.
+            Given this scenario, you do not need to create any branches in the
+            source repository.
+            Rather, you just take the static patches you need and encapsulate
+            them within a feature description.
+            Once you have the feature description, you simply include that into
+            the BSP description as described in the
+            "<link linkend='bsp-descriptions'>BSP Descriptions</link>"
+            section.
+        </para>
+
+        <para>
+            You can find information on how to create patches and BSP
+            descriptions in the "<link linkend='patches'>Patches</link>" and
+            "<link linkend='bsp-descriptions'>BSP Descriptions</link>"
+            sections.
+        </para>
+    </section>
+
+    <section id='machine-branches'>
+        <title>Machine Branches</title>
+
+        <para>
+            When you have multiple machines and architectures to support,
+            or you are actively working on board support, it is more
+            efficient to create branches in the repository based on
+            individual machines.
+            Having machine branches allows common source to remain in the
+            "master" branch with any features specific to a machine stored
+            in the appropriate machine branch.
+            This organization method frees you from continually reintegrating
+            your patches into a feature.
+        </para>
+
+        <para>
+            Once you have a new branch, you can set up your kernel Metadata
+            to use the branch a couple different ways.
+            In the recipe, you can specify the new branch as the
+            <filename>KBRANCH</filename> to use for the board as
+            follows:
+            <literallayout class='monospaced'>
+     KBRANCH = "mynewbranch"
+            </literallayout>
+            Another method is to use the <filename>branch</filename> command
+            in the BSP description:
+            <literallayout class='monospaced'>
+     mybsp.scc:
+        define KMACHINE mybsp
+        define KTYPE standard
+        define KARCH i386
+        include standard.scc
+
+        branch mynewbranch
+
+        include mybsp-hw.scc
+            </literallayout>
+        </para>
+
+        <para>
+            If you find
+            yourself with numerous branches, you might consider using a
+            hierarchical branching system similar to what the linux-yocto Linux
+            kernel repositories use:
+            <literallayout class='monospaced'>
+     <replaceable>common</replaceable>/<replaceable>kernel_type</replaceable>/<replaceable>machine</replaceable>
+            </literallayout>
+        </para>
+
+        <para>
+            If you had two kernel types, "standard" and "small" for
+            instance, three machines, and <replaceable>common</replaceable>
+            as <filename>mydir</filename>, the branches in your
+            Git repository might look like this:
+            <literallayout class='monospaced'>
+     mydir/base
+     mydir/standard/base
+     mydir/standard/machine_a
+     mydir/standard/machine_b
+     mydir/standard/machine_c
+     mydir/small/base
+     mydir/small/machine_a
+            </literallayout>
+        </para>
+
+        <para>
+            This organization can help clarify the branch relationships.
+            In this case, <filename>mydir/standard/machine_a</filename>
+            includes everything in <filename>mydir/base</filename> and
+            <filename>mydir/standard/base</filename>.
+            The "standard" and "small" branches add sources specific to those
+            kernel types that for whatever reason are not appropriate for the
+            other branches.
+            <note>The "base" branches are an artifact of the way Git manages
+                its data internally on the filesystem: Git will not allow you
+                to use <filename>mydir/standard</filename> and
+                <filename>mydir/standard/machine_a</filename> because it
+                would have to create a file and a directory named "standard".
+            </note>
+        </para>
+    </section>
+
+    <section id='feature-branches'>
+        <title>Feature Branches</title>
+
+        <para>
+            When you are actively developing new features, it can be more
+            efficient to work with that feature as a branch, rather than
+            as a set of patches that have to be regularly updated.
+            The Yocto Project Linux kernel tools provide for this with
+            the <filename>git merge</filename> command.
+        </para>
+
+        <para>
+            To merge a feature branch into a BSP, insert the
+            <filename>git merge</filename> command after any
+            <filename>branch</filename> commands:
+            <literallayout class='monospaced'>
+     mybsp.scc:
+        define KMACHINE mybsp
+        define KTYPE standard
+        define KARCH i386
+        include standard.scc
+
+        branch mynewbranch
+        git merge myfeature
+
+        include mybsp-hw.scc
+            </literallayout>
+        </para>
+    </section>
+</section>
+
+<section id='scc-reference'>
+    <title>SCC Description File Reference</title>
+
+    <para>
+        This section provides a brief reference for the commands you can use
+        within an SCC description file (<filename>.scc</filename>):
+        <itemizedlist>
+            <listitem><para><filename>branch [ref]</filename>:
+                Creates a new branch relative to the current branch
+                (typically <filename>${KTYPE}</filename>) using
+                the currently checked-out branch, or "ref" if specified.
+                </para></listitem>
+            <listitem><para><filename>define</filename>:
+                Defines variables, such as <filename>KMACHINE</filename>,
+                <filename>KTYPE</filename>, <filename>KARCH</filename>,
+                and <filename>KFEATURE_DESCRIPTION</filename>.</para></listitem>
+            <listitem><para><filename>include SCC_FILE</filename>:
+                Includes an SCC file in the current file.
+                The file is parsed as if you had inserted it inline.
+                </para></listitem>
+            <listitem><para><filename>kconf [hardware|non-hardware] CFG_FILE</filename>:
+                Queues a configuration fragment for merging into the final
+                Linux <filename>.config</filename> file.</para></listitem>
+            <listitem><para><filename>git merge GIT_BRANCH</filename>:
+                Merges the feature branch into the current branch.
+                </para></listitem>
+            <listitem><para><filename>patch PATCH_FILE</filename>:
+                Applies the patch to the current Git branch.</para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/kernel-dev/kernel-dev-common.xml b/documentation/kernel-dev/kernel-dev-common.xml
new file mode 100644
index 0000000000..58cc98ddff
--- /dev/null
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -0,0 +1,915 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='kernel-dev-common'>
+
+<title>Common Tasks</title>
+
+<para>
+    This chapter presents several common tasks you perform when you
+    work with the Yocto Project Linux kernel.
+    These tasks include preparing a layer, modifying an existing recipe,
+    iterative development, working with your own sources, and incorporating
+    out-of-tree modules.
+    <note>
+        The examples presented in this chapter work with the Yocto Project
+        1.2.2 Release and forward.
+    </note>
+</para>
+
+    <section id='creating-and-preparing-a-layer'>
+        <title>Creating and Preparing a Layer</title>
+
+        <para>
+            If you are going to be modifying kernel recipes, it is recommended
+            that you create and prepare your own layer in which to do your
+            work.
+            Your layer contains its own
+            <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>
+            append files
+            (<filename>.bbappend</filename>) and provides a convenient
+            mechanism to create your own recipe files
+            (<filename>.bb</filename>).
+            For details on how to create and work with layers, see the following
+            sections in the Yocto Project Development Manual:
+            <itemizedlist>
+                <listitem><para>"<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>" for
+                    general information on layers and how to create layers.</para></listitem>
+                <listitem><para>"<ulink url='&YOCTO_DOCS_DEV_URL;#set-up-your-layer-for-the-build'>Set Up Your Layer for the Build</ulink>" for
+                    specific instructions on setting up a layer for kernel
+                    development.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='modifying-an-existing-recipe'>
+        <title>Modifying an Existing Recipe</title>
+
+        <para>
+            In many cases, you can customize an existing linux-yocto recipe to
+            meet the needs of your project.
+            Each release of the Yocto Project provides a few Linux
+            kernel recipes from which you can choose.
+            These are located in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            in <filename>meta/recipes-kernel/linux</filename>.
+        </para>
+
+        <para>
+            Modifying an existing recipe can consist of the following:
+            <itemizedlist>
+                <listitem><para>Creating the append file</para></listitem>
+                <listitem><para>Applying patches</para></listitem>
+                <listitem><para>Changing the configuration</para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            Before modifying an existing recipe, be sure that you have created
+            a minimal, custom layer from which you can work.
+            See the "<link linkend='creating-and-preparing-a-layer'>Creating and Preparing a Layer</link>"
+            section for some general resources.
+            You can also see the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#set-up-your-layer-for-the-build'>Set Up Your Layer for the Build</ulink>" section
+            of the Yocto Project Development Manual for a detailed
+            example.
+        </para>
+
+        <section id='creating-the-append-file'>
+            <title>Creating the Append File</title>
+
+            <para>
+                You create this file in your custom layer.
+                You also name it accordingly based on the linux-yocto recipe
+                you are using.
+                For example, if you are modifying the
+                <filename>meta/recipes-kernel/linux/linux-yocto_3.4.bb</filename>
+                recipe, the append file will typically be located as follows
+                within your custom layer:
+                <literallayout class='monospaced'>
+     <replaceable>your-layer</replaceable>/recipes-kernel/linux/linux-yocto_3.4.bbappend
+                </literallayout>
+                The append file should initially extend the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
+                search path by prepending the directory that contains your
+                files to the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+                variable as follows:
+                <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+                </literallayout>
+                The path <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-THISDIR'><filename>THISDIR</filename></ulink><filename>}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>
+                expands to "linux-yocto" in the current directory for this
+                example.
+                If you add any new files that modify the kernel recipe and you
+                have extended <filename>FILESPATH</filename> as
+                described above, you must place the files in your layer in the
+                following area:
+                <literallayout class='monospaced'>
+     <replaceable>your-layer</replaceable>/recipes-kernel/linux/linux-yocto/
+                </literallayout>
+                <note>If you are working on a new machine Board Support Package
+                    (BSP), be sure to refer to the
+                    <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
+                </note>
+            </para>
+        </section>
+
+        <section id='applying-patches'>
+            <title>Applying Patches</title>
+
+            <para>
+                If you have a single patch or a small series of patches
+                that you want to apply to the Linux kernel source, you
+                can do so just as you would with any other recipe.
+                You first copy the patches to the path added to
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+                in your <filename>.bbappend</filename> file as described in
+                the previous section, and then reference them in
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                statements.
+            </para>
+
+            <para>
+                For example, you can apply a three-patch series by adding the
+                following lines to your linux-yocto <filename>.bbappend</filename>
+                file in your layer:
+                <literallayout class='monospaced'>
+     SRC_URI += "file://0001-first-change.patch"
+     SRC_URI += "file://0002-first-change.patch"
+     SRC_URI += "file://0003-first-change.patch"
+                </literallayout>
+                The next time you run BitBake to build the Linux kernel, BitBake
+                detects the change in the recipe and fetches and applies the patches
+                before building the kernel.
+            </para>
+
+            <para>
+                For a detailed example showing how to patch the kernel, see the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#patching-the-kernel'>Patching the Kernel</ulink>"
+                section in the Yocto Project Development Manual.
+            </para>
+        </section>
+
+        <section id='changing-the-configuration'>
+            <title>Changing the Configuration</title>
+
+            <para>
+                You can make wholesale or incremental changes to the Linux
+                kernel <filename>.config</filename> file by including a
+                <filename>defconfig</filename> and by specifying
+                configuration fragments in the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>.
+            </para>
+
+            <para>
+                If you have a final Linux kernel <filename>.config</filename>
+                file you want to use, copy it to a directory named
+                <filename>files</filename>, which must be in
+                your layer's <filename>recipes-kernel/linux</filename>
+                directory, and name the file "defconfig".
+                Then, add the following lines to your linux-yocto
+                <filename>.bbappend</filename> file in your layer:
+                <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+     SRC_URI += "file://defconfig"
+                </literallayout>
+                The <filename>SRC_URI</filename> tells the build system how to
+                search for the file, while the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+                extends the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
+                variable (search directories) to include the
+                <filename>files</filename> directory you created for the
+                configuration changes.
+            </para>
+
+            <note>
+                The build system applies the configurations from the
+                <filename>.config</filename> file before applying any
+                subsequent configuration fragments.
+                The final kernel configuration is a combination of the
+                configurations in the <filename>.config</filename> file and
+                any configuration fragments you provide.
+                You need to realize that if you have any configuration
+                fragments, the build system applies these on top of and
+                after applying the existing <filename>.config</filename>
+                file configurations.
+            </note>
+
+            <para>
+                Generally speaking, the preferred approach is to determine the
+                incremental change you want to make and add that as a
+                configuration fragment.
+                For example, if you want to add support for a basic serial
+                console, create a file named <filename>8250.cfg</filename> in
+                the <filename>files</filename> directory with the following
+                content (without indentation):
+                <literallayout class='monospaced'>
+     CONFIG_SERIAL_8250=y
+     CONFIG_SERIAL_8250_CONSOLE=y
+     CONFIG_SERIAL_8250_PCI=y
+     CONFIG_SERIAL_8250_NR_UARTS=4
+     CONFIG_SERIAL_8250_RUNTIME_UARTS=4
+     CONFIG_SERIAL_CORE=y
+     CONFIG_SERIAL_CORE_CONSOLE=y
+                </literallayout>
+                Next, include this configuration fragment and extend the
+                <filename>FILESPATH</filename> variable in your
+                <filename>.bbappend</filename> file:
+                <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+     SRC_URI += "file://8250.cfg"
+                </literallayout>
+                The next time you run BitBake to build the Linux kernel, BitBake
+                detects the change in the recipe and fetches and applies the
+                new configuration before building the kernel.
+            </para>
+
+            <para>
+                For a detailed example showing how to configure the kernel,
+                see the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#configuring-the-kernel'>Configuring the Kernel</ulink>"
+                section in the Yocto Project Development Manual.
+            </para>
+        </section>
+    </section>
+
+    <section id='using-an-iterative-development-process'>
+        <title>Using an Iterative Development Process</title>
+
+        <para>
+            If you do not have existing patches or configuration files,
+            you can iteratively generate them from within the BitBake build
+            environment as described within this section.
+            During an iterative workflow, running a previously completed BitBake
+            task causes BitBake to invalidate the tasks that follow the
+            completed task in the build sequence.
+            Invalidated tasks rebuild the next time you run the build using
+            BitBake.
+        </para>
+
+        <para>
+            As you read this section, be sure to substitute the name
+            of your Linux kernel recipe for the term
+            "linux-yocto".
+        </para>
+
+        <section id='tip-dirty-string'>
+            <title>"-dirty" String</title>
+
+<!--
+            <para>
+                <emphasis>AR - Darren Hart:</emphasis>  This section
+                originated from the old Yocto Project Kernel Architecture
+                and Use Manual.
+                It was decided we need to put it in this section here.
+                Darren needs to figure out where we want it and what part
+                of it we want (all, revision???)
+            </para>
+-->
+
+            <para>
+                If kernel images are being built with "-dirty" on the
+                end of the version string, this simply means that
+                modifications in the source directory have not been committed.
+                <literallayout class='monospaced'>
+     $ git status
+                </literallayout>
+            </para>
+
+            <para>
+                You can use the above Git command to report modified,
+                removed, or added files.
+                You should commit those changes to the tree regardless of
+                whether they will be saved, exported, or used.
+                Once you commit the changes, you need to rebuild the kernel.
+            </para>
+
+            <para>
+                To force a pickup and commit of all such pending changes,
+                enter the following:
+                <literallayout class='monospaced'>
+     $ git add .
+     $ git commit -s -a -m "getting rid of -dirty"
+                </literallayout>
+            </para>
+
+            <para>
+                Next, rebuild the kernel.
+            </para>
+        </section>
+
+        <section id='generating-configuration-files'>
+            <title>Generating Configuration Files</title>
+
+            <para>
+                You can manipulate the <filename>.config</filename> file
+                used to build a linux-yocto recipe with the
+                <filename>menuconfig</filename> command as follows:
+                <literallayout class='monospaced'>
+     $ bitbake linux-yocto -c menuconfig
+                </literallayout>
+                This command starts the Linux kernel configuration tool,
+                which allows you to prepare a new
+                <filename>.config</filename> file for the build.
+                When you exit the tool, be sure to save your changes
+                at the prompt.
+            </para>
+
+            <para>
+                The resulting <filename>.config</filename> file is
+                located in
+                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink><filename>}</filename> under the
+                <filename>linux-${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink><filename>}-${<ulink url='&YOCTO_DOCS_REF_URL;#var-KTYPE'><filename>KTYPE</filename></ulink>}-build</filename> directory.
+                You can use the entire <filename>.config</filename> file as the
+                <filename>defconfig</filename> file as described in the
+                "<link linkend='changing-the-configuration'>Changing the Configuration</link>" section.
+            </para>
+
+            <para>
+                A better method is to create a configuration fragment using the
+                differences between two configuration files: one previously
+                created and saved, and one freshly created using the
+                <filename>menuconfig</filename> tool.
+            </para>
+
+            <para>
+                To create a configuration fragment using this method, follow
+                these steps:
+                <orderedlist>
+                    <listitem><para>Complete a build at least through the kernel
+                        configuration task as follows:
+                        <literallayout class='monospaced'>
+     $ bitbake linux-yocto -c kernel_configme -f
+                        </literallayout></para></listitem>
+                    <listitem><para>Run the <filename>menuconfig</filename>
+                        command:
+                        <literallayout class='monospaced'>
+     $ bitbake linux-yocto -c menuconfig
+                        </literallayout></para></listitem>
+                    <listitem><para>Run the <filename>diffconfig</filename>
+                        command to prepare a configuration fragment.
+                        The resulting file <filename>fragment.cfg</filename>
+                        will be placed in the
+                        <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink><filename>}</filename> directory:
+                        <literallayout class='monospaced'>
+     $ bitbake linux-yocto -c diffconfig
+                        </literallayout></para></listitem>
+                </orderedlist>
+            </para>
+
+            <para>
+                The <filename>diffconfig</filename> command creates a file that is a
+                list of Linux kernel <filename>CONFIG_</filename> assignments.
+                See the "<link linkend='changing-the-configuration'>Changing the Configuration</link>"
+                section for information on how to use the output as a
+                configuration fragment.
+                <note>
+                    You can also use this method to create configuration
+                    fragments for a BSP.
+                    See the "<link linkend='bsp-descriptions'>BSP Descriptions</link>"
+                    section for more information.
+                </note>
+            </para>
+
+            <para>
+                The kernel tools also provide configuration validation.
+                You can use these tools to produce warnings for when a
+                requested configuration does not appear in the final
+                <filename>.config</filename> file or when you override a
+                policy configuration in a hardware configuration fragment.
+                Here is an example with some sample output of the command
+                that runs these tools:
+                <literallayout class='monospaced'>
+     $ bitbake linux-yocto -c kernel_configcheck -f
+
+     ...
+
+     NOTE: validating kernel configuration
+     This BSP sets 3 invalid/obsolete kernel options.
+     These config options are not offered anywhere within this kernel.
+     The full list can be found in your kernel src dir at:
+     meta/cfg/standard/mybsp/invalid.cfg
+
+     This BSP sets 21 kernel options that are possibly non-hardware related.
+     The full list can be found in your kernel src dir at:
+     meta/cfg/standard/mybsp/specified_non_hdw.cfg
+
+     WARNING: There were 2 hardware options requested that do not
+              have a corresponding value present in the final ".config" file.
+              This probably means you are not't getting the config you wanted.
+              The full list can be found in your kernel src dir at:
+              meta/cfg/standard/mybsp/mismatch.cfg
+                </literallayout>
+            </para>
+
+            <para>
+                The output describes the various problems that you can
+                encounter along with where to find the offending configuration
+                items.
+                You can use the information in the logs to adjust your
+                configuration files and then repeat the
+                <filename>kernel_configme</filename> and
+                <filename>kernel_configcheck</filename> commands until
+                they produce no warnings.
+            </para>
+
+            <para>
+                For more information on how to use the
+                <filename>menuconfig</filename> tool, see the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#using-menuconfig'>Using <filename>menuconfig</filename></ulink>"
+                section in the Yocto Project Development Manual.
+            </para>
+        </section>
+
+        <section id='modifying-source-code'>
+            <title>Modifying Source Code</title>
+
+            <para>
+                You can experiment with source code changes and create a
+                simple patch without leaving the BitBake environment.
+                To get started, be sure to complete a build at
+                least through the kernel configuration task:
+                <literallayout class='monospaced'>
+     $ bitbake linux-yocto -c kernel_configme -f
+                </literallayout>
+                Taking this step ensures you have the sources prepared
+                and the configuration completed.
+                You can find the sources in the
+                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink><filename>}/linux</filename> directory.
+            </para>
+
+            <para>
+                You can edit the sources as you would any other Linux source
+                tree.
+                However, keep in mind that you will lose changes if you
+                trigger the
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-fetch'><filename>do_fetch</filename></ulink>
+                task for the recipe.
+                You can avoid triggering this task by not using BitBake to
+                run the
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-cleanall'><filename>cleanall</filename></ulink>,
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-cleansstate'><filename>cleansstate</filename></ulink>,
+                or forced
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-fetch'><filename>fetch</filename></ulink>
+                commands.
+                Also, do not modify the recipe itself while working
+                with temporary changes or BitBake might run the
+                <filename>fetch</filename> command depending on the
+                changes to the recipe.
+            </para>
+
+            <para>
+                To test your temporary changes, instruct BitBake to run the
+                <filename>compile</filename> again.
+                The <filename>-f</filename> option forces the command to run
+                even though BitBake might think it has already done so:
+                <literallayout class='monospaced'>
+     $ bitbake linux-yocto -c compile -f
+                </literallayout>
+                If the compile fails, you can update the sources and repeat
+                the <filename>compile</filename>.
+                Once compilation is successful, you can inspect and test
+                the resulting build (i.e. kernel, modules, and so forth) from
+                the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
+                <literallayout class='monospaced'>
+     ${WORKDIR}/linux-${MACHINE}-${KTYPE}-build
+                </literallayout>
+                Alternatively, you can run the <filename>deploy</filename>
+                command to place the kernel image in the
+                <filename>tmp/deploy/images</filename> directory:
+                <literallayout class='monospaced'>
+        $ bitbake linux-yocto -c deploy
+                </literallayout>
+                And, of course, you can perform the remaining installation and
+                packaging steps by issuing:
+                <literallayout class='monospaced'>
+        $ bitbake linux-yocto
+                </literallayout>
+            </para>
+
+            <para>
+                For rapid iterative development, the edit-compile-repeat loop
+                described in this section is preferable to rebuilding the
+                entire recipe because the installation and packaging tasks
+                are very time consuming.
+            </para>
+
+            <para>
+                Once you are satisfied with your source code modifications,
+                you can make them permanent by generating patches and
+                applying them to the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                statement as described in the
+                "<link linkend='applying-patches'>Applying Patches</link>"
+                section.
+                If you are not familiar with generating patches, refer to the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-the-patch'>Creating the Patch</ulink>"
+                section in the Yocto Project Development Manual.
+            </para>
+        </section>
+    </section>
+
+    <section id='working-with-your-own-sources'>
+        <title>Working With Your Own Sources</title>
+
+        <para>
+            If you cannot work with one of the Linux kernel
+            versions supported by existing linux-yocto recipes, you can
+            still make use of the Yocto Project Linux kernel tooling by
+            working with your own sources.
+            When you use your own sources, you will not be able to
+            leverage the existing kernel
+            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> and
+            stabilization work of the linux-yocto sources.
+            However, you will be able to manage your own Metadata in the same
+            format as the linux-yocto sources.
+            Maintaining format compatibility facilitates converging with
+            linux-yocto on a future, mutually-supported kernel version.
+        </para>
+
+        <para>
+            To help you use your own sources, the Yocto Project provides a
+            linux-yocto custom recipe
+            (<filename>linux-yocto-custom.bb</filename>) that uses
+            <filename>kernel.org</filename> sources
+            and the Yocto Project Linux kernel tools for managing
+            kernel Metadata.
+            You can find this recipe in the
+            <filename>poky</filename> Git repository of the
+            Yocto Project <ulink url='&YOCTO_GIT_URL;'>Source Repository</ulink>
+            at:
+            <literallayout class="monospaced">
+     poky/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
+            </literallayout>
+        </para>
+
+        <para>
+            Here are some basic steps you can use to work with your own sources:
+            <orderedlist>
+                <listitem><para>Copy the <filename>linux-yocto-custom.bb</filename>
+                    recipe to your layer and give it a meaningful name.
+                    The name should include the version of the Linux kernel you
+                    are using (e.g. <filename>linux-yocto-myproject_3.5.bb</filename>,
+                    where "3.5" is the base version of the Linux kernel
+                    with which you would be working).</para></listitem>
+                <listitem><para>In the same directory inside your layer,
+                    create a matching directory
+                    to store your patches and configuration files (e.g.
+                    <filename>linux-yocto-myproject</filename>).
+                    </para></listitem>
+                <listitem><para>Edit the following variables in your recipe
+                    as appropriate for your project:
+                    <itemizedlist>
+                        <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>:
+                            The <filename>SRC_URI</filename> should be a Git
+                            repository that uses one of the supported Git fetcher
+                            protocols (i.e. <filename>file</filename>,
+                            <filename>git</filename>, <filename>http</filename>,
+                            and so forth).
+                            The skeleton recipe provides an example
+                            <filename>SRC_URI</filename> as a syntax reference.
+                            </para></listitem>
+                        <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_VERSION'><filename>LINUX_VERSION</filename></ulink>:
+                            The Linux kernel version you are using (e.g.
+                            "3.4").</para></listitem>
+                        <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_VERSION_EXTENSION'><filename>LINUX_VERSION_EXTENSION</filename></ulink>:
+                            The Linux kernel <filename>CONFIG_LOCALVERSION</filename>
+                            that is compiled into the resulting kernel and visible
+                            through the <filename>uname</filename> command.
+                            </para></listitem>
+                        <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-SRCREV'><filename>SRCREV</filename></ulink>:
+                            The commit ID from which you want to build.
+                            </para></listitem>
+                        <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>:
+                            Treat this variable the same as you would in any other
+                            recipe.
+                            Increment the variable to indicate to the OpenEmbedded
+                            build system that the recipe has changed.
+                            </para></listitem>
+                        <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>:
+                            The default <filename>PV</filename> assignment is
+                            typically adequate.
+                            It combines the <filename>LINUX_VERSION</filename>
+                            with the Source Control Manager (SCM) revision
+                            as derived from the
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-SRCPV'><filename>SRCPV</filename></ulink>
+                            variable.
+                            The combined results are a string with
+                            the following form:
+                            <literallayout class='monospaced'>
+     3.4.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2
+                            </literallayout>
+                            While lengthy, the extra verbosity in <filename>PV</filename>
+                            helps ensure you are using the exact
+                            sources from which you intend to build.
+                            </para></listitem>
+                        <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></ulink>:
+                            A list of the machines supported by your new recipe.
+                            This variable in the example recipe is set
+                            by default to a regular expression that matches
+                            only the empty string, "(^$)".
+                            This default setting triggers an explicit build
+                            failure.
+                            You must change it to match a list of the machines
+                            that your new recipe supports.
+                            For example, to support the <filename>qemux86</filename>
+                            and <filename>qemux86-64</filename> machines, use
+                            the following form:
+                            <literallayout class='monospaced'>
+     COMPATIBLE_MACHINE = "qemux86|qemux86-64"
+                            </literallayout></para></listitem>
+                    </itemizedlist></para></listitem>
+                <listitem><para>Provide further customizations to your recipe
+                    as needed just as you would customize an existing
+                    linux-yocto recipe.
+                    See the "<link linkend='modifying-an-existing-recipe'>Modifying
+                    an Existing Recipe</link>" section for information.
+                    </para></listitem>
+            </orderedlist>
+        </para>
+    </section>
+
+    <section id='working-with-out-of-tree-modules'>
+        <title>Working with Out-of-Tree Modules</title>
+
+        <para>
+            This section describes steps to build out-of-tree modules on
+            your target and describes how to incorporate out-of-tree modules
+            in the build.
+        </para>
+
+        <section id='building-out-of-tree-modules-on-the-target'>
+            <title>Building Out-of-Tree Modules on the Target</title>
+
+            <para>
+                If you want to be able to build out-of-tree modules on
+                the target, there are some steps you need to take
+                on the target that is running your SDK image.
+                Briefly, the <filename>kernel-dev</filename> package
+                is installed by default on all
+                <filename>*.sdk</filename> images.
+                However, you need to create some scripts prior to
+                attempting to build the out-of-tree modules on the target
+                that is running that image.
+            </para>
+
+            <para>
+                Prior to attempting to build the out-of-tree modules,
+                you need to be on the target as root and you need to
+                change to the <filename>/usr/src/kernel</filename> directory.
+                Next, <filename>make</filename> the scripts:
+                <literallayout class='monospaced'>
+     # cd /usr/src/kernel
+     # make scripts
+                </literallayout>
+                Because all SDK image recipes include
+                <filename>dev-pkgs</filename>, the
+                <filename>kernel-dev</filename> packages will be installed
+                as part of the SDK image.
+                The SDK uses the scripts when building out-of-tree
+                modules.
+                Once you have switched to that directory and created the
+                scripts, you should be able to build your out-of-tree modules
+                on the target.
+            </para>
+        </section>
+
+        <section id='incorporating-out-of-tree-modules'>
+            <title>Incorporating Out-of-Tree Modules</title>
+
+            <para>
+                While it is always preferable to work with sources integrated
+                into the Linux kernel sources, if you need an external kernel
+                module, the <filename>hello-mod.bb</filename> recipe is
+                available as a template from which you can create your
+                own out-of-tree Linux kernel module recipe.
+            </para>
+
+            <para>
+                This template recipe is located in the
+                <filename>poky</filename> Git repository of the
+                Yocto Project <ulink url='&YOCTO_GIT_URL;'>Source Repository</ulink>
+                at:
+                <literallayout class="monospaced">
+     poky/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb
+                </literallayout>
+            </para>
+
+            <para>
+                To get started, copy this recipe to your layer and give it a
+                meaningful name (e.g. <filename>mymodule_1.0.bb</filename>).
+                In the same directory, create a new directory named
+                <filename>files</filename> where you can store any source files,
+                patches, or other files necessary for building
+                the module that do not come with the sources.
+                Finally, update the recipe as needed for the module.
+                Typically, you will need to set the following variables:
+                <itemizedlist>
+                    <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-DESCRIPTION'><filename>DESCRIPTION</filename></ulink>
+                        </para></listitem>
+                    <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE'><filename>LICENSE*</filename></ulink>
+                        </para></listitem>
+                    <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                        </para></listitem>
+                    <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                Depending on the build system used by the module sources,
+                you might need to make some adjustments.
+                For example, a typical module <filename>Makefile</filename>
+                looks much like the one provided with the
+                <filename>hello-mod</filename> template:
+                <literallayout class='monospaced'>
+     obj-m := hello.o
+
+     SRC := $(shell pwd)
+
+     all:
+         $(MAKE) -C $(KERNEL_SRC) M=$(SRC)
+
+     modules_install:
+         $(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install
+     ...
+                </literallayout>
+            </para>
+
+            <para>
+                The important point to note here is the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_SRC'><filename>KERNEL_SRC</filename></ulink>
+                variable.
+                The
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-module'><filename>module</filename></ulink>
+                class sets this variable and the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_PATH'><filename>KERNEL_PATH</filename></ulink>
+                variable to
+                <filename>${<ulink url='&YOCTO_DOCS_REF_URL;#var-STAGING_KERNEL_DIR'><filename>STAGING_KERNEL_DIR</filename></ulink>}</filename>
+                with the necessary Linux kernel build information to build
+                modules.
+                If your module <filename>Makefile</filename> uses a different
+                variable, you might want to override the
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-compile'><filename>do_compile()</filename></ulink>
+                step, or create a patch to
+                the <filename>Makefile</filename> to work with the more typical
+                <filename>KERNEL_SRC</filename> or
+                <filename>KERNEL_PATH</filename> variables.
+            </para>
+
+            <para>
+                After you have prepared your recipe, you will likely want to
+                include the module in your images.
+                To do this, see the documentation for the following variables in
+                the Yocto Project Reference Manual and set one of them
+                appropriately for your machine configuration file:
+                <itemizedlist>
+                    <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'><filename>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</filename></ulink>
+                        </para></listitem>
+                    <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><filename>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</filename></ulink>
+                        </para></listitem>
+                    <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_EXTRA_RDEPENDS'><filename>MACHINE_EXTRA_RDEPENDS</filename></ulink>
+                        </para></listitem>
+                    <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_EXTRA_RRECOMMENDS'><filename>MACHINE_EXTRA_RRECOMMENDS</filename></ulink>
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                Modules are often not required for boot and can be excluded from
+                certain build configurations.
+                The following allows for the most flexibility:
+                <literallayout class='monospaced'>
+     MACHINE_EXTRA_RRECOMMENDS += "kernel-module-mymodule"
+                </literallayout>
+                The value is derived by appending the module filename without
+                the <filename>.ko</filename> extension to the string
+                "kernel-module-".
+            </para>
+
+            <para>
+                Because the variable is
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS'><filename>RRECOMMENDS</filename></ulink>
+                and not a
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-RDEPENDS'><filename>RDEPENDS</filename></ulink>
+                variable, the build will not fail if this module is not
+                available to include in the image.
+            </para>
+        </section>
+    </section>
+
+
+    <section id='inspecting-changes-and-commits'>
+        <title>Inspecting Changes and Commits</title>
+
+        <para>
+            A common question when working with a kernel is:
+            "What changes have been applied to this tree?"
+            Rather than using "grep" across directories to see what has
+            changed, you can use Git to inspect or search the kernel tree.
+            Using Git is an efficient way to see what has changed in the tree.
+        </para>
+
+        <section id='what-changed-in-a-kernel'>
+            <title>What Changed in a Kernel?</title>
+
+            <para>
+                Following are a few examples that show how to use Git
+                commands to examine changes.
+                These examples are by no means the only way to see changes.
+                <note>
+                    In the following examples, unless you provide a commit
+                    range, <filename>kernel.org</filename> history is blended
+                    with Yocto Project kernel changes.
+                    You can form ranges by using branch names from the
+                    kernel tree as the upper and lower commit markers with
+                    the Git commands.
+                    You can see the branch names through the web interface
+                    to the Yocto Project source repositories at
+                    <ulink url='http://git.yoctoproject.org/cgit.cgi'></ulink>.
+                </note>
+                To see a full range of the changes, use the
+                <filename>git whatchanged</filename> command and specify a
+                commit range for the branch
+                (<filename>&lt;commit&gt;..&lt;commit&gt;</filename>).
+            </para>
+
+            <para>
+                Here is an example that looks at what has changed in the
+                <filename>emenlow</filename> branch of the
+                <filename>linux-yocto-3.4</filename> kernel.
+                The lower commit range is the commit associated with the
+                <filename>standard/base</filename> branch, while
+                the upper commit range is the commit associated with the
+                <filename>standard/emenlow</filename> branch.
+                <literallayout class='monospaced'>
+     $ git whatchanged origin/standard/base..origin/standard/emenlow
+                </literallayout>
+            </para>
+
+            <para>
+                To see short, one line summaries of changes use the
+                <filename>git log</filename> command:
+                <literallayout class='monospaced'>
+     $ git log --oneline origin/standard/base..origin/standard/emenlow
+                </literallayout>
+            </para>
+
+            <para>
+                Use this command to see code differences for the changes:
+                <literallayout class='monospaced'>
+     $ git diff origin/standard/base..origin/standard/emenlow
+                </literallayout>
+            </para>
+
+            <para>
+                Use this command to see the commit log messages and the
+                text differences:
+                <literallayout class='monospaced'>
+     $ git show origin/standard/base..origin/standard/emenlow
+                </literallayout>
+            </para>
+
+            <para>
+                Use this command to create individual patches for
+                each change.
+                Here is an example that that creates patch files for each
+                commit and places them in your <filename>Documents</filename>
+                directory:
+                <literallayout class='monospaced'>
+     $ git format-patch -o $HOME/Documents origin/standard/base..origin/standard/emenlow
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='showing-a-particular-feature-or-branch-change'>
+            <title>Showing a Particular Feature or Branch Change</title>
+
+            <para>
+                Tags in the Yocto Project kernel tree divide changes for
+                significant features or branches.
+                The <filename>git show &lt;tag&gt;</filename> command shows
+                changes based on a tag.
+                Here is an example that shows <filename>systemtap</filename>
+                changes:
+                <literallayout class='monospaced'>
+     $ git show systemtap
+                </literallayout>
+                You can use the
+                <filename>git branch --contains &lt;tag&gt;</filename> command
+                to show the branches that contain a particular feature.
+                This command shows the branches that contain the
+                <filename>systemtap</filename> feature:
+                <literallayout class='monospaced'>
+     $ git branch --contains systemtap
+                </literallayout>
+            </para>
+        </section>
+    </section>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/kernel-dev/kernel-dev-concepts-appx.xml b/documentation/kernel-dev/kernel-dev-concepts-appx.xml
new file mode 100644
index 0000000000..ac91749cd6
--- /dev/null
+++ b/documentation/kernel-dev/kernel-dev-concepts-appx.xml
@@ -0,0 +1,253 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<appendix id='kernel-dev-concepts-appx'>
+<title>Advanced Kernel Concepts</title>
+
+    <section id='kernel-big-picture'>
+        <title>Yocto Project Kernel Development and Maintenance</title>
+        <para>
+            Kernels available through the Yocto Project, like other kernels, are based off the Linux
+            kernel releases from <ulink url='http://www.kernel.org'></ulink>.
+            At the beginning of a major development cycle, the Yocto Project team
+            chooses its kernel based on factors such as release timing, the anticipated release
+            timing of final upstream <filename>kernel.org</filename> versions, and Yocto Project
+            feature requirements.
+            Typically, the kernel chosen is in the
+            final stages of development by the community.
+            In other words, the kernel is in the release
+            candidate or "rc" phase and not yet a final release.
+            But, by being in the final stages of external development, the team knows that the
+            <filename>kernel.org</filename> final release will clearly be within the early stages of
+            the Yocto Project development window.
+        </para>
+        <para>
+            This balance allows the team to deliver the most up-to-date kernel
+            possible, while still ensuring that the team has a stable official release for
+            the baseline Linux kernel version.
+        </para>
+        <para>
+            The ultimate source for kernels available through the Yocto Project are released kernels
+            from <filename>kernel.org</filename>.
+            In addition to a foundational kernel from <filename>kernel.org</filename>, the
+            kernels available contain a mix of important new mainline
+            developments, non-mainline developments (when there is no alternative),
+            Board Support Package (BSP) developments,
+            and custom features.
+            These additions result in a commercially released Yocto Project Linux kernel that caters
+            to specific embedded designer needs for targeted hardware.
+        </para>
+        <para>
+            Once a kernel is officially released, the Yocto Project team goes into
+            their next development cycle, or upward revision (uprev) cycle, while still
+            continuing maintenance on the released kernel.
+            It is important to note that the most sustainable and stable way
+            to include feature development upstream is through a kernel uprev process.
+            Back-porting hundreds of individual fixes and minor features from various
+            kernel versions is not sustainable and can easily compromise quality.
+        </para>
+        <para>
+            During the uprev cycle, the Yocto Project team uses an ongoing analysis of
+            kernel development, BSP support, and release timing to select the best
+            possible <filename>kernel.org</filename> version.
+            The team continually monitors community kernel
+            development to look for significant features of interest.
+            The team does consider back-porting large features if they have a significant advantage.
+            User or community demand can also trigger a back-port or creation of new
+            functionality in the Yocto Project baseline kernel during the uprev cycle.
+        </para>
+        <para>
+            Generally speaking, every new kernel both adds features and introduces new bugs.
+            These consequences are the basic properties of upstream kernel development and are
+            managed by the Yocto Project team's kernel strategy.
+            It is the Yocto Project team's policy to not back-port minor features to the released kernel.
+            They only consider back-porting significant technological jumps - and, that is done
+            after a complete gap analysis.
+            The reason for this policy is that back-porting any small to medium sized change
+            from an evolving kernel can easily create mismatches, incompatibilities and very
+            subtle errors.
+        </para>
+        <para>
+            These policies result in both a stable and a cutting
+            edge kernel that mixes forward ports of existing features and significant and critical
+            new functionality.
+            Forward porting functionality in the kernels available through the Yocto Project kernel
+            can be thought of as a "micro uprev."
+            The many “micro uprevs” produce a kernel version with a mix of
+            important new mainline, non-mainline, BSP developments and feature integrations.
+            This kernel gives insight into new features and allows focused
+            amounts of testing to be done on the kernel, which prevents
+            surprises when selecting the next major uprev.
+            The quality of these cutting edge kernels is evolving and the kernels are used in leading edge
+            feature and BSP development.
+        </para>
+    </section>
+
+    <section id='kernel-architecture'>
+        <title>Kernel Architecture</title>
+        <para>
+            This section describes the architecture of the kernels available through the
+            Yocto Project and provides information
+            on the mechanisms used to achieve that architecture.
+        </para>
+
+        <section id='architecture-overview'>
+            <title>Overview</title>
+            <para>
+                As mentioned earlier, a key goal of the Yocto Project is to present the
+                developer with
+                a kernel that has a clear and continuous history that is visible to the user.
+                The architecture and mechanisms used achieve that goal in a manner similar to the
+                upstream <filename>kernel.org</filename>.
+            </para>
+            <para>
+                You can think of a Yocto Project kernel as consisting of a baseline Linux kernel with
+                added features logically structured on top of the baseline.
+                The features are tagged and organized by way of a branching strategy implemented by the
+                source code manager (SCM) Git.
+                For information on Git as applied to the Yocto Project, see the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>" section in the
+                Yocto Project Development Manual.
+            </para>
+            <para>
+                The result is that the user has the ability to see the added features and
+                the commits that make up those features.
+                In addition to being able to see added features, the user can also view the history of what
+                made up the baseline kernel.
+            </para>
+            <para>
+                The following illustration shows the conceptual Yocto Project kernel.
+            </para>
+            <para>
+                <imagedata fileref="figures/kernel-architecture-overview.png" width="6in" depth="7in" align="center" scale="100" />
+            </para>
+            <para>
+                In the illustration, the "Kernel.org Branch Point"
+                marks the specific spot (or release) from
+                which the Yocto Project kernel is created.
+                From this point "up" in the tree, features and differences are organized and tagged.
+            </para>
+            <para>
+                The "Yocto Project Baseline Kernel" contains functionality that is common to every kernel
+                type and BSP that is organized further up the tree.
+                Placing these common features in the
+                tree this way means features do not have to be duplicated along individual branches of the
+                structure.
+            </para>
+            <para>
+                From the Yocto Project Baseline Kernel, branch points represent specific functionality
+                for individual BSPs as well as real-time kernels.
+                The illustration represents this through three BSP-specific branches and a real-time
+                kernel branch.
+                Each branch represents some unique functionality for the BSP or a real-time kernel.
+            </para>
+            <para>
+                In this example structure, the real-time kernel branch has common features for all
+                real-time kernels and contains
+                more branches for individual BSP-specific real-time kernels.
+                The illustration shows three branches as an example.
+                Each branch points the way to specific, unique features for a respective real-time
+                kernel as they apply to a given BSP.
+            </para>
+            <para>
+                The resulting tree structure presents a clear path of markers (or branches) to the
+                developer that, for all practical purposes, is the kernel needed for any given set
+                of requirements.
+            </para>
+        </section>
+
+        <section id='branching-and-workflow'>
+            <title>Branching Strategy and Workflow</title>
+            <para>
+                The Yocto Project team creates kernel branches at points where functionality is
+                no longer shared and thus, needs to be isolated.
+                For example, board-specific incompatibilities would require different functionality
+                and would require a branch to separate the features.
+                Likewise, for specific kernel features, the same branching strategy is used.
+            </para>
+            <para>
+                This branching strategy results in a tree that has features organized to be specific
+                for particular functionality, single kernel types, or a subset of kernel types.
+                This strategy also results in not having to store the same feature twice
+                internally in the tree.
+                Rather, the kernel team stores the unique differences required to apply the
+                feature onto the kernel type in question.
+                <note>
+                    The Yocto Project team strives to place features in the tree such that they can be
+                    shared by all boards and kernel types where possible.
+                    However, during development cycles or when large features are merged,
+                    the team cannot always follow this practice.
+                    In those cases, the team uses isolated branches to merge features.
+                </note>
+            </para>
+            <para>
+                BSP-specific code additions are handled in a similar manner to kernel-specific additions.
+                Some BSPs only make sense given certain kernel types.
+                So, for these types, the team creates branches off the end of that kernel type for all
+                of the BSPs that are supported on that kernel type.
+                From the perspective of the tools that create the BSP branch, the BSP is really no
+                different than a feature.
+                Consequently, the same branching strategy applies to BSPs as it does to features.
+                So again, rather than store the BSP twice, the team only stores the unique
+                differences for the BSP across the supported multiple kernels.
+            </para>
+            <para>
+                While this strategy can result in a tree with a significant number of branches, it is
+                important to realize that from the developer's point of view, there is a linear
+                path that travels from the baseline <filename>kernel.org</filename>, through a select
+                group of features and ends with their BSP-specific commits.
+                In other words, the divisions of the kernel are transparent and are not relevant
+                to the developer on a day-to-day basis.
+                From the developer's perspective, this path is the "master" branch.
+                The developer does not need to be aware of the existence of any other branches at all.
+                Of course, there is value in the existence of these branches
+                in the tree, should a person decide to explore them.
+                For example, a comparison between two BSPs at either the commit level or at the line-by-line
+                code <filename>diff</filename> level is now a trivial operation.
+            </para>
+            <para>
+                Working with the kernel as a structured tree follows recognized community best practices.
+                In particular, the kernel as shipped with the product, should be
+                considered an "upstream source" and viewed as a series of
+                historical and documented modifications (commits).
+                These modifications represent the development and stabilization done
+                by the Yocto Project kernel development team.
+            </para>
+            <para>
+                Because commits only change at significant release points in the product life cycle,
+                developers can work on a branch created
+                from the last relevant commit in the shipped Yocto Project kernel.
+                As mentioned previously, the structure is transparent to the developer
+                because the kernel tree is left in this state after cloning and building the kernel.
+            </para>
+        </section>
+
+        <section id='source-code-manager-git'>
+            <title>Source Code Manager - Git</title>
+            <para>
+                The Source Code Manager (SCM) is Git.
+                This SCM is the obvious mechanism for meeting the previously mentioned goals.
+                Not only is it the SCM for <filename>kernel.org</filename> but,
+                Git continues to grow in popularity and supports many different work flows,
+                front-ends and management techniques.
+            </para>
+            <para>
+                You can find documentation on Git at <ulink url='http://git-scm.com/documentation'></ulink>.
+                You can also get an introduction to Git as it applies to the Yocto Project in the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>"
+                section in the Yocto Project Development Manual.
+                These referenced sections overview Git and describe a minimal set of
+                commands that allows you to be functional using Git.
+                <note>
+                    You can use as much, or as little, of what Git has to offer to accomplish what
+                    you need for your project.
+                    You do not have to be a "Git Master" in order to use it with the Yocto Project.
+                </note>
+            </para>
+        </section>
+    </section>
+</appendix>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/kernel-dev/kernel-dev-customization.xsl b/documentation/kernel-dev/kernel-dev-customization.xsl
new file mode 100644
index 0000000000..8676d66c3a
--- /dev/null
+++ b/documentation/kernel-dev/kernel-dev-customization.xsl
@@ -0,0 +1,18 @@
+<?xml version='1.0'?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
+
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
+
+  <xsl:include href="../template/permalinks.xsl"/>
+  <xsl:include href="../template/section.title.xsl"/>
+  <xsl:include href="../template/component.title.xsl"/>
+  <xsl:include href="../template/division.title.xsl"/>
+  <xsl:include href="../template/formal.object.heading.xsl"/>
+
+  <xsl:param name="html.stylesheet" select="'kernel-dev-style.css'" />
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="appendix.autolabel">A</xsl:param>
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+
+</xsl:stylesheet>
diff --git a/documentation/kernel-dev/kernel-dev-eclipse-customization.xsl b/documentation/kernel-dev/kernel-dev-eclipse-customization.xsl
new file mode 100644
index 0000000000..7d1bb8dc08
--- /dev/null
+++ b/documentation/kernel-dev/kernel-dev-eclipse-customization.xsl
@@ -0,0 +1,27 @@
+<?xml version='1.0'?>
+<xsl:stylesheet
+        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+        xmlns="http://www.w3.org/1999/xhtml"
+        xmlns:fo="http://www.w3.org/1999/XSL/Format"
+        version="1.0">
+
+  <xsl:import
+          href="http://docbook.sourceforge.net/release/xsl/current/eclipse/eclipse3.xsl" />
+
+  <xsl:param name="chunker.output.indent" select="'yes'"/>
+  <xsl:param name="chunk.quietly" select="1"/>
+  <xsl:param name="chunk.first.sections" select="1"/>
+  <xsl:param name="chunk.section.depth" select="10"/>
+  <xsl:param name="use.id.as.filename" select="1"/>
+  <xsl:param name="ulink.target" select="'_self'" />
+  <xsl:param name="base.dir" select="'html/kernel-dev/'"/>
+  <xsl:param name="html.stylesheet" select="'../book.css'"/>
+  <xsl:param name="eclipse.manifest" select="0"/>
+  <xsl:param name="create.plugin.xml" select="0"/>
+  <xsl:param name="suppress.navigation" select="1"/>
+  <xsl:param name="generate.index" select="0"/>
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="appendix.autolabel">A</xsl:param>
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+</xsl:stylesheet>
diff --git a/documentation/kernel-dev/kernel-dev-examples.xml b/documentation/kernel-dev/kernel-dev-examples.xml
new file mode 100644
index 0000000000..9d9aef6d06
--- /dev/null
+++ b/documentation/kernel-dev/kernel-dev-examples.xml
@@ -0,0 +1,918 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='kernel-how-to'>
+
+<title>Working with the Yocto Project Kernel</title>
+
+
+<section id='actions-org'>
+    <title>Introduction</title>
+    <para>
+        This chapter describes how to accomplish tasks involving a kernel's tree structure.
+        The information is designed to help the developer that wants to modify the Yocto
+        Project kernel and contribute changes upstream to the Yocto Project.
+        The information covers the following:
+        <itemizedlist>
+            <listitem><para>Tree construction</para></listitem>
+            <listitem><para>Build strategies</para></listitem>
+            <listitem><para>Workflow examples</para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+    <section id='tree-construction'>
+        <title>Tree Construction</title>
+        <para>
+            This section describes construction of the Yocto Project kernel source repositories
+            as accomplished by the Yocto Project team to create kernel repositories.
+            These kernel repositories are found under the heading "Yocto Linux Kernel" at
+            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>&YOCTO_GIT_URL;/cgit.cgi</ulink>
+            and can be shipped as part of a Yocto Project release.
+            The team creates these repositories by
+            compiling and executing the set of feature descriptions for every BSP/feature
+            in the product.
+            Those feature descriptions list all necessary patches,
+            configuration, branching, tagging and feature divisions found in a kernel.
+            Thus, the Yocto Project kernel repository (or tree) is built.
+        </para>
+        <para>
+            The existence of this tree allows you to access and clone a particular
+            Yocto Project kernel repository and use it to build images based on their configurations
+            and features.
+        </para>
+        <para>
+            You can find the files used to describe all the valid features and BSPs
+            in the Yocto Project kernel in any clone of the Yocto Project kernel source repository
+            Git tree.
+            For example, the following command clones the Yocto Project baseline kernel that
+            branched off of <filename>linux.org</filename> version 3.4:
+            <literallayout class='monospaced'>
+     $ git clone git://git.yoctoproject.org/linux-yocto-3.4
+            </literallayout>
+            For another example of how to set up a local Git repository of the Yocto Project
+            kernel files, see the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Yocto Project Kernel</ulink>" bulleted
+            item in the Yocto Project Development Manual.
+        </para>
+        <para>
+            Once you have cloned the kernel Git repository on your local machine, you can
+            switch to the <filename>meta</filename> branch within the repository.
+            Here is an example that assumes the local Git repository for the kernel is in
+            a top-level directory named <filename>linux-yocto-3.4</filename>:
+            <literallayout class='monospaced'>
+     $ cd ~/linux-yocto-3.4
+     $ git checkout -b meta origin/meta
+            </literallayout>
+            Once you have checked out and switched to the <filename>meta</filename> branch,
+            you can see a snapshot of all the kernel configuration and feature descriptions that are
+            used to build that particular kernel repository.
+            These descriptions are in the form of <filename>.scc</filename> files.
+        </para>
+        <para>
+            You should realize, however, that browsing your local kernel repository
+            for feature descriptions and patches is not an effective way to determine what is in a
+            particular kernel branch.
+            Instead, you should use Git directly to discover the changes in a branch.
+            Using Git is an efficient and flexible way to inspect changes to the kernel.
+            For examples showing how to use Git to inspect kernel commits, see the following sections
+            in this chapter.
+            <note>
+                Ground up reconstruction of the complete kernel tree is an action only taken by the
+                Yocto Project team during an active development cycle.
+                When you create a clone of the kernel Git repository, you are simply making it
+                efficiently available for building and development.
+            </note>
+        </para>
+        <para>
+            The following steps describe what happens when the Yocto Project Team constructs
+            the Yocto Project kernel source Git repository (or tree) found at
+            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink> given the
+            introduction of a new top-level kernel feature or BSP.
+            These are the actions that effectively create the tree
+            that includes the new feature, patch or BSP:
+            <orderedlist>
+                <listitem><para>A top-level kernel feature is passed to the kernel build subsystem.
+                    Normally, this feature is a BSP for a particular kernel type.</para></listitem>
+                <listitem><para>The file that describes the top-level feature is located by searching
+                    these system directories:
+                    <itemizedlist>
+                        <listitem><para>The in-tree kernel-cache directories, which are located
+                            in <filename>meta/cfg/kernel-cache</filename></para></listitem>
+                        <listitem><para>Areas pointed to by <filename>SRC_URI</filename> statements
+                            found in recipes</para></listitem>
+                    </itemizedlist>
+                    For a typical build, the target of the search is a
+                    feature description in an <filename>.scc</filename> file
+                    whose name follows this format:
+                    <literallayout class='monospaced'>
+     &lt;bsp_name&gt;-&lt;kernel_type&gt;.scc
+                    </literallayout>
+                </para></listitem>
+                <listitem><para>Once located, the feature description is either compiled into a simple script
+                    of actions, or into an existing equivalent script that is already part of the
+                    shipped kernel.</para></listitem>
+                <listitem><para>Extra features are appended to the top-level feature description.
+                    These features can come from the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink>
+                    variable in recipes.</para></listitem>
+                <listitem><para>Each extra feature is located, compiled and appended to the script
+                    as described in step three.</para></listitem>
+                <listitem><para>The script is executed to produce a series of <filename>meta-*</filename>
+                    directories.
+                    These directories are descriptions of all the branches, tags, patches and configurations that
+                    need to be applied to the base Git repository to completely create the
+                    source (build) branch for the new BSP or feature.</para></listitem>
+                <listitem><para>The base repository is cloned, and the actions
+                    listed in the <filename>meta-*</filename> directories are applied to the
+                    tree.</para></listitem>
+                <listitem><para>The Git repository is left with the desired branch checked out and any
+                    required branching, patching and tagging has been performed.</para></listitem>
+            </orderedlist>
+        </para>
+        <para>
+            The kernel tree is now ready for developer consumption to be locally cloned,
+            configured, and built into a Yocto Project kernel specific to some target hardware.
+            <note><para>The generated <filename>meta-*</filename> directories add to the kernel
+                as shipped with the Yocto Project release.
+                Any add-ons and configuration data are applied to the end of an existing branch.
+                The full repository generation that is found in the
+                official Yocto Project kernel repositories at
+                <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>http://git.yoctoproject.org/cgit.cgi</ulink>
+                is the combination of all supported boards and configurations.</para>
+                <para>The technique the Yocto Project team uses is flexible and allows for seamless
+                blending of an immutable history with additional patches specific to a
+                deployment.
+                Any additions to the kernel become an integrated part of the branches.</para>
+            </note>
+        </para>
+    </section>
+
+    <section id='build-strategy'>
+        <title>Build Strategy</title>
+        <para>
+            Once a local Git repository of the Yocto Project kernel exists on a development system,
+            you can consider the compilation phase of kernel development - building a kernel image.
+            Some prerequisites exist that are validated by the build process before compilation
+            starts:
+        </para>
+
+        <itemizedlist>
+            <listitem><para>The
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> points
+                to the kernel Git repository.</para></listitem>
+            <listitem><para>A BSP build branch exists.
+                This branch has the following form:
+                <literallayout class='monospaced'>
+     &lt;kernel_type&gt;/&lt;bsp_name&gt;
+                </literallayout></para></listitem>
+        </itemizedlist>
+
+        <para>
+            The OpenEmbedded build system makes sure these conditions exist before attempting compilation.
+            Other means, however, do exist, such as as bootstrapping a BSP, see
+            the "<link linkend='workflow-examples'>Workflow Examples</link>".
+        </para>
+
+        <para>
+            Before building a kernel, the build process verifies the tree
+            and configures the kernel by processing all of the
+            configuration "fragments" specified by feature descriptions in the <filename>.scc</filename>
+            files.
+            As the features are compiled, associated kernel configuration fragments are noted
+            and recorded in the <filename>meta-*</filename> series of directories in their compilation order.
+            The fragments are migrated, pre-processed and passed to the Linux Kernel
+            Configuration subsystem (<filename>lkc</filename>) as raw input in the form
+            of a <filename>.config</filename> file.
+            The <filename>lkc</filename> uses its own internal dependency constraints to do the final
+            processing of that information and generates the final <filename>.config</filename> file
+            that is used during compilation.
+        </para>
+
+        <para>
+            Using the board's architecture and other relevant values from the board's template,
+            kernel compilation is started and a kernel image is produced.
+        </para>
+
+        <para>
+            The other thing that you notice once you configure a kernel is that
+            the build process generates a build tree that is separate from your kernel's local Git
+            source repository tree.
+            This build tree has a name that uses the following form, where
+            <filename>${MACHINE}</filename> is the metadata name of the machine (BSP) and "kernel_type" is one
+            of the Yocto Project supported kernel types (e.g. "standard"):
+        <literallayout class='monospaced'>
+     linux-${MACHINE}-&lt;kernel_type&gt;-build
+        </literallayout>
+        </para>
+
+        <para>
+            The existing support in the <filename>kernel.org</filename> tree achieves this
+            default functionality.
+        </para>
+
+        <para>
+            This behavior means that all the generated files for a particular machine or BSP are now in
+            the build tree directory.
+            The files include the final <filename>.config</filename> file, all the <filename>.o</filename>
+            files, the <filename>.a</filename> files, and so forth.
+            Since each machine or BSP has its own separate build directory in its own separate branch
+            of the Git repository, you can easily switch between different builds.
+        </para>
+    </section>
+
+    <section id='workflow-examples'>
+        <title>Workflow Examples</title>
+
+        <para>
+            As previously noted, the Yocto Project kernel has built-in Git integration.
+            However, these utilities are not the only way to work with the kernel repository.
+            The Yocto Project has not made changes to Git or to other tools that
+            would invalidate alternate workflows.
+            Additionally, the way the kernel repository is constructed results in using
+            only core Git functionality, thus allowing any number of tools or front ends to use the
+            resulting tree.
+        </para>
+
+        <para>
+            This section contains several workflow examples.
+            Many of the examples use Git commands.
+            You can find Git documentation at
+            <ulink url='http://git-scm.com/documentation'></ulink>.
+            You can find a simple overview of using Git with the Yocto Project in the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>"
+            section of the Yocto Project Development Manual.
+        </para>
+
+        <section id='change-inspection-kernel-changes-commits'>
+            <title>Change Inspection: Changes/Commits</title>
+
+            <para>
+                A common question when working with a kernel is:
+                "What changes have been applied to this tree?"
+            </para>
+
+            <para>
+                In projects that have a collection of directories that
+                contain patches to the kernel, it is possible to inspect or "grep" the contents
+                of the directories to get a general feel for the changes.
+                This sort of patch inspection is not an efficient way to determine what has been
+                done to the kernel.
+                The reason it is inefficient is because there are many optional patches that are
+                selected based on the kernel type and the feature description.
+                Additionally, patches could exist in directories that are not included in the search.
+            </para>
+
+            <para>
+                A more efficient way to determine what has changed in the branch is to use
+                Git and inspect or search the kernel tree.
+                This method gives you a full view of not only the source code modifications,
+                but also provides the reasons for the changes.
+            </para>
+
+            <section id='what-changed-in-a-kernel'>
+                <title>What Changed in a Kernel?</title>
+
+                <para>
+                    Following are a few examples that show how to use Git commands to examine changes.
+                    Because Git repositories in the Yocto Project do not break existing Git
+                    functionality, and because there exists many permutations of these types of
+                    Git commands, many methods exist by which you can discover changes.
+                    <note>
+                        In the following examples, unless you provide a commit range,
+                        <filename>kernel.org</filename> history is blended with Yocto Project
+                        kernel changes.
+                        You can form ranges by using branch names from the kernel tree as the
+                        upper and lower commit markers with the Git commands.
+                        You can see the branch names through the web interface to the
+                        Yocto Project source repositories at
+                        <ulink url='http://git.yoctoproject.org/cgit.cgi'></ulink>.
+                        For example, the branch names for the <filename>linux-yocto-3.4</filename>
+                        kernel repository can be seen at
+                        <ulink url='http://git.yoctoproject.org/cgit.cgi/linux-yocto-3.4/refs/heads'></ulink>.
+                    </note>
+                    To see a full range of the changes, use the
+                    <filename>git whatchanged</filename> command and specify a commit range
+                    for the branch (<filename>&lt;commit&gt;..&lt;commit&gt;</filename>).
+                </para>
+
+                <para>
+                    Here is an example that looks at what has changed in the
+                    <filename>emenlow</filename> branch of the
+                    <filename>linux-yocto-3.4</filename> kernel.
+                    The lower commit range is the commit associated with the
+                    <filename>standard/base</filename> branch, while
+                    the upper commit range is the commit associated with the
+                    <filename>standard/emenlow</filename> branch.
+                    <literallayout class='monospaced'>
+     $ git whatchanged origin/standard/base..origin/standard/emenlow
+                    </literallayout>
+                </para>
+
+                <para>
+                    To see a summary of changes use the <filename>git log</filename> command.
+                    Here is an example using the same branches:
+                    <literallayout class='monospaced'>
+     $ git log --oneline origin/standard/base..origin/standard/emenlow
+                    </literallayout>
+                    The <filename>git log</filename> output might be more useful than
+                    the <filename>git whatchanged</filename> as you get
+                    a short, one-line summary of each change and not the entire commit.
+                </para>
+
+                <para>
+                    If you want to see code differences associated with all the changes, use
+                    the <filename>git diff</filename> command.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     $ git diff origin/standard/base..origin/standard/emenlow
+                    </literallayout>
+                </para>
+
+                <para>
+                    You can see the commit log messages and the text differences using the
+                    <filename>git show</filename> command:
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     $ git show origin/standard/base..origin/standard/emenlow
+                    </literallayout>
+                </para>
+
+                <para>
+                    You can create individual patches for each change by using the
+                    <filename>git format-patch</filename> command.
+                    Here is an example that that creates patch files for each commit and
+                    places them in your <filename>Documents</filename> directory:
+                    <literallayout class='monospaced'>
+     $ git format-patch -o $HOME/Documents origin/standard/base..origin/standard/emenlow
+                    </literallayout>
+                </para>
+            </section>
+
+            <section id='show-a-particular-feature-or-branch-change'>
+                <title>Show a Particular Feature or Branch Change</title>
+
+                <para>
+                    Developers use tags in the Yocto Project kernel tree to divide changes for significant
+                    features or branches.
+                    Once you know a particular tag, you can use Git commands
+                    to show changes associated with the tag and find the branches that contain
+                    the feature.
+                    <note>
+                        Because BSP branch, <filename>kernel.org</filename>, and feature tags are all
+                        present, there could be many tags.
+                    </note>
+                    The <filename>git show &lt;tag&gt;</filename> command shows changes that are tagged by
+                    a feature.
+                    Here is an example that shows changes tagged by the <filename>systemtap</filename>
+                    feature:
+                    <literallayout class='monospaced'>
+     $ git show systemtap
+                    </literallayout>
+                    You can use the <filename>git branch --contains &lt;tag&gt;</filename> command
+                    to show the branches that contain a particular feature.
+                    This command shows the branches that contain the <filename>systemtap</filename>
+                    feature:
+                    <literallayout class='monospaced'>
+     $ git branch --contains systemtap
+                    </literallayout>
+                </para>
+
+                <para>
+                    You can use many other comparisons to isolate BSP and kernel changes.
+                    For example, you can compare against <filename>kernel.org</filename> tags
+                    such as the <filename>v3.4</filename> tag.
+                </para>
+            </section>
+        </section>
+
+        <section id='development-saving-kernel-modifications'>
+            <title>Development: Saving Kernel Modifications</title>
+
+            <para>
+                Another common operation is to build a BSP supplied by the Yocto Project, make some
+                changes, rebuild, and then test.
+                Those local changes often need to be exported, shared or otherwise maintained.
+            </para>
+
+            <para>
+                Since the Yocto Project kernel source tree is backed by Git, this activity is
+                much easier as compared to with previous releases.
+                Because Git tracks file modifications, additions and deletions, it is easy
+                to modify the code and later realize that you need to save the changes.
+                It is also easy to determine what has changed.
+                This method also provides many tools to commit, undo and export those modifications.
+            </para>
+
+            <para>
+                This section and its sub-sections, describe general application of Git's
+                <filename>push</filename> and <filename>pull</filename> commands, which are used to
+                get your changes upstream or source your code from an upstream repository.
+                The Yocto Project provides scripts that help you work in a collaborative development
+                environment.
+                For information on these scripts, see the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#pushing-a-change-upstream'>Using Scripts to Push a Change
+                Upstream and Request a Pull</ulink>" and
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#submitting-a-patch'>Using Email to Submit a Patch</ulink>"
+                sections in the Yocto Project Development Manual.
+            </para>
+
+            <para>
+                There are many ways to save kernel modifications.
+                The technique employed
+                depends on the destination for the patches:
+
+                <itemizedlist>
+                    <listitem><para>Bulk storage</para></listitem>
+                    <listitem><para>Internal sharing either through patches or by using Git</para></listitem>
+                    <listitem><para>External submissions</para></listitem>
+                    <listitem><para>Exporting for integration into another Source Code
+                        Manager (SCM)</para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                Because of the following list of issues, the destination of the patches also influences
+                the method for gathering them:
+
+                <itemizedlist>
+                    <listitem><para>Bisectability</para></listitem>
+                    <listitem><para>Commit headers</para></listitem>
+                    <listitem><para>Division of subsystems for separate submission or review</para></listitem>
+                </itemizedlist>
+            </para>
+
+            <section id='bulk-export'>
+                <title>Bulk Export</title>
+
+                <para>
+                    This section describes how you can "bulk" export changes that have not
+                    been separated or divided.
+                    This situation works well when you are simply storing patches outside of the kernel
+                    source repository, either permanently or temporarily, and you are not committing
+                    incremental changes during development.
+                    <note>
+                        This technique is not appropriate for full integration of upstream submission
+                        because changes are not properly divided and do not provide an avenue for per-change
+                        commit messages.
+                        Therefore, this example assumes that changes have not been committed incrementally
+                        during development and that you simply must gather and export them.
+                    </note>
+                    <literallayout class='monospaced'>
+     # bulk export of ALL modifications without separation or division
+     # of the changes
+
+     $ git add .
+     $ git commit -s -a -m &lt;msg&gt;
+        or
+     $ git commit -s -a # and interact with $EDITOR
+                    </literallayout>
+                </para>
+
+                <para>
+                    The previous operations capture all the local changes in the project source
+                    tree in a single Git commit.
+                    And, that commit is also stored in the project's source tree.
+                </para>
+
+                <para>
+                    Once the changes are exported, you can restore them manually using a template
+                    or through integration with the <filename>default_kernel</filename>.
+                </para>
+
+            </section>
+
+            <section id='incremental-planned-sharing'>
+                <title>Incremental/Planned Sharing</title>
+
+                <para>
+                    This section describes how to save modifications when you are making incremental
+                    commits or practicing planned sharing.
+                    The examples in this section assume that you have incrementally committed
+                    changes to the tree during development and now need to export them.
+                    The sections that follow
+                    describe how you can export your changes internally through either patches or by
+                    using Git commands.
+                </para>
+
+                <para>
+                    During development, the following commands are of interest.
+                    For full Git documentation, refer to the Git documentation at
+                    <ulink url='http://github.com'></ulink>.
+
+                    <literallayout class='monospaced'>
+     # edit a file
+     $ vi &lt;path&gt;/file
+     # stage the change
+     $ git add &lt;path&gt;/file
+     # commit the change
+     $ git commit -s
+     # remove a file
+     $ git rm &lt;path&gt;/file
+     # commit the change
+     $ git commit -s
+
+     ... etc.
+                    </literallayout>
+                </para>
+
+                <para>
+                    Distributed development with Git is possible when you use a universally
+                    agreed-upon unique commit identifier (set by the creator of the commit) that maps to a
+                    specific change set with a specific parent.
+                    This identifier is created for you when
+                    you create a commit, and is re-created when you amend, alter or re-apply
+                    a commit.
+                    As an individual in isolation, this is of no interest.
+                    However, if you
+                    intend to share your tree with normal Git <filename>push</filename> and
+                    <filename>pull</filename> operations for
+                    distributed development, you should consider the ramifications of changing a
+                    commit that you have already shared with others.
+                </para>
+
+                <para>
+                    Assuming that the changes have not been pushed upstream, or pulled into
+                    another repository, you can update both the commit content and commit messages
+                    associated with development by using the following commands:
+
+                    <literallayout class='monospaced'>
+     $ Git add &lt;path&gt;/file
+     $ Git commit --amend
+     $ Git rebase or Git rebase -i
+                    </literallayout>
+                </para>
+
+                <para>
+                    Again, assuming that the changes have not been pushed upstream, and that
+                    no pending works-in-progress exist (use <filename>git status</filename> to check), then
+                    you can revert (undo) commits by using the following commands:
+
+                    <literallayout class='monospaced'>
+     # remove the commit, update working tree and remove all
+     # traces of the change
+     $ git reset --hard HEAD^
+     # remove the commit, but leave the files changed and staged for re-commit
+     $ git reset --soft HEAD^
+     # remove the commit, leave file change, but not staged for commit
+     $ git reset --mixed HEAD^
+                    </literallayout>
+                </para>
+
+                <para>
+                    You can create branches, "cherry-pick" changes, or perform any number of Git
+                    operations until the commits are in good order for pushing upstream
+                    or for pull requests.
+                    After a <filename>push</filename> or <filename>pull</filename> command,
+                    commits are normally considered
+                    "permanent" and you should not modify them.
+                    If the commits need to be changed, you can incrementally do so with new commits.
+                    These practices follow standard Git workflow and the <filename>kernel.org</filename> best
+                    practices, which is recommended.
+                    <note>
+                        It is recommended to tag or branch before adding changes to a Yocto Project
+                        BSP or before creating a new one.
+                        The reason for this recommendation is because the branch or tag provides a
+                        reference point to facilitate locating and exporting local changes.
+                    </note>
+                </para>
+
+                <section id='export-internally-via-patches'>
+                    <title>Exporting Changes Internally by Using Patches</title>
+
+                    <para>
+                        This section describes how you can extract committed changes from a working directory
+                        by exporting them as patches.
+                        Once the changes have been extracted, you can use the patches for upstream submission,
+                        place them in a Yocto Project template for automatic kernel patching,
+                        or apply them in many other common uses.
+                    </para>
+
+                    <para>
+                        This example shows how to create a directory with sequentially numbered patches.
+                        Once the directory is created, you can apply it to a repository using the
+                        <filename>git am</filename> command to reproduce the original commit and all
+                        the related information such as author, date, commit log, and so forth.
+                        <note>
+                            The new commit identifiers (ID) will be generated upon re-application.
+                            This action reflects that the commit is now applied to an underlying commit
+                            with a different ID.
+                        </note>
+                        <literallayout class='monospaced'>
+     # &lt;first-commit&gt; can be a tag if one was created before development
+     # began. It can also be the parent branch if a branch was created
+     # before development began.
+
+     $ git format-patch -o &lt;dir&gt; &lt;first commit&gt;..&lt;last commit&gt;
+                        </literallayout>
+                    </para>
+
+                    <para>
+                        In other words:
+                        <literallayout class='monospaced'>
+     # Identify commits of interest.
+
+     # If the tree was tagged before development
+     $ git format-patch -o &lt;save dir&gt; &lt;tag&gt;
+
+     # If no tags are available
+     $ git format-patch -o &lt;save dir&gt; HEAD^  # last commit
+     $ git format-patch -o &lt;save dir&gt; HEAD^^ # last 2 commits
+     $ git whatchanged # identify last commit
+     $ git format-patch -o &lt;save dir&gt; &lt;commit id&gt;
+     $ git format-patch -o &lt;save dir&gt; &lt;rev-list&gt;
+                        </literallayout>
+                    </para>
+                </section>
+
+                <section id='export-internally-via-git'>
+                    <title>Exporting Changes Internally by Using Git</title>
+
+                    <para>
+                        This section describes how you can export changes from a working directory
+                        by pushing the changes into a master repository or by making a pull request.
+                        Once you have pushed the changes to the master repository, you can then
+                        pull those same changes into a new kernel build at a later time.
+                    </para>
+
+                    <para>
+                        Use this command form to push the changes:
+                        <literallayout class='monospaced'>
+     $ git push ssh://&lt;master_server&gt;/&lt;path_to_repo&gt;
+        &lt;local_branch&gt;:&lt;remote_branch&gt;
+                        </literallayout>
+                    </para>
+
+                    <para>
+                        For example, the following command pushes the changes from your local branch
+                        <filename>yocto/standard/common-pc/base</filename> to the remote branch with the same name
+                        in the master repository <filename>//git.mycompany.com/pub/git/kernel-3.4</filename>.
+                        <literallayout class='monospaced'>
+     $ git push ssh://git.mycompany.com/pub/git/kernel-3.4 \
+        yocto/standard/common-pc/base:yocto/standard/common-pc/base
+                        </literallayout>
+                    </para>
+
+                    <para>
+                        A pull request entails using the <filename>git request-pull</filename> command to compose
+                        an email to the
+                        maintainer requesting that a branch be pulled into the master repository, see
+                        <ulink url='http://github.com/guides/pull-requests'></ulink> for an example.
+                        <note>
+                            Other commands such as <filename>git stash</filename> or branching can also be used to save
+                            changes, but are not covered in this document.
+                        </note>
+                    </para>
+                </section>
+            </section>
+
+            <section id='export-for-external-upstream-submission'>
+                <title>Exporting Changes for External (Upstream) Submission</title>
+
+                <para>
+                    This section describes how to export changes for external upstream submission.
+                    If the patch series is large or the maintainer prefers to pull
+                    changes, you can submit these changes by using a pull request.
+                    However, it is common to send patches as an email series.
+                    This method allows easy review and integration of the changes.
+                    <note>
+                        Before sending patches for review be sure you understand the
+                        community standards for submitting and documenting changes and follow their best practices.
+                        For example, kernel patches should follow standards such as:
+                        <itemizedlist>
+                            <listitem><para>
+                                <ulink url='http://linux.yyz.us/patch-format.html'></ulink></para></listitem>
+                            <listitem><para>Documentation/SubmittingPatches (in any linux
+                                kernel source tree)</para></listitem>
+                        </itemizedlist>
+                    </note>
+                </para>
+
+                <para>
+                    The messages used to commit changes are a large part of these standards.
+                    Consequently, be sure that the headers for each commit have the required information.
+                    For information on how to follow the Yocto Project commit message standards, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>How to Submit a
+                    Change</ulink>" section in the Yocto Project Development Manual.
+                </para>
+
+                <para>
+                    If the initial commits were not properly documented or do not meet those standards,
+                    you can re-base by using the <filename>git rebase -i</filename> command to
+                    manipulate the commits and
+                    get them into the required format.
+                    Other techniques such as branching and cherry-picking commits are also viable options.
+                </para>
+
+                <para>
+                    Once you complete the commits, you can generate the email that sends the patches
+                    to the maintainer(s) or lists that review and integrate changes.
+                    The command <filename>git send-email</filename> is commonly used to ensure
+                    that patches are properly
+                    formatted for easy application and avoid mailer-induced patch damage.
+                </para>
+
+                <para>
+                    The following is an example of dumping patches for external submission:
+                    <literallayout class='monospaced'>
+     # dump the last 4 commits
+     $ git format-patch --thread -n -o ~/rr/ HEAD^^^^
+     $ git send-email --compose --subject '[RFC 0/N] &lt;patch series summary&gt;' \
+      --to foo@yoctoproject.org --to bar@yoctoproject.org \
+      --cc list@yoctoproject.org  ~/rr
+     # the editor is invoked for the 0/N patch, and when complete the entire
+     # series is sent via email for review
+                    </literallayout>
+                </para>
+            </section>
+
+            <section id='export-for-import-into-other-scm'>
+                <title>Exporting Changes for Import into Another SCM</title>
+
+                <para>
+                    When you want to export changes for import into another
+                    Source Code Manager (SCM), you can use any of the previously discussed
+                    techniques.
+                    However, if the patches are manually applied to a secondary tree and then
+                    that tree is checked into the SCM, you can lose change information such as
+                    commit logs.
+                    This process is not recommended.
+                </para>
+
+                <para>
+                    Many SCMs can directly import Git commits, or can translate Git patches so that
+                    information is not lost.
+                    Those facilities are SCM-dependent and you should use them whenever possible.
+                </para>
+            </section>
+        </section>
+
+        <section id='scm-working-with-the-yocto-project-kernel-in-another-scm'>
+            <title>Working with the Yocto Project Kernel in Another SCM</title>
+
+            <para>
+                This section describes kernel development in an SCM other than Git,
+                which is not the same as exporting changes to another SCM described earlier.
+                For this scenario, you use the OpenEmbedded build system to
+                develop the kernel in a different SCM.
+                The following must be true for you to accomplish this:
+                <itemizedlist>
+                    <listitem><para>The delivered Yocto Project kernel must be exported into the second
+                        SCM.</para></listitem>
+                    <listitem><para>Development must be exported from that secondary SCM into a
+                        format that can be used by the OpenEmbedded build system.</para></listitem>
+                </itemizedlist>
+            </para>
+
+            <section id='exporting-delivered-kernel-to-scm'>
+                <title>Exporting the Delivered Kernel to the SCM</title>
+
+                <para>
+                    Depending on the SCM, it might be possible to export the entire Yocto Project
+                    kernel Git repository, branches and all, into a new environment.
+                    This method is preferred because it has the most flexibility and potential to maintain
+                    the meta data associated with each commit.
+                </para>
+
+                <para>
+                    When a direct import mechanism is not available, it is still possible to
+                    export a branch (or series of branches) and check them into a new repository.
+                </para>
+
+                <para>
+                    The following commands illustrate some of the steps you could use to
+                    import the <filename>yocto/standard/common-pc/base</filename>
+                    kernel into a secondary SCM:
+                    <literallayout class='monospaced'>
+     $ git checkout yocto/standard/common-pc/base
+     $ cd .. ; echo linux/.git &gt; .cvsignore
+     $ cvs import -m "initial import" linux MY_COMPANY start
+                    </literallayout>
+                </para>
+
+                <para>
+                    You could now relocate the CVS repository and use it in a centralized manner.
+                </para>
+
+                <para>
+                    The following commands illustrate how you can condense and merge two BSPs into a
+                    second SCM:
+                    <literallayout class='monospaced'>
+     $ git checkout yocto/standard/common-pc/base
+     $ git merge yocto/standard/common-pc-64/base
+     # resolve any conflicts and commit them
+     $ cd .. ; echo linux/.git &gt; .cvsignore
+     $ cvs import -m "initial import" linux MY_COMPANY start
+                    </literallayout>
+                </para>
+            </section>
+
+            <section id='importing-changes-for-build'>
+                <title>Importing Changes for the Build</title>
+
+                <para>
+                    Once development has reached a suitable point in the second development
+                    environment, you need to export the changes as patches.
+                    To export them, place the changes in a recipe and
+                    automatically apply them to the kernel during patching.
+                </para>
+            </section>
+        </section>
+
+        <section id='bsp-creating'>
+            <title>Creating a BSP Based on an Existing Similar BSP</title>
+
+            <para>
+                This section overviews the process of creating a BSP based on an
+                existing similar BSP.
+                The information is introductory in nature and does not provide step-by-step examples.
+                For detailed information on how to create a new BSP, see
+                the "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>" section in the
+                Yocto Project Board Support Package (BSP) Developer's Guide, or see the
+                <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>Transcript:_creating_one_generic_Atom_BSP_from_another</ulink>
+                wiki page.
+            </para>
+
+            <para>
+                The basic steps you need to follow are:
+                <orderedlist>
+                    <listitem><para><emphasis>Make sure you have set up a local Source Directory:</emphasis>
+                        You must create a local
+                        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                        by either creating a Git repository (recommended) or
+                        extracting a Yocto Project release tarball.</para></listitem>
+                    <listitem><para><emphasis>Choose an existing BSP available with the Yocto Project:</emphasis>
+                        Try to map your board features as closely to the features of a BSP that is
+                        already supported and exists in the Yocto Project.
+                        Starting with something as close as possible to your board makes developing
+                        your BSP easier.
+                        You can find all the BSPs that are supported and ship with the Yocto Project
+                        on the Yocto Project's Download page at
+                        <ulink url='&YOCTO_HOME_URL;/download'></ulink>.</para></listitem>
+                    <listitem><para><emphasis>Be sure you have the Base BSP:</emphasis>
+                        You need to either have a local Git repository of the base BSP set up or
+                        have downloaded and extracted the files from a release BSP tarball.
+                        Either method gives you access to the BSP source files.</para></listitem>
+                    <listitem><para><emphasis>Make a copy of the existing BSP, thus isolating your new
+                        BSP work:</emphasis>
+                        Copying the existing BSP file structure gives you a new area in which to work.</para></listitem>
+                    <listitem><para><emphasis>Make configuration and recipe changes to your new BSP:</emphasis>
+                        Configuration changes involve the files in the BSP's <filename>conf</filename>
+                        directory.
+                        Changes include creating a machine-specific configuration file and editing the
+                        <filename>layer.conf</filename> file.
+                        The configuration changes identify the kernel you will be using.
+                        Recipe changes include removing, modifying, or adding new recipe files that
+                        instruct the build process on what features to include in the image.</para></listitem>
+                    <listitem><para><emphasis>Prepare for the build:</emphasis>
+                        Before you actually initiate the build, you need to set up the build environment
+                        by sourcing the environment initialization script.
+                        After setting up the environment, you need to make some build configuration
+                        changes to the <filename>local.conf</filename> and <filename>bblayers.conf</filename>
+                        files.</para></listitem>
+                    <listitem><para><emphasis>Build the image:</emphasis>
+                        The OpenEmbedded build system uses BitBake to create the image.
+                        You need to decide on the type of image you are going to build (e.g. minimal, base,
+                        core, sato, and so forth) and then start the build using the <filename>bitbake</filename>
+                        command.</para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+
+        <section id='tip-dirty-string'>
+            <title>"-dirty" String</title>
+
+            <para>
+                If kernel images are being built with "-dirty" on the end of the version
+                string, this simply means that modifications in the source
+                directory have not been committed.
+                <literallayout class='monospaced'>
+     $ git status
+                </literallayout>
+            </para>
+
+            <para>
+                You can use the above Git command to report modified, removed, or added files.
+                You should commit those changes to the tree regardless of whether they will be saved,
+                exported, or used.
+                Once you commit the changes you need to rebuild the kernel.
+            </para>
+
+            <para>
+                To brute force pickup and commit all such pending changes, enter the following:
+                <literallayout class='monospaced'>
+     $ git add .
+     $ git commit -s -a -m "getting rid of -dirty"
+                </literallayout>
+            </para>
+
+            <para>
+                Next, rebuild the kernel.
+            </para>
+        </section>
+    </section>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/kernel-dev/kernel-dev-faq.xml b/documentation/kernel-dev/kernel-dev-faq.xml
new file mode 100644
index 0000000000..2b99ad2dde
--- /dev/null
+++ b/documentation/kernel-dev/kernel-dev-faq.xml
@@ -0,0 +1,140 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<appendix id='kernel-dev-faq'>
+<title>Kernel Development FAQ</title>
+
+<section id='kernel-dev-faq-section'>
+    <title>Common Questions and Solutions</title>
+
+    <para>
+        The following lists some solutions for common questions.
+
+
+        <qandaset>
+            <qandaentry>
+                <question>
+                    <para>
+                        How do I use my own Linux kernel <filename>.config</filename>
+                        file?
+                    </para>
+                </question>
+                <answer>
+            <para>
+                        Refer to the "<link linkend='changing-the-configuration'>Changing the Configuration</link>"
+                        section for information.
+                    </para>
+                </answer>
+            </qandaentry>
+
+            <qandaentry>
+                <question>
+                    <para>
+                        How do I create configuration fragments?
+                    </para>
+                </question>
+                <answer>
+                    <para>
+                        Refer to the "<link linkend='generating-configuration-files'>Generating Configuration Files</link>"
+                        section for information.
+                    </para>
+                </answer>
+            </qandaentry>
+
+            <qandaentry>
+                <question>
+                    <para>
+                        How do I use my own Linux kernel sources?
+                    </para>
+                </question>
+                <answer>
+                    <para>
+                        Refer to the "<link linkend='working-with-your-own-sources'>Working With Your Own Sources</link>"
+                        section for information.
+                    </para>
+                </answer>
+            </qandaentry>
+
+            <qandaentry>
+                <question>
+                    <para>
+                        How do I install/not-install the kernel image on the rootfs?
+                    </para>
+                </question>
+                <answer>
+                    <para>
+                        The kernel image (e.g. <filename>vmlinuz</filename>) is provided
+                        by the <filename>kernel-image</filename> package.
+                        Image recipes depend on <filename>kernel-base</filename>.
+                        To specify whether or not the kernel
+                        image is installed in the generated root filesystem, override
+                        <filename>RDEPENDS_kernel-base</filename> to include or not
+                        include "kernel-image".</para>
+                        <para>See the
+                        "<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files</ulink>"
+                        section in the Yocto Project Development Manual for information on
+                        how to use an append file to override metadata.
+                    </para>
+                </answer>
+            </qandaentry>
+
+            <qandaentry>
+                <question>
+                    <para>
+                        How do I install a specific kernel module?
+                    </para>
+                </question>
+                <answer>
+                    <para>
+                        Linux kernel modules are packaged individually.
+                        To ensure a specific kernel module is included in an image,
+                        include it in the appropriate machine
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS'><filename>RRECOMMENDS</filename></ulink>
+                        variable.</para>
+                        <para>These other variables are useful for installing specific
+                        modules:
+                        <literallayout class='monospaced'>
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'><filename>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</filename></ulink>
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><filename>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</filename></ulink>
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_EXTRA_RDEPENDS'><filename>MACHINE_EXTRA_RDEPENDS</filename></ulink>
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_EXTRA_RRECOMMENDS'><filename>MACHINE_EXTRA_RRECOMMENDS</filename></ulink>
+                        </literallayout>
+                        For example, set the following in the <filename>qemux86.conf</filename>
+                        file to include the <filename>ab123</filename> kernel modules
+                        with images built for the <filename>qemux86</filename> machine:
+                        <literallayout class='monospaced'>
+     MACHINE_EXTRA_RRECOMMENDS += "kernel-module-ab123"
+                        </literallayout>
+                        For more information, see the
+                        "<link linkend='incorporating-out-of-tree-modules'>Incorporating Out-of-Tree Modules</link>"
+                        section.
+                    </para>
+                </answer>
+            </qandaentry>
+
+            <qandaentry>
+                <question>
+                    <para>
+                        How do I change the Linux kernel command line?
+                   </para>
+                </question>
+                <answer>
+                    <para>
+                        The Linux kernel command line is typically specified in
+                        the machine config using the <filename>APPEND</filename> variable.
+                For example, you can add some helpful debug information doing
+                        the following:
+                        <literallayout class='monospaced'>
+     APPEND += "printk.time=y initcall_debug debug"
+                        </literallayout>
+                    </para>
+                </answer>
+            </qandaentry>
+        </qandaset>
+    </para>
+</section>
+</appendix>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/kernel-dev/kernel-dev-intro.xml b/documentation/kernel-dev/kernel-dev-intro.xml
new file mode 100644
index 0000000000..38ef36de5a
--- /dev/null
+++ b/documentation/kernel-dev/kernel-dev-intro.xml
@@ -0,0 +1,147 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='kernel-dev-intro'>
+<title>Introduction</title>
+
+<!--
+<para>
+    <emphasis>AR - Darrren Hart:</emphasis>  See if the concepts in these
+    three bullets are adequately covered in somewhere in this manual:
+    <itemizedlist>
+        <listitem><para>Do we convey that our kernel Git repositories
+            have a clear and continuous history, similar to the way the
+            kernel Git repositories for <filename>kernel.org</filename>
+            do.
+            </para></listitem>
+        <listitem><para>Does the manual note that Yocto Project delivers
+            a key set of supported kernel types, where
+            each type is tailored to meet a specific use (e.g. networking,
+            consumer, devices, and so forth).</para></listitem>
+        <listitem><para>Do we convey that the Yocto Project uses a
+            Git branching strategy that, from a
+            developer's point of view, results in a linear path from the
+            baseline kernel.org, through a select group of features and
+            ends with their BSP-specific commits.</para></listitem>
+    </itemizedlist>
+</para>
+-->
+
+    <section id='kernel-dev-overview'>
+        <title>Overview</title>
+
+        <para>
+            Regardless of how you intend to make use of the Yocto Project,
+            chances are you will work with the Linux kernel.
+            This manual provides background information on the Yocto Linux kernel
+            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>,
+            describes common tasks you can perform using the kernel tools,
+            and shows you how to use the kernel Metadata needed to work with
+            the kernel inside the Yocto Project.
+       </para>
+
+       <para>
+            Each Yocto Project release has a set of linux-yocto recipes, whose
+            Git repositories you can view in the Yocto
+            <ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink> under
+            the "Yocto Linux Kernel" heading.
+            New recipes for the release track the latest upstream developments
+            and introduce newly supported platforms.
+            Previous recipes in the release are refreshed and supported for at
+            least one additional release.
+            As they align, these previous releases are updated to include the
+            latest from the Long Term Support Initiative (LTSI) project.
+            Also included is a linux-yocto development recipe
+            (<filename>linux-yocto-dev.bb</filename>) should you want to work
+            with the very latest in upstream Linux kernel development and
+            kernel Metadata development.
+        </para>
+
+        <para>
+            The Yocto Project also provides a powerful set of kernel
+            tools for managing Linux kernel sources and configuration data.
+            You can use these tools to make a single configuration change,
+            apply multiple patches, or work with your own kernel sources.
+        </para>
+
+        <para>
+            In particular, the kernel tools allow you to generate configuration
+            fragments that specify only what you must, and nothing more.
+            Configuration fragments only need to contain the highest level
+            visible <filename>CONFIG</filename> options as presented by the Linux
+            kernel <filename>menuconfig</filename> system.
+            Contrast this against a complete Linux kernel
+            <filename>.config</filename>, which includes all the automatically
+            selected <filename>CONFIG</filename> options.
+            This efficiency reduces your maintenance effort and allows you
+            to further separate your configuration in ways that make sense for
+            your project.
+            A common split separates policy and hardware.
+            For example, all your kernels might support
+            the <filename>proc</filename> and <filename>sys</filename> filesystems,
+            but only specific boards require sound, USB, or specific drivers.
+            Specifying these configurations individually allows you to aggregate
+            them together as needed, but maintains them in only one place.
+            Similar logic applies to separating source changes.
+        </para>
+
+        <para>
+            If you do not maintain your own kernel sources and need to make
+            only minimal changes to the sources, the released recipes provide a
+            vetted base upon which to layer your changes.
+            Doing so allows you to benefit from the continual kernel
+            integration and testing performed during development of the
+            Yocto Project.
+        </para>
+
+        <para>
+            If, instead, you have a very specific Linux kernel source tree
+            and are unable to align with one of the official linux-yocto
+            recipes, an alternative exists by which you can use the Yocto
+            Project Linux kernel tools with your own kernel sources.
+        </para>
+    </section>
+
+    <section id='kernel-dev-other-resources'>
+        <title>Other Resources</title>
+
+        <para>
+            The sections that follow provide instructions for completing
+            specific Linux kernel development tasks.
+            These instructions assume you are comfortable working with
+            <ulink url='http://openembedded.org/wiki/Bitbake'>BitBake</ulink>
+            recipes and basic open-source development tools.
+            Understanding these concepts will facilitate the process of working
+            with the kernel recipes.
+            If you find you need some additional background, please be sure to
+            review and understand the following documentation:
+            <itemizedlist>
+                <listitem><para><ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>
+                    </para></listitem>
+                <listitem><para>The "<ulink url='&YOCTO_DOCS_DEV_URL;#modifying-temporary-source-code'>Modifying Temporary Source Code</ulink>"
+                    section in the Yocto Project Development Manual
+                    </para></listitem>
+                <listitem><para>The "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>" section
+                    in the Yocto Project Development Manual</para></listitem>
+                <listitem><para>The "<ulink url='&YOCTO_DOCS_DEV_URL;#modifying-the-kernel'>Modifying the Kernel</ulink>" section
+                    in the Yocto Project Development Manual.</para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            Finally, while this document focuses on the manual creation of
+            recipes, patches, and configuration files, the Yocto Project
+            Board Support Package (BSP) tools are available to automate
+            this process with existing content and work well to create the
+            initial framework and boilerplate code.
+            For details on these tools, see the
+            "<ulink url='&YOCTO_DOCS_BSP_URL;#using-the-yocto-projects-bsp-tools'>Using the Yocto Project's BSP Tools</ulink>"
+            section in the Yocto Project Board Support Package (BSP) Developer's
+            Guide.
+        </para>
+    </section>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/kernel-dev/kernel-dev-maint-appx.xml b/documentation/kernel-dev/kernel-dev-maint-appx.xml
new file mode 100644
index 0000000000..a72dcff01b
--- /dev/null
+++ b/documentation/kernel-dev/kernel-dev-maint-appx.xml
@@ -0,0 +1,220 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<appendix id='kernel-dev-maint-appx'>
+<title>Kernel Maintenance</title>
+
+    <section id='tree-construction'>
+        <title>Tree Construction</title>
+        <para>
+            This section describes construction of the Yocto Project kernel source repositories
+            as accomplished by the Yocto Project team to create kernel repositories.
+            These kernel repositories are found under the heading "Yocto Linux Kernel" at
+            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>&YOCTO_GIT_URL;/cgit.cgi</ulink>
+            and can be shipped as part of a Yocto Project release.
+            The team creates these repositories by
+            compiling and executing the set of feature descriptions for every BSP
+            and feature in the product.
+            Those feature descriptions list all necessary patches,
+            configuration, branching, tagging and feature divisions found in a kernel.
+            Thus, the Yocto Project kernel repository (or tree) is built.
+        </para>
+        <para>
+            The existence of this tree allows you to access and clone a particular
+            Yocto Project kernel repository and use it to build images based on their configurations
+            and features.
+        </para>
+        <para>
+            You can find the files used to describe all the valid features and BSPs
+            in the Yocto Project kernel in any clone of the Yocto Project kernel source repository
+            Git tree.
+            For example, the following command clones the Yocto Project baseline kernel that
+            branched off of <filename>linux.org</filename> version 3.4:
+            <literallayout class='monospaced'>
+     $ git clone git://git.yoctoproject.org/linux-yocto-3.4
+            </literallayout>
+            For another example of how to set up a local Git repository of the Yocto Project
+            kernel files, see the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Yocto Project Kernel</ulink>" bulleted
+            item in the Yocto Project Development Manual.
+        </para>
+        <para>
+            Once you have cloned the kernel Git repository on your local machine, you can
+            switch to the <filename>meta</filename> branch within the repository.
+            Here is an example that assumes the local Git repository for the kernel is in
+            a top-level directory named <filename>linux-yocto-3.4</filename>:
+            <literallayout class='monospaced'>
+     $ cd linux-yocto-3.4
+     $ git checkout -b meta origin/meta
+            </literallayout>
+            Once you have checked out and switched to the <filename>meta</filename> branch,
+            you can see a snapshot of all the kernel configuration and feature descriptions that are
+            used to build that particular kernel repository.
+            These descriptions are in the form of <filename>.scc</filename> files.
+        </para>
+        <para>
+            You should realize, however, that browsing your local kernel repository
+            for feature descriptions and patches is not an effective way to determine what is in a
+            particular kernel branch.
+            Instead, you should use Git directly to discover the changes in a branch.
+            Using Git is an efficient and flexible way to inspect changes to the kernel.
+            <note>
+                Ground up reconstruction of the complete kernel tree is an action only taken by the
+                Yocto Project team during an active development cycle.
+                When you create a clone of the kernel Git repository, you are simply making it
+                efficiently available for building and development.
+            </note>
+        </para>
+        <para>
+            The following steps describe what happens when the Yocto Project Team constructs
+            the Yocto Project kernel source Git repository (or tree) found at
+            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink> given the
+            introduction of a new top-level kernel feature or BSP.
+            These are the actions that effectively create the tree
+            that includes the new feature, patch or BSP:
+            <orderedlist>
+                <listitem><para>A top-level kernel feature is passed to the kernel build subsystem.
+                    Normally, this feature is a BSP for a particular kernel type.</para></listitem>
+                <listitem><para>The file that describes the top-level feature is located by searching
+                    these system directories:
+                    <itemizedlist>
+                        <listitem><para>The in-tree kernel-cache directories, which are located
+                            in <filename>meta/cfg/kernel-cache</filename></para></listitem>
+                        <listitem><para>Areas pointed to by <filename>SRC_URI</filename> statements
+                            found in recipes</para></listitem>
+                    </itemizedlist>
+                    For a typical build, the target of the search is a
+                    feature description in an <filename>.scc</filename> file
+                    whose name follows this format:
+                    <literallayout class='monospaced'>
+     <replaceable>bsp_name</replaceable>-<replaceable>kernel_type</replaceable>.scc
+                    </literallayout>
+                </para></listitem>
+                <listitem><para>Once located, the feature description is either compiled into a simple script
+                    of actions, or into an existing equivalent script that is already part of the
+                    shipped kernel.</para></listitem>
+                <listitem><para>Extra features are appended to the top-level feature description.
+                    These features can come from the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink>
+                    variable in recipes.</para></listitem>
+                <listitem><para>Each extra feature is located, compiled and appended to the script
+                    as described in step three.</para></listitem>
+                <listitem><para>The script is executed to produce a series of <filename>meta-*</filename>
+                    directories.
+                    These directories are descriptions of all the branches, tags, patches and configurations that
+                    need to be applied to the base Git repository to completely create the
+                    source (build) branch for the new BSP or feature.</para></listitem>
+                <listitem><para>The base repository is cloned, and the actions
+                    listed in the <filename>meta-*</filename> directories are applied to the
+                    tree.</para></listitem>
+                <listitem><para>The Git repository is left with the desired branch checked out and any
+                    required branching, patching and tagging has been performed.</para></listitem>
+            </orderedlist>
+        </para>
+        <para>
+            The kernel tree is now ready for developer consumption to be locally cloned,
+            configured, and built into a Yocto Project kernel specific to some target hardware.
+            <note><para>The generated <filename>meta-*</filename> directories add to the kernel
+                as shipped with the Yocto Project release.
+                Any add-ons and configuration data are applied to the end of an existing branch.
+                The full repository generation that is found in the
+                official Yocto Project kernel repositories at
+                <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>http://git.yoctoproject.org/cgit.cgi</ulink>
+                is the combination of all supported boards and configurations.</para>
+                <para>The technique the Yocto Project team uses is flexible and allows for seamless
+                blending of an immutable history with additional patches specific to a
+                deployment.
+                Any additions to the kernel become an integrated part of the branches.</para>
+            </note>
+        </para>
+    </section>
+
+    <section id='build-strategy'>
+        <title>Build Strategy</title>
+
+<!--
+        <para>
+            <emphasis>AR - Darrren Hart:</emphasis>  Some parts of this section
+            need to be in the
+            "<link linkend='using-an-iterative-development-process'>Using an Iterative Development Process</link>"
+            section.
+            Darren needs to figure out which parts and identify them.
+        </para>
+-->
+
+        <para>
+            Once a local Git repository of the Yocto Project kernel exists on a development system,
+            you can consider the compilation phase of kernel development - building a kernel image.
+            Some prerequisites exist that are validated by the build process before compilation
+            starts:
+        </para>
+
+        <itemizedlist>
+            <listitem><para>The
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> points
+                to the kernel Git repository.</para></listitem>
+            <listitem><para>A BSP build branch exists.
+                This branch has the following form:
+                <literallayout class='monospaced'>
+     <replaceable>kernel_type</replaceable>/<replaceable>bsp_name</replaceable>
+                </literallayout></para></listitem>
+        </itemizedlist>
+
+        <para>
+            The OpenEmbedded build system makes sure these conditions exist before attempting compilation.
+            Other means, however, do exist, such as as bootstrapping a BSP.
+        </para>
+
+        <para>
+            Before building a kernel, the build process verifies the tree
+            and configures the kernel by processing all of the
+            configuration "fragments" specified by feature descriptions in the <filename>.scc</filename>
+            files.
+            As the features are compiled, associated kernel configuration fragments are noted
+            and recorded in the <filename>meta-*</filename> series of directories in their compilation order.
+            The fragments are migrated, pre-processed and passed to the Linux Kernel
+            Configuration subsystem (<filename>lkc</filename>) as raw input in the form
+            of a <filename>.config</filename> file.
+            The <filename>lkc</filename> uses its own internal dependency constraints to do the final
+            processing of that information and generates the final <filename>.config</filename> file
+            that is used during compilation.
+        </para>
+
+        <para>
+            Using the board's architecture and other relevant values from the board's template,
+            kernel compilation is started and a kernel image is produced.
+        </para>
+
+        <para>
+            The other thing that you notice once you configure a kernel is that
+            the build process generates a build tree that is separate from your kernel's local Git
+            source repository tree.
+            This build tree has a name that uses the following form, where
+            <filename>${MACHINE}</filename> is the metadata name of the machine (BSP) and "kernel_type" is one
+            of the Yocto Project supported kernel types (e.g. "standard"):
+        <literallayout class='monospaced'>
+     linux-${MACHINE}-<replaceable>kernel_type</replaceable>-build
+        </literallayout>
+        </para>
+
+        <para>
+            The existing support in the <filename>kernel.org</filename> tree achieves this
+            default functionality.
+        </para>
+
+        <para>
+            This behavior means that all the generated files for a particular machine or BSP are now in
+            the build tree directory.
+            The files include the final <filename>.config</filename> file, all the <filename>.o</filename>
+            files, the <filename>.a</filename> files, and so forth.
+            Since each machine or BSP has its own separate
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            in its own separate branch
+            of the Git repository, you can easily switch between different builds.
+        </para>
+    </section>
+</appendix>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/kernel-dev/kernel-dev-style.css b/documentation/kernel-dev/kernel-dev-style.css
new file mode 100644
index 0000000000..6e0c1c7fc9
--- /dev/null
+++ b/documentation/kernel-dev/kernel-dev-style.css
@@ -0,0 +1,984 @@
+/*
+   Generic XHTML / DocBook XHTML CSS Stylesheet.
+
+   Browser wrangling and typographic design by
+      Oyvind Kolas / pippin@gimp.org
+
+   Customised for Poky by
+      Matthew Allum / mallum@o-hand.com
+
+   Thanks to:
+     Liam R. E. Quin
+     William Skaggs
+     Jakub Steiner
+
+   Structure
+   ---------
+
+   The stylesheet is divided into the following sections:
+
+       Positioning
+          Margins, paddings, width, font-size, clearing.
+       Decorations
+          Borders, style
+       Colors
+          Colors
+       Graphics
+          Graphical backgrounds
+       Nasty IE tweaks
+          Workarounds needed to make it work in internet explorer,
+          currently makes the stylesheet non validating, but up until
+          this point it is validating.
+       Mozilla extensions
+          Transparency for footer
+          Rounded corners on boxes
+
+*/
+
+
+  /*************** /
+ /  Positioning   /
+/ ***************/
+
+body {
+  font-family: Verdana, Sans, sans-serif;
+
+  min-width: 640px;
+  width: 80%;
+  margin:  0em auto;
+  padding: 2em 5em 5em 5em;
+  color: #333;
+}
+
+h1,h2,h3,h4,h5,h6,h7 {
+  font-family: Arial, Sans;
+  color: #00557D;
+  clear: both;
+}
+
+h1 {
+  font-size: 2em;
+  text-align: left;
+  padding: 0em 0em 0em 0em;
+  margin: 2em 0em 0em 0em;
+}
+
+h2.subtitle {
+  margin: 0.10em 0em 3.0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 1.8em;
+  padding-left: 20%;
+  font-weight: normal;
+  font-style: italic;
+}
+
+h2 {
+  margin: 2em 0em 0.66em 0em;
+  padding: 0.5em 0em 0em 0em;
+  font-size: 1.5em;
+  font-weight: bold;
+}
+
+h3.subtitle {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 142.14%;
+  text-align: right;
+}
+
+h3 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 140%;
+  font-weight: bold;
+}
+
+h4 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 120%;
+  font-weight: bold;
+}
+
+h5 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+h6 {
+  margin: 1em 0em 0em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+.authorgroup {
+  background-color: transparent;
+  background-repeat: no-repeat;
+  padding-top: 256px;
+  background-image: url("figures/kernel-dev-title.png");
+  background-position: left top;
+  margin-top: -256px;
+  padding-right: 50px;
+  margin-left: 0px;
+  text-align: right;
+  width: 740px;
+}
+
+h3.author {
+  margin: 0em 0me 0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-weight: normal;
+  font-size: 100%;
+  color: #333;
+  clear: both;
+}
+
+.author tt.email {
+  font-size: 66%;
+}
+
+.titlepage hr {
+  width: 0em;
+  clear: both;
+}
+
+.revhistory {
+  padding-top: 2em;
+  clear: both;
+}
+
+.toc,
+.list-of-tables,
+.list-of-examples,
+.list-of-figures {
+  padding: 1.33em 0em 2.5em 0em;
+  color: #00557D;
+}
+
+.toc p,
+.list-of-tables p,
+.list-of-figures p,
+.list-of-examples p {
+  padding: 0em 0em 0em 0em;
+  padding: 0em 0em 0.3em;
+  margin: 1.5em 0em 0em 0em;
+}
+
+.toc p b,
+.list-of-tables p b,
+.list-of-figures p b,
+.list-of-examples p b{
+  font-size: 100.0%;
+  font-weight: bold;
+}
+
+.toc dl,
+.list-of-tables dl,
+.list-of-figures dl,
+.list-of-examples dl {
+  margin: 0em 0em 0.5em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dt {
+  margin: 0em 0em 0em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dd {
+  margin: 0em 0em 0em 2.6em;
+  padding: 0em 0em 0em 0em;
+}
+
+div.glossary dl,
+div.variablelist dl {
+}
+
+.glossary dl dt,
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  font-weight: normal;
+  width: 20em;
+  text-align: right;
+}
+
+.variablelist dl dt {
+  margin-top: 0.5em;
+}
+
+.glossary dl dd,
+.variablelist dl dd {
+  margin-top: -1em;
+  margin-left: 25.5em;
+}
+
+.glossary dd p,
+.variablelist dd p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+
+div.calloutlist table td {
+  padding: 0em 0em 0em 0em;
+  margin: 0em 0em 0em 0em;
+}
+
+div.calloutlist table td p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+div p.copyright {
+  text-align: left;
+}
+
+div.legalnotice p.legalnotice-title {
+  margin-bottom: 0em;
+}
+
+p {
+  line-height: 1.5em;
+  margin-top: 0em;
+
+}
+
+dl {
+  padding-top: 0em;
+}
+
+hr {
+  border: solid 1px;
+}
+
+
+.mediaobject,
+.mediaobjectco {
+  text-align: center;
+}
+
+img {
+  border: none;
+}
+
+ul {
+  padding: 0em 0em 0em 1.5em;
+}
+
+ul li {
+  padding: 0em 0em 0em 0em;
+}
+
+ul li p {
+  text-align: left;
+}
+
+table {
+  width :100%;
+}
+
+th {
+  padding: 0.25em;
+  text-align: left;
+  font-weight: normal;
+  vertical-align: top;
+}
+
+td {
+  padding: 0.25em;
+  vertical-align: top;
+}
+
+p a[id] {
+  margin: 0px;
+  padding: 0px;
+  display: inline;
+  background-image: none;
+}
+
+a {
+  text-decoration: underline;
+  color: #444;
+}
+
+pre {
+    overflow: auto;
+}
+
+a:hover {
+  text-decoration: underline;
+  /*font-weight: bold;*/
+}
+
+/* This style defines how the permalink character
+   appears by itself and when hovered over with
+   the mouse. */
+
+[alt='Permalink'] { color: #eee; }
+[alt='Permalink']:hover { color: black; }
+
+
+div.informalfigure,
+div.informalexample,
+div.informaltable,
+div.figure,
+div.table,
+div.example {
+  margin: 1em 0em;
+  padding: 1em;
+  page-break-inside: avoid;
+}
+
+
+div.informalfigure p.title b,
+div.informalexample p.title b,
+div.informaltable p.title b,
+div.figure p.title b,
+div.example p.title b,
+div.table p.title b{
+    padding-top: 0em;
+    margin-top: 0em;
+    font-size: 100%;
+    font-weight: normal;
+}
+
+.mediaobject .caption,
+.mediaobject .caption p  {
+  text-align: center;
+  font-size: 80%;
+  padding-top: 0.5em;
+  padding-bottom: 0.5em;
+}
+
+.epigraph {
+  padding-left: 55%;
+  margin-bottom: 1em;
+}
+
+.epigraph p {
+  text-align: left;
+}
+
+.epigraph .quote {
+  font-style: italic;
+}
+.epigraph .attribution {
+  font-style: normal;
+  text-align: right;
+}
+
+span.application {
+  font-style: italic;
+}
+
+.programlisting {
+  font-family: monospace;
+  font-size: 80%;
+  white-space: pre;
+  margin: 1.33em 0em;
+  padding: 1.33em;
+}
+
+.tip,
+.warning,
+.caution,
+.note {
+  margin-top: 1em;
+  margin-bottom: 1em;
+
+}
+
+/* force full width of table within div */
+.tip table,
+.warning table,
+.caution table,
+.note table {
+  border: none;
+  width: 100%;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  padding: 0.8em 0.0em 0.0em 0.0em;
+  margin : 0em 0em 0em 0em;
+}
+
+.tip p,
+.warning p,
+.caution p,
+.note p {
+  margin-top: 0.5em;
+  margin-bottom: 0.5em;
+  padding-right: 1em;
+  text-align: left;
+}
+
+.acronym {
+  text-transform: uppercase;
+}
+
+b.keycap,
+.keycap {
+  padding: 0.09em 0.3em;
+  margin: 0em;
+}
+
+.itemizedlist li {
+  clear: none;
+}
+
+.filename {
+  font-size: medium;
+  font-family: Courier, monospace;
+}
+
+
+div.navheader, div.heading{
+  position: absolute;
+  left: 0em;
+  top: 0em;
+  width: 100%;
+  background-color: #cdf;
+  width: 100%;
+}
+
+div.navfooter, div.footing{
+  position: fixed;
+  left: 0em;
+  bottom: 0em;
+  background-color: #eee;
+  width: 100%;
+}
+
+
+div.navheader td,
+div.navfooter td {
+  font-size: 66%;
+}
+
+div.navheader table th {
+  /*font-family: Georgia, Times, serif;*/
+  /*font-size: x-large;*/
+  font-size: 80%;
+}
+
+div.navheader table {
+  border-left: 0em;
+  border-right: 0em;
+  border-top: 0em;
+  width: 100%;
+}
+
+div.navfooter table {
+  border-left: 0em;
+  border-right: 0em;
+  border-bottom: 0em;
+  width: 100%;
+}
+
+div.navheader table td a,
+div.navfooter table td a {
+  color: #777;
+  text-decoration: none;
+}
+
+/* normal text in the footer */
+div.navfooter table td {
+  color: black;
+}
+
+div.navheader table td a:visited,
+div.navfooter table td a:visited {
+  color: #444;
+}
+
+
+/* links in header and footer */
+div.navheader table td a:hover,
+div.navfooter table td a:hover {
+  text-decoration: underline;
+  background-color: transparent;
+  color: #33a;
+}
+
+div.navheader hr,
+div.navfooter hr {
+  display: none;
+}
+
+
+.qandaset tr.question td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.qandaset tr.answer td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+.answer td {
+  padding-bottom: 1.5em;
+}
+
+.emphasis {
+  font-weight: bold;
+}
+
+
+  /************* /
+ / decorations  /
+/ *************/
+
+.titlepage {
+}
+
+.part .title {
+}
+
+.subtitle {
+    border: none;
+}
+
+/*
+h1 {
+  border: none;
+}
+
+h2 {
+  border-top: solid 0.2em;
+  border-bottom: solid 0.06em;
+}
+
+h3 {
+  border-top: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h4 {
+  border: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h5 {
+  border: 0em;
+}
+*/
+
+.programlisting {
+  border: solid 1px;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example {
+  border: 1px solid;
+}
+
+
+
+.tip,
+.warning,
+.caution,
+.note {
+  border: 1px solid;
+}
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom: 1px solid;
+}
+
+.question td {
+  border-top: 1px solid black;
+}
+
+.answer {
+}
+
+
+b.keycap,
+.keycap {
+  border: 1px solid;
+}
+
+
+div.navheader, div.heading{
+  border-bottom: 1px solid;
+}
+
+
+div.navfooter, div.footing{
+  border-top: 1px solid;
+}
+
+  /********* /
+ /  colors  /
+/ *********/
+
+body {
+  color: #333;
+  background: white;
+}
+
+a {
+  background: transparent;
+}
+
+a:hover {
+  background-color: #dedede;
+}
+
+
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7,
+h8 {
+  background-color: transparent;
+}
+
+hr {
+  border-color: #aaa;
+}
+
+
+.tip, .warning, .caution, .note {
+  border-color: #fff;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom-color: #fff;
+}
+
+
+.warning {
+  background-color: #f0f0f2;
+}
+
+.caution {
+  background-color: #f0f0f2;
+}
+
+.tip {
+  background-color: #f0f0f2;
+}
+
+.note {
+  background-color: #f0f0f2;
+}
+
+.glossary dl dt,
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  color: #044;
+}
+
+div.figure,
+div.table,
+div.example,
+div.informalfigure,
+div.informaltable,
+div.informalexample {
+  border-color: #aaa;
+}
+
+pre.programlisting {
+  color: black;
+  background-color: #fff;
+  border-color: #aaa;
+  border-width: 2px;
+}
+
+.guimenu,
+.guilabel,
+.guimenuitem {
+  background-color: #eee;
+}
+
+
+b.keycap,
+.keycap {
+  background-color: #eee;
+  border-color: #999;
+}
+
+
+div.navheader {
+  border-color: black;
+}
+
+
+div.navfooter {
+  border-color: black;
+}
+
+
+  /*********** /
+ /  graphics  /
+/ ***********/
+
+/*
+body {
+  background-image: url("images/body_bg.jpg");
+  background-attachment: fixed;
+}
+
+.navheader,
+.note,
+.tip {
+  background-image: url("images/note_bg.jpg");
+  background-attachment: fixed;
+}
+
+.warning,
+.caution {
+  background-image: url("images/warning_bg.jpg");
+  background-attachment: fixed;
+}
+
+.figure,
+.informalfigure,
+.example,
+.informalexample,
+.table,
+.informaltable {
+  background-image: url("images/figure_bg.jpg");
+  background-attachment: fixed;
+}
+
+*/
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7{
+}
+
+/*
+Example of how to stick an image as part of the title.
+
+div.article .titlepage .title
+{
+  background-image: url("figures/white-on-black.png");
+  background-position: center;
+  background-repeat: repeat-x;
+}
+*/
+
+div.preface .titlepage .title,
+div.colophon .title,
+div.chapter .titlepage .title,
+div.article .titlepage .title
+{
+}
+
+div.section div.section .titlepage .title,
+div.sect2 .titlepage .title {
+    background: none;
+}
+
+
+h1.title {
+  background-color: transparent;
+  background-repeat: no-repeat;
+  height: 256px;
+  text-indent: -9000px;
+  overflow:hidden;
+}
+
+h2.subtitle {
+  background-color: transparent;
+  text-indent: -9000px;
+  overflow:hidden;
+  width: 0px;
+  display: none;
+}
+
+  /*************************************** /
+ /  pippin.gimp.org specific alterations  /
+/ ***************************************/
+
+/*
+div.heading, div.navheader {
+  color: #777;
+  font-size: 80%;
+  padding: 0;
+  margin: 0;
+  text-align: left;
+  position: absolute;
+  top: 0px;
+  left: 0px;
+  width: 100%;
+  height: 50px;
+  background: url('/gfx/heading_bg.png') transparent;
+  background-repeat: repeat-x;
+  background-attachment: fixed;
+  border: none;
+}
+
+div.heading a {
+  color: #444;
+}
+
+div.footing, div.navfooter {
+  border: none;
+  color: #ddd;
+  font-size: 80%;
+  text-align:right;
+
+  width: 100%;
+  padding-top: 10px;
+  position: absolute;
+  bottom: 0px;
+  left: 0px;
+
+  background: url('/gfx/footing_bg.png') transparent;
+}
+*/
+
+
+
+  /****************** /
+ /  nasty ie tweaks  /
+/ ******************/
+
+/*
+div.heading, div.navheader {
+  width:expression(document.body.clientWidth + "px");
+}
+
+div.footing, div.navfooter {
+  width:expression(document.body.clientWidth + "px");
+  margin-left:expression("-5em");
+}
+body {
+  padding:expression("4em 5em 0em 5em");
+}
+*/
+
+  /**************************************** /
+ / mozilla vendor specific css extensions  /
+/ ****************************************/
+/*
+div.navfooter, div.footing{
+  -moz-opacity: 0.8em;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example,
+.tip,
+.warning,
+.caution,
+.note {
+  -moz-border-radius: 0.5em;
+}
+
+b.keycap,
+.keycap {
+  -moz-border-radius: 0.3em;
+}
+*/
+
+table tr td table tr td {
+  display: none;
+}
+
+
+hr {
+  display: none;
+}
+
+table {
+  border: 0em;
+}
+
+ .photo {
+  float: right;
+  margin-left:   1.5em;
+  margin-bottom: 1.5em;
+  margin-top: 0em;
+  max-width:      17em;
+  border:     1px solid gray;
+  padding:    3px;
+  background: white;
+}
+ .seperator {
+   padding-top: 2em;
+   clear: both;
+  }
+
+  #validators {
+      margin-top: 5em;
+      text-align: right;
+      color: #777;
+  }
+  @media print {
+      body {
+          font-size: 8pt;
+      }
+      .noprint {
+          display: none;
+      }
+  }
+
+
+.tip,
+.note {
+   background: #f0f0f2;
+   color: #333;
+   padding: 20px;
+   margin: 20px;
+}
+
+.tip h3,
+.note h3 {
+   padding: 0em;
+   margin: 0em;
+   font-size: 2em;
+   font-weight: bold;
+   color: #333;
+}
+
+.tip a,
+.note a {
+   color: #333;
+   text-decoration: underline;
+}
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
diff --git a/documentation/kernel-dev/kernel-dev.xml b/documentation/kernel-dev/kernel-dev.xml
new file mode 100644
index 0000000000..4ab95cbfce
--- /dev/null
+++ b/documentation/kernel-dev/kernel-dev.xml
@@ -0,0 +1,115 @@
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<book id='kernel-dev' lang='en'
+      xmlns:xi="http://www.w3.org/2003/XInclude"
+      xmlns="http://docbook.org/ns/docbook"
+      >
+    <bookinfo>
+
+        <mediaobject>
+            <imageobject>
+                <imagedata fileref='figures/kernel-dev-title.png'
+                    format='SVG'
+                    align='left' scalefit='1' width='100%'/>
+            </imageobject>
+        </mediaobject>
+
+        <title>
+                  Yocto Project Linux Kernel Development Manual
+                </title>
+
+        <authorgroup>
+            <author>
+                <firstname>Darren</firstname> <surname>Hart</surname>
+                <affiliation>
+                    <orgname>Intel Corporation</orgname>
+                </affiliation>
+                <email>darren.hart@intel.com</email>
+            </author>
+        </authorgroup>
+
+        <revhistory>
+            <revision>
+                <revnumber>1.4</revnumber>
+                <date>April 2013</date>
+                <revremark>Released with the Yocto Project 1.4 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5</revnumber>
+                <date>October 2013</date>
+                <revremark>Released with the Yocto Project 1.5 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.1</revnumber>
+                <date>January 2014</date>
+                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.6</revnumber>
+                <date>April 2014</date>
+                <revremark>Released with the Yocto Project 1.6 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7</revnumber>
+                <date>October 2014</date>
+                <revremark>Released with the Yocto Project 1.7 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.1</revnumber>
+                <date>January 2015</date>
+                <revremark>Released with the Yocto Project 1.7.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.2</revnumber>
+                <date>June 2015</date>
+                <revremark>Released with the Yocto Project 1.7.2 Release.</revremark>
+            </revision>
+        </revhistory>
+
+    <copyright>
+      <year>&COPYRIGHT_YEAR;</year>
+      <holder>Linux Foundation</holder>
+    </copyright>
+
+    <legalnotice>
+      <para>
+        Permission is granted to copy, distribute and/or modify this document under
+        the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
+      </para>
+      <note>
+          For the latest version of this manual associated with this
+          Yocto Project release, see the
+          <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>
+          from the Yocto Project website.
+      </note>
+    </legalnotice>
+
+    </bookinfo>
+
+    <xi:include href="kernel-dev-intro.xml"/>
+
+    <xi:include href="kernel-dev-common.xml"/>
+
+    <xi:include href="kernel-dev-advanced.xml"/>
+
+    <xi:include href="kernel-dev-concepts-appx.xml"/>
+
+    <xi:include href="kernel-dev-maint-appx.xml"/>
+
+<!--
+    <xi:include href="kernel-dev-examples.xml"/>
+-->
+
+    <xi:include href="kernel-dev-faq.xml"/>
+
+<!--    <index id='index'>
+      <title>Index</title>
+    </index>
+-->
+
+</book>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/mega-manual/figures/adt-title.png b/documentation/mega-manual/figures/adt-title.png
new file mode 100644
index 0000000000..6e71e41f1a
--- /dev/null
+++ b/documentation/mega-manual/figures/adt-title.png
diff --git a/documentation/mega-manual/figures/analysis-for-package-splitting.png b/documentation/mega-manual/figures/analysis-for-package-splitting.png
new file mode 100644
index 0000000000..04f2794ea9
--- /dev/null
+++ b/documentation/mega-manual/figures/analysis-for-package-splitting.png
diff --git a/documentation/mega-manual/figures/app-dev-flow.png b/documentation/mega-manual/figures/app-dev-flow.png
new file mode 100644
index 0000000000..4927b93d67
--- /dev/null
+++ b/documentation/mega-manual/figures/app-dev-flow.png
diff --git a/documentation/mega-manual/figures/bsp-dev-flow.png b/documentation/mega-manual/figures/bsp-dev-flow.png
new file mode 100644
index 0000000000..540b0abb9f
--- /dev/null
+++ b/documentation/mega-manual/figures/bsp-dev-flow.png
diff --git a/documentation/mega-manual/figures/bsp-title.png b/documentation/mega-manual/figures/bsp-title.png
new file mode 100644
index 0000000000..f624dd4f94
--- /dev/null
+++ b/documentation/mega-manual/figures/bsp-title.png
diff --git a/documentation/mega-manual/figures/buildhistory-web.png b/documentation/mega-manual/figures/buildhistory-web.png
new file mode 100644
index 0000000000..f6db86c977
--- /dev/null
+++ b/documentation/mega-manual/figures/buildhistory-web.png
diff --git a/documentation/mega-manual/figures/buildhistory.png b/documentation/mega-manual/figures/buildhistory.png
new file mode 100644
index 0000000000..9a77bde68b
--- /dev/null
+++ b/documentation/mega-manual/figures/buildhistory.png
diff --git a/documentation/mega-manual/figures/building-an-image.png b/documentation/mega-manual/figures/building-an-image.png
new file mode 100755
index 0000000000..1fbea5ab00
--- /dev/null
+++ b/documentation/mega-manual/figures/building-an-image.png
diff --git a/documentation/mega-manual/figures/configuration-compile-autoreconf.png b/documentation/mega-manual/figures/configuration-compile-autoreconf.png
new file mode 100644
index 0000000000..a07464f04c
--- /dev/null
+++ b/documentation/mega-manual/figures/configuration-compile-autoreconf.png
diff --git a/documentation/mega-manual/figures/cross-development-toolchains.png b/documentation/mega-manual/figures/cross-development-toolchains.png
new file mode 100644
index 0000000000..d36670a198
--- /dev/null
+++ b/documentation/mega-manual/figures/cross-development-toolchains.png
diff --git a/documentation/mega-manual/figures/dev-title.png b/documentation/mega-manual/figures/dev-title.png
new file mode 100644
index 0000000000..d3cac4a7e5
--- /dev/null
+++ b/documentation/mega-manual/figures/dev-title.png
diff --git a/documentation/mega-manual/figures/git-workflow.png b/documentation/mega-manual/figures/git-workflow.png
new file mode 100644
index 0000000000..e401330a12
--- /dev/null
+++ b/documentation/mega-manual/figures/git-workflow.png
diff --git a/documentation/mega-manual/figures/image-generation.png b/documentation/mega-manual/figures/image-generation.png
new file mode 100644
index 0000000000..ab962580c3
--- /dev/null
+++ b/documentation/mega-manual/figures/image-generation.png
diff --git a/documentation/mega-manual/figures/images.png b/documentation/mega-manual/figures/images.png
new file mode 100644
index 0000000000..d99eac1fbf
--- /dev/null
+++ b/documentation/mega-manual/figures/images.png
diff --git a/documentation/mega-manual/figures/index-downloads.png b/documentation/mega-manual/figures/index-downloads.png
new file mode 100644
index 0000000000..c907997db2
--- /dev/null
+++ b/documentation/mega-manual/figures/index-downloads.png
diff --git a/documentation/mega-manual/figures/kernel-architecture-overview.png b/documentation/mega-manual/figures/kernel-architecture-overview.png
new file mode 100755
index 0000000000..2aad172db3
--- /dev/null
+++ b/documentation/mega-manual/figures/kernel-architecture-overview.png
diff --git a/documentation/mega-manual/figures/kernel-dev-flow.png b/documentation/mega-manual/figures/kernel-dev-flow.png
new file mode 100644
index 0000000000..009105d122
--- /dev/null
+++ b/documentation/mega-manual/figures/kernel-dev-flow.png
diff --git a/documentation/mega-manual/figures/kernel-dev-title.png b/documentation/mega-manual/figures/kernel-dev-title.png
new file mode 100644
index 0000000000..7a8dd54372
--- /dev/null
+++ b/documentation/mega-manual/figures/kernel-dev-title.png
diff --git a/documentation/mega-manual/figures/kernel-overview-1.png b/documentation/mega-manual/figures/kernel-overview-1.png
new file mode 100644
index 0000000000..116c0b9bd4
--- /dev/null
+++ b/documentation/mega-manual/figures/kernel-overview-1.png
diff --git a/documentation/mega-manual/figures/kernel-overview-2-generic.png b/documentation/mega-manual/figures/kernel-overview-2-generic.png
new file mode 100644
index 0000000000..889ff1bf0d
--- /dev/null
+++ b/documentation/mega-manual/figures/kernel-overview-2-generic.png
diff --git a/documentation/mega-manual/figures/kernel-title.png b/documentation/mega-manual/figures/kernel-title.png
new file mode 100644
index 0000000000..59d86c00dc
--- /dev/null
+++ b/documentation/mega-manual/figures/kernel-title.png
diff --git a/documentation/mega-manual/figures/kernelshark-all.png b/documentation/mega-manual/figures/kernelshark-all.png
new file mode 100644
index 0000000000..99b40bafe5
--- /dev/null
+++ b/documentation/mega-manual/figures/kernelshark-all.png
diff --git a/documentation/mega-manual/figures/kernelshark-choose-events.png b/documentation/mega-manual/figures/kernelshark-choose-events.png
new file mode 100644
index 0000000000..e8dd62a571
--- /dev/null
+++ b/documentation/mega-manual/figures/kernelshark-choose-events.png
diff --git a/documentation/mega-manual/figures/kernelshark-i915-display.png b/documentation/mega-manual/figures/kernelshark-i915-display.png
new file mode 100644
index 0000000000..bb0edfb7fd
--- /dev/null
+++ b/documentation/mega-manual/figures/kernelshark-i915-display.png
diff --git a/documentation/mega-manual/figures/kernelshark-output-display.png b/documentation/mega-manual/figures/kernelshark-output-display.png
new file mode 100644
index 0000000000..ae2d0e5730
--- /dev/null
+++ b/documentation/mega-manual/figures/kernelshark-output-display.png
diff --git a/documentation/mega-manual/figures/layer-input.png b/documentation/mega-manual/figures/layer-input.png
new file mode 100644
index 0000000000..0a4f2e74f3
--- /dev/null
+++ b/documentation/mega-manual/figures/layer-input.png
diff --git a/documentation/mega-manual/figures/lttngmain0.png b/documentation/mega-manual/figures/lttngmain0.png
new file mode 100644
index 0000000000..5f60113cc3
--- /dev/null
+++ b/documentation/mega-manual/figures/lttngmain0.png
diff --git a/documentation/mega-manual/figures/oprofileui-busybox.png b/documentation/mega-manual/figures/oprofileui-busybox.png
new file mode 100644
index 0000000000..a8275c65d2
--- /dev/null
+++ b/documentation/mega-manual/figures/oprofileui-busybox.png
diff --git a/documentation/mega-manual/figures/oprofileui-copy-to-user.png b/documentation/mega-manual/figures/oprofileui-copy-to-user.png
new file mode 100644
index 0000000000..deb6470204
--- /dev/null
+++ b/documentation/mega-manual/figures/oprofileui-copy-to-user.png
diff --git a/documentation/mega-manual/figures/oprofileui-downloading.png b/documentation/mega-manual/figures/oprofileui-downloading.png
new file mode 100644
index 0000000000..57742d6723
--- /dev/null
+++ b/documentation/mega-manual/figures/oprofileui-downloading.png
diff --git a/documentation/mega-manual/figures/oprofileui-processes.png b/documentation/mega-manual/figures/oprofileui-processes.png
new file mode 100644
index 0000000000..ae547028f4
--- /dev/null
+++ b/documentation/mega-manual/figures/oprofileui-processes.png
diff --git a/documentation/mega-manual/figures/package-feeds.png b/documentation/mega-manual/figures/package-feeds.png
new file mode 100644
index 0000000000..4bc311f3d6
--- /dev/null
+++ b/documentation/mega-manual/figures/package-feeds.png
diff --git a/documentation/mega-manual/figures/patching.png b/documentation/mega-manual/figures/patching.png
new file mode 100644
index 0000000000..8ecd018502
--- /dev/null
+++ b/documentation/mega-manual/figures/patching.png
diff --git a/documentation/mega-manual/figures/perf-probe-do_fork-profile.png b/documentation/mega-manual/figures/perf-probe-do_fork-profile.png
new file mode 100644
index 0000000000..1a1070deb8
--- /dev/null
+++ b/documentation/mega-manual/figures/perf-probe-do_fork-profile.png
diff --git a/documentation/mega-manual/figures/perf-report-cycles-u.png b/documentation/mega-manual/figures/perf-report-cycles-u.png
new file mode 100644
index 0000000000..68ec6af80b
--- /dev/null
+++ b/documentation/mega-manual/figures/perf-report-cycles-u.png
diff --git a/documentation/mega-manual/figures/perf-systemwide-libc.png b/documentation/mega-manual/figures/perf-systemwide-libc.png
new file mode 100644
index 0000000000..2b72869c77
--- /dev/null
+++ b/documentation/mega-manual/figures/perf-systemwide-libc.png
diff --git a/documentation/mega-manual/figures/perf-systemwide.png b/documentation/mega-manual/figures/perf-systemwide.png
new file mode 100644
index 0000000000..12ce2444ae
--- /dev/null
+++ b/documentation/mega-manual/figures/perf-systemwide.png
diff --git a/documentation/mega-manual/figures/perf-wget-busybox-annotate-menu.png b/documentation/mega-manual/figures/perf-wget-busybox-annotate-menu.png
new file mode 100644
index 0000000000..ceb34eaead
--- /dev/null
+++ b/documentation/mega-manual/figures/perf-wget-busybox-annotate-menu.png
diff --git a/documentation/mega-manual/figures/perf-wget-busybox-annotate-udhcpc.png b/documentation/mega-manual/figures/perf-wget-busybox-annotate-udhcpc.png
new file mode 100644
index 0000000000..3581e9daa6
--- /dev/null
+++ b/documentation/mega-manual/figures/perf-wget-busybox-annotate-udhcpc.png
diff --git a/documentation/mega-manual/figures/perf-wget-busybox-debuginfo.png b/documentation/mega-manual/figures/perf-wget-busybox-debuginfo.png
new file mode 100644
index 0000000000..c317b49a4e
--- /dev/null
+++ b/documentation/mega-manual/figures/perf-wget-busybox-debuginfo.png
diff --git a/documentation/mega-manual/figures/perf-wget-busybox-dso-zoom-menu.png b/documentation/mega-manual/figures/perf-wget-busybox-dso-zoom-menu.png
new file mode 100644
index 0000000000..1913c867d0
--- /dev/null
+++ b/documentation/mega-manual/figures/perf-wget-busybox-dso-zoom-menu.png
diff --git a/documentation/mega-manual/figures/perf-wget-busybox-dso-zoom.png b/documentation/mega-manual/figures/perf-wget-busybox-dso-zoom.png
new file mode 100644
index 0000000000..a1962c437a
--- /dev/null
+++ b/documentation/mega-manual/figures/perf-wget-busybox-dso-zoom.png
diff --git a/documentation/mega-manual/figures/perf-wget-busybox-expanded-stripped.png b/documentation/mega-manual/figures/perf-wget-busybox-expanded-stripped.png
new file mode 100644
index 0000000000..b642d06c8b
--- /dev/null
+++ b/documentation/mega-manual/figures/perf-wget-busybox-expanded-stripped.png
diff --git a/documentation/mega-manual/figures/perf-wget-flat-stripped.png b/documentation/mega-manual/figures/perf-wget-flat-stripped.png
new file mode 100644
index 0000000000..c8f395ab53
--- /dev/null
+++ b/documentation/mega-manual/figures/perf-wget-flat-stripped.png
diff --git a/documentation/mega-manual/figures/perf-wget-g-copy-from-user-expanded-stripped.png b/documentation/mega-manual/figures/perf-wget-g-copy-from-user-expanded-stripped.png
new file mode 100644
index 0000000000..bb7c764ce0
--- /dev/null
+++ b/documentation/mega-manual/figures/perf-wget-g-copy-from-user-expanded-stripped.png
diff --git a/documentation/mega-manual/figures/perf-wget-g-copy-to-user-expanded-debuginfo.png b/documentation/mega-manual/figures/perf-wget-g-copy-to-user-expanded-debuginfo.png
new file mode 100644
index 0000000000..a799af5127
--- /dev/null
+++ b/documentation/mega-manual/figures/perf-wget-g-copy-to-user-expanded-debuginfo.png
diff --git a/documentation/mega-manual/figures/perf-wget-g-copy-to-user-expanded-stripped-unresolved-hidden.png b/documentation/mega-manual/figures/perf-wget-g-copy-to-user-expanded-stripped-unresolved-hidden.png
new file mode 100644
index 0000000000..e91808ae40
--- /dev/null
+++ b/documentation/mega-manual/figures/perf-wget-g-copy-to-user-expanded-stripped-unresolved-hidden.png
diff --git a/documentation/mega-manual/figures/perf-wget-g-copy-to-user-expanded-stripped.png b/documentation/mega-manual/figures/perf-wget-g-copy-to-user-expanded-stripped.png
new file mode 100644
index 0000000000..812302d0a8
--- /dev/null
+++ b/documentation/mega-manual/figures/perf-wget-g-copy-to-user-expanded-stripped.png
diff --git a/documentation/mega-manual/figures/poky-title.png b/documentation/mega-manual/figures/poky-title.png
new file mode 100644
index 0000000000..2893d84620
--- /dev/null
+++ b/documentation/mega-manual/figures/poky-title.png
diff --git a/documentation/mega-manual/figures/profile-title.png b/documentation/mega-manual/figures/profile-title.png
new file mode 100644
index 0000000000..ce5c682b58
--- /dev/null
+++ b/documentation/mega-manual/figures/profile-title.png
diff --git a/documentation/mega-manual/figures/pybootchartgui-linux-yocto.png b/documentation/mega-manual/figures/pybootchartgui-linux-yocto.png
new file mode 100644
index 0000000000..2b6bfdacf9
--- /dev/null
+++ b/documentation/mega-manual/figures/pybootchartgui-linux-yocto.png
diff --git a/documentation/mega-manual/figures/pychart-linux-yocto-rpm-nostrip.png b/documentation/mega-manual/figures/pychart-linux-yocto-rpm-nostrip.png
new file mode 100644
index 0000000000..444675c543
--- /dev/null
+++ b/documentation/mega-manual/figures/pychart-linux-yocto-rpm-nostrip.png
diff --git a/documentation/mega-manual/figures/pychart-linux-yocto-rpm.png b/documentation/mega-manual/figures/pychart-linux-yocto-rpm.png
new file mode 100644
index 0000000000..8ee35352d8
--- /dev/null
+++ b/documentation/mega-manual/figures/pychart-linux-yocto-rpm.png
diff --git a/documentation/mega-manual/figures/recipe-workflow.png b/documentation/mega-manual/figures/recipe-workflow.png
new file mode 100644
index 0000000000..c0e960b13b
--- /dev/null
+++ b/documentation/mega-manual/figures/recipe-workflow.png
diff --git a/documentation/mega-manual/figures/sched-wakeup-profile.png b/documentation/mega-manual/figures/sched-wakeup-profile.png
new file mode 100644
index 0000000000..2f25811889
--- /dev/null
+++ b/documentation/mega-manual/figures/sched-wakeup-profile.png
diff --git a/documentation/mega-manual/figures/sdk-generation.png b/documentation/mega-manual/figures/sdk-generation.png
new file mode 100644
index 0000000000..c37e2748ca
--- /dev/null
+++ b/documentation/mega-manual/figures/sdk-generation.png
diff --git a/documentation/mega-manual/figures/sdk.png b/documentation/mega-manual/figures/sdk.png
new file mode 100644
index 0000000000..a539cc52f0
--- /dev/null
+++ b/documentation/mega-manual/figures/sdk.png
diff --git a/documentation/mega-manual/figures/source-fetching.png b/documentation/mega-manual/figures/source-fetching.png
new file mode 100644
index 0000000000..26aefb50c2
--- /dev/null
+++ b/documentation/mega-manual/figures/source-fetching.png
diff --git a/documentation/mega-manual/figures/source-input.png b/documentation/mega-manual/figures/source-input.png
new file mode 100644
index 0000000000..f7515058ef
--- /dev/null
+++ b/documentation/mega-manual/figures/source-input.png
diff --git a/documentation/mega-manual/figures/source-repos.png b/documentation/mega-manual/figures/source-repos.png
new file mode 100644
index 0000000000..65c5f29a43
--- /dev/null
+++ b/documentation/mega-manual/figures/source-repos.png
diff --git a/documentation/mega-manual/figures/sysprof-callers.png b/documentation/mega-manual/figures/sysprof-callers.png
new file mode 100644
index 0000000000..640c8d9140
--- /dev/null
+++ b/documentation/mega-manual/figures/sysprof-callers.png
diff --git a/documentation/mega-manual/figures/sysprof-copy-from-user.png b/documentation/mega-manual/figures/sysprof-copy-from-user.png
new file mode 100644
index 0000000000..8d31427824
--- /dev/null
+++ b/documentation/mega-manual/figures/sysprof-copy-from-user.png
diff --git a/documentation/mega-manual/figures/sysprof-copy-to-user.png b/documentation/mega-manual/figures/sysprof-copy-to-user.png
new file mode 100644
index 0000000000..7a5bab7991
--- /dev/null
+++ b/documentation/mega-manual/figures/sysprof-copy-to-user.png
diff --git a/documentation/mega-manual/figures/user-configuration.png b/documentation/mega-manual/figures/user-configuration.png
new file mode 100644
index 0000000000..f2b3f8e7fe
--- /dev/null
+++ b/documentation/mega-manual/figures/user-configuration.png
diff --git a/documentation/mega-manual/figures/using-a-pre-built-image.png b/documentation/mega-manual/figures/using-a-pre-built-image.png
new file mode 100644
index 0000000000..b03130d123
--- /dev/null
+++ b/documentation/mega-manual/figures/using-a-pre-built-image.png
diff --git a/documentation/mega-manual/figures/yocto-environment-ref.png b/documentation/mega-manual/figures/yocto-environment-ref.png
new file mode 100644
index 0000000000..650c6c8030
--- /dev/null
+++ b/documentation/mega-manual/figures/yocto-environment-ref.png
diff --git a/documentation/mega-manual/figures/yocto-environment.png b/documentation/mega-manual/figures/yocto-environment.png
new file mode 100644
index 0000000000..82b7a55a35
--- /dev/null
+++ b/documentation/mega-manual/figures/yocto-environment.png
diff --git a/documentation/mega-manual/figures/yocto-project-transp.png b/documentation/mega-manual/figures/yocto-project-transp.png
new file mode 100755
index 0000000000..31d2b147fd
--- /dev/null
+++ b/documentation/mega-manual/figures/yocto-project-transp.png
diff --git a/documentation/mega-manual/figures/yp-download.png b/documentation/mega-manual/figures/yp-download.png
new file mode 100644
index 0000000000..5770be6883
--- /dev/null
+++ b/documentation/mega-manual/figures/yp-download.png
diff --git a/documentation/mega-manual/mega-manual-customization.xsl b/documentation/mega-manual/mega-manual-customization.xsl
new file mode 100644
index 0000000000..a8b9bd6b5b
--- /dev/null
+++ b/documentation/mega-manual/mega-manual-customization.xsl
@@ -0,0 +1,34 @@
+<?xml version='1.0'?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
+
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
+
+  <xsl:param name="generate.toc">
+   appendix  toc
+   chapter   toc
+   article   nop
+   book      nop
+   part      nop
+   preface   nop
+   qandadiv  nop
+   qandaset  nop
+   reference nop
+   section   nop
+   set       nop
+  </xsl:param>
+
+  <xsl:include href="../template/permalinks.xsl"/>
+  <xsl:include href="../template/section.title.xsl"/>
+  <xsl:include href="../template/component.title.xsl"/>
+  <xsl:include href="../template/division.title.xsl"/>
+  <xsl:include href="../template/formal.object.heading.xsl"/>
+  <xsl:include href="../template/gloss-permalinks.xsl"/>
+
+  <xsl:param name="html.stylesheet" select="'ref-style.css'" />
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="appendix.autolabel">A</xsl:param>
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+  <xsl:param name="generate.id.attributes" select="1" />
+
+</xsl:stylesheet>
diff --git a/documentation/mega-manual/mega-manual.xml b/documentation/mega-manual/mega-manual.xml
new file mode 100644
index 0000000000..01af789aed
--- /dev/null
+++ b/documentation/mega-manual/mega-manual.xml
@@ -0,0 +1,53 @@
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+
+<book id='mega-manual' lang='en'
+      xmlns:xi="http://www.w3.org/2003/XInclude"
+      xmlns="http://docbook.org/ns/docbook"
+      >
+
+    <xi:include
+        xmlns:xi="http://www.w3.org/2003/XInclude" href="../yocto-project-qs/yocto-project-qs.xml"/>
+
+<para><imagedata fileref="figures/dev-title.png" width="100%" align="left" scalefit="1" /></para>
+
+    <xi:include
+        xmlns:xi="http://www.w3.org/2003/XInclude" href="../dev-manual/dev-manual.xml"/>
+
+<para><imagedata fileref="figures/adt-title.png" width="100%" align="left" scalefit="1" /></para>
+
+    <xi:include
+        xmlns:xi="http://www.w3.org/2003/XInclude" href="../adt-manual/adt-manual.xml"/>
+
+<para><imagedata fileref="figures/bsp-title.png" width="100%" align="left" scalefit="1" /></para>
+
+    <xi:include
+        xmlns:xi="http://www.w3.org/2003/XInclude" href="../bsp-guide/bsp-guide.xml"/>
+
+<para><imagedata fileref="figures/kernel-dev-title.png" width="100%" align="left" scalefit="1" /></para>
+
+    <xi:include
+        xmlns:xi="http://www.w3.org/2003/XInclude" href="../kernel-dev/kernel-dev.xml"/>
+
+<para><imagedata fileref="figures/profile-title.png" width="100%" align="left" scalefit="1" /></para>
+
+    <xi:include
+        xmlns:xi="http://www.w3.org/2003/XInclude" href="../profile-manual/profile-manual.xml"/>
+
+<para><imagedata fileref="figures/poky-title.png" width="100%" align="left" scalefit="1" /></para>
+
+    <xi:include
+        xmlns:xi="http://www.w3.org/2003/XInclude" href="../ref-manual/ref-manual.xml"/>
+
+<!--    <index id='index'>
+      <title>Index</title>
+    </index>
+-->
+
+</book>
+
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/mega-manual/mega-style.css b/documentation/mega-manual/mega-style.css
new file mode 100644
index 0000000000..45b77ac958
--- /dev/null
+++ b/documentation/mega-manual/mega-style.css
@@ -0,0 +1,983 @@
+/*
+   Generic XHTML / DocBook XHTML CSS Stylesheet.
+
+   Browser wrangling and typographic design by
+      Oyvind Kolas / pippin@gimp.org
+
+   Customised for Poky by
+      Matthew Allum / mallum@o-hand.com
+
+   Thanks to:
+     Liam R. E. Quin
+     William Skaggs
+     Jakub Steiner
+
+   Structure
+   ---------
+
+   The stylesheet is divided into the following sections:
+
+       Positioning
+          Margins, paddings, width, font-size, clearing.
+       Decorations
+          Borders, style
+       Colors
+          Colors
+       Graphics
+          Graphical backgrounds
+       Nasty IE tweaks
+          Workarounds needed to make it work in internet explorer,
+          currently makes the stylesheet non validating, but up until
+          this point it is validating.
+       Mozilla extensions
+          Transparency for footer
+          Rounded corners on boxes
+
+*/
+
+
+  /*************** /
+ /  Positioning   /
+/ ***************/
+
+body {
+  font-family: Verdana, Sans, sans-serif;
+
+  min-width: 640px;
+  width: 80%;
+  margin:  0em auto;
+  padding: 2em 5em 5em 5em;
+  color: #333;
+}
+
+h1,h2,h3,h4,h5,h6,h7 {
+  font-family: Arial, Sans;
+  color: #00557D;
+  clear: both;
+}
+
+h1 {
+  font-size: 2em;
+  text-align: left;
+  padding: 0em 0em 0em 0em;
+  margin: 2em 0em 0em 0em;
+}
+
+h2.subtitle {
+  margin: 0.10em 0em 3.0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 1.8em;
+  padding-left: 20%;
+  font-weight: normal;
+  font-style: italic;
+}
+
+h2 {
+  margin: 2em 0em 0.66em 0em;
+  padding: 0.5em 0em 0em 0em;
+  font-size: 1.5em;
+  font-weight: bold;
+}
+
+h3.subtitle {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 142.14%;
+  text-align: right;
+}
+
+h3 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 140%;
+  font-weight: bold;
+}
+
+h4 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 120%;
+  font-weight: bold;
+}
+
+h5 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+h6 {
+  margin: 1em 0em 0em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+.authorgroup {
+  background-color: transparent;
+  background-repeat: no-repeat;
+  padding-top: 256px;
+  background-position: top;
+  margin-top: -256px;
+  padding-right: 50px;
+  margin-left: 50px;
+  text-align: center;
+  width: 600px;
+}
+
+h3.author {
+  margin: 0em 0em 0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-weight: normal;
+  font-size: 100%;
+  color: #333;
+  clear: both;
+}
+
+.author tt.email {
+  font-size: 66%;
+}
+
+.titlepage hr {
+  width: 0em;
+  clear: both;
+}
+
+.revhistory {
+  padding-top: 2em;
+  clear: both;
+}
+
+.toc,
+.list-of-tables,
+.list-of-examples,
+.list-of-figures {
+  padding: 1.33em 0em 2.5em 0em;
+  color: #00557D;
+}
+
+.toc p,
+.list-of-tables p,
+.list-of-figures p,
+.list-of-examples p {
+  padding: 0em 0em 0em 0em;
+  padding: 0em 0em 0.3em;
+  margin: 1.5em 0em 0em 0em;
+}
+
+.toc p b,
+.list-of-tables p b,
+.list-of-figures p b,
+.list-of-examples p b{
+  font-size: 100.0%;
+  font-weight: bold;
+}
+
+.toc dl,
+.list-of-tables dl,
+.list-of-figures dl,
+.list-of-examples dl {
+  margin: 0em 0em 0.5em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dt {
+  margin: 0em 0em 0em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dd {
+  margin: 0em 0em 0em 2.6em;
+  padding: 0em 0em 0em 0em;
+}
+
+div.glossary dl,
+div.variablelist dl {
+}
+
+.glossary dl dt,
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  font-weight: normal;
+  width: 20em;
+  text-align: right;
+}
+
+.variablelist dl dt {
+  margin-top: 0.5em;
+}
+
+.glossary dl dd,
+.variablelist dl dd {
+  margin-top: -1em;
+  margin-left: 25.5em;
+}
+
+.glossary dd p,
+.variablelist dd p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+
+div.calloutlist table td {
+  padding: 0em 0em 0em 0em;
+  margin: 0em 0em 0em 0em;
+}
+
+div.calloutlist table td p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+div p.copyright {
+  text-align: left;
+}
+
+div.legalnotice p.legalnotice-title {
+  margin-bottom: 0em;
+}
+
+p {
+  line-height: 1.5em;
+  margin-top: 0em;
+
+}
+
+dl {
+  padding-top: 0em;
+}
+
+hr {
+  border: solid 1px;
+}
+
+
+.mediaobject,
+.mediaobjectco {
+  text-align: center;
+}
+
+img {
+  border: none;
+}
+
+ul {
+  padding: 0em 0em 0em 1.5em;
+}
+
+ul li {
+  padding: 0em 0em 0em 0em;
+}
+
+ul li p {
+  text-align: left;
+}
+
+table {
+  width :100%;
+}
+
+th {
+  padding: 0.25em;
+  text-align: left;
+  font-weight: normal;
+  vertical-align: top;
+}
+
+td {
+  padding: 0.25em;
+  vertical-align: top;
+}
+
+p a[id] {
+  margin: 0px;
+  padding: 0px;
+  display: inline;
+  background-image: none;
+}
+
+a {
+  text-decoration: underline;
+  color: #444;
+}
+
+pre {
+    overflow: auto;
+}
+
+a:hover {
+  text-decoration: underline;
+  /*font-weight: bold;*/
+}
+
+/* This style defines how the permalink character
+   appears by itself and when hovered over with
+   the mouse. */
+
+[alt='Permalink'] { color: #eee; }
+[alt='Permalink']:hover { color: black; }
+
+
+div.informalfigure,
+div.informalexample,
+div.informaltable,
+div.figure,
+div.table,
+div.example {
+  margin: 1em 0em;
+  padding: 1em;
+  page-break-inside: avoid;
+}
+
+
+div.informalfigure p.title b,
+div.informalexample p.title b,
+div.informaltable p.title b,
+div.figure p.title b,
+div.example p.title b,
+div.table p.title b{
+    padding-top: 0em;
+    margin-top: 0em;
+    font-size: 100%;
+    font-weight: normal;
+}
+
+.mediaobject .caption,
+.mediaobject .caption p  {
+  text-align: center;
+  font-size: 80%;
+  padding-top: 0.5em;
+  padding-bottom: 0.5em;
+}
+
+.epigraph {
+  padding-left: 55%;
+  margin-bottom: 1em;
+}
+
+.epigraph p {
+  text-align: left;
+}
+
+.epigraph .quote {
+  font-style: italic;
+}
+.epigraph .attribution {
+  font-style: normal;
+  text-align: right;
+}
+
+span.application {
+  font-style: italic;
+}
+
+.programlisting {
+  font-family: monospace;
+  font-size: 80%;
+  white-space: pre;
+  margin: 1.33em 0em;
+  padding: 1.33em;
+}
+
+.tip,
+.warning,
+.caution,
+.note {
+  margin-top: 1em;
+  margin-bottom: 1em;
+
+}
+
+/* force full width of table within div */
+.tip table,
+.warning table,
+.caution table,
+.note table {
+  border: none;
+  width: 100%;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  padding: 0.8em 0.0em 0.0em 0.0em;
+  margin : 0em 0em 0em 0em;
+}
+
+.tip p,
+.warning p,
+.caution p,
+.note p {
+  margin-top: 0.5em;
+  margin-bottom: 0.5em;
+  padding-right: 1em;
+  text-align: left;
+}
+
+.acronym {
+  text-transform: uppercase;
+}
+
+b.keycap,
+.keycap {
+  padding: 0.09em 0.3em;
+  margin: 0em;
+}
+
+.itemizedlist li {
+  clear: none;
+}
+
+.filename {
+  font-size: medium;
+  font-family: Courier, monospace;
+}
+
+
+div.navheader, div.heading{
+  position: absolute;
+  left: 0em;
+  top: 0em;
+  width: 100%;
+  background-color: #cdf;
+  width: 100%;
+}
+
+div.navfooter, div.footing{
+  position: fixed;
+  left: 0em;
+  bottom: 0em;
+  background-color: #eee;
+  width: 100%;
+}
+
+
+div.navheader td,
+div.navfooter td {
+  font-size: 66%;
+}
+
+div.navheader table th {
+  /*font-family: Georgia, Times, serif;*/
+  /*font-size: x-large;*/
+  font-size: 80%;
+}
+
+div.navheader table {
+  border-left: 0em;
+  border-right: 0em;
+  border-top: 0em;
+  width: 100%;
+}
+
+div.navfooter table {
+  border-left: 0em;
+  border-right: 0em;
+  border-bottom: 0em;
+  width: 100%;
+}
+
+div.navheader table td a,
+div.navfooter table td a {
+  color: #777;
+  text-decoration: none;
+}
+
+/* normal text in the footer */
+div.navfooter table td {
+  color: black;
+}
+
+div.navheader table td a:visited,
+div.navfooter table td a:visited {
+  color: #444;
+}
+
+
+/* links in header and footer */
+div.navheader table td a:hover,
+div.navfooter table td a:hover {
+  text-decoration: underline;
+  background-color: transparent;
+  color: #33a;
+}
+
+div.navheader hr,
+div.navfooter hr {
+  display: none;
+}
+
+
+.qandaset tr.question td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.qandaset tr.answer td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+.answer td {
+  padding-bottom: 1.5em;
+}
+
+.emphasis {
+  font-weight: bold;
+}
+
+
+  /************* /
+ / decorations  /
+/ *************/
+
+.titlepage {
+}
+
+.part .title {
+}
+
+.subtitle {
+    border: none;
+}
+
+/*
+h1 {
+  border: none;
+}
+
+h2 {
+  border-top: solid 0.2em;
+  border-bottom: solid 0.06em;
+}
+
+h3 {
+  border-top: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h4 {
+  border: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h5 {
+  border: 0em;
+}
+*/
+
+.programlisting {
+  border: solid 1px;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example {
+  border: 1px solid;
+}
+
+
+
+.tip,
+.warning,
+.caution,
+.note {
+  border: 1px solid;
+}
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom: 1px solid;
+}
+
+.question td {
+  border-top: 1px solid black;
+}
+
+.answer {
+}
+
+
+b.keycap,
+.keycap {
+  border: 1px solid;
+}
+
+
+div.navheader, div.heading{
+  border-bottom: 1px solid;
+}
+
+
+div.navfooter, div.footing{
+  border-top: 1px solid;
+}
+
+  /********* /
+ /  colors  /
+/ *********/
+
+body {
+  color: #333;
+  background: white;
+}
+
+a {
+  background: transparent;
+}
+
+a:hover {
+  background-color: #dedede;
+}
+
+
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7,
+h8 {
+  background-color: transparent;
+}
+
+hr {
+  border-color: #aaa;
+}
+
+
+.tip, .warning, .caution, .note {
+  border-color: #fff;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom-color: #fff;
+}
+
+
+.warning {
+  background-color: #f0f0f2;
+}
+
+.caution {
+  background-color: #f0f0f2;
+}
+
+.tip {
+  background-color: #f0f0f2;
+}
+
+.note {
+  background-color: #f0f0f2;
+}
+
+.glossary dl dt,
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  color: #044;
+}
+
+div.figure,
+div.table,
+div.example,
+div.informalfigure,
+div.informaltable,
+div.informalexample {
+  border-color: #aaa;
+}
+
+pre.programlisting {
+  color: black;
+  background-color: #fff;
+  border-color: #aaa;
+  border-width: 2px;
+}
+
+.guimenu,
+.guilabel,
+.guimenuitem {
+  background-color: #eee;
+}
+
+
+b.keycap,
+.keycap {
+  background-color: #eee;
+  border-color: #999;
+}
+
+
+div.navheader {
+  border-color: black;
+}
+
+
+div.navfooter {
+  border-color: black;
+}
+
+
+  /*********** /
+ /  graphics  /
+/ ***********/
+
+/*
+body {
+  background-image: url("images/body_bg.jpg");
+  background-attachment: fixed;
+}
+
+.navheader,
+.note,
+.tip {
+  background-image: url("images/note_bg.jpg");
+  background-attachment: fixed;
+}
+
+.warning,
+.caution {
+  background-image: url("images/warning_bg.jpg");
+  background-attachment: fixed;
+}
+
+.figure,
+.informalfigure,
+.example,
+.informalexample,
+.table,
+.informaltable {
+  background-image: url("images/figure_bg.jpg");
+  background-attachment: fixed;
+}
+
+*/
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7{
+}
+
+/*
+Example of how to stick an image as part of the title.
+
+div.article .titlepage .title
+{
+  background-image: url("figures/white-on-black.png");
+  background-position: center;
+  background-repeat: repeat-x;
+}
+*/
+
+div.preface .titlepage .title,
+div.colophon .title,
+div.chapter .titlepage .title,
+div.article .titlepage .title
+{
+}
+
+div.section div.section .titlepage .title,
+div.sect2 .titlepage .title {
+    background: none;
+}
+
+
+h1.title {
+  background-color: transparent;
+  background-repeat: no-repeat;
+  height: 256px;
+  text-indent: -9000px;
+  overflow:hidden;
+}
+
+h2.subtitle {
+  background-color: transparent;
+  text-indent: -9000px;
+  overflow:hidden;
+  width: 0px;
+  display: none;
+}
+
+  /*************************************** /
+ /  pippin.gimp.org specific alterations  /
+/ ***************************************/
+
+/*
+div.heading, div.navheader {
+  color: #777;
+  font-size: 80%;
+  padding: 0;
+  margin: 0;
+  text-align: left;
+  position: absolute;
+  top: 0px;
+  left: 0px;
+  width: 100%;
+  height: 50px;
+  background: url('/gfx/heading_bg.png') transparent;
+  background-repeat: repeat-x;
+  background-attachment: fixed;
+  border: none;
+}
+
+div.heading a {
+  color: #444;
+}
+
+div.footing, div.navfooter {
+  border: none;
+  color: #ddd;
+  font-size: 80%;
+  text-align:right;
+
+  width: 100%;
+  padding-top: 10px;
+  position: absolute;
+  bottom: 0px;
+  left: 0px;
+
+  background: url('/gfx/footing_bg.png') transparent;
+}
+*/
+
+
+
+  /****************** /
+ /  nasty ie tweaks  /
+/ ******************/
+
+/*
+div.heading, div.navheader {
+  width:expression(document.body.clientWidth + "px");
+}
+
+div.footing, div.navfooter {
+  width:expression(document.body.clientWidth + "px");
+  margin-left:expression("-5em");
+}
+body {
+  padding:expression("4em 5em 0em 5em");
+}
+*/
+
+  /**************************************** /
+ / mozilla vendor specific css extensions  /
+/ ****************************************/
+/*
+div.navfooter, div.footing{
+  -moz-opacity: 0.8em;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example,
+.tip,
+.warning,
+.caution,
+.note {
+  -moz-border-radius: 0.5em;
+}
+
+b.keycap,
+.keycap {
+  -moz-border-radius: 0.3em;
+}
+*/
+
+table tr td table tr td {
+  display: none;
+}
+
+
+hr {
+  display: none;
+}
+
+table {
+  border: 0em;
+}
+
+ .photo {
+  float: right;
+  margin-left:   1.5em;
+  margin-bottom: 1.5em;
+  margin-top: 0em;
+  max-width:      17em;
+  border:     1px solid gray;
+  padding:    3px;
+  background: white;
+}
+ .seperator {
+   padding-top: 2em;
+   clear: both;
+  }
+
+  #validators {
+      margin-top: 5em;
+      text-align: right;
+      color: #777;
+  }
+  @media print {
+      body {
+          font-size: 8pt;
+      }
+      .noprint {
+          display: none;
+      }
+  }
+
+
+.tip,
+.note {
+   background: #f0f0f2;
+   color: #333;
+   padding: 20px;
+   margin: 20px;
+}
+
+.tip h3,
+.note h3 {
+   padding: 0em;
+   margin: 0em;
+   font-size: 2em;
+   font-weight: bold;
+   color: #333;
+}
+
+.tip a,
+.note a {
+   color: #333;
+   text-decoration: underline;
+}
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
diff --git a/documentation/poky.ent b/documentation/poky.ent
new file mode 100644
index 0000000000..4fa1a08c4f
--- /dev/null
+++ b/documentation/poky.ent
@@ -0,0 +1,66 @@
+<!ENTITY DISTRO "1.7.2">
+<!ENTITY DISTRO_COMPRESSED "172">
+<!ENTITY DISTRO_NAME "dizzy">
+<!ENTITY YOCTO_DOC_VERSION "1.7.2">
+<!ENTITY POKYVERSION "12.0.2">
+<!ENTITY POKYVERSION_COMPRESSED "1202">
+<!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
+<!ENTITY COPYRIGHT_YEAR "2010-2015">
+<!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
+<!ENTITY YOCTO_HOME_URL "http://www.yoctoproject.org">
+<!ENTITY YOCTO_LISTS_URL "http://lists.yoctoproject.org">
+<!ENTITY YOCTO_BUGZILLA_URL "http://bugzilla.yoctoproject.org">
+<!ENTITY YOCTO_WIKI_URL "https://wiki.yoctoproject.org">
+<!ENTITY YOCTO_AB_URL "http://autobuilder.yoctoproject.org">
+<!ENTITY YOCTO_GIT_URL "http://git.yoctoproject.org">
+<!ENTITY YOCTO_ADTREPO_URL "http://adtrepo.yoctoproject.org">
+<!ENTITY YOCTO_RELEASE_NOTES "&YOCTO_HOME_URL;/downloads/core/&DISTRO_NAME;&DISTRO_COMPRESSED;">
+<!ENTITY OE_HOME_URL "http://www.openembedded.org">
+<!ENTITY OE_LISTS_URL "http://lists.openembedded.org/mailman">
+<!ENTITY OE_DOCS_URL "http://docs.openembedded.org">
+<!ENTITY OH_HOME_URL "http://o-hand.com">
+<!ENTITY BITBAKE_HOME_URL "http://developer.berlios.de/projects/bitbake/">
+<!ENTITY ECLIPSE_MAIN_URL "http://www.eclipse.org/downloads">
+<!ENTITY ECLIPSE_DL_URL "http://download.eclipse.org">
+<!ENTITY ECLIPSE_DL_PLUGIN_URL "&YOCTO_DL_URL;/releases/eclipse-plugin/&DISTRO;">
+<!ENTITY ECLIPSE_UPDATES_URL "&ECLIPSE_DL_URL;/tm/updates/3.3">
+<!ENTITY ECLIPSE_INDIGO_URL "&ECLIPSE_DL_URL;/releases/indigo">
+<!ENTITY ECLIPSE_JUNO_URL "&ECLIPSE_DL_URL;/releases/juno">
+<!ENTITY ECLIPSE_KEPLER_URL "&ECLIPSE_DL_URL;/releases/kepler">
+<!ENTITY ECLIPSE_INDIGO_CDT_URL "&ECLIPSE_DL_URL;/tools/cdt/releases/indigo">
+<!ENTITY YOCTO_DOCS_URL "&YOCTO_HOME_URL;/docs">
+<!ENTITY YOCTO_SOURCES_URL "&YOCTO_HOME_URL;/sources/">
+<!ENTITY YOCTO_AB_PORT_URL "&YOCTO_AB_URL;:8010">
+<!ENTITY YOCTO_AB_NIGHTLY_URL "&YOCTO_AB_URL;/nightly/">
+<!ENTITY YOCTO_POKY_URL "&YOCTO_DL_URL;/releases/poky/">
+<!ENTITY YOCTO_RELEASE_DL_URL "&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;">
+<!ENTITY YOCTO_TOOLCHAIN_DL_URL "&YOCTO_RELEASE_DL_URL;/toolchain/">
+<!ENTITY YOCTO_ECLIPSE_DL_URL "&YOCTO_RELEASE_DL_URL;/eclipse-plugin/">
+<!ENTITY YOCTO_ADTINSTALLER_DL_URL "&YOCTO_RELEASE_DL_URL;/adt-installer">
+<!ENTITY YOCTO_POKY_DL_URL "&YOCTO_RELEASE_DL_URL;/&YOCTO_POKY;.tar.bz2">
+<!ENTITY YOCTO_MACHINES_DL_URL "&YOCTO_RELEASE_DL_URL;/machines">
+<!ENTITY YOCTO_QEMU_DL_URL "&YOCTO_MACHINES_DL_URL;/qemu">
+<!ENTITY YOCTO_PYTHON-i686_DL_URL "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-i686.tar.bz2">
+<!ENTITY YOCTO_PYTHON-x86_64_DL_URL "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-x86_64.tar.bz2">
+<!ENTITY YOCTO_DOCS_QS_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/yocto-project-qs/yocto-project-qs.html">
+<!ENTITY YOCTO_DOCS_ADT_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/adt-manual/adt-manual.html">
+<!ENTITY YOCTO_DOCS_REF_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/ref-manual/ref-manual.html">
+<!ENTITY YOCTO_DOCS_BSP_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/bsp-guide/bsp-guide.html">
+<!ENTITY YOCTO_DOCS_DEV_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/dev-manual/dev-manual.html">
+<!ENTITY YOCTO_DOCS_KERNEL_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/kernel-manual/kernel-manual.html">
+<!ENTITY YOCTO_DOCS_KERNEL_DEV_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/kernel-dev/kernel-dev.html">
+<!ENTITY YOCTO_DOCS_PROF_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/profile-manual/profile-manual.html">
+<!ENTITY YOCTO_DOCS_BB_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/bitbake-user-manual/bitbake-user-manual.html">
+<!ENTITY YOCTO_ADTPATH_DIR "/opt/poky/&DISTRO;">
+<!ENTITY YOCTO_POKY_TARBALL "&YOCTO_POKY;.tar.bz2">
+<!ENTITY OE_INIT_PATH "&YOCTO_POKY;/oe-init-build-env">
+<!ENTITY OE_INIT_FILE "oe-init-build-env">
+<!ENTITY UBUNTU_HOST_PACKAGES_ESSENTIAL "gawk wget git-core diffstat unzip texinfo gcc-multilib \
+     build-essential chrpath socat">
+<!ENTITY FEDORA_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch \
+     diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \
+     ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue socat">
+<!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git chrpath make wget python-xml \
+     diffstat texinfo python-curses patch socat">
+<!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch \
+     diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath socat">
diff --git a/documentation/profile-manual/figures/kernelshark-all.png b/documentation/profile-manual/figures/kernelshark-all.png
new file mode 100644
index 0000000000..99b40bafe5
--- /dev/null
+++ b/documentation/profile-manual/figures/kernelshark-all.png
diff --git a/documentation/profile-manual/figures/kernelshark-choose-events.png b/documentation/profile-manual/figures/kernelshark-choose-events.png
new file mode 100644
index 0000000000..e8dd62a571
--- /dev/null
+++ b/documentation/profile-manual/figures/kernelshark-choose-events.png
diff --git a/documentation/profile-manual/figures/kernelshark-i915-display.png b/documentation/profile-manual/figures/kernelshark-i915-display.png
new file mode 100644
index 0000000000..bb0edfb7fd
--- /dev/null
+++ b/documentation/profile-manual/figures/kernelshark-i915-display.png
diff --git a/documentation/profile-manual/figures/kernelshark-output-display.png b/documentation/profile-manual/figures/kernelshark-output-display.png
new file mode 100644
index 0000000000..ae2d0e5730
--- /dev/null
+++ b/documentation/profile-manual/figures/kernelshark-output-display.png
diff --git a/documentation/profile-manual/figures/lttngmain0.png b/documentation/profile-manual/figures/lttngmain0.png
new file mode 100644
index 0000000000..5f60113cc3
--- /dev/null
+++ b/documentation/profile-manual/figures/lttngmain0.png
diff --git a/documentation/profile-manual/figures/oprofileui-busybox.png b/documentation/profile-manual/figures/oprofileui-busybox.png
new file mode 100644
index 0000000000..a8275c65d2
--- /dev/null
+++ b/documentation/profile-manual/figures/oprofileui-busybox.png
diff --git a/documentation/profile-manual/figures/oprofileui-copy-to-user.png b/documentation/profile-manual/figures/oprofileui-copy-to-user.png
new file mode 100644
index 0000000000..deb6470204
--- /dev/null
+++ b/documentation/profile-manual/figures/oprofileui-copy-to-user.png
diff --git a/documentation/profile-manual/figures/oprofileui-downloading.png b/documentation/profile-manual/figures/oprofileui-downloading.png
new file mode 100644
index 0000000000..57742d6723
--- /dev/null
+++ b/documentation/profile-manual/figures/oprofileui-downloading.png
diff --git a/documentation/profile-manual/figures/oprofileui-processes.png b/documentation/profile-manual/figures/oprofileui-processes.png
new file mode 100644
index 0000000000..ae547028f4
--- /dev/null
+++ b/documentation/profile-manual/figures/oprofileui-processes.png
diff --git a/documentation/profile-manual/figures/perf-probe-do_fork-profile.png b/documentation/profile-manual/figures/perf-probe-do_fork-profile.png
new file mode 100644
index 0000000000..1a1070deb8
--- /dev/null
+++ b/documentation/profile-manual/figures/perf-probe-do_fork-profile.png
diff --git a/documentation/profile-manual/figures/perf-report-cycles-u.png b/documentation/profile-manual/figures/perf-report-cycles-u.png
new file mode 100644
index 0000000000..68ec6af80b
--- /dev/null
+++ b/documentation/profile-manual/figures/perf-report-cycles-u.png
diff --git a/documentation/profile-manual/figures/perf-systemwide-libc.png b/documentation/profile-manual/figures/perf-systemwide-libc.png
new file mode 100644
index 0000000000..2b72869c77
--- /dev/null
+++ b/documentation/profile-manual/figures/perf-systemwide-libc.png
diff --git a/documentation/profile-manual/figures/perf-systemwide.png b/documentation/profile-manual/figures/perf-systemwide.png
new file mode 100644
index 0000000000..12ce2444ae
--- /dev/null
+++ b/documentation/profile-manual/figures/perf-systemwide.png
diff --git a/documentation/profile-manual/figures/perf-wget-busybox-annotate-menu.png b/documentation/profile-manual/figures/perf-wget-busybox-annotate-menu.png
new file mode 100644
index 0000000000..ceb34eaead
--- /dev/null
+++ b/documentation/profile-manual/figures/perf-wget-busybox-annotate-menu.png
diff --git a/documentation/profile-manual/figures/perf-wget-busybox-annotate-udhcpc.png b/documentation/profile-manual/figures/perf-wget-busybox-annotate-udhcpc.png
new file mode 100644
index 0000000000..3581e9daa6
--- /dev/null
+++ b/documentation/profile-manual/figures/perf-wget-busybox-annotate-udhcpc.png
diff --git a/documentation/profile-manual/figures/perf-wget-busybox-debuginfo.png b/documentation/profile-manual/figures/perf-wget-busybox-debuginfo.png
new file mode 100644
index 0000000000..c317b49a4e
--- /dev/null
+++ b/documentation/profile-manual/figures/perf-wget-busybox-debuginfo.png
diff --git a/documentation/profile-manual/figures/perf-wget-busybox-dso-zoom-menu.png b/documentation/profile-manual/figures/perf-wget-busybox-dso-zoom-menu.png
new file mode 100644
index 0000000000..1913c867d0
--- /dev/null
+++ b/documentation/profile-manual/figures/perf-wget-busybox-dso-zoom-menu.png
diff --git a/documentation/profile-manual/figures/perf-wget-busybox-dso-zoom.png b/documentation/profile-manual/figures/perf-wget-busybox-dso-zoom.png
new file mode 100644
index 0000000000..a1962c437a
--- /dev/null
+++ b/documentation/profile-manual/figures/perf-wget-busybox-dso-zoom.png
diff --git a/documentation/profile-manual/figures/perf-wget-busybox-expanded-stripped.png b/documentation/profile-manual/figures/perf-wget-busybox-expanded-stripped.png
new file mode 100644
index 0000000000..b642d06c8b
--- /dev/null
+++ b/documentation/profile-manual/figures/perf-wget-busybox-expanded-stripped.png
diff --git a/documentation/profile-manual/figures/perf-wget-flat-stripped.png b/documentation/profile-manual/figures/perf-wget-flat-stripped.png
new file mode 100644
index 0000000000..c8f395ab53
--- /dev/null
+++ b/documentation/profile-manual/figures/perf-wget-flat-stripped.png
diff --git a/documentation/profile-manual/figures/perf-wget-g-copy-from-user-expanded-stripped.png b/documentation/profile-manual/figures/perf-wget-g-copy-from-user-expanded-stripped.png
new file mode 100644
index 0000000000..bb7c764ce0
--- /dev/null
+++ b/documentation/profile-manual/figures/perf-wget-g-copy-from-user-expanded-stripped.png
diff --git a/documentation/profile-manual/figures/perf-wget-g-copy-to-user-expanded-debuginfo.png b/documentation/profile-manual/figures/perf-wget-g-copy-to-user-expanded-debuginfo.png
new file mode 100644
index 0000000000..a799af5127
--- /dev/null
+++ b/documentation/profile-manual/figures/perf-wget-g-copy-to-user-expanded-debuginfo.png
diff --git a/documentation/profile-manual/figures/perf-wget-g-copy-to-user-expanded-stripped-unresolved-hidden.png b/documentation/profile-manual/figures/perf-wget-g-copy-to-user-expanded-stripped-unresolved-hidden.png
new file mode 100644
index 0000000000..e91808ae40
--- /dev/null
+++ b/documentation/profile-manual/figures/perf-wget-g-copy-to-user-expanded-stripped-unresolved-hidden.png
diff --git a/documentation/profile-manual/figures/perf-wget-g-copy-to-user-expanded-stripped.png b/documentation/profile-manual/figures/perf-wget-g-copy-to-user-expanded-stripped.png
new file mode 100644
index 0000000000..812302d0a8
--- /dev/null
+++ b/documentation/profile-manual/figures/perf-wget-g-copy-to-user-expanded-stripped.png
diff --git a/documentation/profile-manual/figures/profile-title.png b/documentation/profile-manual/figures/profile-title.png
new file mode 100644
index 0000000000..ce5c682b58
--- /dev/null
+++ b/documentation/profile-manual/figures/profile-title.png
diff --git a/documentation/profile-manual/figures/pybootchartgui-linux-yocto.png b/documentation/profile-manual/figures/pybootchartgui-linux-yocto.png
new file mode 100644
index 0000000000..2b6bfdacf9
--- /dev/null
+++ b/documentation/profile-manual/figures/pybootchartgui-linux-yocto.png
diff --git a/documentation/profile-manual/figures/pychart-linux-yocto-rpm-nostrip.png b/documentation/profile-manual/figures/pychart-linux-yocto-rpm-nostrip.png
new file mode 100644
index 0000000000..444675c543
--- /dev/null
+++ b/documentation/profile-manual/figures/pychart-linux-yocto-rpm-nostrip.png
diff --git a/documentation/profile-manual/figures/pychart-linux-yocto-rpm.png b/documentation/profile-manual/figures/pychart-linux-yocto-rpm.png
new file mode 100644
index 0000000000..8ee35352d8
--- /dev/null
+++ b/documentation/profile-manual/figures/pychart-linux-yocto-rpm.png
diff --git a/documentation/profile-manual/figures/sched-wakeup-profile.png b/documentation/profile-manual/figures/sched-wakeup-profile.png
new file mode 100644
index 0000000000..2f25811889
--- /dev/null
+++ b/documentation/profile-manual/figures/sched-wakeup-profile.png
diff --git a/documentation/profile-manual/figures/sysprof-callers.png b/documentation/profile-manual/figures/sysprof-callers.png
new file mode 100644
index 0000000000..640c8d9140
--- /dev/null
+++ b/documentation/profile-manual/figures/sysprof-callers.png
diff --git a/documentation/profile-manual/figures/sysprof-copy-from-user.png b/documentation/profile-manual/figures/sysprof-copy-from-user.png
new file mode 100644
index 0000000000..8d31427824
--- /dev/null
+++ b/documentation/profile-manual/figures/sysprof-copy-from-user.png
diff --git a/documentation/profile-manual/figures/sysprof-copy-to-user.png b/documentation/profile-manual/figures/sysprof-copy-to-user.png
new file mode 100644
index 0000000000..7a5bab7991
--- /dev/null
+++ b/documentation/profile-manual/figures/sysprof-copy-to-user.png
diff --git a/documentation/profile-manual/profile-manual-arch.xml b/documentation/profile-manual/profile-manual-arch.xml
new file mode 100644
index 0000000000..19d1155229
--- /dev/null
+++ b/documentation/profile-manual/profile-manual-arch.xml
@@ -0,0 +1,45 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='profile-manual-arch'>
+
+<title>Overall Architecture of the Linux Tracing and Profiling Tools</title>
+
+<section id='architecture-of-the-tracing-and-profiling-tools'>
+    <title>Architecture of the Tracing and Profiling Tools</title>
+
+    <para>
+        It may seem surprising to see a section covering an 'overall architecture'
+        for what seems to be a random collection of tracing tools that together
+        make up the Linux tracing and profiling space.
+        The fact is, however, that in recent years this seemingly disparate
+        set of tools has started to converge on a 'core' set of underlying
+        mechanisms:
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>static tracepoints</listitem>
+            <listitem>dynamic tracepoints
+                 <itemizedlist>
+                     <listitem>kprobes</listitem>
+                     <listitem>uprobes</listitem>
+                 </itemizedlist>
+            </listitem>
+            <listitem>the perf_events subsystem</listitem>
+            <listitem>debugfs</listitem>
+        </itemizedlist>
+    </para>
+
+    <informalexample>
+        <emphasis>Tying it Together:</emphasis> Rather than enumerating here how each tool makes use of
+        these common mechanisms, textboxes like this will make note of the
+        specific usages in each tool as they come up in the course
+        of the text.
+    </informalexample>
+</section>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/profile-manual/profile-manual-customization.xsl b/documentation/profile-manual/profile-manual-customization.xsl
new file mode 100644
index 0000000000..7284aec365
--- /dev/null
+++ b/documentation/profile-manual/profile-manual-customization.xsl
@@ -0,0 +1,19 @@
+<?xml version='1.0'?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
+
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
+
+  <xsl:include href="../template/permalinks.xsl"/>
+  <xsl:include href="../template/section.title.xsl"/>
+  <xsl:include href="../template/component.title.xsl"/>
+  <xsl:include href="../template/division.title.xsl"/>
+  <xsl:include href="../template/formal.object.heading.xsl"/>
+
+  <xsl:param name="html.stylesheet" select="'profile-manual-style.css'" />
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="appendix.autolabel" select="A" />
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+  <xsl:param name="generate.id.attributes" select="1" />
+
+</xsl:stylesheet>
diff --git a/documentation/profile-manual/profile-manual-eclipse-customization.xsl b/documentation/profile-manual/profile-manual-eclipse-customization.xsl
new file mode 100644
index 0000000000..e4ff6e99ab
--- /dev/null
+++ b/documentation/profile-manual/profile-manual-eclipse-customization.xsl
@@ -0,0 +1,27 @@
+<?xml version='1.0'?>
+<xsl:stylesheet
+        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+        xmlns="http://www.w3.org/1999/xhtml"
+        xmlns:fo="http://www.w3.org/1999/XSL/Format"
+        version="1.0">
+
+  <xsl:import
+          href="http://docbook.sourceforge.net/release/xsl/current/eclipse/eclipse3.xsl" />
+
+  <xsl:param name="chunker.output.indent" select="'yes'"/>
+  <xsl:param name="chunk.quietly" select="1"/>
+  <xsl:param name="chunk.first.sections" select="1"/>
+  <xsl:param name="chunk.section.depth" select="10"/>
+  <xsl:param name="use.id.as.filename" select="1"/>
+  <xsl:param name="ulink.target" select="'_self'" />
+  <xsl:param name="base.dir" select="'html/profile-manual/'"/>
+  <xsl:param name="html.stylesheet" select="'../book.css'"/>
+  <xsl:param name="eclipse.manifest" select="0"/>
+  <xsl:param name="create.plugin.xml" select="0"/>
+  <xsl:param name="suppress.navigation" select="1"/>
+  <xsl:param name="generate.index" select="0"/>
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="appendix.autolabel">A</xsl:param>
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+</xsl:stylesheet>
diff --git a/documentation/profile-manual/profile-manual-examples.xml b/documentation/profile-manual/profile-manual-examples.xml
new file mode 100644
index 0000000000..9630c6c307
--- /dev/null
+++ b/documentation/profile-manual/profile-manual-examples.xml
@@ -0,0 +1,39 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='profile-manual-examples'>
+
+<title>Real-World Examples</title>
+
+<para>
+    This chapter contains real-world examples.
+</para>
+
+<section id='slow-write-speed-on-live-images'>
+    <title>Slow Write Speed on Live Images</title>
+
+    <para>
+        In one of our previous releases (denzil), users noticed that booting
+        off of a live image and writing to disk was noticeably slower.
+        This included the boot itself, especially the first one, since first
+        boots tend to do a significant amount of writing due to certain
+        post-install scripts.
+    </para>
+
+    <para>
+        The problem (and solution) was discovered by using the Yocto tracing
+        tools, in this case 'perf stat', 'perf script', 'perf record'
+        and 'perf report'.
+    </para>
+
+    <para>
+        See all the unvarnished details of how this bug was diagnosed and
+        solved here: Yocto Bug #3049
+    </para>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/profile-manual/profile-manual-intro.xml b/documentation/profile-manual/profile-manual-intro.xml
new file mode 100644
index 0000000000..0d3f5a6099
--- /dev/null
+++ b/documentation/profile-manual/profile-manual-intro.xml
@@ -0,0 +1,102 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='profile-manual-intro'>
+
+<title>Yocto Project Profiling and Tracing Manual</title>
+    <section id='intro'>
+        <title>Introduction</title>
+
+        <para>
+            Yocto bundles a number of tracing and profiling tools - this 'HOWTO'
+            describes their basic usage and shows by example how to make use
+            of them to examine application and system behavior.
+        </para>
+
+        <para>
+            The tools presented are for the most part completely open-ended and
+            have quite good and/or extensive documentation of their own which
+            can be used to solve just about any problem you might come across
+            in Linux.
+            Each section that describes a particular tool has links to that
+            tool's documentation and website.
+        </para>
+
+        <para>
+            The purpose of this 'HOWTO' is to present a set of common and
+            generally useful tracing and profiling idioms along with their
+            application (as appropriate) to each tool, in the context of a
+            general-purpose 'drill-down' methodology that can be applied
+            to solving a large number (90%?) of problems.
+            For help with more advanced usages and problems, please see
+            the documentation and/or websites listed for each tool.
+        </para>
+
+        <para>
+            The final section of this 'HOWTO' is a collection of real-world
+            examples which we'll be continually adding to as we solve more
+            problems using the tools - feel free to add your own examples
+            to the list!
+        </para>
+    </section>
+
+    <section id='profile-manual-general-setup'>
+        <title>General Setup</title>
+
+        <para>
+            Most of the tools are available only in 'sdk' images or in images
+            built after adding 'tools-profile' to your local.conf.
+            So, in order to be able to access all of the tools described here,
+            please first build and boot an 'sdk' image e.g.
+            <literallayout class='monospaced'>
+     $ bitbake core-image-sato-sdk
+            </literallayout>
+            or alternatively by adding 'tools-profile' to the
+            EXTRA_IMAGE_FEATURES line in your local.conf:
+            <literallayout class='monospaced'>
+      EXTRA_IMAGE_FEATURES = "debug-tweaks tools-profile"
+            </literallayout>
+            If you use the 'tools-profile' method, you don't need to build an
+            sdk image - the tracing and profiling tools will be included in
+            non-sdk images as well e.g.:
+            <literallayout class='monospaced'>
+     $ bitbake core-image-sato
+            </literallayout>
+            <note><para>
+                By default, the Yocto build system strips symbols from the
+                binaries it packages, which makes it difficult to use some
+                of the tools.
+                </para><para>You can prevent that by putting the following
+                in your local.conf when you build the image:
+                </para>
+            </note>
+            <literallayout class='monospaced'>
+     INHIBIT_PACKAGE_STRIP = "1"
+            </literallayout>
+            The above setting will noticeably increase the size of your image.
+        </para>
+
+        <para>
+            If you've already built a stripped image, you can generate
+            debug packages (xxx-dbg) which you can manually install as
+            needed.
+        </para>
+
+        <para>
+            To generate debug info for packages, you can add dbg-pkgs to
+            EXTRA_IMAGE_FEATURES in local.conf. For example:
+            <literallayout class='monospaced'>
+     EXTRA_IMAGE_FEATURES = "debug-tweaks tools-profile dbg-pkgs"
+            </literallayout>
+            Additionally, in order to generate the right type of
+            debuginfo, we also need to add the following to local.conf:
+            <literallayout class='monospaced'>
+     PACKAGE_DEBUG_SPLIT_STYLE = 'debug-file-directory'
+            </literallayout>
+        </para>
+    </section>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/profile-manual/profile-manual-style.css b/documentation/profile-manual/profile-manual-style.css
new file mode 100644
index 0000000000..f3cca8536d
--- /dev/null
+++ b/documentation/profile-manual/profile-manual-style.css
@@ -0,0 +1,984 @@
+/*
+   Generic XHTML / DocBook XHTML CSS Stylesheet.
+
+   Browser wrangling and typographic design by
+      Oyvind Kolas / pippin@gimp.org
+
+   Customised for Poky by
+      Matthew Allum / mallum@o-hand.com
+
+   Thanks to:
+     Liam R. E. Quin
+     William Skaggs
+     Jakub Steiner
+
+   Structure
+   ---------
+
+   The stylesheet is divided into the following sections:
+
+       Positioning
+          Margins, paddings, width, font-size, clearing.
+       Decorations
+          Borders, style
+       Colors
+          Colors
+       Graphics
+          Graphical backgrounds
+       Nasty IE tweaks
+          Workarounds needed to make it work in internet explorer,
+          currently makes the stylesheet non validating, but up until
+          this point it is validating.
+       Mozilla extensions
+          Transparency for footer
+          Rounded corners on boxes
+
+*/
+
+
+  /*************** /
+ /  Positioning   /
+/ ***************/
+
+body {
+  font-family: Verdana, Sans, sans-serif;
+
+  min-width: 640px;
+  width: 80%;
+  margin:  0em auto;
+  padding: 2em 5em 5em 5em;
+  color: #333;
+}
+
+h1,h2,h3,h4,h5,h6,h7 {
+  font-family: Arial, Sans;
+  color: #00557D;
+  clear: both;
+}
+
+h1 {
+  font-size: 2em;
+  text-align: left;
+  padding: 0em 0em 0em 0em;
+  margin: 2em 0em 0em 0em;
+}
+
+h2.subtitle {
+  margin: 0.10em 0em 3.0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 1.8em;
+  padding-left: 20%;
+  font-weight: normal;
+  font-style: italic;
+}
+
+h2 {
+  margin: 2em 0em 0.66em 0em;
+  padding: 0.5em 0em 0em 0em;
+  font-size: 1.5em;
+  font-weight: bold;
+}
+
+h3.subtitle {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 142.14%;
+  text-align: right;
+}
+
+h3 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 140%;
+  font-weight: bold;
+}
+
+h4 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 120%;
+  font-weight: bold;
+}
+
+h5 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+h6 {
+  margin: 1em 0em 0em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+.authorgroup {
+  background-color: transparent;
+  background-repeat: no-repeat;
+  padding-top: 256px;
+  background-image: url("figures/profile-title.png");
+  background-position: left top;
+  margin-top: -256px;
+  padding-right: 50px;
+  margin-left: 0px;
+  text-align: right;
+  width: 740px;
+}
+
+h3.author {
+  margin: 0em 0me 0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-weight: normal;
+  font-size: 100%;
+  color: #333;
+  clear: both;
+}
+
+.author tt.email {
+  font-size: 66%;
+}
+
+.titlepage hr {
+  width: 0em;
+  clear: both;
+}
+
+.revhistory {
+  padding-top: 2em;
+  clear: both;
+}
+
+.toc,
+.list-of-tables,
+.list-of-examples,
+.list-of-figures {
+  padding: 1.33em 0em 2.5em 0em;
+  color: #00557D;
+}
+
+.toc p,
+.list-of-tables p,
+.list-of-figures p,
+.list-of-examples p {
+  padding: 0em 0em 0em 0em;
+  padding: 0em 0em 0.3em;
+  margin: 1.5em 0em 0em 0em;
+}
+
+.toc p b,
+.list-of-tables p b,
+.list-of-figures p b,
+.list-of-examples p b{
+  font-size: 100.0%;
+  font-weight: bold;
+}
+
+.toc dl,
+.list-of-tables dl,
+.list-of-figures dl,
+.list-of-examples dl {
+  margin: 0em 0em 0.5em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dt {
+  margin: 0em 0em 0em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dd {
+  margin: 0em 0em 0em 2.6em;
+  padding: 0em 0em 0em 0em;
+}
+
+div.glossary dl,
+div.variablelist dl {
+}
+
+.glossary dl dt,
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  font-weight: normal;
+  width: 20em;
+  text-align: right;
+}
+
+.variablelist dl dt {
+  margin-top: 0.5em;
+}
+
+.glossary dl dd,
+.variablelist dl dd {
+  margin-top: -1em;
+  margin-left: 25.5em;
+}
+
+.glossary dd p,
+.variablelist dd p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+
+div.calloutlist table td {
+  padding: 0em 0em 0em 0em;
+  margin: 0em 0em 0em 0em;
+}
+
+div.calloutlist table td p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+div p.copyright {
+  text-align: left;
+}
+
+div.legalnotice p.legalnotice-title {
+  margin-bottom: 0em;
+}
+
+p {
+  line-height: 1.5em;
+  margin-top: 0em;
+
+}
+
+dl {
+  padding-top: 0em;
+}
+
+hr {
+  border: solid 1px;
+}
+
+
+.mediaobject,
+.mediaobjectco {
+  text-align: center;
+}
+
+img {
+  border: none;
+}
+
+ul {
+  padding: 0em 0em 0em 1.5em;
+}
+
+ul li {
+  padding: 0em 0em 0em 0em;
+}
+
+ul li p {
+  text-align: left;
+}
+
+table {
+  width :100%;
+}
+
+th {
+  padding: 0.25em;
+  text-align: left;
+  font-weight: normal;
+  vertical-align: top;
+}
+
+td {
+  padding: 0.25em;
+  vertical-align: top;
+}
+
+p a[id] {
+  margin: 0px;
+  padding: 0px;
+  display: inline;
+  background-image: none;
+}
+
+a {
+  text-decoration: underline;
+  color: #444;
+}
+
+pre {
+    overflow: auto;
+}
+
+a:hover {
+  text-decoration: underline;
+  /*font-weight: bold;*/
+}
+
+/* This style defines how the permalink character
+   appears by itself and when hovered over with
+   the mouse. */
+
+[alt='Permalink'] { color: #eee; }
+[alt='Permalink']:hover { color: black; }
+
+
+div.informalfigure,
+div.informalexample,
+div.informaltable,
+div.figure,
+div.table,
+div.example {
+  margin: 1em 0em;
+  padding: 1em;
+  page-break-inside: avoid;
+}
+
+
+div.informalfigure p.title b,
+div.informalexample p.title b,
+div.informaltable p.title b,
+div.figure p.title b,
+div.example p.title b,
+div.table p.title b{
+    padding-top: 0em;
+    margin-top: 0em;
+    font-size: 100%;
+    font-weight: normal;
+}
+
+.mediaobject .caption,
+.mediaobject .caption p  {
+  text-align: center;
+  font-size: 80%;
+  padding-top: 0.5em;
+  padding-bottom: 0.5em;
+}
+
+.epigraph {
+  padding-left: 55%;
+  margin-bottom: 1em;
+}
+
+.epigraph p {
+  text-align: left;
+}
+
+.epigraph .quote {
+  font-style: italic;
+}
+.epigraph .attribution {
+  font-style: normal;
+  text-align: right;
+}
+
+span.application {
+  font-style: italic;
+}
+
+.programlisting {
+  font-family: monospace;
+  font-size: 80%;
+  white-space: pre;
+  margin: 1.33em 0em;
+  padding: 1.33em;
+}
+
+.tip,
+.warning,
+.caution,
+.note {
+  margin-top: 1em;
+  margin-bottom: 1em;
+
+}
+
+/* force full width of table within div */
+.tip table,
+.warning table,
+.caution table,
+.note table {
+  border: none;
+  width: 100%;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  padding: 0.8em 0.0em 0.0em 0.0em;
+  margin : 0em 0em 0em 0em;
+}
+
+.tip p,
+.warning p,
+.caution p,
+.note p {
+  margin-top: 0.5em;
+  margin-bottom: 0.5em;
+  padding-right: 1em;
+  text-align: left;
+}
+
+.acronym {
+  text-transform: uppercase;
+}
+
+b.keycap,
+.keycap {
+  padding: 0.09em 0.3em;
+  margin: 0em;
+}
+
+.itemizedlist li {
+  clear: none;
+}
+
+.filename {
+  font-size: medium;
+  font-family: Courier, monospace;
+}
+
+
+div.navheader, div.heading{
+  position: absolute;
+  left: 0em;
+  top: 0em;
+  width: 100%;
+  background-color: #cdf;
+  width: 100%;
+}
+
+div.navfooter, div.footing{
+  position: fixed;
+  left: 0em;
+  bottom: 0em;
+  background-color: #eee;
+  width: 100%;
+}
+
+
+div.navheader td,
+div.navfooter td {
+  font-size: 66%;
+}
+
+div.navheader table th {
+  /*font-family: Georgia, Times, serif;*/
+  /*font-size: x-large;*/
+  font-size: 80%;
+}
+
+div.navheader table {
+  border-left: 0em;
+  border-right: 0em;
+  border-top: 0em;
+  width: 100%;
+}
+
+div.navfooter table {
+  border-left: 0em;
+  border-right: 0em;
+  border-bottom: 0em;
+  width: 100%;
+}
+
+div.navheader table td a,
+div.navfooter table td a {
+  color: #777;
+  text-decoration: none;
+}
+
+/* normal text in the footer */
+div.navfooter table td {
+  color: black;
+}
+
+div.navheader table td a:visited,
+div.navfooter table td a:visited {
+  color: #444;
+}
+
+
+/* links in header and footer */
+div.navheader table td a:hover,
+div.navfooter table td a:hover {
+  text-decoration: underline;
+  background-color: transparent;
+  color: #33a;
+}
+
+div.navheader hr,
+div.navfooter hr {
+  display: none;
+}
+
+
+.qandaset tr.question td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.qandaset tr.answer td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+.answer td {
+  padding-bottom: 1.5em;
+}
+
+.emphasis {
+  font-weight: bold;
+}
+
+
+  /************* /
+ / decorations  /
+/ *************/
+
+.titlepage {
+}
+
+.part .title {
+}
+
+.subtitle {
+    border: none;
+}
+
+/*
+h1 {
+  border: none;
+}
+
+h2 {
+  border-top: solid 0.2em;
+  border-bottom: solid 0.06em;
+}
+
+h3 {
+  border-top: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h4 {
+  border: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h5 {
+  border: 0em;
+}
+*/
+
+.programlisting {
+  border: solid 1px;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example {
+  border: 1px solid;
+}
+
+
+
+.tip,
+.warning,
+.caution,
+.note {
+  border: 1px solid;
+}
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom: 1px solid;
+}
+
+.question td {
+  border-top: 1px solid black;
+}
+
+.answer {
+}
+
+
+b.keycap,
+.keycap {
+  border: 1px solid;
+}
+
+
+div.navheader, div.heading{
+  border-bottom: 1px solid;
+}
+
+
+div.navfooter, div.footing{
+  border-top: 1px solid;
+}
+
+  /********* /
+ /  colors  /
+/ *********/
+
+body {
+  color: #333;
+  background: white;
+}
+
+a {
+  background: transparent;
+}
+
+a:hover {
+  background-color: #dedede;
+}
+
+
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7,
+h8 {
+  background-color: transparent;
+}
+
+hr {
+  border-color: #aaa;
+}
+
+
+.tip, .warning, .caution, .note {
+  border-color: #fff;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom-color: #fff;
+}
+
+
+.warning {
+  background-color: #f0f0f2;
+}
+
+.caution {
+  background-color: #f0f0f2;
+}
+
+.tip {
+  background-color: #f0f0f2;
+}
+
+.note {
+  background-color: #f0f0f2;
+}
+
+.glossary dl dt,
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  color: #044;
+}
+
+div.figure,
+div.table,
+div.example,
+div.informalfigure,
+div.informaltable,
+div.informalexample {
+  border-color: #aaa;
+}
+
+pre.programlisting {
+  color: black;
+  background-color: #fff;
+  border-color: #aaa;
+  border-width: 2px;
+}
+
+.guimenu,
+.guilabel,
+.guimenuitem {
+  background-color: #eee;
+}
+
+
+b.keycap,
+.keycap {
+  background-color: #eee;
+  border-color: #999;
+}
+
+
+div.navheader {
+  border-color: black;
+}
+
+
+div.navfooter {
+  border-color: black;
+}
+
+
+  /*********** /
+ /  graphics  /
+/ ***********/
+
+/*
+body {
+  background-image: url("images/body_bg.jpg");
+  background-attachment: fixed;
+}
+
+.navheader,
+.note,
+.tip {
+  background-image: url("images/note_bg.jpg");
+  background-attachment: fixed;
+}
+
+.warning,
+.caution {
+  background-image: url("images/warning_bg.jpg");
+  background-attachment: fixed;
+}
+
+.figure,
+.informalfigure,
+.example,
+.informalexample,
+.table,
+.informaltable {
+  background-image: url("images/figure_bg.jpg");
+  background-attachment: fixed;
+}
+
+*/
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7{
+}
+
+/*
+Example of how to stick an image as part of the title.
+
+div.article .titlepage .title
+{
+  background-image: url("figures/white-on-black.png");
+  background-position: center;
+  background-repeat: repeat-x;
+}
+*/
+
+div.preface .titlepage .title,
+div.colophon .title,
+div.chapter .titlepage .title,
+div.article .titlepage .title
+{
+}
+
+div.section div.section .titlepage .title,
+div.sect2 .titlepage .title {
+    background: none;
+}
+
+
+h1.title {
+  background-color: transparent;
+  background-repeat: no-repeat;
+  height: 256px;
+  text-indent: -9000px;
+  overflow:hidden;
+}
+
+h2.subtitle {
+  background-color: transparent;
+  text-indent: -9000px;
+  overflow:hidden;
+  width: 0px;
+  display: none;
+}
+
+  /*************************************** /
+ /  pippin.gimp.org specific alterations  /
+/ ***************************************/
+
+/*
+div.heading, div.navheader {
+  color: #777;
+  font-size: 80%;
+  padding: 0;
+  margin: 0;
+  text-align: left;
+  position: absolute;
+  top: 0px;
+  left: 0px;
+  width: 100%;
+  height: 50px;
+  background: url('/gfx/heading_bg.png') transparent;
+  background-repeat: repeat-x;
+  background-attachment: fixed;
+  border: none;
+}
+
+div.heading a {
+  color: #444;
+}
+
+div.footing, div.navfooter {
+  border: none;
+  color: #ddd;
+  font-size: 80%;
+  text-align:right;
+
+  width: 100%;
+  padding-top: 10px;
+  position: absolute;
+  bottom: 0px;
+  left: 0px;
+
+  background: url('/gfx/footing_bg.png') transparent;
+}
+*/
+
+
+
+  /****************** /
+ /  nasty ie tweaks  /
+/ ******************/
+
+/*
+div.heading, div.navheader {
+  width:expression(document.body.clientWidth + "px");
+}
+
+div.footing, div.navfooter {
+  width:expression(document.body.clientWidth + "px");
+  margin-left:expression("-5em");
+}
+body {
+  padding:expression("4em 5em 0em 5em");
+}
+*/
+
+  /**************************************** /
+ / mozilla vendor specific css extensions  /
+/ ****************************************/
+/*
+div.navfooter, div.footing{
+  -moz-opacity: 0.8em;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example,
+.tip,
+.warning,
+.caution,
+.note {
+  -moz-border-radius: 0.5em;
+}
+
+b.keycap,
+.keycap {
+  -moz-border-radius: 0.3em;
+}
+*/
+
+table tr td table tr td {
+  display: none;
+}
+
+
+hr {
+  display: none;
+}
+
+table {
+  border: 0em;
+}
+
+ .photo {
+  float: right;
+  margin-left:   1.5em;
+  margin-bottom: 1.5em;
+  margin-top: 0em;
+  max-width:      17em;
+  border:     1px solid gray;
+  padding:    3px;
+  background: white;
+}
+ .seperator {
+   padding-top: 2em;
+   clear: both;
+  }
+
+  #validators {
+      margin-top: 5em;
+      text-align: right;
+      color: #777;
+  }
+  @media print {
+      body {
+          font-size: 8pt;
+      }
+      .noprint {
+          display: none;
+      }
+  }
+
+
+.tip,
+.note {
+   background: #f0f0f2;
+   color: #333;
+   padding: 20px;
+   margin: 20px;
+}
+
+.tip h3,
+.note h3 {
+   padding: 0em;
+   margin: 0em;
+   font-size: 2em;
+   font-weight: bold;
+   color: #333;
+}
+
+.tip a,
+.note a {
+   color: #333;
+   text-decoration: underline;
+}
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
diff --git a/documentation/profile-manual/profile-manual-usage.xml b/documentation/profile-manual/profile-manual-usage.xml
new file mode 100644
index 0000000000..95ad73909c
--- /dev/null
+++ b/documentation/profile-manual/profile-manual-usage.xml
@@ -0,0 +1,3695 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='profile-manual-usage'>
+
+<title>Basic Usage (with examples) for each of the Yocto Tracing Tools</title>
+
+<para>
+    This chapter presents basic usage examples for each of the tracing
+    tools.
+</para>
+
+<section id='profile-manual-perf'>
+    <title>perf</title>
+
+    <para>
+        The 'perf' tool is the profiling and tracing tool that comes
+        bundled with the Linux kernel.
+    </para>
+
+    <para>
+        Don't let the fact that it's part of the kernel fool you into thinking
+        that it's only for tracing and profiling the kernel - you can indeed
+        use it to trace and profile just the kernel, but you can also use it
+        to profile specific applications separately (with or without kernel
+        context), and you can also use it to trace and profile the kernel
+        and all applications on the system simultaneously to gain a system-wide
+        view of what's going on.
+    </para>
+
+    <para>
+        In many ways, perf aims to be a superset of all the tracing and profiling
+        tools available in Linux today, including all the other tools covered
+        in this HOWTO. The past couple of years have seen perf subsume a lot
+        of the functionality of those other tools and, at the same time, those
+        other tools have removed large portions of their previous functionality
+        and replaced it with calls to the equivalent functionality now
+        implemented by the perf subsystem. Extrapolation suggests that at
+        some point those other tools will simply become completely redundant
+        and go away; until then, we'll cover those other tools in these pages
+        and in many cases show how the same things can be accomplished in
+        perf and the other tools when it seems useful to do so.
+    </para>
+
+    <para>
+        The coverage below details some of the most common ways you'll likely
+        want to apply the tool; full documentation can be found either within
+        the tool itself or in the man pages at
+        <ulink url='http://linux.die.net/man/1/perf'>perf(1)</ulink>.
+    </para>
+
+    <section id='perf-setup'>
+        <title>Setup</title>
+
+        <para>
+            For this section, we'll assume you've already performed the basic
+            setup outlined in the General Setup section.
+        </para>
+
+        <para>
+            In particular, you'll get the most mileage out of perf if you
+            profile an image built with INHIBIT_PACKAGE_STRIP = "1" in your
+            local.conf.
+        </para>
+
+        <para>
+            perf runs on the target system for the most part. You can archive
+            profile data and copy it to the host for analysis, but for the
+            rest of this document we assume you've ssh'ed to the host and
+            will be running the perf commands on the target.
+        </para>
+    </section>
+
+    <section id='perf-basic-usage'>
+        <title>Basic Usage</title>
+
+        <para>
+            The perf tool is pretty much self-documenting. To remind yourself
+            of the available commands, simply type 'perf', which will show you
+            basic usage along with the available perf subcommands:
+            <literallayout class='monospaced'>
+     root@crownbay:~# perf
+
+     usage: perf [--version] [--help] COMMAND [ARGS]
+
+     The most commonly used perf commands are:
+       annotate        Read perf.data (created by perf record) and display annotated code
+       archive         Create archive with object files with build-ids found in perf.data file
+       bench           General framework for benchmark suites
+       buildid-cache   Manage build-id cache.
+       buildid-list    List the buildids in a perf.data file
+       diff            Read two perf.data files and display the differential profile
+       evlist          List the event names in a perf.data file
+       inject          Filter to augment the events stream with additional information
+       kmem            Tool to trace/measure kernel memory(slab) properties
+       kvm             Tool to trace/measure kvm guest os
+       list            List all symbolic event types
+       lock            Analyze lock events
+       probe           Define new dynamic tracepoints
+       record          Run a command and record its profile into perf.data
+       report          Read perf.data (created by perf record) and display the profile
+       sched           Tool to trace/measure scheduler properties (latencies)
+       script          Read perf.data (created by perf record) and display trace output
+       stat            Run a command and gather performance counter statistics
+       test            Runs sanity tests.
+       timechart       Tool to visualize total system behavior during a workload
+       top             System profiling tool.
+
+     See 'perf help COMMAND' for more information on a specific command.
+            </literallayout>
+        </para>
+
+        <section id='using-perf-to-do-basic-profiling'>
+            <title>Using perf to do Basic Profiling</title>
+
+            <para>
+                As a simple test case, we'll profile the 'wget' of a fairly large
+                file, which is a minimally interesting case because it has both
+                file and network I/O aspects, and at least in the case of standard
+                Yocto images, it's implemented as part of busybox, so the methods
+                we use to analyze it can be used in a very similar way to the whole
+                host of supported busybox applets in Yocto.
+                <literallayout class='monospaced'>
+     root@crownbay:~# rm linux-2.6.19.2.tar.bz2; \
+     wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>
+                </literallayout>
+                The quickest and easiest way to get some basic overall data about
+                what's going on for a particular workload is to profile it using
+                'perf stat'. 'perf stat' basically profiles using a few default
+                counters and displays the summed counts at the end of the run:
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf stat wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>
+     Connecting to downloads.yoctoproject.org (140.211.169.59:80)
+     linux-2.6.19.2.tar.b 100% |***************************************************| 41727k  0:00:00 ETA
+
+     Performance counter stats for 'wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>':
+
+           4597.223902 task-clock                #    0.077 CPUs utilized
+                 23568 context-switches          #    0.005 M/sec
+                    68 CPU-migrations            #    0.015 K/sec
+                   241 page-faults               #    0.052 K/sec
+            3045817293 cycles                    #    0.663 GHz
+       &lt;not supported&gt; stalled-cycles-frontend
+       &lt;not supported&gt; stalled-cycles-backend
+             858909167 instructions              #    0.28  insns per cycle
+             165441165 branches                  #   35.987 M/sec
+              19550329 branch-misses             #   11.82% of all branches
+
+          59.836627620 seconds time elapsed
+                </literallayout>
+                Many times such a simple-minded test doesn't yield much of
+                interest, but sometimes it does (see Real-world Yocto bug
+                (slow loop-mounted write speed)).
+            </para>
+
+            <para>
+                Also, note that 'perf stat' isn't restricted to a fixed set of
+                counters - basically any event listed in the output of 'perf list'
+                can be tallied by 'perf stat'. For example, suppose we wanted to
+                see a summary of all the events related to kernel memory
+                allocation/freeing along with cache hits and misses:
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf stat -e kmem:* -e cache-references -e cache-misses wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>
+     Connecting to downloads.yoctoproject.org (140.211.169.59:80)
+     linux-2.6.19.2.tar.b 100% |***************************************************| 41727k  0:00:00 ETA
+
+     Performance counter stats for 'wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>':
+
+                  5566 kmem:kmalloc
+                125517 kmem:kmem_cache_alloc
+                     0 kmem:kmalloc_node
+                     0 kmem:kmem_cache_alloc_node
+                 34401 kmem:kfree
+                 69920 kmem:kmem_cache_free
+                   133 kmem:mm_page_free
+                    41 kmem:mm_page_free_batched
+                 11502 kmem:mm_page_alloc
+                 11375 kmem:mm_page_alloc_zone_locked
+                     0 kmem:mm_page_pcpu_drain
+                     0 kmem:mm_page_alloc_extfrag
+              66848602 cache-references
+               2917740 cache-misses              #    4.365 % of all cache refs
+
+          44.831023415 seconds time elapsed
+                </literallayout>
+                So 'perf stat' gives us a nice easy way to get a quick overview of
+                what might be happening for a set of events, but normally we'd
+                need a little more detail in order to understand what's going on
+                in a way that we can act on in a useful way.
+            </para>
+
+            <para>
+                To dive down into a next level of detail, we can use 'perf
+                record'/'perf report' which will collect profiling data and
+                present it to use using an interactive text-based UI (or
+                simply as text if we specify --stdio to 'perf report').
+            </para>
+
+            <para>
+                As our first attempt at profiling this workload, we'll simply
+                run 'perf record', handing it the workload we want to profile
+                (everything after 'perf record' and any perf options we hand
+                it - here none - will be executed in a new shell). perf collects
+                samples until the process exits and records them in a file named
+                'perf.data' in the current working directory.
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf record wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>
+
+     Connecting to downloads.yoctoproject.org (140.211.169.59:80)
+     linux-2.6.19.2.tar.b 100% |************************************************| 41727k  0:00:00 ETA
+     [ perf record: Woken up 1 times to write data ]
+     [ perf record: Captured and wrote 0.176 MB perf.data (~7700 samples) ]
+            </literallayout>
+            To see the results in a 'text-based UI' (tui), simply run
+            'perf report', which will read the perf.data file in the current
+            working directory and display the results in an interactive UI:
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf report
+                </literallayout>
+            </para>
+
+            <para>
+                <imagedata fileref="figures/perf-wget-flat-stripped.png" width="6in" depth="7in" align="center" scalefit="1" />
+            </para>
+
+            <para>
+                The above screenshot displays a 'flat' profile, one entry for
+                each 'bucket' corresponding to the functions that were profiled
+                during the profiling run, ordered from the most popular to the
+                least (perf has options to sort in various orders and keys as
+                well as display entries only above a certain threshold and so
+                on - see the perf documentation for details). Note that this
+                includes both userspace functions (entries containing a [.]) and
+                kernel functions accounted to the process (entries containing
+                a [k]). (perf has command-line modifiers that can be used to
+                restrict the profiling to kernel or userspace, among others).
+            </para>
+
+            <para>
+                Notice also that the above report shows an entry for 'busybox',
+                which is the executable that implements 'wget' in Yocto, but that
+                instead of a useful function name in that entry, it displays
+                a not-so-friendly hex value instead. The steps below will show
+                how to fix that problem.
+            </para>
+
+            <para>
+                Before we do that, however, let's try running a different profile,
+                one which shows something a little more interesting. The only
+                difference between the new profile and the previous one is that
+                we'll add the -g option, which will record not just the address
+                of a sampled function, but the entire callchain to the sampled
+                function as well:
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf record -g wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>
+     Connecting to downloads.yoctoproject.org (140.211.169.59:80)
+     linux-2.6.19.2.tar.b 100% |************************************************| 41727k  0:00:00 ETA
+     [ perf record: Woken up 3 times to write data ]
+     [ perf record: Captured and wrote 0.652 MB perf.data (~28476 samples) ]
+
+
+     root@crownbay:~# perf report
+                </literallayout>
+            </para>
+
+            <para>
+                <imagedata fileref="figures/perf-wget-g-copy-to-user-expanded-stripped.png" width="6in" depth="7in" align="center" scalefit="1" />
+            </para>
+
+            <para>
+                Using the callgraph view, we can actually see not only which
+                functions took the most time, but we can also see a summary of
+                how those functions were called and learn something about how the
+                program interacts with the kernel in the process.
+            </para>
+
+            <para>
+                Notice that each entry in the above screenshot now contains a '+'
+                on the left-hand side. This means that we can expand the entry and
+                drill down into the callchains that feed into that entry.
+                Pressing 'enter' on any one of them will expand the callchain
+                (you can also press 'E' to expand them all at the same time or 'C'
+                to collapse them all).
+            </para>
+
+            <para>
+                In the screenshot above, we've toggled the __copy_to_user_ll()
+                entry and several subnodes all the way down. This lets us see
+                which callchains contributed to the profiled __copy_to_user_ll()
+                function which contributed 1.77% to the total profile.
+            </para>
+
+            <para>
+                As a bit of background explanation for these callchains, think
+                about what happens at a high level when you run wget to get a file
+                out on the network. Basically what happens is that the data comes
+                into the kernel via the network connection (socket) and is passed
+                to the userspace program 'wget' (which is actually a part of
+                busybox, but that's not important for now), which takes the buffers
+                the kernel passes to it and writes it to a disk file to save it.
+            </para>
+
+            <para>
+                The part of this process that we're looking at in the above call
+                stacks is the part where the kernel passes the data it's read from
+                the socket down to wget i.e. a copy-to-user.
+            </para>
+
+            <para>
+                Notice also that here there's also a case where the hex value
+                is displayed in the callstack, here in the expanded
+                sys_clock_gettime() function. Later we'll see it resolve to a
+                userspace function call in busybox.
+            </para>
+
+            <para>
+                <imagedata fileref="figures/perf-wget-g-copy-from-user-expanded-stripped.png" width="6in" depth="7in" align="center" scalefit="1" />
+            </para>
+
+            <para>
+                The above screenshot shows the other half of the journey for the
+                data - from the wget program's userspace buffers to disk. To get
+                the buffers to disk, the wget program issues a write(2), which
+                does a copy-from-user to the kernel, which then takes care via
+                some circuitous path (probably also present somewhere in the
+                profile data), to get it safely to disk.
+            </para>
+
+            <para>
+                Now that we've seen the basic layout of the profile data and the
+                basics of how to extract useful information out of it, let's get
+                back to the task at hand and see if we can get some basic idea
+                about where the time is spent in the program we're profiling,
+                wget. Remember that wget is actually implemented as an applet
+                in busybox, so while the process name is 'wget', the executable
+                we're actually interested in is busybox. So let's expand the
+                first entry containing busybox:
+            </para>
+
+            <para>
+                <imagedata fileref="figures/perf-wget-busybox-expanded-stripped.png" width="6in" depth="7in" align="center" scalefit="1" />
+            </para>
+
+            <para>
+                Again, before we expanded we saw that the function was labeled
+                with a hex value instead of a symbol as with most of the kernel
+                entries. Expanding the busybox entry doesn't make it any better.
+            </para>
+
+            <para>
+                The problem is that perf can't find the symbol information for the
+                busybox binary, which is actually stripped out by the Yocto build
+                system.
+            </para>
+
+            <para>
+                One way around that is to put the following in your local.conf
+                when you build the image:
+                <literallayout class='monospaced'>
+     INHIBIT_PACKAGE_STRIP = "1"
+                </literallayout>
+                However, we already have an image with the binaries stripped,
+                so what can we do to get perf to resolve the symbols? Basically
+                we need to install the debuginfo for the busybox package.
+            </para>
+
+            <para>
+                To generate the debug info for the packages in the image, we can
+                add dbg-pkgs to EXTRA_IMAGE_FEATURES in local.conf. For example:
+                <literallayout class='monospaced'>
+     EXTRA_IMAGE_FEATURES = "debug-tweaks tools-profile dbg-pkgs"
+                </literallayout>
+                Additionally, in order to generate the type of debuginfo that
+                perf understands, we also need to add the following to local.conf:
+                <literallayout class='monospaced'>
+     PACKAGE_DEBUG_SPLIT_STYLE = 'debug-file-directory'
+                </literallayout>
+                Once we've done that, we can install the debuginfo for busybox.
+                The debug packages once built can be found in
+                build/tmp/deploy/rpm/* on the host system. Find the
+                busybox-dbg-...rpm file and copy it to the target. For example:
+                <literallayout class='monospaced'>
+     [trz@empanada core2]$ scp /home/trz/yocto/crownbay-tracing-dbg/build/tmp/deploy/rpm/core2_32/busybox-dbg-1.20.2-r2.core2_32.rpm root@192.168.1.31:
+     root@192.168.1.31's password:
+     busybox-dbg-1.20.2-r2.core2_32.rpm                     100% 1826KB   1.8MB/s   00:01
+                </literallayout>
+                Now install the debug rpm on the target:
+                <literallayout class='monospaced'>
+     root@crownbay:~# rpm -i busybox-dbg-1.20.2-r2.core2_32.rpm
+                </literallayout>
+                Now that the debuginfo is installed, we see that the busybox
+                entries now display their functions symbolically:
+            </para>
+
+            <para>
+                <imagedata fileref="figures/perf-wget-busybox-debuginfo.png" width="6in" depth="7in" align="center" scalefit="1" />
+            </para>
+
+            <para>
+                If we expand one of the entries and press 'enter' on a leaf node,
+                we're presented with a menu of actions we can take to get more
+                information related to that entry:
+            </para>
+
+            <para>
+                <imagedata fileref="figures/perf-wget-busybox-dso-zoom-menu.png" width="6in" depth="2in" align="center" scalefit="1" />
+            </para>
+
+            <para>
+                One of these actions allows us to show a view that displays a
+                busybox-centric view of the profiled functions (in this case we've
+                also expanded all the nodes using the 'E' key):
+            </para>
+
+            <para>
+                <imagedata fileref="figures/perf-wget-busybox-dso-zoom.png" width="6in" depth="7in" align="center" scalefit="1" />
+            </para>
+
+            <para>
+                Finally, we can see that now that the busybox debuginfo is
+                installed, the previously unresolved symbol in the
+                sys_clock_gettime() entry mentioned previously is now resolved,
+                and shows that the sys_clock_gettime system call that was the
+                source of 6.75% of the copy-to-user overhead was initiated by
+                the handle_input() busybox function:
+            </para>
+
+            <para>
+                <imagedata fileref="figures/perf-wget-g-copy-to-user-expanded-debuginfo.png" width="6in" depth="7in" align="center" scalefit="1" />
+            </para>
+
+            <para>
+                At the lowest level of detail, we can dive down to the assembly
+                level and see which instructions caused the most overhead in a
+                function. Pressing 'enter' on the 'udhcpc_main' function, we're
+                again presented with a menu:
+            </para>
+
+            <para>
+                <imagedata fileref="figures/perf-wget-busybox-annotate-menu.png" width="6in" depth="2in" align="center" scalefit="1" />
+            </para>
+
+            <para>
+                Selecting 'Annotate udhcpc_main', we get a detailed listing of
+                percentages by instruction for the udhcpc_main function. From the
+                display, we can see that over 50% of the time spent in this
+                function is taken up by a couple tests and the move of a
+                constant (1) to a register:
+            </para>
+
+            <para>
+                <imagedata fileref="figures/perf-wget-busybox-annotate-udhcpc.png" width="6in" depth="7in" align="center" scalefit="1" />
+            </para>
+
+            <para>
+                As a segue into tracing, let's try another profile using a
+                different counter, something other than the default 'cycles'.
+            </para>
+
+            <para>
+                The tracing and profiling infrastructure in Linux has become
+                unified in a way that allows us to use the same tool with a
+                completely different set of counters, not just the standard
+                hardware counters that traditional tools have had to restrict
+                themselves to (of course the traditional tools can also make use
+                of the expanded possibilities now available to them, and in some
+                cases have, as mentioned previously).
+            </para>
+
+            <para>
+                We can get a list of the available events that can be used to
+                profile a workload via 'perf list':
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf list
+
+     List of pre-defined events (to be used in -e):
+      cpu-cycles OR cycles                               [Hardware event]
+      stalled-cycles-frontend OR idle-cycles-frontend    [Hardware event]
+      stalled-cycles-backend OR idle-cycles-backend      [Hardware event]
+      instructions                                       [Hardware event]
+      cache-references                                   [Hardware event]
+      cache-misses                                       [Hardware event]
+      branch-instructions OR branches                    [Hardware event]
+      branch-misses                                      [Hardware event]
+      bus-cycles                                         [Hardware event]
+      ref-cycles                                         [Hardware event]
+
+      cpu-clock                                          [Software event]
+      task-clock                                         [Software event]
+      page-faults OR faults                              [Software event]
+      minor-faults                                       [Software event]
+      major-faults                                       [Software event]
+      context-switches OR cs                             [Software event]
+      cpu-migrations OR migrations                       [Software event]
+      alignment-faults                                   [Software event]
+      emulation-faults                                   [Software event]
+
+      L1-dcache-loads                                    [Hardware cache event]
+      L1-dcache-load-misses                              [Hardware cache event]
+      L1-dcache-prefetch-misses                          [Hardware cache event]
+      L1-icache-loads                                    [Hardware cache event]
+      L1-icache-load-misses                              [Hardware cache event]
+      .
+      .
+      .
+      rNNN                                               [Raw hardware event descriptor]
+      cpu/t1=v1[,t2=v2,t3 ...]/modifier                  [Raw hardware event descriptor]
+       (see 'perf list --help' on how to encode it)
+
+      mem:&lt;addr&gt;[:access]                                [Hardware breakpoint]
+
+      sunrpc:rpc_call_status                             [Tracepoint event]
+      sunrpc:rpc_bind_status                             [Tracepoint event]
+      sunrpc:rpc_connect_status                          [Tracepoint event]
+      sunrpc:rpc_task_begin                              [Tracepoint event]
+      skb:kfree_skb                                      [Tracepoint event]
+      skb:consume_skb                                    [Tracepoint event]
+      skb:skb_copy_datagram_iovec                        [Tracepoint event]
+      net:net_dev_xmit                                   [Tracepoint event]
+      net:net_dev_queue                                  [Tracepoint event]
+      net:netif_receive_skb                              [Tracepoint event]
+      net:netif_rx                                       [Tracepoint event]
+      napi:napi_poll                                     [Tracepoint event]
+      sock:sock_rcvqueue_full                            [Tracepoint event]
+      sock:sock_exceed_buf_limit                         [Tracepoint event]
+      udp:udp_fail_queue_rcv_skb                         [Tracepoint event]
+      hda:hda_send_cmd                                   [Tracepoint event]
+      hda:hda_get_response                               [Tracepoint event]
+      hda:hda_bus_reset                                  [Tracepoint event]
+      scsi:scsi_dispatch_cmd_start                       [Tracepoint event]
+      scsi:scsi_dispatch_cmd_error                       [Tracepoint event]
+      scsi:scsi_eh_wakeup                                [Tracepoint event]
+      drm:drm_vblank_event                               [Tracepoint event]
+      drm:drm_vblank_event_queued                        [Tracepoint event]
+      drm:drm_vblank_event_delivered                     [Tracepoint event]
+      random:mix_pool_bytes                              [Tracepoint event]
+      random:mix_pool_bytes_nolock                       [Tracepoint event]
+      random:credit_entropy_bits                         [Tracepoint event]
+      gpio:gpio_direction                                [Tracepoint event]
+      gpio:gpio_value                                    [Tracepoint event]
+      block:block_rq_abort                               [Tracepoint event]
+      block:block_rq_requeue                             [Tracepoint event]
+      block:block_rq_issue                               [Tracepoint event]
+      block:block_bio_bounce                             [Tracepoint event]
+      block:block_bio_complete                           [Tracepoint event]
+      block:block_bio_backmerge                          [Tracepoint event]
+      .
+      .
+      writeback:writeback_wake_thread                    [Tracepoint event]
+      writeback:writeback_wake_forker_thread             [Tracepoint event]
+      writeback:writeback_bdi_register                   [Tracepoint event]
+      .
+      .
+      writeback:writeback_single_inode_requeue           [Tracepoint event]
+      writeback:writeback_single_inode                   [Tracepoint event]
+      kmem:kmalloc                                       [Tracepoint event]
+      kmem:kmem_cache_alloc                              [Tracepoint event]
+      kmem:mm_page_alloc                                 [Tracepoint event]
+      kmem:mm_page_alloc_zone_locked                     [Tracepoint event]
+      kmem:mm_page_pcpu_drain                            [Tracepoint event]
+      kmem:mm_page_alloc_extfrag                         [Tracepoint event]
+      vmscan:mm_vmscan_kswapd_sleep                      [Tracepoint event]
+      vmscan:mm_vmscan_kswapd_wake                       [Tracepoint event]
+      vmscan:mm_vmscan_wakeup_kswapd                     [Tracepoint event]
+      vmscan:mm_vmscan_direct_reclaim_begin              [Tracepoint event]
+      .
+      .
+      module:module_get                                  [Tracepoint event]
+      module:module_put                                  [Tracepoint event]
+      module:module_request                              [Tracepoint event]
+      sched:sched_kthread_stop                           [Tracepoint event]
+      sched:sched_wakeup                                 [Tracepoint event]
+      sched:sched_wakeup_new                             [Tracepoint event]
+      sched:sched_process_fork                           [Tracepoint event]
+      sched:sched_process_exec                           [Tracepoint event]
+      sched:sched_stat_runtime                           [Tracepoint event]
+      rcu:rcu_utilization                                [Tracepoint event]
+      workqueue:workqueue_queue_work                     [Tracepoint event]
+      workqueue:workqueue_execute_end                    [Tracepoint event]
+      signal:signal_generate                             [Tracepoint event]
+      signal:signal_deliver                              [Tracepoint event]
+      timer:timer_init                                   [Tracepoint event]
+      timer:timer_start                                  [Tracepoint event]
+      timer:hrtimer_cancel                               [Tracepoint event]
+      timer:itimer_state                                 [Tracepoint event]
+      timer:itimer_expire                                [Tracepoint event]
+      irq:irq_handler_entry                              [Tracepoint event]
+      irq:irq_handler_exit                               [Tracepoint event]
+      irq:softirq_entry                                  [Tracepoint event]
+      irq:softirq_exit                                   [Tracepoint event]
+      irq:softirq_raise                                  [Tracepoint event]
+      printk:console                                     [Tracepoint event]
+      task:task_newtask                                  [Tracepoint event]
+      task:task_rename                                   [Tracepoint event]
+      syscalls:sys_enter_socketcall                      [Tracepoint event]
+      syscalls:sys_exit_socketcall                       [Tracepoint event]
+      .
+      .
+      .
+      syscalls:sys_enter_unshare                         [Tracepoint event]
+      syscalls:sys_exit_unshare                          [Tracepoint event]
+      raw_syscalls:sys_enter                             [Tracepoint event]
+      raw_syscalls:sys_exit                              [Tracepoint event]
+                </literallayout>
+            </para>
+
+            <informalexample>
+                <emphasis>Tying it Together:</emphasis> These are exactly the same set of events defined
+                by the trace event subsystem and exposed by
+                ftrace/tracecmd/kernelshark as files in
+                /sys/kernel/debug/tracing/events, by SystemTap as
+                kernel.trace("tracepoint_name") and (partially) accessed by LTTng.
+            </informalexample>
+
+            <para>
+                Only a subset of these would be of interest to us when looking at
+                this workload, so let's choose the most likely subsystems
+                (identified by the string before the colon in the Tracepoint events)
+                and do a 'perf stat' run using only those wildcarded subsystems:
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf stat -e skb:* -e net:* -e napi:* -e sched:* -e workqueue:* -e irq:* -e syscalls:* wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>
+     Performance counter stats for 'wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>':
+
+                 23323 skb:kfree_skb
+                     0 skb:consume_skb
+                 49897 skb:skb_copy_datagram_iovec
+                  6217 net:net_dev_xmit
+                  6217 net:net_dev_queue
+                  7962 net:netif_receive_skb
+                     2 net:netif_rx
+                  8340 napi:napi_poll
+                     0 sched:sched_kthread_stop
+                     0 sched:sched_kthread_stop_ret
+                  3749 sched:sched_wakeup
+                     0 sched:sched_wakeup_new
+                     0 sched:sched_switch
+                    29 sched:sched_migrate_task
+                     0 sched:sched_process_free
+                     1 sched:sched_process_exit
+                     0 sched:sched_wait_task
+                     0 sched:sched_process_wait
+                     0 sched:sched_process_fork
+                     1 sched:sched_process_exec
+                     0 sched:sched_stat_wait
+         2106519415641 sched:sched_stat_sleep
+                     0 sched:sched_stat_iowait
+             147453613 sched:sched_stat_blocked
+           12903026955 sched:sched_stat_runtime
+                     0 sched:sched_pi_setprio
+                  3574 workqueue:workqueue_queue_work
+                  3574 workqueue:workqueue_activate_work
+                     0 workqueue:workqueue_execute_start
+                     0 workqueue:workqueue_execute_end
+                 16631 irq:irq_handler_entry
+                 16631 irq:irq_handler_exit
+                 28521 irq:softirq_entry
+                 28521 irq:softirq_exit
+                 28728 irq:softirq_raise
+                     1 syscalls:sys_enter_sendmmsg
+                     1 syscalls:sys_exit_sendmmsg
+                     0 syscalls:sys_enter_recvmmsg
+                     0 syscalls:sys_exit_recvmmsg
+                    14 syscalls:sys_enter_socketcall
+                    14 syscalls:sys_exit_socketcall
+                       .
+                       .
+                       .
+                 16965 syscalls:sys_enter_read
+                 16965 syscalls:sys_exit_read
+                 12854 syscalls:sys_enter_write
+                 12854 syscalls:sys_exit_write
+                       .
+                       .
+                       .
+
+          58.029710972 seconds time elapsed
+                </literallayout>
+                Let's pick one of these tracepoints and tell perf to do a profile
+                using it as the sampling event:
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf record -g -e sched:sched_wakeup wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>
+                </literallayout>
+            </para>
+
+            <para>
+                <imagedata fileref="figures/sched-wakeup-profile.png" width="6in" depth="7in" align="center" scalefit="1" />
+            </para>
+
+            <para>
+                The screenshot above shows the results of running a profile using
+                sched:sched_switch tracepoint, which shows the relative costs of
+                various paths to sched_wakeup (note that sched_wakeup is the
+                name of the tracepoint - it's actually defined just inside
+                ttwu_do_wakeup(), which accounts for the function name actually
+                displayed in the profile:
+                <literallayout class='monospaced'>
+     /*
+      * Mark the task runnable and perform wakeup-preemption.
+      */
+     static void
+     ttwu_do_wakeup(struct rq *rq, struct task_struct *p, int wake_flags)
+     {
+          trace_sched_wakeup(p, true);
+          .
+          .
+          .
+     }
+                </literallayout>
+                A couple of the more interesting callchains are expanded and
+                displayed above, basically some network receive paths that
+                presumably end up waking up wget (busybox) when network data is
+                ready.
+            </para>
+
+            <para>
+                Note that because tracepoints are normally used for tracing,
+                the default sampling period for tracepoints is 1 i.e. for
+                tracepoints perf will sample on every event occurrence (this
+                can be changed using the -c option). This is in contrast to
+                hardware counters such as for example the default 'cycles'
+                hardware counter used for normal profiling, where sampling
+                periods are much higher (in the thousands) because profiling should
+                have as low an overhead as possible and sampling on every cycle
+                would be prohibitively expensive.
+            </para>
+        </section>
+
+        <section id='using-perf-to-do-basic-tracing'>
+            <title>Using perf to do Basic Tracing</title>
+
+            <para>
+                Profiling is a great tool for solving many problems or for
+                getting a high-level view of what's going on with a workload or
+                across the system. It is however by definition an approximation,
+                as suggested by the most prominent word associated with it,
+                'sampling'. On the one hand, it allows a representative picture of
+                what's going on in the system to be cheaply taken, but on the other
+                hand, that cheapness limits its utility when that data suggests a
+                need to 'dive down' more deeply to discover what's really going
+                on. In such cases, the only way to see what's really going on is
+                to be able to look at (or summarize more intelligently) the
+                individual steps that go into the higher-level behavior exposed
+                by the coarse-grained profiling data.
+            </para>
+
+            <para>
+                As a concrete example, we can trace all the events we think might
+                be applicable to our workload:
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf record -g -e skb:* -e net:* -e napi:* -e sched:sched_switch -e sched:sched_wakeup -e irq:*
+      -e syscalls:sys_enter_read -e syscalls:sys_exit_read -e syscalls:sys_enter_write -e syscalls:sys_exit_write
+      wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>
+                </literallayout>
+                We can look at the raw trace output using 'perf script' with no
+                arguments:
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf script
+
+           perf  1262 [000] 11624.857082: sys_exit_read: 0x0
+           perf  1262 [000] 11624.857193: sched_wakeup: comm=migration/0 pid=6 prio=0 success=1 target_cpu=000
+           wget  1262 [001] 11624.858021: softirq_raise: vec=1 [action=TIMER]
+           wget  1262 [001] 11624.858074: softirq_entry: vec=1 [action=TIMER]
+           wget  1262 [001] 11624.858081: softirq_exit: vec=1 [action=TIMER]
+           wget  1262 [001] 11624.858166: sys_enter_read: fd: 0x0003, buf: 0xbf82c940, count: 0x0200
+           wget  1262 [001] 11624.858177: sys_exit_read: 0x200
+           wget  1262 [001] 11624.858878: kfree_skb: skbaddr=0xeb248d80 protocol=0 location=0xc15a5308
+           wget  1262 [001] 11624.858945: kfree_skb: skbaddr=0xeb248000 protocol=0 location=0xc15a5308
+           wget  1262 [001] 11624.859020: softirq_raise: vec=1 [action=TIMER]
+           wget  1262 [001] 11624.859076: softirq_entry: vec=1 [action=TIMER]
+           wget  1262 [001] 11624.859083: softirq_exit: vec=1 [action=TIMER]
+           wget  1262 [001] 11624.859167: sys_enter_read: fd: 0x0003, buf: 0xb7720000, count: 0x0400
+           wget  1262 [001] 11624.859192: sys_exit_read: 0x1d7
+           wget  1262 [001] 11624.859228: sys_enter_read: fd: 0x0003, buf: 0xb7720000, count: 0x0400
+           wget  1262 [001] 11624.859233: sys_exit_read: 0x0
+           wget  1262 [001] 11624.859573: sys_enter_read: fd: 0x0003, buf: 0xbf82c580, count: 0x0200
+           wget  1262 [001] 11624.859584: sys_exit_read: 0x200
+           wget  1262 [001] 11624.859864: sys_enter_read: fd: 0x0003, buf: 0xb7720000, count: 0x0400
+           wget  1262 [001] 11624.859888: sys_exit_read: 0x400
+           wget  1262 [001] 11624.859935: sys_enter_read: fd: 0x0003, buf: 0xb7720000, count: 0x0400
+           wget  1262 [001] 11624.859944: sys_exit_read: 0x400
+                </literallayout>
+                This gives us a detailed timestamped sequence of events that
+                occurred within the workload with respect to those events.
+            </para>
+
+            <para>
+                In many ways, profiling can be viewed as a subset of tracing -
+                theoretically, if you have a set of trace events that's sufficient
+                to capture all the important aspects of a workload, you can derive
+                any of the results or views that a profiling run can.
+            </para>
+
+            <para>
+                Another aspect of traditional profiling is that while powerful in
+                many ways, it's limited by the granularity of the underlying data.
+                Profiling tools offer various ways of sorting and presenting the
+                sample data, which make it much more useful and amenable to user
+                experimentation, but in the end it can't be used in an open-ended
+                way to extract data that just isn't present as a consequence of
+                the fact that conceptually, most of it has been thrown away.
+            </para>
+
+            <para>
+                Full-blown detailed tracing data does however offer the opportunity
+                to manipulate and present the information collected during a
+                tracing run in an infinite variety of ways.
+            </para>
+
+            <para>
+                Another way to look at it is that there are only so many ways that
+                the 'primitive' counters can be used on their own to generate
+                interesting output; to get anything more complicated than simple
+                counts requires some amount of additional logic, which is typically
+                very specific to the problem at hand. For example, if we wanted to
+                make use of a 'counter' that maps to the value of the time
+                difference between when a process was scheduled to run on a
+                processor and the time it actually ran, we wouldn't expect such
+                a counter to exist on its own, but we could derive one called say
+                'wakeup_latency' and use it to extract a useful view of that metric
+                from trace data. Likewise, we really can't figure out from standard
+                profiling tools how much data every process on the system reads and
+                writes, along with how many of those reads and writes fail
+                completely. If we have sufficient trace data, however, we could
+                with the right tools easily extract and present that information,
+                but we'd need something other than pre-canned profiling tools to
+                do that.
+            </para>
+
+            <para>
+                Luckily, there is a general-purpose way to handle such needs,
+                called 'programming languages'. Making programming languages
+                easily available to apply to such problems given the specific
+                format of data is called a 'programming language binding' for
+                that data and language. Perf supports two programming language
+                bindings, one for Python and one for Perl.
+            </para>
+
+            <informalexample>
+                <emphasis>Tying it Together:</emphasis> Language bindings for manipulating and
+                aggregating trace data are of course not a new
+                idea.  One of the first projects to do this was IBM's DProbes
+                dpcc compiler, an ANSI C compiler which targeted a low-level
+                assembly language running on an in-kernel interpreter on the
+                target system.  This is exactly analogous to what Sun's DTrace
+                did, except that DTrace invented its own language for the purpose.
+                Systemtap, heavily inspired by DTrace, also created its own
+                one-off language, but rather than running the product on an
+                in-kernel interpreter, created an elaborate compiler-based
+                machinery to translate its language into kernel modules written
+                in C.
+            </informalexample>
+
+            <para>
+                Now that we have the trace data in perf.data, we can use
+                'perf script -g' to generate a skeleton script with handlers
+                for the read/write entry/exit events we recorded:
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf script -g python
+     generated Python script: perf-script.py
+                </literallayout>
+                The skeleton script simply creates a python function for each
+                event type in the perf.data file. The body of each function simply
+                prints the event name along with its parameters. For example:
+                <literallayout class='monospaced'>
+     def net__netif_rx(event_name, context, common_cpu,
+            common_secs, common_nsecs, common_pid, common_comm,
+            skbaddr, len, name):
+                    print_header(event_name, common_cpu, common_secs, common_nsecs,
+                            common_pid, common_comm)
+
+                     print "skbaddr=%u, len=%u, name=%s\n" % (skbaddr, len, name),
+                </literallayout>
+                We can run that script directly to print all of the events
+                contained in the perf.data file:
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf script -s perf-script.py
+
+     in trace_begin
+     syscalls__sys_exit_read     0 11624.857082795     1262 perf                  nr=3, ret=0
+     sched__sched_wakeup      0 11624.857193498     1262 perf                  comm=migration/0, pid=6, prio=0,      success=1, target_cpu=0
+     irq__softirq_raise       1 11624.858021635     1262 wget                  vec=TIMER
+     irq__softirq_entry       1 11624.858074075     1262 wget                  vec=TIMER
+     irq__softirq_exit        1 11624.858081389     1262 wget                  vec=TIMER
+     syscalls__sys_enter_read     1 11624.858166434     1262 wget                  nr=3, fd=3, buf=3213019456,      count=512
+     syscalls__sys_exit_read     1 11624.858177924     1262 wget                  nr=3, ret=512
+     skb__kfree_skb           1 11624.858878188     1262 wget                  skbaddr=3945041280,           location=3243922184, protocol=0
+     skb__kfree_skb           1 11624.858945608     1262 wget                  skbaddr=3945037824,      location=3243922184, protocol=0
+     irq__softirq_raise       1 11624.859020942     1262 wget                  vec=TIMER
+     irq__softirq_entry       1 11624.859076935     1262 wget                  vec=TIMER
+     irq__softirq_exit        1 11624.859083469     1262 wget                  vec=TIMER
+     syscalls__sys_enter_read     1 11624.859167565     1262 wget                  nr=3, fd=3, buf=3077701632,      count=1024
+     syscalls__sys_exit_read     1 11624.859192533     1262 wget                  nr=3, ret=471
+     syscalls__sys_enter_read     1 11624.859228072     1262 wget                  nr=3, fd=3, buf=3077701632,      count=1024
+     syscalls__sys_exit_read     1 11624.859233707     1262 wget                  nr=3, ret=0
+     syscalls__sys_enter_read     1 11624.859573008     1262 wget                  nr=3, fd=3, buf=3213018496,      count=512
+     syscalls__sys_exit_read     1 11624.859584818     1262 wget                  nr=3, ret=512
+     syscalls__sys_enter_read     1 11624.859864562     1262 wget                  nr=3, fd=3, buf=3077701632,      count=1024
+     syscalls__sys_exit_read     1 11624.859888770     1262 wget                  nr=3, ret=1024
+     syscalls__sys_enter_read     1 11624.859935140     1262 wget                  nr=3, fd=3, buf=3077701632,      count=1024
+     syscalls__sys_exit_read     1 11624.859944032     1262 wget                  nr=3, ret=1024
+                </literallayout>
+                That in itself isn't very useful; after all, we can accomplish
+                pretty much the same thing by simply running 'perf script'
+                without arguments in the same directory as the perf.data file.
+            </para>
+
+            <para>
+                We can however replace the print statements in the generated
+                function bodies with whatever we want, and thereby make it
+                infinitely more useful.
+            </para>
+
+            <para>
+                As a simple example, let's just replace the print statements in
+                the function bodies with a simple function that does nothing but
+                increment a per-event count. When the program is run against a
+                perf.data file, each time a particular event is encountered,
+                a tally is incremented for that event. For example:
+                <literallayout class='monospaced'>
+     def net__netif_rx(event_name, context, common_cpu,
+            common_secs, common_nsecs, common_pid, common_comm,
+            skbaddr, len, name):
+                          inc_counts(event_name)
+                </literallayout>
+                Each event handler function in the generated code is modified
+                to do this. For convenience, we define a common function called
+                inc_counts() that each handler calls; inc_counts() simply tallies
+                a count for each event using the 'counts' hash, which is a
+                specialized hash function that does Perl-like autovivification, a
+                capability that's extremely useful for kinds of multi-level
+                aggregation commonly used in processing traces (see perf's
+                documentation on the Python language binding for details):
+                <literallayout class='monospaced'>
+     counts = autodict()
+
+     def inc_counts(event_name):
+            try:
+                    counts[event_name] += 1
+            except TypeError:
+                    counts[event_name] = 1
+                </literallayout>
+                Finally, at the end of the trace processing run, we want to
+                print the result of all the per-event tallies. For that, we
+                use the special 'trace_end()' function:
+                <literallayout class='monospaced'>
+     def trace_end():
+            for event_name, count in counts.iteritems():
+                    print "%-40s %10s\n" % (event_name, count)
+                </literallayout>
+                The end result is a summary of all the events recorded in the
+                trace:
+                <literallayout class='monospaced'>
+     skb__skb_copy_datagram_iovec                  13148
+     irq__softirq_entry                             4796
+     irq__irq_handler_exit                          3805
+     irq__softirq_exit                              4795
+     syscalls__sys_enter_write                      8990
+     net__net_dev_xmit                               652
+     skb__kfree_skb                                 4047
+     sched__sched_wakeup                            1155
+     irq__irq_handler_entry                         3804
+     irq__softirq_raise                             4799
+     net__net_dev_queue                              652
+     syscalls__sys_enter_read                      17599
+     net__netif_receive_skb                         1743
+     syscalls__sys_exit_read                       17598
+     net__netif_rx                                     2
+     napi__napi_poll                                1877
+     syscalls__sys_exit_write                       8990
+                </literallayout>
+                Note that this is pretty much exactly the same information we get
+                from 'perf stat', which goes a little way to support the idea
+                mentioned previously that given the right kind of trace data,
+                higher-level profiling-type summaries can be derived from it.
+            </para>
+
+            <para>
+                Documentation on using the
+                <ulink url='http://linux.die.net/man/1/perf-script-python'>'perf script' python binding</ulink>.
+            </para>
+        </section>
+
+        <section id='system-wide-tracing-and-profiling'>
+            <title>System-Wide Tracing and Profiling</title>
+
+            <para>
+                The examples so far have focused on tracing a particular program or
+                workload - in other words, every profiling run has specified the
+                program to profile in the command-line e.g. 'perf record wget ...'.
+            </para>
+
+            <para>
+                It's also possible, and more interesting in many cases, to run a
+                system-wide profile or trace while running the workload in a
+                separate shell.
+            </para>
+
+            <para>
+                To do system-wide profiling or tracing, you typically use
+                the -a flag to 'perf record'.
+            </para>
+
+            <para>
+                To demonstrate this, open up one window and start the profile
+                using the -a flag (press Ctrl-C to stop tracing):
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf record -g -a
+     ^C[ perf record: Woken up 6 times to write data ]
+     [ perf record: Captured and wrote 1.400 MB perf.data (~61172 samples) ]
+                </literallayout>
+                In another window, run the wget test:
+                <literallayout class='monospaced'>
+     root@crownbay:~# wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>
+     Connecting to downloads.yoctoproject.org (140.211.169.59:80)
+     linux-2.6.19.2.tar.b 100% |*******************************| 41727k  0:00:00 ETA
+                </literallayout>
+                Here we see entries not only for our wget load, but for other
+                processes running on the system as well:
+            </para>
+
+            <para>
+                <imagedata fileref="figures/perf-systemwide.png" width="6in" depth="7in" align="center" scalefit="1" />
+            </para>
+
+            <para>
+                In the snapshot above, we can see callchains that originate in
+                libc, and a callchain from Xorg that demonstrates that we're
+                using a proprietary X driver in userspace (notice the presence
+                of 'PVR' and some other unresolvable symbols in the expanded
+                Xorg callchain).
+            </para>
+
+            <para>
+                Note also that we have both kernel and userspace entries in the
+                above snapshot. We can also tell perf to focus on userspace but
+                providing a modifier, in this case 'u', to the 'cycles' hardware
+                counter when we record a profile:
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf record -g -a -e cycles:u
+     ^C[ perf record: Woken up 2 times to write data ]
+     [ perf record: Captured and wrote 0.376 MB perf.data (~16443 samples) ]
+                </literallayout>
+            </para>
+
+            <para>
+                <imagedata fileref="figures/perf-report-cycles-u.png" width="6in" depth="7in" align="center" scalefit="1" />
+            </para>
+
+            <para>
+                Notice in the screenshot above, we see only userspace entries ([.])
+            </para>
+
+            <para>
+                Finally, we can press 'enter' on a leaf node and select the 'Zoom
+                into DSO' menu item to show only entries associated with a
+                specific DSO. In the screenshot below, we've zoomed into the
+                'libc' DSO which shows all the entries associated with the
+                libc-xxx.so DSO.
+            </para>
+
+            <para>
+                <imagedata fileref="figures/perf-systemwide-libc.png" width="6in" depth="7in" align="center" scalefit="1" />
+            </para>
+
+            <para>
+                We can also use the system-wide -a switch to do system-wide
+                tracing. Here we'll trace a couple of scheduler events:
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf record -a -e sched:sched_switch -e sched:sched_wakeup
+     ^C[ perf record: Woken up 38 times to write data ]
+     [ perf record: Captured and wrote 9.780 MB perf.data (~427299 samples) ]
+                </literallayout>
+                We can look at the raw output using 'perf script' with no
+                arguments:
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf script
+
+                perf  1383 [001]  6171.460045: sched_wakeup: comm=kworker/1:1 pid=21 prio=120 success=1 target_cpu=001
+                perf  1383 [001]  6171.460066: sched_switch: prev_comm=perf prev_pid=1383 prev_prio=120 prev_state=R+ ==> next_comm=kworker/1:1 next_pid=21 next_prio=120
+         kworker/1:1    21 [001]  6171.460093: sched_switch: prev_comm=kworker/1:1 prev_pid=21 prev_prio=120 prev_state=S ==> next_comm=perf next_pid=1383 next_prio=120
+             swapper     0 [000]  6171.468063: sched_wakeup: comm=kworker/0:3 pid=1209 prio=120 success=1 target_cpu=000
+             swapper     0 [000]  6171.468107: sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=kworker/0:3 next_pid=1209 next_prio=120
+         kworker/0:3  1209 [000]  6171.468143: sched_switch: prev_comm=kworker/0:3 prev_pid=1209 prev_prio=120 prev_state=S ==> next_comm=swapper/0 next_pid=0 next_prio=120
+                perf  1383 [001]  6171.470039: sched_wakeup: comm=kworker/1:1 pid=21 prio=120 success=1 target_cpu=001
+                perf  1383 [001]  6171.470058: sched_switch: prev_comm=perf prev_pid=1383 prev_prio=120 prev_state=R+ ==> next_comm=kworker/1:1 next_pid=21 next_prio=120
+         kworker/1:1    21 [001]  6171.470082: sched_switch: prev_comm=kworker/1:1 prev_pid=21 prev_prio=120 prev_state=S ==> next_comm=perf next_pid=1383 next_prio=120
+                perf  1383 [001]  6171.480035: sched_wakeup: comm=kworker/1:1 pid=21 prio=120 success=1 target_cpu=001
+                </literallayout>
+            </para>
+
+            <section id='perf-filtering'>
+                <title>Filtering</title>
+
+                <para>
+                    Notice that there are a lot of events that don't really have
+                    anything to do with what we're interested in, namely events
+                    that schedule 'perf' itself in and out or that wake perf up.
+                    We can get rid of those by using the '--filter' option -
+                    for each event we specify using -e, we can add a --filter
+                    after that to filter out trace events that contain fields
+                    with specific values:
+                    <literallayout class='monospaced'>
+     root@crownbay:~# perf record -a -e sched:sched_switch --filter 'next_comm != perf &amp;&amp; prev_comm != perf' -e sched:sched_wakeup --filter 'comm != perf'
+     ^C[ perf record: Woken up 38 times to write data ]
+     [ perf record: Captured and wrote 9.688 MB perf.data (~423279 samples) ]
+
+
+     root@crownbay:~# perf script
+
+             swapper     0 [000]  7932.162180: sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=kworker/0:3 next_pid=1209 next_prio=120
+         kworker/0:3  1209 [000]  7932.162236: sched_switch: prev_comm=kworker/0:3 prev_pid=1209 prev_prio=120 prev_state=S ==> next_comm=swapper/0 next_pid=0 next_prio=120
+                perf  1407 [001]  7932.170048: sched_wakeup: comm=kworker/1:1 pid=21 prio=120 success=1 target_cpu=001
+                perf  1407 [001]  7932.180044: sched_wakeup: comm=kworker/1:1 pid=21 prio=120 success=1 target_cpu=001
+                perf  1407 [001]  7932.190038: sched_wakeup: comm=kworker/1:1 pid=21 prio=120 success=1 target_cpu=001
+                perf  1407 [001]  7932.200044: sched_wakeup: comm=kworker/1:1 pid=21 prio=120 success=1 target_cpu=001
+                perf  1407 [001]  7932.210044: sched_wakeup: comm=kworker/1:1 pid=21 prio=120 success=1 target_cpu=001
+                perf  1407 [001]  7932.220044: sched_wakeup: comm=kworker/1:1 pid=21 prio=120 success=1 target_cpu=001
+             swapper     0 [001]  7932.230111: sched_wakeup: comm=kworker/1:1 pid=21 prio=120 success=1 target_cpu=001
+             swapper     0 [001]  7932.230146: sched_switch: prev_comm=swapper/1 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=kworker/1:1 next_pid=21 next_prio=120
+         kworker/1:1    21 [001]  7932.230205: sched_switch: prev_comm=kworker/1:1 prev_pid=21 prev_prio=120 prev_state=S ==> next_comm=swapper/1 next_pid=0 next_prio=120
+             swapper     0 [000]  7932.326109: sched_wakeup: comm=kworker/0:3 pid=1209 prio=120 success=1 target_cpu=000
+             swapper     0 [000]  7932.326171: sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=kworker/0:3 next_pid=1209 next_prio=120
+         kworker/0:3  1209 [000]  7932.326214: sched_switch: prev_comm=kworker/0:3 prev_pid=1209 prev_prio=120 prev_state=S ==> next_comm=swapper/0 next_pid=0 next_prio=120
+                    </literallayout>
+                    In this case, we've filtered out all events that have 'perf'
+                    in their 'comm' or 'comm_prev' or 'comm_next' fields. Notice
+                    that there are still events recorded for perf, but notice
+                    that those events don't have values of 'perf' for the filtered
+                    fields. To completely filter out anything from perf will
+                    require a bit more work, but for the purpose of demonstrating
+                    how to use filters, it's close enough.
+                </para>
+
+                <informalexample>
+                    <emphasis>Tying it Together:</emphasis> These are exactly the same set of event
+                    filters defined by the trace event subsystem. See the
+                    ftrace/tracecmd/kernelshark section for more discussion about
+                    these event filters.
+                </informalexample>
+
+                <informalexample>
+                    <emphasis>Tying it Together:</emphasis> These event filters are implemented by a
+                    special-purpose pseudo-interpreter in the kernel and are an
+                    integral and indispensable part of the perf design as it
+                    relates to tracing.  kernel-based event filters provide a
+                    mechanism to precisely throttle the event stream that appears
+                    in user space, where it makes sense to provide bindings to real
+                    programming languages for postprocessing the event stream.
+                    This architecture allows for the intelligent and flexible
+                    partitioning of processing between the kernel and user space.
+                    Contrast this with other tools such as SystemTap, which does
+                    all of its processing in the kernel and as such requires a
+                    special project-defined language in order to accommodate that
+                    design, or LTTng, where everything is sent to userspace and
+                    as such requires a super-efficient kernel-to-userspace
+                    transport mechanism in order to function properly.  While
+                    perf certainly can benefit from for instance advances in
+                    the design of the transport, it doesn't fundamentally depend
+                    on them.  Basically, if you find that your perf tracing
+                    application is causing buffer I/O overruns, it probably
+                    means that you aren't taking enough advantage of the
+                    kernel filtering engine.
+                </informalexample>
+            </section>
+        </section>
+
+        <section id='using-dynamic-tracepoints'>
+            <title>Using Dynamic Tracepoints</title>
+
+            <para>
+                perf isn't restricted to the fixed set of static tracepoints
+                listed by 'perf list'. Users can also add their own 'dynamic'
+                tracepoints anywhere in the kernel. For instance, suppose we
+                want to define our own tracepoint on do_fork(). We can do that
+                using the 'perf probe' perf subcommand:
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf probe do_fork
+     Added new event:
+       probe:do_fork        (on do_fork)
+
+     You can now use it in all perf tools, such as:
+
+             perf record -e probe:do_fork -aR sleep 1
+                </literallayout>
+                Adding a new tracepoint via 'perf probe' results in an event
+                with all the expected files and format in
+                /sys/kernel/debug/tracing/events, just the same as for static
+                tracepoints (as discussed in more detail in the trace events
+                subsystem section:
+                <literallayout class='monospaced'>
+     root@crownbay:/sys/kernel/debug/tracing/events/probe/do_fork# ls -al
+     drwxr-xr-x    2 root     root             0 Oct 28 11:42 .
+     drwxr-xr-x    3 root     root             0 Oct 28 11:42 ..
+     -rw-r--r--    1 root     root             0 Oct 28 11:42 enable
+     -rw-r--r--    1 root     root             0 Oct 28 11:42 filter
+     -r--r--r--    1 root     root             0 Oct 28 11:42 format
+     -r--r--r--    1 root     root             0 Oct 28 11:42 id
+
+     root@crownbay:/sys/kernel/debug/tracing/events/probe/do_fork# cat format
+     name: do_fork
+     ID: 944
+     format:
+             field:unsigned short common_type;  offset:0;       size:2; signed:0;
+             field:unsigned char common_flags;  offset:2;       size:1; signed:0;
+             field:unsigned char common_preempt_count;  offset:3;       size:1; signed:0;
+             field:int common_pid;      offset:4;       size:4; signed:1;
+             field:int common_padding;  offset:8;       size:4; signed:1;
+
+             field:unsigned long __probe_ip;    offset:12;      size:4; signed:0;
+
+     print fmt: "(%lx)", REC->__probe_ip
+                </literallayout>
+                We can list all dynamic tracepoints currently in existence:
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf probe -l
+      probe:do_fork        (on do_fork)
+      probe:schedule       (on schedule)
+                </literallayout>
+                Let's record system-wide ('sleep 30' is a trick for recording
+                system-wide but basically do nothing and then wake up after
+                30 seconds):
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf record -g -a -e probe:do_fork sleep 30
+     [ perf record: Woken up 1 times to write data ]
+     [ perf record: Captured and wrote 0.087 MB perf.data (~3812 samples) ]
+                </literallayout>
+                Using 'perf script' we can see each do_fork event that fired:
+                <literallayout class='monospaced'>
+     root@crownbay:~# perf script
+
+     # ========
+     # captured on: Sun Oct 28 11:55:18 2012
+     # hostname : crownbay
+     # os release : 3.4.11-yocto-standard
+     # perf version : 3.4.11
+     # arch : i686
+     # nrcpus online : 2
+     # nrcpus avail : 2
+     # cpudesc : Intel(R) Atom(TM) CPU E660 @ 1.30GHz
+     # cpuid : GenuineIntel,6,38,1
+     # total memory : 1017184 kB
+     # cmdline : /usr/bin/perf record -g -a -e probe:do_fork sleep 30
+     # event : name = probe:do_fork, type = 2, config = 0x3b0, config1 = 0x0, config2 = 0x0, excl_usr = 0, excl_kern
+      = 0, id = { 5, 6 }
+     # HEADER_CPU_TOPOLOGY info available, use -I to display
+     # ========
+     #
+      matchbox-deskto  1197 [001] 34211.378318: do_fork: (c1028460)
+      matchbox-deskto  1295 [001] 34211.380388: do_fork: (c1028460)
+              pcmanfm  1296 [000] 34211.632350: do_fork: (c1028460)
+              pcmanfm  1296 [000] 34211.639917: do_fork: (c1028460)
+      matchbox-deskto  1197 [001] 34217.541603: do_fork: (c1028460)
+      matchbox-deskto  1299 [001] 34217.543584: do_fork: (c1028460)
+               gthumb  1300 [001] 34217.697451: do_fork: (c1028460)
+               gthumb  1300 [001] 34219.085734: do_fork: (c1028460)
+               gthumb  1300 [000] 34219.121351: do_fork: (c1028460)
+               gthumb  1300 [001] 34219.264551: do_fork: (c1028460)
+              pcmanfm  1296 [000] 34219.590380: do_fork: (c1028460)
+      matchbox-deskto  1197 [001] 34224.955965: do_fork: (c1028460)
+      matchbox-deskto  1306 [001] 34224.957972: do_fork: (c1028460)
+      matchbox-termin  1307 [000] 34225.038214: do_fork: (c1028460)
+      matchbox-termin  1307 [001] 34225.044218: do_fork: (c1028460)
+      matchbox-termin  1307 [000] 34225.046442: do_fork: (c1028460)
+      matchbox-deskto  1197 [001] 34237.112138: do_fork: (c1028460)
+      matchbox-deskto  1311 [001] 34237.114106: do_fork: (c1028460)
+                 gaku  1312 [000] 34237.202388: do_fork: (c1028460)
+                </literallayout>
+                And using 'perf report' on the same file, we can see the
+                callgraphs from starting a few programs during those 30 seconds:
+            </para>
+
+            <para>
+                <imagedata fileref="figures/perf-probe-do_fork-profile.png" width="6in" depth="7in" align="center" scalefit="1" />
+            </para>
+
+            <informalexample>
+                <emphasis>Tying it Together:</emphasis> The trace events subsystem accommodate static
+                and dynamic tracepoints in exactly the same way - there's no
+                difference as far as the infrastructure is concerned.  See the
+                ftrace section for more details on the trace event subsystem.
+            </informalexample>
+
+            <informalexample>
+                <emphasis>Tying it Together:</emphasis> Dynamic tracepoints are implemented under the
+                covers by kprobes and uprobes.  kprobes and uprobes are also used
+                by and in fact are the main focus of SystemTap.
+            </informalexample>
+        </section>
+    </section>
+
+    <section id='perf-documentation'>
+        <title>Documentation</title>
+
+        <para>
+            Online versions of the man pages for the commands discussed in this
+            section can be found here:
+            <itemizedlist>
+                <listitem><para>The <ulink url='http://linux.die.net/man/1/perf-stat'>'perf stat' manpage</ulink>.
+                    </para></listitem>
+                <listitem><para>The <ulink url='http://linux.die.net/man/1/perf-record'>'perf record' manpage</ulink>.
+                    </para></listitem>
+                <listitem><para>The <ulink url='http://linux.die.net/man/1/perf-report'>'perf report' manpage</ulink>.
+                    </para></listitem>
+                <listitem><para>The <ulink url='http://linux.die.net/man/1/perf-probe'>'perf probe' manpage</ulink>.
+                    </para></listitem>
+                <listitem><para>The <ulink url='http://linux.die.net/man/1/perf-script'>'perf script' manpage</ulink>.
+                    </para></listitem>
+                <listitem><para>Documentation on using the
+                    <ulink url='http://linux.die.net/man/1/perf-script-python'>'perf script' python binding</ulink>.
+                    </para></listitem>
+                <listitem><para>The top-level
+                    <ulink url='http://linux.die.net/man/1/perf'>perf(1) manpage</ulink>.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            Normally, you should be able to invoke the man pages via perf
+            itself e.g. 'perf help' or 'perf help record'.
+        </para>
+
+        <para>
+            However, by default Yocto doesn't install man pages, but perf
+            invokes the man pages for most help functionality. This is a bug
+            and is being addressed by a Yocto bug:
+            <ulink url='https://bugzilla.yoctoproject.org/show_bug.cgi?id=3388'>Bug 3388 - perf: enable man pages for basic 'help' functionality</ulink>.
+        </para>
+
+        <para>
+            The man pages in text form, along with some other files, such as
+            a set of examples, can be found in the 'perf' directory of the
+            kernel tree:
+            <literallayout class='monospaced'>
+     tools/perf/Documentation
+            </literallayout>
+            There's also a nice perf tutorial on the perf wiki that goes
+            into more detail than we do here in certain areas:
+            <ulink url='https://perf.wiki.kernel.org/index.php/Tutorial'>Perf Tutorial</ulink>
+        </para>
+    </section>
+</section>
+
+<section id='profile-manual-ftrace'>
+    <title>ftrace</title>
+
+    <para>
+        'ftrace' literally refers to the 'ftrace function tracer' but in
+        reality this encompasses a number of related tracers along with
+        the infrastructure that they all make use of.
+    </para>
+
+    <section id='ftrace-setup'>
+        <title>Setup</title>
+
+        <para>
+            For this section, we'll assume you've already performed the basic
+            setup outlined in the General Setup section.
+        </para>
+
+        <para>
+            ftrace, trace-cmd, and kernelshark run on the target system,
+            and are ready to go out-of-the-box - no additional setup is
+            necessary. For the rest of this section we assume you've ssh'ed
+            to the host and will be running ftrace on the target. kernelshark
+            is a GUI application and if you use the '-X' option to ssh you
+            can have the kernelshark GUI run on the target but display
+            remotely on the host if you want.
+        </para>
+    </section>
+
+    <section id='basic-ftrace-usage'>
+        <title>Basic ftrace usage</title>
+
+        <para>
+            'ftrace' essentially refers to everything included in
+            the /tracing directory of the mounted debugfs filesystem
+            (Yocto follows the standard convention and mounts it
+            at /sys/kernel/debug). Here's a listing of all the files
+            found in /sys/kernel/debug/tracing on a Yocto system:
+            <literallayout class='monospaced'>
+     root@sugarbay:/sys/kernel/debug/tracing# ls
+     README                      kprobe_events               trace
+     available_events            kprobe_profile              trace_clock
+     available_filter_functions  options                     trace_marker
+     available_tracers           per_cpu                     trace_options
+     buffer_size_kb              printk_formats              trace_pipe
+     buffer_total_size_kb        saved_cmdlines              tracing_cpumask
+     current_tracer              set_event                   tracing_enabled
+     dyn_ftrace_total_info       set_ftrace_filter           tracing_on
+     enabled_functions           set_ftrace_notrace          tracing_thresh
+     events                      set_ftrace_pid
+     free_buffer                 set_graph_function
+            </literallayout>
+            The files listed above are used for various purposes -
+            some relate directly to the tracers themselves, others are
+            used to set tracing options, and yet others actually contain
+            the tracing output when a tracer is in effect. Some of the
+            functions can be guessed from their names, others need
+            explanation; in any case, we'll cover some of the files we
+            see here below but for an explanation of the others, please
+            see the ftrace documentation.
+        </para>
+
+        <para>
+            We'll start by looking at some of the available built-in
+            tracers.
+        </para>
+
+        <para>
+            cat'ing the 'available_tracers' file lists the set of
+            available tracers:
+            <literallayout class='monospaced'>
+     root@sugarbay:/sys/kernel/debug/tracing# cat available_tracers
+     blk function_graph function nop
+            </literallayout>
+            The 'current_tracer' file contains the tracer currently in
+            effect:
+            <literallayout class='monospaced'>
+     root@sugarbay:/sys/kernel/debug/tracing# cat current_tracer
+     nop
+            </literallayout>
+            The above listing of current_tracer shows that
+            the 'nop' tracer is in effect, which is just another
+            way of saying that there's actually no tracer
+            currently in effect.
+        </para>
+
+        <para>
+            echo'ing one of the available_tracers into current_tracer
+            makes the specified tracer the current tracer:
+            <literallayout class='monospaced'>
+     root@sugarbay:/sys/kernel/debug/tracing# echo function > current_tracer
+     root@sugarbay:/sys/kernel/debug/tracing# cat current_tracer
+     function
+            </literallayout>
+            The above sets the current tracer to be the
+            'function tracer'. This tracer traces every function
+            call in the kernel and makes it available as the
+            contents of the 'trace' file. Reading the 'trace' file
+            lists the currently buffered function calls that have been
+            traced by the function tracer:
+            <literallayout class='monospaced'>
+     root@sugarbay:/sys/kernel/debug/tracing# cat trace | less
+
+     # tracer: function
+     #
+     # entries-in-buffer/entries-written: 310629/766471   #P:8
+     #
+     #                              _-----=&gt; irqs-off
+     #                             / _----=&gt; need-resched
+     #                            | / _---=&gt; hardirq/softirq
+     #                            || / _--=&gt; preempt-depth
+     #                            ||| /     delay
+     #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
+     #              | |       |   ||||       |         |
+              &lt;idle&gt;-0     [004] d..1   470.867169: ktime_get_real &lt;-intel_idle
+              &lt;idle&gt;-0     [004] d..1   470.867170: getnstimeofday &lt;-ktime_get_real
+              &lt;idle&gt;-0     [004] d..1   470.867171: ns_to_timeval &lt;-intel_idle
+              &lt;idle&gt;-0     [004] d..1   470.867171: ns_to_timespec &lt;-ns_to_timeval
+              &lt;idle&gt;-0     [004] d..1   470.867172: smp_apic_timer_interrupt &lt;-apic_timer_interrupt
+              &lt;idle&gt;-0     [004] d..1   470.867172: native_apic_mem_write &lt;-smp_apic_timer_interrupt
+              &lt;idle&gt;-0     [004] d..1   470.867172: irq_enter &lt;-smp_apic_timer_interrupt
+              &lt;idle&gt;-0     [004] d..1   470.867172: rcu_irq_enter &lt;-irq_enter
+              &lt;idle&gt;-0     [004] d..1   470.867173: rcu_idle_exit_common.isra.33 &lt;-rcu_irq_enter
+              &lt;idle&gt;-0     [004] d..1   470.867173: local_bh_disable &lt;-irq_enter
+              &lt;idle&gt;-0     [004] d..1   470.867173: add_preempt_count &lt;-local_bh_disable
+              &lt;idle&gt;-0     [004] d.s1   470.867174: tick_check_idle &lt;-irq_enter
+              &lt;idle&gt;-0     [004] d.s1   470.867174: tick_check_oneshot_broadcast &lt;-tick_check_idle
+              &lt;idle&gt;-0     [004] d.s1   470.867174: ktime_get &lt;-tick_check_idle
+              &lt;idle&gt;-0     [004] d.s1   470.867174: tick_nohz_stop_idle &lt;-tick_check_idle
+              &lt;idle&gt;-0     [004] d.s1   470.867175: update_ts_time_stats &lt;-tick_nohz_stop_idle
+              &lt;idle&gt;-0     [004] d.s1   470.867175: nr_iowait_cpu &lt;-update_ts_time_stats
+              &lt;idle&gt;-0     [004] d.s1   470.867175: tick_do_update_jiffies64 &lt;-tick_check_idle
+              &lt;idle&gt;-0     [004] d.s1   470.867175: _raw_spin_lock &lt;-tick_do_update_jiffies64
+              &lt;idle&gt;-0     [004] d.s1   470.867176: add_preempt_count &lt;-_raw_spin_lock
+              &lt;idle&gt;-0     [004] d.s2   470.867176: do_timer &lt;-tick_do_update_jiffies64
+              &lt;idle&gt;-0     [004] d.s2   470.867176: _raw_spin_lock &lt;-do_timer
+              &lt;idle&gt;-0     [004] d.s2   470.867176: add_preempt_count &lt;-_raw_spin_lock
+              &lt;idle&gt;-0     [004] d.s3   470.867177: ntp_tick_length &lt;-do_timer
+              &lt;idle&gt;-0     [004] d.s3   470.867177: _raw_spin_lock_irqsave &lt;-ntp_tick_length
+              .
+              .
+              .
+            </literallayout>
+            Each line in the trace above shows what was happening in
+            the kernel on a given cpu, to the level of detail of
+            function calls. Each entry shows the function called,
+            followed by its caller (after the arrow).
+        </para>
+
+        <para>
+            The function tracer gives you an extremely detailed idea
+            of what the kernel was doing at the point in time the trace
+            was taken, and is a great way to learn about how the kernel
+            code works in a dynamic sense.
+        </para>
+
+        <informalexample>
+            <emphasis>Tying it Together:</emphasis> The ftrace function tracer is also
+            available from within perf, as the ftrace:function tracepoint.
+        </informalexample>
+
+        <para>
+            It is a little more difficult to follow the call chains than
+            it needs to be - luckily there's a variant of the function
+            tracer that displays the callchains explicitly, called the
+            'function_graph' tracer:
+            <literallayout class='monospaced'>
+     root@sugarbay:/sys/kernel/debug/tracing# echo function_graph &gt; current_tracer
+     root@sugarbay:/sys/kernel/debug/tracing# cat trace | less
+
+      tracer: function_graph
+
+      CPU  DURATION                  FUNCTION CALLS
+      |     |   |                     |   |   |   |
+     7)   0.046 us    |      pick_next_task_fair();
+     7)   0.043 us    |      pick_next_task_stop();
+     7)   0.042 us    |      pick_next_task_rt();
+     7)   0.032 us    |      pick_next_task_fair();
+     7)   0.030 us    |      pick_next_task_idle();
+     7)               |      _raw_spin_unlock_irq() {
+     7)   0.033 us    |        sub_preempt_count();
+     7)   0.258 us    |      }
+     7)   0.032 us    |      sub_preempt_count();
+     7) + 13.341 us   |    } /* __schedule */
+     7)   0.095 us    |  } /* sub_preempt_count */
+     7)               |  schedule() {
+     7)               |    __schedule() {
+     7)   0.060 us    |      add_preempt_count();
+     7)   0.044 us    |      rcu_note_context_switch();
+     7)               |      _raw_spin_lock_irq() {
+     7)   0.033 us    |        add_preempt_count();
+     7)   0.247 us    |      }
+     7)               |      idle_balance() {
+     7)               |        _raw_spin_unlock() {
+     7)   0.031 us    |          sub_preempt_count();
+     7)   0.246 us    |        }
+     7)               |        update_shares() {
+     7)   0.030 us    |          __rcu_read_lock();
+     7)   0.029 us    |          __rcu_read_unlock();
+     7)   0.484 us    |        }
+     7)   0.030 us    |        __rcu_read_lock();
+     7)               |        load_balance() {
+     7)               |          find_busiest_group() {
+     7)   0.031 us    |            idle_cpu();
+     7)   0.029 us    |            idle_cpu();
+     7)   0.035 us    |            idle_cpu();
+     7)   0.906 us    |          }
+     7)   1.141 us    |        }
+     7)   0.022 us    |        msecs_to_jiffies();
+     7)               |        load_balance() {
+     7)               |          find_busiest_group() {
+     7)   0.031 us    |            idle_cpu();
+     .
+     .
+     .
+     4)   0.062 us    |        msecs_to_jiffies();
+     4)   0.062 us    |        __rcu_read_unlock();
+     4)               |        _raw_spin_lock() {
+     4)   0.073 us    |          add_preempt_count();
+     4)   0.562 us    |        }
+     4) + 17.452 us   |      }
+     4)   0.108 us    |      put_prev_task_fair();
+     4)   0.102 us    |      pick_next_task_fair();
+     4)   0.084 us    |      pick_next_task_stop();
+     4)   0.075 us    |      pick_next_task_rt();
+     4)   0.062 us    |      pick_next_task_fair();
+     4)   0.066 us    |      pick_next_task_idle();
+     ------------------------------------------
+     4)   kworker-74   =&gt;    &lt;idle&gt;-0
+     ------------------------------------------
+
+     4)               |      finish_task_switch() {
+     4)               |        _raw_spin_unlock_irq() {
+     4)   0.100 us    |          sub_preempt_count();
+     4)   0.582 us    |        }
+     4)   1.105 us    |      }
+     4)   0.088 us    |      sub_preempt_count();
+     4) ! 100.066 us  |    }
+     .
+     .
+     .
+     3)               |  sys_ioctl() {
+     3)   0.083 us    |    fget_light();
+     3)               |    security_file_ioctl() {
+     3)   0.066 us    |      cap_file_ioctl();
+     3)   0.562 us    |    }
+     3)               |    do_vfs_ioctl() {
+     3)               |      drm_ioctl() {
+     3)   0.075 us    |        drm_ut_debug_printk();
+     3)               |        i915_gem_pwrite_ioctl() {
+     3)               |          i915_mutex_lock_interruptible() {
+     3)   0.070 us    |            mutex_lock_interruptible();
+     3)   0.570 us    |          }
+     3)               |          drm_gem_object_lookup() {
+     3)               |            _raw_spin_lock() {
+     3)   0.080 us    |              add_preempt_count();
+     3)   0.620 us    |            }
+     3)               |            _raw_spin_unlock() {
+     3)   0.085 us    |              sub_preempt_count();
+     3)   0.562 us    |            }
+     3)   2.149 us    |          }
+     3)   0.133 us    |          i915_gem_object_pin();
+     3)               |          i915_gem_object_set_to_gtt_domain() {
+     3)   0.065 us    |            i915_gem_object_flush_gpu_write_domain();
+     3)   0.065 us    |            i915_gem_object_wait_rendering();
+     3)   0.062 us    |            i915_gem_object_flush_cpu_write_domain();
+     3)   1.612 us    |          }
+     3)               |          i915_gem_object_put_fence() {
+     3)   0.097 us    |            i915_gem_object_flush_fence.constprop.36();
+     3)   0.645 us    |          }
+     3)   0.070 us    |          add_preempt_count();
+     3)   0.070 us    |          sub_preempt_count();
+     3)   0.073 us    |          i915_gem_object_unpin();
+     3)   0.068 us    |          mutex_unlock();
+     3)   9.924 us    |        }
+     3) + 11.236 us   |      }
+     3) + 11.770 us   |    }
+     3) + 13.784 us   |  }
+     3)               |  sys_ioctl() {
+            </literallayout>
+            As you can see, the function_graph display is much easier to
+            follow. Also note that in addition to the function calls and
+            associated braces, other events such as scheduler events
+            are displayed in context. In fact, you can freely include
+            any tracepoint available in the trace events subsystem described
+            in the next section by simply enabling those events, and they'll
+            appear in context in the function graph display. Quite a
+            powerful tool for understanding kernel dynamics.
+        </para>
+
+        <para>
+            Also notice that there are various annotations on the left
+            hand side of the display. For example if the total time it
+            took for a given function to execute is above a certain
+            threshold, an exclamation point or plus sign appears on the
+            left hand side. Please see the ftrace documentation for
+            details on all these fields.
+        </para>
+    </section>
+
+    <section id='the-trace-events-subsystem'>
+        <title>The 'trace events' Subsystem</title>
+
+        <para>
+            One especially important directory contained within
+            the /sys/kernel/debug/tracing directory is the 'events'
+            subdirectory, which contains representations of every
+            tracepoint in the system. Listing out the contents of
+            the 'events' subdirectory, we see mainly another set of
+            subdirectories:
+            <literallayout class='monospaced'>
+     root@sugarbay:/sys/kernel/debug/tracing# cd events
+     root@sugarbay:/sys/kernel/debug/tracing/events# ls -al
+     drwxr-xr-x   38 root     root             0 Nov 14 23:19 .
+     drwxr-xr-x    5 root     root             0 Nov 14 23:19 ..
+     drwxr-xr-x   19 root     root             0 Nov 14 23:19 block
+     drwxr-xr-x   32 root     root             0 Nov 14 23:19 btrfs
+     drwxr-xr-x    5 root     root             0 Nov 14 23:19 drm
+     -rw-r--r--    1 root     root             0 Nov 14 23:19 enable
+     drwxr-xr-x   40 root     root             0 Nov 14 23:19 ext3
+     drwxr-xr-x   79 root     root             0 Nov 14 23:19 ext4
+     drwxr-xr-x   14 root     root             0 Nov 14 23:19 ftrace
+     drwxr-xr-x    8 root     root             0 Nov 14 23:19 hda
+     -r--r--r--    1 root     root             0 Nov 14 23:19 header_event
+     -r--r--r--    1 root     root             0 Nov 14 23:19 header_page
+     drwxr-xr-x   25 root     root             0 Nov 14 23:19 i915
+     drwxr-xr-x    7 root     root             0 Nov 14 23:19 irq
+     drwxr-xr-x   12 root     root             0 Nov 14 23:19 jbd
+     drwxr-xr-x   14 root     root             0 Nov 14 23:19 jbd2
+     drwxr-xr-x   14 root     root             0 Nov 14 23:19 kmem
+     drwxr-xr-x    7 root     root             0 Nov 14 23:19 module
+     drwxr-xr-x    3 root     root             0 Nov 14 23:19 napi
+     drwxr-xr-x    6 root     root             0 Nov 14 23:19 net
+     drwxr-xr-x    3 root     root             0 Nov 14 23:19 oom
+     drwxr-xr-x   12 root     root             0 Nov 14 23:19 power
+     drwxr-xr-x    3 root     root             0 Nov 14 23:19 printk
+     drwxr-xr-x    8 root     root             0 Nov 14 23:19 random
+     drwxr-xr-x    4 root     root             0 Nov 14 23:19 raw_syscalls
+     drwxr-xr-x    3 root     root             0 Nov 14 23:19 rcu
+     drwxr-xr-x    6 root     root             0 Nov 14 23:19 rpm
+     drwxr-xr-x   20 root     root             0 Nov 14 23:19 sched
+     drwxr-xr-x    7 root     root             0 Nov 14 23:19 scsi
+     drwxr-xr-x    4 root     root             0 Nov 14 23:19 signal
+     drwxr-xr-x    5 root     root             0 Nov 14 23:19 skb
+     drwxr-xr-x    4 root     root             0 Nov 14 23:19 sock
+     drwxr-xr-x   10 root     root             0 Nov 14 23:19 sunrpc
+     drwxr-xr-x  538 root     root             0 Nov 14 23:19 syscalls
+     drwxr-xr-x    4 root     root             0 Nov 14 23:19 task
+     drwxr-xr-x   14 root     root             0 Nov 14 23:19 timer
+     drwxr-xr-x    3 root     root             0 Nov 14 23:19 udp
+     drwxr-xr-x   21 root     root             0 Nov 14 23:19 vmscan
+     drwxr-xr-x    3 root     root             0 Nov 14 23:19 vsyscall
+     drwxr-xr-x    6 root     root             0 Nov 14 23:19 workqueue
+     drwxr-xr-x   26 root     root             0 Nov 14 23:19 writeback
+            </literallayout>
+            Each one of these subdirectories corresponds to a
+            'subsystem' and contains yet again more subdirectories,
+            each one of those finally corresponding to a tracepoint.
+            For example, here are the contents of the 'kmem' subsystem:
+            <literallayout class='monospaced'>
+     root@sugarbay:/sys/kernel/debug/tracing/events# cd kmem
+     root@sugarbay:/sys/kernel/debug/tracing/events/kmem# ls -al
+     drwxr-xr-x   14 root     root             0 Nov 14 23:19 .
+     drwxr-xr-x   38 root     root             0 Nov 14 23:19 ..
+     -rw-r--r--    1 root     root             0 Nov 14 23:19 enable
+     -rw-r--r--    1 root     root             0 Nov 14 23:19 filter
+     drwxr-xr-x    2 root     root             0 Nov 14 23:19 kfree
+     drwxr-xr-x    2 root     root             0 Nov 14 23:19 kmalloc
+     drwxr-xr-x    2 root     root             0 Nov 14 23:19 kmalloc_node
+     drwxr-xr-x    2 root     root             0 Nov 14 23:19 kmem_cache_alloc
+     drwxr-xr-x    2 root     root             0 Nov 14 23:19 kmem_cache_alloc_node
+     drwxr-xr-x    2 root     root             0 Nov 14 23:19 kmem_cache_free
+     drwxr-xr-x    2 root     root             0 Nov 14 23:19 mm_page_alloc
+     drwxr-xr-x    2 root     root             0 Nov 14 23:19 mm_page_alloc_extfrag
+     drwxr-xr-x    2 root     root             0 Nov 14 23:19 mm_page_alloc_zone_locked
+     drwxr-xr-x    2 root     root             0 Nov 14 23:19 mm_page_free
+     drwxr-xr-x    2 root     root             0 Nov 14 23:19 mm_page_free_batched
+     drwxr-xr-x    2 root     root             0 Nov 14 23:19 mm_page_pcpu_drain
+            </literallayout>
+            Let's see what's inside the subdirectory for a specific
+            tracepoint, in this case the one for kmalloc:
+            <literallayout class='monospaced'>
+     root@sugarbay:/sys/kernel/debug/tracing/events/kmem# cd kmalloc
+     root@sugarbay:/sys/kernel/debug/tracing/events/kmem/kmalloc# ls -al
+     drwxr-xr-x    2 root     root             0 Nov 14 23:19 .
+     drwxr-xr-x   14 root     root             0 Nov 14 23:19 ..
+     -rw-r--r--    1 root     root             0 Nov 14 23:19 enable
+     -rw-r--r--    1 root     root             0 Nov 14 23:19 filter
+     -r--r--r--    1 root     root             0 Nov 14 23:19 format
+     -r--r--r--    1 root     root             0 Nov 14 23:19 id
+            </literallayout>
+            The 'format' file for the tracepoint describes the event
+            in memory, which is used by the various tracing tools
+            that now make use of these tracepoint to parse the event
+            and make sense of it, along with a 'print fmt' field that
+            allows tools like ftrace to display the event as text.
+            Here's what the format of the kmalloc event looks like:
+            <literallayout class='monospaced'>
+     root@sugarbay:/sys/kernel/debug/tracing/events/kmem/kmalloc# cat format
+     name: kmalloc
+     ID: 313
+     format:
+             field:unsigned short common_type;  offset:0;       size:2; signed:0;
+             field:unsigned char common_flags;  offset:2;       size:1; signed:0;
+             field:unsigned char common_preempt_count;  offset:3;       size:1; signed:0;
+             field:int common_pid;      offset:4;       size:4; signed:1;
+             field:int common_padding;  offset:8;       size:4; signed:1;
+
+             field:unsigned long call_site;     offset:16;      size:8; signed:0;
+             field:const void * ptr;    offset:24;      size:8; signed:0;
+             field:size_t bytes_req;    offset:32;      size:8; signed:0;
+             field:size_t bytes_alloc;  offset:40;      size:8; signed:0;
+             field:gfp_t gfp_flags;     offset:48;      size:4; signed:0;
+
+     print fmt: "call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s", REC->call_site, REC->ptr, REC->bytes_req, REC->bytes_alloc,
+     (REC->gfp_flags) ? __print_flags(REC->gfp_flags, "|", {(unsigned long)(((( gfp_t)0x10u) | (( gfp_t)0x40u) | (( gfp_t)0x80u) | ((
+     gfp_t)0x20000u) | (( gfp_t)0x02u) | (( gfp_t)0x08u)) | (( gfp_t)0x4000u) | (( gfp_t)0x10000u) | (( gfp_t)0x1000u) | (( gfp_t)0x200u) | ((
+     gfp_t)0x400000u)), "GFP_TRANSHUGE"}, {(unsigned long)((( gfp_t)0x10u) | (( gfp_t)0x40u) | (( gfp_t)0x80u) | (( gfp_t)0x20000u) | ((
+     gfp_t)0x02u) | (( gfp_t)0x08u)), "GFP_HIGHUSER_MOVABLE"}, {(unsigned long)((( gfp_t)0x10u) | (( gfp_t)0x40u) | (( gfp_t)0x80u) | ((
+     gfp_t)0x20000u) | (( gfp_t)0x02u)), "GFP_HIGHUSER"}, {(unsigned long)((( gfp_t)0x10u) | (( gfp_t)0x40u) | (( gfp_t)0x80u) | ((
+     gfp_t)0x20000u)), "GFP_USER"}, {(unsigned long)((( gfp_t)0x10u) | (( gfp_t)0x40u) | (( gfp_t)0x80u) | (( gfp_t)0x80000u)), GFP_TEMPORARY"},
+     {(unsigned long)((( gfp_t)0x10u) | (( gfp_t)0x40u) | (( gfp_t)0x80u)), "GFP_KERNEL"}, {(unsigned long)((( gfp_t)0x10u) | (( gfp_t)0x40u)),
+     "GFP_NOFS"}, {(unsigned long)((( gfp_t)0x20u)), "GFP_ATOMIC"}, {(unsigned long)((( gfp_t)0x10u)), "GFP_NOIO"}, {(unsigned long)((
+     gfp_t)0x20u), "GFP_HIGH"}, {(unsigned long)(( gfp_t)0x10u), "GFP_WAIT"}, {(unsigned long)(( gfp_t)0x40u), "GFP_IO"}, {(unsigned long)((
+     gfp_t)0x100u), "GFP_COLD"}, {(unsigned long)(( gfp_t)0x200u), "GFP_NOWARN"}, {(unsigned long)(( gfp_t)0x400u), "GFP_REPEAT"}, {(unsigned
+     long)(( gfp_t)0x800u), "GFP_NOFAIL"}, {(unsigned long)(( gfp_t)0x1000u), "GFP_NORETRY"},      {(unsigned long)(( gfp_t)0x4000u), "GFP_COMP"},
+     {(unsigned long)(( gfp_t)0x8000u), "GFP_ZERO"}, {(unsigned long)(( gfp_t)0x10000u), "GFP_NOMEMALLOC"}, {(unsigned long)(( gfp_t)0x20000u),
+     "GFP_HARDWALL"}, {(unsigned long)(( gfp_t)0x40000u), "GFP_THISNODE"}, {(unsigned long)(( gfp_t)0x80000u), "GFP_RECLAIMABLE"}, {(unsigned
+     long)(( gfp_t)0x08u), "GFP_MOVABLE"}, {(unsigned long)(( gfp_t)0), "GFP_NOTRACK"}, {(unsigned long)(( gfp_t)0x400000u), "GFP_NO_KSWAPD"},
+     {(unsigned long)(( gfp_t)0x800000u), "GFP_OTHER_NODE"} ) : "GFP_NOWAIT"
+            </literallayout>
+            The 'enable' file in the tracepoint directory is what allows
+            the user (or tools such as trace-cmd) to actually turn the
+            tracepoint on and off. When enabled, the corresponding
+            tracepoint will start appearing in the ftrace 'trace'
+            file described previously. For example, this turns on the
+            kmalloc tracepoint:
+            <literallayout class='monospaced'>
+     root@sugarbay:/sys/kernel/debug/tracing/events/kmem/kmalloc# echo 1 > enable
+            </literallayout>
+            At the moment, we're not interested in the function tracer or
+            some other tracer that might be in effect, so we first turn
+            it off, but if we do that, we still need to turn tracing on in
+            order to see the events in the output buffer:
+            <literallayout class='monospaced'>
+     root@sugarbay:/sys/kernel/debug/tracing# echo nop > current_tracer
+     root@sugarbay:/sys/kernel/debug/tracing# echo 1 > tracing_on
+            </literallayout>
+            Now, if we look at the the 'trace' file, we see nothing
+            but the kmalloc events we just turned on:
+            <literallayout class='monospaced'>
+     root@sugarbay:/sys/kernel/debug/tracing# cat trace | less
+     # tracer: nop
+     #
+     # entries-in-buffer/entries-written: 1897/1897   #P:8
+     #
+     #                              _-----=&gt; irqs-off
+     #                             / _----=&gt; need-resched
+     #                            | / _---=&gt; hardirq/softirq
+     #                            || / _--=&gt; preempt-depth
+     #                            ||| /     delay
+     #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
+     #              | |       |   ||||       |         |
+            dropbear-1465  [000] ...1 18154.620753: kmalloc: call_site=ffffffff816650d4 ptr=ffff8800729c3000 bytes_req=2048 bytes_alloc=2048 gfp_flags=GFP_KERNEL
+              &lt;idle&gt;-0     [000] ..s3 18154.621640: kmalloc: call_site=ffffffff81619b36 ptr=ffff88006d555800 bytes_req=512 bytes_alloc=512 gfp_flags=GFP_ATOMIC
+              &lt;idle&gt;-0     [000] ..s3 18154.621656: kmalloc: call_site=ffffffff81619b36 ptr=ffff88006d555800 bytes_req=512 bytes_alloc=512 gfp_flags=GFP_ATOMIC
+     matchbox-termin-1361  [001] ...1 18154.755472: kmalloc: call_site=ffffffff81614050 ptr=ffff88006d5f0e00 bytes_req=512 bytes_alloc=512 gfp_flags=GFP_KERNEL|GFP_REPEAT
+                Xorg-1264  [002] ...1 18154.755581: kmalloc: call_site=ffffffff8141abe8 ptr=ffff8800734f4cc0 bytes_req=168 bytes_alloc=192 gfp_flags=GFP_KERNEL|GFP_NOWARN|GFP_NORETRY
+                Xorg-1264  [002] ...1 18154.755583: kmalloc: call_site=ffffffff814192a3 ptr=ffff88001f822520 bytes_req=24 bytes_alloc=32 gfp_flags=GFP_KERNEL|GFP_ZERO
+                Xorg-1264  [002] ...1 18154.755589: kmalloc: call_site=ffffffff81419edb ptr=ffff8800721a2f00 bytes_req=64 bytes_alloc=64 gfp_flags=GFP_KERNEL|GFP_ZERO
+     matchbox-termin-1361  [001] ...1 18155.354594: kmalloc: call_site=ffffffff81614050 ptr=ffff88006db35400 bytes_req=576 bytes_alloc=1024 gfp_flags=GFP_KERNEL|GFP_REPEAT
+                Xorg-1264  [002] ...1 18155.354703: kmalloc: call_site=ffffffff8141abe8 ptr=ffff8800734f4cc0 bytes_req=168 bytes_alloc=192 gfp_flags=GFP_KERNEL|GFP_NOWARN|GFP_NORETRY
+                Xorg-1264  [002] ...1 18155.354705: kmalloc: call_site=ffffffff814192a3 ptr=ffff88001f822520 bytes_req=24 bytes_alloc=32 gfp_flags=GFP_KERNEL|GFP_ZERO
+                Xorg-1264  [002] ...1 18155.354711: kmalloc: call_site=ffffffff81419edb ptr=ffff8800721a2f00 bytes_req=64 bytes_alloc=64 gfp_flags=GFP_KERNEL|GFP_ZERO
+              &lt;idle&gt;-0     [000] ..s3 18155.673319: kmalloc: call_site=ffffffff81619b36 ptr=ffff88006d555800 bytes_req=512 bytes_alloc=512 gfp_flags=GFP_ATOMIC
+            dropbear-1465  [000] ...1 18155.673525: kmalloc: call_site=ffffffff816650d4 ptr=ffff8800729c3000 bytes_req=2048 bytes_alloc=2048 gfp_flags=GFP_KERNEL
+              &lt;idle&gt;-0     [000] ..s3 18155.674821: kmalloc: call_site=ffffffff81619b36 ptr=ffff88006d554800 bytes_req=512 bytes_alloc=512 gfp_flags=GFP_ATOMIC
+              &lt;idle&gt;-0     [000] ..s3 18155.793014: kmalloc: call_site=ffffffff81619b36 ptr=ffff88006d554800 bytes_req=512 bytes_alloc=512 gfp_flags=GFP_ATOMIC
+            dropbear-1465  [000] ...1 18155.793219: kmalloc: call_site=ffffffff816650d4 ptr=ffff8800729c3000 bytes_req=2048 bytes_alloc=2048 gfp_flags=GFP_KERNEL
+              &lt;idle&gt;-0     [000] ..s3 18155.794147: kmalloc: call_site=ffffffff81619b36 ptr=ffff88006d555800 bytes_req=512 bytes_alloc=512 gfp_flags=GFP_ATOMIC
+              &lt;idle&gt;-0     [000] ..s3 18155.936705: kmalloc: call_site=ffffffff81619b36 ptr=ffff88006d555800 bytes_req=512 bytes_alloc=512 gfp_flags=GFP_ATOMIC
+            dropbear-1465  [000] ...1 18155.936910: kmalloc: call_site=ffffffff816650d4 ptr=ffff8800729c3000 bytes_req=2048 bytes_alloc=2048 gfp_flags=GFP_KERNEL
+              &lt;idle&gt;-0     [000] ..s3 18155.937869: kmalloc: call_site=ffffffff81619b36 ptr=ffff88006d554800 bytes_req=512 bytes_alloc=512 gfp_flags=GFP_ATOMIC
+     matchbox-termin-1361  [001] ...1 18155.953667: kmalloc: call_site=ffffffff81614050 ptr=ffff88006d5f2000 bytes_req=512 bytes_alloc=512 gfp_flags=GFP_KERNEL|GFP_REPEAT
+                Xorg-1264  [002] ...1 18155.953775: kmalloc: call_site=ffffffff8141abe8 ptr=ffff8800734f4cc0 bytes_req=168 bytes_alloc=192 gfp_flags=GFP_KERNEL|GFP_NOWARN|GFP_NORETRY
+                Xorg-1264  [002] ...1 18155.953777: kmalloc: call_site=ffffffff814192a3 ptr=ffff88001f822520 bytes_req=24 bytes_alloc=32 gfp_flags=GFP_KERNEL|GFP_ZERO
+                Xorg-1264  [002] ...1 18155.953783: kmalloc: call_site=ffffffff81419edb ptr=ffff8800721a2f00 bytes_req=64 bytes_alloc=64 gfp_flags=GFP_KERNEL|GFP_ZERO
+              &lt;idle&gt;-0     [000] ..s3 18156.176053: kmalloc: call_site=ffffffff81619b36 ptr=ffff88006d554800 bytes_req=512 bytes_alloc=512 gfp_flags=GFP_ATOMIC
+            dropbear-1465  [000] ...1 18156.176257: kmalloc: call_site=ffffffff816650d4 ptr=ffff8800729c3000 bytes_req=2048 bytes_alloc=2048 gfp_flags=GFP_KERNEL
+              &lt;idle&gt;-0     [000] ..s3 18156.177717: kmalloc: call_site=ffffffff81619b36 ptr=ffff88006d555800 bytes_req=512 bytes_alloc=512 gfp_flags=GFP_ATOMIC
+              &lt;idle&gt;-0     [000] ..s3 18156.399229: kmalloc: call_site=ffffffff81619b36 ptr=ffff88006d555800 bytes_req=512 bytes_alloc=512 gfp_flags=GFP_ATOMIC
+            dropbear-1465  [000] ...1 18156.399434: kmalloc: call_site=ffffffff816650d4 ptr=ffff8800729c3000 bytes_http://rostedt.homelinux.com/kernelshark/req=2048 bytes_alloc=2048 gfp_flags=GFP_KERNEL
+              &lt;idle&gt;-0     [000] ..s3 18156.400660: kmalloc: call_site=ffffffff81619b36 ptr=ffff88006d554800 bytes_req=512 bytes_alloc=512 gfp_flags=GFP_ATOMIC
+     matchbox-termin-1361  [001] ...1 18156.552800: kmalloc: call_site=ffffffff81614050 ptr=ffff88006db34800 bytes_req=576 bytes_alloc=1024 gfp_flags=GFP_KERNEL|GFP_REPEAT
+            </literallayout>
+            To again disable the kmalloc event, we need to send 0 to the
+            enable file:
+            <literallayout class='monospaced'>
+     root@sugarbay:/sys/kernel/debug/tracing/events/kmem/kmalloc# echo 0 > enable
+            </literallayout>
+            You can enable any number of events or complete subsystems
+            (by using the 'enable' file in the subsystem directory) and
+            get an arbitrarily fine-grained idea of what's going on in the
+            system by enabling as many of the appropriate tracepoints
+            as applicable.
+        </para>
+
+        <para>
+            A number of the tools described in this HOWTO do just that,
+            including trace-cmd and kernelshark in the next section.
+        </para>
+
+        <informalexample>
+            <emphasis>Tying it Together:</emphasis> These tracepoints and their representation
+            are used not only by ftrace,  but by many of the other tools
+            covered in this document and they form a central point of
+            integration for the various tracers available in Linux.
+            They form a central part of the instrumentation for the
+            following tools: perf, lttng, ftrace, blktrace and SystemTap
+        </informalexample>
+
+        <informalexample>
+            <emphasis>Tying it Together:</emphasis> Eventually all the special-purpose tracers
+            currently available in /sys/kernel/debug/tracing will be
+            removed and replaced with equivalent tracers based on the
+            'trace events' subsystem.
+        </informalexample>
+    </section>
+
+    <section id='trace-cmd-kernelshark'>
+        <title>trace-cmd/kernelshark</title>
+
+        <para>
+            trace-cmd is essentially an extensive command-line 'wrapper'
+            interface that hides the details of all the individual files
+            in /sys/kernel/debug/tracing, allowing users to specify
+            specific particular events within the
+            /sys/kernel/debug/tracing/events/ subdirectory and to collect
+            traces and avoid having to deal with those details directly.
+        </para>
+
+        <para>
+            As yet another layer on top of that, kernelshark provides a GUI
+            that allows users to start and stop traces and specify sets
+            of events using an intuitive interface, and view the
+            output as both trace events and as a per-CPU graphical
+            display. It directly uses 'trace-cmd' as the plumbing
+            that accomplishes all that underneath the covers (and
+            actually displays the trace-cmd command it uses, as we'll see).
+        </para>
+
+        <para>
+            To start a trace using kernelshark, first start kernelshark:
+            <literallayout class='monospaced'>
+     root@sugarbay:~# kernelshark
+            </literallayout>
+            Then bring up the 'Capture' dialog by choosing from the
+            kernelshark menu:
+            <literallayout class='monospaced'>
+     Capture | Record
+            </literallayout>
+            That will display the following dialog, which allows you to
+            choose one or more events (or even one or more complete
+            subsystems) to trace:
+        </para>
+
+        <para>
+            <imagedata fileref="figures/kernelshark-choose-events.png" width="6in" depth="6in" align="center" scalefit="1" />
+        </para>
+
+        <para>
+            Note that these are exactly the same sets of events described
+            in the previous trace events subsystem section, and in fact
+            is where trace-cmd gets them for kernelshark.
+        </para>
+
+        <para>
+            In the above screenshot, we've decided to explore the
+            graphics subsystem a bit and so have chosen to trace all
+            the tracepoints contained within the 'i915' and 'drm'
+            subsystems.
+        </para>
+
+        <para>
+            After doing that, we can start and stop the trace using
+            the 'Run' and 'Stop' button on the lower right corner of
+            the dialog (the same button will turn into the 'Stop'
+            button after the trace has started):
+        </para>
+
+        <para>
+            <imagedata fileref="figures/kernelshark-output-display.png" width="6in" depth="6in" align="center" scalefit="1" />
+        </para>
+
+        <para>
+            Notice that the right-hand pane shows the exact trace-cmd
+            command-line that's used to run the trace, along with the
+            results of the trace-cmd run.
+        </para>
+
+        <para>
+            Once the 'Stop' button is pressed, the graphical view magically
+            fills up with a colorful per-cpu display of the trace data,
+            along with the detailed event listing below that:
+        </para>
+
+        <para>
+            <imagedata fileref="figures/kernelshark-i915-display.png" width="6in" depth="7in" align="center" scalefit="1" />
+        </para>
+
+        <para>
+            Here's another example, this time a display resulting
+            from tracing 'all events':
+        </para>
+
+        <para>
+            <imagedata fileref="figures/kernelshark-all.png" width="6in" depth="7in" align="center" scalefit="1" />
+        </para>
+
+        <para>
+            The tool is pretty self-explanatory, but for more detailed
+            information on navigating through the data, see the
+            <ulink url='http://rostedt.homelinux.com/kernelshark/'>kernelshark website</ulink>.
+        </para>
+    </section>
+
+    <section id='ftrace-documentation'>
+        <title>Documentation</title>
+
+        <para>
+            The documentation for ftrace can be found in the kernel
+            Documentation directory:
+            <literallayout class='monospaced'>
+     Documentation/trace/ftrace.txt
+            </literallayout>
+            The documentation for the trace event subsystem can also
+            be found in the kernel Documentation directory:
+            <literallayout class='monospaced'>
+     Documentation/trace/events.txt
+            </literallayout>
+            There is a nice series of articles on using
+            ftrace and trace-cmd at LWN:
+            <itemizedlist>
+                <listitem><para><ulink url='http://lwn.net/Articles/365835/'>Debugging the kernel using Ftrace - part 1</ulink>
+                    </para></listitem>
+                <listitem><para><ulink url='http://lwn.net/Articles/366796/'>Debugging the kernel using Ftrace - part 2</ulink>
+                    </para></listitem>
+                <listitem><para><ulink url='http://lwn.net/Articles/370423/'>Secrets of the Ftrace function tracer</ulink>
+                    </para></listitem>
+                <listitem><para><ulink url='https://lwn.net/Articles/410200/'>trace-cmd: A front-end for Ftrace</ulink>
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            There's more detailed documentation kernelshark usage here:
+            <ulink url='http://rostedt.homelinux.com/kernelshark/'>KernelShark</ulink>
+        </para>
+
+        <para>
+            An amusing yet useful README (a tracing mini-HOWTO) can be
+            found in /sys/kernel/debug/tracing/README.
+        </para>
+    </section>
+</section>
+
+<section id='profile-manual-systemtap'>
+    <title>systemtap</title>
+
+    <para>
+        SystemTap is a system-wide script-based tracing and profiling tool.
+    </para>
+
+    <para>
+        SystemTap scripts are C-like programs that are executed in the
+        kernel to gather/print/aggregate data extracted from the context
+        they end up being invoked under.
+    </para>
+
+    <para>
+        For example, this probe from the
+        <ulink url='http://sourceware.org/systemtap/tutorial/'>SystemTap tutorial</ulink>
+        simply prints a line every time any process on the system open()s
+        a file. For each line, it prints the executable name of the
+        program that opened the file, along with its PID, and the name
+        of the file it opened (or tried to open), which it extracts
+        from the open syscall's argstr.
+        <literallayout class='monospaced'>
+     probe syscall.open
+     {
+             printf ("%s(%d) open (%s)\n", execname(), pid(), argstr)
+     }
+
+     probe timer.ms(4000) # after 4 seconds
+     {
+             exit ()
+     }
+        </literallayout>
+        Normally, to execute this probe, you'd simply install
+        systemtap on the system you want to probe, and directly run
+        the probe on that system e.g. assuming the name of the file
+        containing the above text is trace_open.stp:
+        <literallayout class='monospaced'>
+     # stap trace_open.stp
+        </literallayout>
+        What systemtap does under the covers to run this probe is 1)
+        parse and convert the probe to an equivalent 'C' form, 2)
+        compile the 'C' form into a kernel module, 3) insert the
+        module into the kernel, which arms it, and 4) collect the data
+        generated by the probe and display it to the user.
+     </para>
+
+     <para>
+        In order to accomplish steps 1 and 2, the 'stap' program needs
+        access to the kernel build system that produced the kernel
+        that the probed system is running. In the case of a typical
+        embedded system (the 'target'), the kernel build system
+        unfortunately isn't typically part of the image running on
+        the target. It is normally available on the 'host' system
+        that produced the target image however; in such cases,
+        steps 1 and 2 are executed on the host system, and steps
+        3 and 4 are executed on the target system, using only the
+        systemtap 'runtime'.
+    </para>
+
+    <para>
+        The systemtap support in Yocto assumes that only steps
+        3 and 4 are run on the target; it is possible to do
+        everything on the target, but this section assumes only
+        the typical embedded use-case.
+    </para>
+
+    <para>
+        So basically what you need to do in order to run a systemtap
+        script on the target is to 1) on the host system, compile the
+        probe into a kernel module that makes sense to the target, 2)
+        copy the module onto the target system and 3) insert the
+        module into the target kernel, which arms it, and 4) collect
+        the data generated by the probe and display it to the user.
+    </para>
+
+    <section id='systemtap-setup'>
+        <title>Setup</title>
+
+        <para>
+            Those are a lot of steps and a lot of details, but
+            fortunately Yocto includes a script called 'crosstap'
+            that will take care of those details, allowing you to
+            simply execute a systemtap script on the remote target,
+            with arguments if necessary.
+        </para>
+
+        <para>
+            In order to do this from a remote host, however, you
+            need to have access to the build for the image you
+            booted. The 'crosstap' script provides details on how
+            to do this if you run the script on the host without having
+            done a build:
+            <note>
+                SystemTap, which uses 'crosstap', assumes you can establish an
+                ssh connection to the remote target.
+                Please refer to the crosstap wiki page for details on verifying
+                ssh connections at
+                <ulink url='https://wiki.yoctoproject.org/wiki/Tracing_and_Profiling#systemtap'></ulink>.
+                Also, the ability to ssh into the target system is not enabled
+                by default in *-minimal images.
+            </note>
+            <literallayout class='monospaced'>
+     $ crosstap root@192.168.1.88 trace_open.stp
+
+     Error: No target kernel build found.
+     Did you forget to create a local build of your image?
+
+     'crosstap' requires a local sdk build of the target system
+     (or a build that includes 'tools-profile') in order to build
+     kernel modules that can probe the target system.
+
+     Practically speaking, that means you need to do the following:
+      - If you're running a pre-built image, download the release
+        and/or BSP tarballs used to build the image.
+      - If you're working from git sources, just clone the metadata
+        and BSP layers needed to build the image you'll be booting.
+      - Make sure you're properly set up to build a new image (see
+        the BSP README and/or the widely available basic documentation
+        that discusses how to build images).
+      - Build an -sdk version of the image e.g.:
+          $ bitbake core-image-sato-sdk
+      OR
+      - Build a non-sdk image but include the profiling tools:
+          [ edit local.conf and add 'tools-profile' to the end of
+            the EXTRA_IMAGE_FEATURES variable ]
+          $ bitbake core-image-sato
+
+     Once you've build the image on the host system, you're ready to
+     boot it (or the equivalent pre-built image) and use 'crosstap'
+     to probe it (you need to source the environment as usual first):
+
+        $ source oe-init-build-env
+        $ cd ~/my/systemtap/scripts
+        $ crosstap root@192.168.1.xxx myscript.stp
+            </literallayout>
+            So essentially what you need to do is build an SDK image or
+            image with 'tools-profile' as detailed in the
+            "<link linkend='profile-manual-general-setup'>General Setup</link>"
+            section of this manual, and boot the resulting target image.
+        </para>
+
+        <note>
+            If you have a build directory containing multiple machines,
+            you need to have the MACHINE you're connecting to selected
+            in local.conf, and the kernel in that machine's build
+            directory must match the kernel on the booted system exactly,
+            or you'll get the above 'crosstap' message when you try to
+            invoke a script.
+        </note>
+    </section>
+
+    <section id='running-a-script-on-a-target'>
+        <title>Running a Script on a Target</title>
+
+        <para>
+            Once you've done that, you should be able to run a systemtap
+            script on the target:
+            <literallayout class='monospaced'>
+     $ cd /path/to/yocto
+     $ source oe-init-build-env
+
+     ### Shell environment set up for builds. ###
+
+     You can now run 'bitbake <replaceable>target</replaceable>'
+
+     Common targets are:
+         core-image-minimal
+         core-image-sato
+         meta-toolchain
+         adt-installer
+         meta-ide-support
+
+     You can also run generated qemu images with a command like 'runqemu qemux86'
+            </literallayout>
+            Once you've done that, you can cd to whatever directory
+            contains your scripts and use 'crosstap' to run the script:
+            <literallayout class='monospaced'>
+     $ cd /path/to/my/systemap/script
+     $ crosstap root@192.168.7.2 trace_open.stp
+            </literallayout>
+            If you get an error connecting to the target e.g.:
+            <literallayout class='monospaced'>
+     $ crosstap root@192.168.7.2 trace_open.stp
+     error establishing ssh connection on remote 'root@192.168.7.2'
+            </literallayout>
+            Try ssh'ing to the target and see what happens:
+            <literallayout class='monospaced'>
+     $ ssh root@192.168.7.2
+            </literallayout>
+            A lot of the time, connection problems are due specifying a
+            wrong IP address or having a 'host key verification error'.
+        </para>
+
+        <para>
+            If everything worked as planned, you should see something
+            like this (enter the password when prompted, or press enter
+            if it's set up to use no password):
+            <literallayout class='monospaced'>
+     $ crosstap root@192.168.7.2 trace_open.stp
+     root@192.168.7.2's password:
+     matchbox-termin(1036) open ("/tmp/vte3FS2LW", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600)
+     matchbox-termin(1036) open ("/tmp/vteJMC7LW", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600)
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='systemtap-documentation'>
+        <title>Documentation</title>
+
+        <para>
+            The SystemTap language reference can be found here:
+            <ulink url='http://sourceware.org/systemtap/langref/'>SystemTap Language Reference</ulink>
+        </para>
+
+        <para>
+            Links to other SystemTap documents, tutorials, and examples can be
+            found here:
+            <ulink url='http://sourceware.org/systemtap/documentation.html'>SystemTap documentation page</ulink>
+        </para>
+    </section>
+</section>
+
+<section id='profile-manual-oprofile'>
+    <title>oprofile</title>
+
+    <para>
+        oprofile itself is a command-line application that runs on the
+        target system.
+    </para>
+
+    <section id='oprofile-setup'>
+        <title>Setup</title>
+
+        <para>
+            For this section, we'll assume you've already performed the
+            basic setup outlined in the
+            "<link linkend='profile-manual-general-setup'>General Setup</link>"
+            section.
+        </para>
+
+        <para>
+            For the section that deals with running oprofile from the command-line,
+            we assume you've ssh'ed to the host and will be running
+            oprofile on the target.
+        </para>
+
+        <para>
+            oprofileui (oprofile-viewer) is a GUI-based program that runs
+            on the host and interacts remotely with the target.
+            See the oprofileui section for the exact steps needed to
+            install oprofileui on the host.
+        </para>
+    </section>
+
+    <section id='oprofile-basic-usage'>
+        <title>Basic Usage</title>
+
+        <para>
+            Oprofile as configured in Yocto is a system-wide profiler
+            (i.e. the version in Yocto doesn't yet make use of the
+            perf_events interface which would allow it to profile
+            specific processes and workloads). It relies on hardware
+            counter support in the hardware (but can fall back to a
+            timer-based mode), which means that it doesn't take
+            advantage of tracepoints or other event sources for example.
+        </para>
+
+        <para>
+            It consists of a kernel module that collects samples and a
+            userspace daemon that writes the sample data to disk.
+        </para>
+
+        <para>
+            The 'opcontrol' shell script is used for transparently
+            managing these components and starting and stopping
+            profiles, and the 'opreport' command is used to
+            display the results.
+        </para>
+
+        <para>
+            The oprofile daemon should already be running, but before
+            you start profiling, you may need to change some settings
+            and some of these settings may require the daemon to not
+            be running. One of these settings is the path to the
+            vmlinux file, which you'll want to set using the --vmlinux
+            option if you want the kernel profiled:
+            <literallayout class='monospaced'>
+     root@crownbay:~# opcontrol --vmlinux=/boot/vmlinux-`uname -r`
+     The profiling daemon is currently active, so changes to the configuration
+     will be used the next time you restart oprofile after a --shutdown or --deinit.
+            </literallayout>
+            You can check if vmlinux file: is set using opcontrol --status:
+            <literallayout class='monospaced'>
+     root@crownbay:~# opcontrol --status
+     Daemon paused: pid 1334
+     Separate options: library
+     vmlinux file: none
+     Image filter: none
+     Call-graph depth: 6
+            </literallayout>
+            If it's not, you need to shutdown the daemon, add the setting
+            and restart the daemon:
+            <literallayout class='monospaced'>
+     root@crownbay:~# opcontrol --shutdown
+     Killing daemon.
+
+     root@crownbay:~# opcontrol --vmlinux=/boot/vmlinux-`uname -r`
+     root@crownbay:~# opcontrol --start-daemon
+     Using default event: CPU_CLK_UNHALTED:100000:0:1:1
+     Using 2.6+ OProfile kernel interface.
+     Reading module info.
+     Using log file /var/lib/oprofile/samples/oprofiled.log
+     Daemon started.
+            </literallayout>
+            If we check the status again we now see our updated settings:
+            <literallayout class='monospaced'>
+     root@crownbay:~# opcontrol --status
+     Daemon paused: pid 1649
+     Separate options: library
+     vmlinux file: /boot/vmlinux-3.4.11-yocto-standard
+     Image filter: none
+     Call-graph depth: 6
+            </literallayout>
+            We're now in a position to run a profile. For that we use
+            'opcontrol --start':
+            <literallayout class='monospaced'>
+     root@crownbay:~# opcontrol --start
+     Profiler running.
+            </literallayout>
+            In another window, run our wget workload:
+            <literallayout class='monospaced'>
+     root@crownbay:~# rm linux-2.6.19.2.tar.bz2; wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>; sync
+     Connecting to downloads.yoctoproject.org (140.211.169.59:80)
+     linux-2.6.19.2.tar.b 100% |*******************************| 41727k  0:00:00 ETA
+            </literallayout>
+            To stop the profile we use 'opcontrol --shutdown', which not
+            only stops the profile but shuts down the daemon as well:
+            <literallayout class='monospaced'>
+     root@crownbay:~# opcontrol --shutdown
+     Stopping profiling.
+     Killing daemon.
+            </literallayout>
+            Oprofile writes sample data to /var/lib/oprofile/samples,
+            which you can look at if you're interested in seeing how the
+            samples are structured. This is also interesting because
+            it's related to how you dive down to get further details
+            about specific executables in OProfile.
+        </para>
+
+        <para>
+            To see the default display output for a profile, simply type
+            'opreport', which will show the results using the data in
+            /var/lib/oprofile/samples:
+            <literallayout class='monospaced'>
+     root@crownbay:~# opreport
+
+     WARNING! The OProfile kernel driver reports sample buffer overflows.
+     Such overflows can result in incorrect sample attribution, invalid sample
+     files and other symptoms.  See the oprofiled.log for details.
+     You should adjust your sampling frequency to eliminate (or at least minimize)
+     these overflows.
+     CPU: Intel Architectural Perfmon, speed 1.3e+06 MHz (estimated)
+     Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000
+     CPU_CLK_UNHALT...|
+      samples|      %|
+     ------------------
+       464365 79.8156 vmlinux-3.4.11-yocto-standard
+        65108 11.1908 oprofiled
+             CPU_CLK_UNHALT...|
+               samples|      %|
+             ------------------
+                 64416 98.9372 oprofiled
+                   692  1.0628 libc-2.16.so
+        36959  6.3526 no-vmlinux
+         4378  0.7525 busybox
+             CPU_CLK_UNHALT...|
+               samples|      %|
+             ------------------
+                  2844 64.9612 libc-2.16.so
+                  1337 30.5391 busybox
+                   193  4.4084 ld-2.16.so
+                     2  0.0457 libnss_compat-2.16.so
+                     1  0.0228 libnsl-2.16.so
+                     1  0.0228 libnss_files-2.16.so
+         4344  0.7467 bash
+             CPU_CLK_UNHALT...|
+               samples|      %|
+             ------------------
+                  2657 61.1648 bash
+                  1665 38.3287 libc-2.16.so
+                    18  0.4144 ld-2.16.so
+                     3  0.0691 libtinfo.so.5.9
+                     1  0.0230 libdl-2.16.so
+         3118  0.5359 nf_conntrack
+          686  0.1179 matchbox-terminal
+             CPU_CLK_UNHALT...|
+               samples|      %|
+             ------------------
+                   214 31.1953 libglib-2.0.so.0.3200.4
+                   114 16.6181 libc-2.16.so
+                    79 11.5160 libcairo.so.2.11200.2
+                    78 11.3703 libgdk-x11-2.0.so.0.2400.8
+                    51  7.4344 libpthread-2.16.so
+                    45  6.5598 libgobject-2.0.so.0.3200.4
+                    29  4.2274 libvte.so.9.2800.2
+                    25  3.6443 libX11.so.6.3.0
+                    19  2.7697 libxcb.so.1.1.0
+                    17  2.4781 libgtk-x11-2.0.so.0.2400.8
+                    12  1.7493 librt-2.16.so
+                     3  0.4373 libXrender.so.1.3.0
+          671  0.1153 emgd
+          411  0.0706 nf_conntrack_ipv4
+          391  0.0672 iptable_nat
+          378  0.0650 nf_nat
+          263  0.0452 Xorg
+             CPU_CLK_UNHALT...|
+               samples|      %|
+             ------------------
+                   106 40.3042 Xorg
+                    53 20.1521 libc-2.16.so
+                    31 11.7871 libpixman-1.so.0.27.2
+                    26  9.8859 emgd_drv.so
+                    16  6.0837 libemgdsrv_um.so.1.5.15.3226
+                    11  4.1825 libEMGD2d.so.1.5.15.3226
+                     9  3.4221 libfb.so
+                     7  2.6616 libpthread-2.16.so
+                     1  0.3802 libudev.so.0.9.3
+                     1  0.3802 libdrm.so.2.4.0
+                     1  0.3802 libextmod.so
+                     1  0.3802 mouse_drv.so
+     .
+     .
+     .
+           9  0.0015 connmand
+             CPU_CLK_UNHALT...|
+               samples|      %|
+             ------------------
+                     4 44.4444 libglib-2.0.so.0.3200.4
+                     2 22.2222 libpthread-2.16.so
+                     1 11.1111 connmand
+                     1 11.1111 libc-2.16.so
+                     1 11.1111 librt-2.16.so
+            6  0.0010 oprofile-server
+         CPU_CLK_UNHALT...|
+               samples|      %|
+             ------------------
+                     3 50.0000 libc-2.16.so
+                     1 16.6667 oprofile-server
+                     1 16.6667 libpthread-2.16.so
+                     1 16.6667 libglib-2.0.so.0.3200.4
+           5 8.6e-04 gconfd-2
+             CPU_CLK_UNHALT...|
+               samples|      %|
+             ------------------
+                     2 40.0000 libdbus-1.so.3.7.2
+                     2 40.0000 libglib-2.0.so.0.3200.4
+                     1 20.0000 libc-2.16.so
+            </literallayout>
+            The output above shows the breakdown or samples by both
+            number of samples and percentage for each executable.
+            Within an executable, the sample counts are broken down
+            further into executable and shared libraries (DSOs) used
+            by the executable.
+        </para>
+
+        <para>
+            To get even more detailed breakdowns by function, we need to
+            have the full paths to the DSOs, which we can get by
+            using -f with opreport:
+            <literallayout class='monospaced'>
+     root@crownbay:~# opreport -f
+
+     CPU: Intel Architectural Perfmon, speed 1.3e+06 MHz (estimated)
+     Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000
+     CPU_CLK_UNHALT...|
+      samples|      %|
+
+       464365 79.8156 /boot/vmlinux-3.4.11-yocto-standard
+       65108 11.1908 /usr/bin/oprofiled
+             CPU_CLK_UNHALT...|
+               samples|      %|
+             ------------------
+                 64416 98.9372 /usr/bin/oprofiled
+                   692  1.0628 /lib/libc-2.16.so
+        36959  6.3526 /no-vmlinux
+         4378  0.7525 /bin/busybox
+             CPU_CLK_UNHALT...|
+               samples|      %|
+             ------------------
+                  2844 64.9612 /lib/libc-2.16.so
+                  1337 30.5391 /bin/busybox
+                   193  4.4084 /lib/ld-2.16.so
+                     2  0.0457 /lib/libnss_compat-2.16.so
+                     1  0.0228 /lib/libnsl-2.16.so
+                     1  0.0228 /lib/libnss_files-2.16.so
+         4344  0.7467 /bin/bash
+             CPU_CLK_UNHALT...|
+               samples|      %|
+             ------------------
+                  2657 61.1648 /bin/bash
+                  1665 38.3287 /lib/libc-2.16.so
+                    18  0.4144 /lib/ld-2.16.so
+                     3  0.0691 /lib/libtinfo.so.5.9
+                     1  0.0230 /lib/libdl-2.16.so
+     .
+     .
+     .
+            </literallayout>
+            Using the paths shown in the above output and the -l option to
+            opreport, we can see all the functions that have hits in the
+            profile and their sample counts and percentages. Here's a
+            portion of what we get for the kernel:
+            <literallayout class='monospaced'>
+     root@crownbay:~# opreport -l /boot/vmlinux-3.4.11-yocto-standard
+
+     CPU: Intel Architectural Perfmon, speed 1.3e+06 MHz (estimated)
+     Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000
+     samples  %        symbol name
+     233981   50.3873  intel_idle
+     15437     3.3243  rb_get_reader_page
+     14503     3.1232  ring_buffer_consume
+     14092     3.0347  mutex_spin_on_owner
+     13024     2.8047  read_hpet
+     8039      1.7312  sub_preempt_count
+     7096      1.5281  ioread32
+     6997      1.5068  add_preempt_count
+     3985      0.8582  rb_advance_reader
+     3488      0.7511  add_event_entry
+     3303      0.7113  get_parent_ip
+     3104      0.6684  rb_buffer_peek
+     2960      0.6374  op_cpu_buffer_read_entry
+     2614      0.5629  sync_buffer
+     2545      0.5481  debug_smp_processor_id
+     2456      0.5289  ohci_irq
+     2397      0.5162  memset
+     2349      0.5059  __copy_to_user_ll
+     2185      0.4705  ring_buffer_event_length
+     1918      0.4130  in_lock_functions
+     1850      0.3984  __schedule
+     1767      0.3805  __copy_from_user_ll_nozero
+     1575      0.3392  rb_event_data_length
+     1256      0.2705  memcpy
+     1233      0.2655  system_call
+     1213      0.2612  menu_select
+            </literallayout>
+            Notice that above we see an entry for the __copy_to_user_ll()
+            function that we've looked at with other profilers as well.
+        </para>
+
+        <para>
+            Here's what we get when we do the same thing for the
+            busybox executable:
+            <literallayout class='monospaced'>
+     CPU: Intel Architectural Perfmon, speed 1.3e+06 MHz (estimated)
+     Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000
+     samples  %        image name               symbol name
+     349       8.4198  busybox                  retrieve_file_data
+     308       7.4306  libc-2.16.so             _IO_file_xsgetn
+     283       6.8275  libc-2.16.so             __read_nocancel
+     235       5.6695  libc-2.16.so             syscall
+     233       5.6212  libc-2.16.so             clearerr
+     215       5.1870  libc-2.16.so             fread
+     181       4.3667  libc-2.16.so             __write_nocancel
+     158       3.8118  libc-2.16.so             __underflow
+     151       3.6429  libc-2.16.so             _dl_addr
+     150       3.6188  busybox                  progress_meter
+     150       3.6188  libc-2.16.so             __poll_nocancel
+     148       3.5706  libc-2.16.so             _IO_file_underflow@@GLIBC_2.1
+     137       3.3052  busybox                  safe_poll
+     125       3.0157  busybox                  bb_progress_update
+     122       2.9433  libc-2.16.so             __x86.get_pc_thunk.bx
+     95        2.2919  busybox                  full_write
+     81        1.9542  busybox                  safe_write
+     77        1.8577  busybox                  xwrite
+     72        1.7370  libc-2.16.so             _IO_file_read
+     71        1.7129  libc-2.16.so             _IO_sgetn
+     67        1.6164  libc-2.16.so             poll
+     52        1.2545  libc-2.16.so             _IO_switch_to_get_mode
+     45        1.0856  libc-2.16.so             read
+     34        0.8203  libc-2.16.so             write
+     32        0.7720  busybox                  monotonic_sec
+     25        0.6031  libc-2.16.so             vfprintf
+     22        0.5308  busybox                  get_mono
+     14        0.3378  ld-2.16.so               strcmp
+     14        0.3378  libc-2.16.so             __x86.get_pc_thunk.cx
+     .
+     .
+     .
+            </literallayout>
+            Since we recorded the profile with a callchain depth of 6, we
+            should be able to see our __copy_to_user_ll() callchains in
+            the output, and indeed we can if we search around a bit in
+            the 'opreport --callgraph' output:
+            <literallayout class='monospaced'>
+     root@crownbay:~# opreport --callgraph /boot/vmlinux-3.4.11-yocto-standard
+
+       392       6.9639  vmlinux-3.4.11-yocto-standard sock_aio_read
+       736      13.0751  vmlinux-3.4.11-yocto-standard __generic_file_aio_write
+       3255     57.8255  vmlinux-3.4.11-yocto-standard inet_recvmsg
+     785       0.1690  vmlinux-3.4.11-yocto-standard tcp_recvmsg
+       1790     31.7940  vmlinux-3.4.11-yocto-standard local_bh_enable
+       1238     21.9893  vmlinux-3.4.11-yocto-standard __kfree_skb
+       992      17.6199  vmlinux-3.4.11-yocto-standard lock_sock_nested
+       785      13.9432  vmlinux-3.4.11-yocto-standard tcp_recvmsg [self]
+       525       9.3250  vmlinux-3.4.11-yocto-standard release_sock
+       112       1.9893  vmlinux-3.4.11-yocto-standard tcp_cleanup_rbuf
+       72        1.2789  vmlinux-3.4.11-yocto-standard skb_copy_datagram_iovec
+
+     170       0.0366  vmlinux-3.4.11-yocto-standard skb_copy_datagram_iovec
+       1491     73.3038  vmlinux-3.4.11-yocto-standard memcpy_toiovec
+       327      16.0767  vmlinux-3.4.11-yocto-standard skb_copy_datagram_iovec
+       170       8.3579  vmlinux-3.4.11-yocto-standard skb_copy_datagram_iovec [self]
+       20        0.9833  vmlinux-3.4.11-yocto-standard copy_to_user
+
+       2588     98.2909  vmlinux-3.4.11-yocto-standard copy_to_user
+     2349      0.5059  vmlinux-3.4.11-yocto-standard __copy_to_user_ll
+       2349     89.2138  vmlinux-3.4.11-yocto-standard __copy_to_user_ll [self]
+       166       6.3046  vmlinux-3.4.11-yocto-standard do_page_fault
+            </literallayout>
+            Remember that by default OProfile sessions are cumulative
+            i.e. if you start and stop a profiling session, then start a
+            new one, the new one will not erase the previous run(s) but
+            will build on it. If you want to restart a profile from scratch,
+            you need to reset:
+            <literallayout class='monospaced'>
+     root@crownbay:~# opcontrol --reset
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='oprofileui-a-gui-for-oprofile'>
+        <title>OProfileUI - A GUI for OProfile</title>
+
+        <para>
+            Yocto also supports a graphical UI for controlling and viewing
+            OProfile traces, called OProfileUI. To use it, you first need
+            to clone the oprofileui git repo, then configure, build, and
+            install it:
+            <literallayout class='monospaced'>
+     [trz@empanada tmp]$ git clone git://git.yoctoproject.org/oprofileui
+     [trz@empanada tmp]$ cd oprofileui
+     [trz@empanada oprofileui]$ ./autogen.sh
+     [trz@empanada oprofileui]$ sudo make install
+            </literallayout>
+            OprofileUI replaces the 'opreport' functionality with a GUI,
+            and normally doesn't require the user to use 'opcontrol' either.
+            If you want to profile the kernel, however, you need to either
+            use the UI to specify a vmlinux or use 'opcontrol' to specify
+            it on the target:
+        </para>
+
+        <para>
+            First, on the target, check if vmlinux file: is set:
+            <literallayout class='monospaced'>
+     root@crownbay:~# opcontrol --status
+            </literallayout>
+            If not:
+            <literallayout class='monospaced'>
+     root@crownbay:~# opcontrol --shutdown
+     root@crownbay:~# opcontrol --vmlinux=/boot/vmlinux-`uname -r`
+     root@crownbay:~# opcontrol --start-daemon
+            </literallayout>
+            Now, start the oprofile UI on the host system:
+            <literallayout class='monospaced'>
+     [trz@empanada oprofileui]$ oprofile-viewer
+            </literallayout>
+            To run a profile on the remote system, first connect to the
+            remote system by pressing the 'Connect' button and supplying
+            the IP address and port of the remote system (the default
+            port is 4224).
+        </para>
+
+        <para>
+            The oprofile server should automatically be started already.
+            If not, the connection will fail and you either typed in the
+            wrong IP address and port (see below), or you need to start
+            the server yourself:
+            <literallayout class='monospaced'>
+     root@crownbay:~# oprofile-server
+            </literallayout>
+            Or, to specify a specific port:
+            <literallayout class='monospaced'>
+     root@crownbay:~# oprofile-server --port 8888
+            </literallayout>
+            Once connected, press the 'Start' button and then run the
+            wget workload on the remote system:
+            <literallayout class='monospaced'>
+     root@crownbay:~# rm linux-2.6.19.2.tar.bz2; wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>; sync
+     Connecting to downloads.yoctoproject.org (140.211.169.59:80)
+     linux-2.6.19.2.tar.b 100% |*******************************| 41727k  0:00:00 ETA
+            </literallayout>
+            Once the workload completes, press the 'Stop' button. At that
+            point the OProfile viewer will download the profile files it's
+            collected (this may take some time, especially if the kernel
+            was profiled). While it downloads the files, you should see
+            something like the following:
+        </para>
+
+        <para>
+            <imagedata fileref="figures/oprofileui-downloading.png" width="6in" depth="7in" align="center" scalefit="1" />
+        </para>
+
+        <para>
+            Once the profile files have been retrieved, you should see a
+            list of the processes that were profiled:
+        </para>
+
+        <para>
+            <imagedata fileref="figures/oprofileui-processes.png" width="6in" depth="7in" align="center" scalefit="1" />
+        </para>
+
+        <para>
+            If you select one of them, you should see all the symbols that
+            were hit during the profile. Selecting one of them will show a
+            list of callers and callees of the chosen function in two
+            panes below the top pane. For example, here's what we see
+            when we select __copy_to_user_ll():
+        </para>
+
+        <para>
+            <imagedata fileref="figures/oprofileui-copy-to-user.png" width="6in" depth="7in" align="center" scalefit="1" />
+        </para>
+
+        <para>
+            As another example, we can look at the busybox process and see
+            that the progress meter made a system call:
+        </para>
+
+        <para>
+            <imagedata fileref="figures/oprofileui-busybox.png" width="6in" depth="7in" align="center" scalefit="1" />
+        </para>
+    </section>
+
+    <section id='oprofile-documentation'>
+        <title>Documentation</title>
+
+        <para>
+            Yocto already has some information on setting up and using
+            OProfile and oprofileui. As this document doesn't cover
+            everything in detail, it may be worth taking a look at the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-oprofile'>Profiling with OProfile</ulink>"
+            section in the Yocto Project Development Manual
+        </para>
+
+        <para>
+            The OProfile manual can be found here:
+            <ulink url='http://oprofile.sourceforge.net/doc/index.html'>OProfile manual</ulink>
+        </para>
+
+        <para>
+            The OProfile website contains links to the above manual and
+            bunch of other items including an extensive set of examples:
+            <ulink url='http://oprofile.sourceforge.net/about/'>About OProfile</ulink>
+        </para>
+    </section>
+</section>
+
+<section id='profile-manual-sysprof'>
+    <title>Sysprof</title>
+
+    <para>
+        Sysprof is a very easy to use system-wide profiler that consists
+        of a single window with three panes and a few buttons which allow
+        you to start, stop, and view the profile from one place.
+    </para>
+
+    <section id='sysprof-setup'>
+        <title>Setup</title>
+
+        <para>
+            For this section, we'll assume you've already performed the
+            basic setup outlined in the General Setup section.
+        </para>
+
+        <para>
+            Sysprof is a GUI-based application that runs on the target
+            system. For the rest of this document we assume you've
+            ssh'ed to the host and will be running Sysprof on the
+            target (you can use the '-X' option to ssh and have the
+            Sysprof GUI run on the target but display remotely on the
+            host if you want).
+        </para>
+    </section>
+
+    <section id='sysprof-basic-usage'>
+        <title>Basic Usage</title>
+
+        <para>
+            To start profiling the system, you simply press the 'Start'
+            button. To stop profiling and to start viewing the profile data
+            in one easy step, press the 'Profile' button.
+        </para>
+
+        <para>
+            Once you've pressed the profile button, the three panes will
+            fill up with profiling data:
+        </para>
+
+        <para>
+            <imagedata fileref="figures/sysprof-copy-to-user.png" width="6in" depth="4in" align="center" scalefit="1" />
+        </para>
+
+        <para>
+            The left pane shows a list of functions and processes.
+            Selecting one of those expands that function in the right
+            pane, showing all its callees. Note that this caller-oriented
+            display is essentially the inverse of perf's default
+            callee-oriented callchain display.
+        </para>
+
+        <para>
+            In the screenshot above, we're focusing on __copy_to_user_ll()
+            and looking up the callchain we can see that one of the callers
+            of __copy_to_user_ll is sys_read() and the complete callpath
+            between them. Notice that this is essentially a portion of the
+            same information we saw in the perf display shown in the perf
+            section of this page.
+        </para>
+
+        <para>
+            <imagedata fileref="figures/sysprof-copy-from-user.png" width="6in" depth="4in" align="center" scalefit="1" />
+        </para>
+
+        <para>
+            Similarly, the above is a snapshot of the Sysprof display of a
+            copy-from-user callchain.
+        </para>
+
+        <para>
+            Finally, looking at the third Sysprof pane in the lower left,
+            we can see a list of all the callers of a particular function
+            selected in the top left pane. In this case, the lower pane is
+            showing all the callers of __mark_inode_dirty:
+        </para>
+
+        <para>
+            <imagedata fileref="figures/sysprof-callers.png" width="6in" depth="4in" align="center" scalefit="1" />
+        </para>
+
+        <para>
+            Double-clicking on one of those functions will in turn change the
+            focus to the selected function, and so on.
+        </para>
+
+        <informalexample>
+            <emphasis>Tying it Together:</emphasis> If you like sysprof's 'caller-oriented'
+            display, you may be able to approximate it in other tools as
+            well.  For example, 'perf report' has the -g (--call-graph)
+            option that you can experiment with; one of the options is
+            'caller' for an inverted caller-based callgraph display.
+        </informalexample>
+    </section>
+
+    <section id='sysprof-documentation'>
+        <title>Documentation</title>
+
+        <para>
+            There doesn't seem to be any documentation for Sysprof, but
+            maybe that's because it's pretty self-explanatory.
+            The Sysprof website, however, is here:
+            <ulink url='http://sysprof.com/'>Sysprof, System-wide Performance Profiler for Linux</ulink>
+        </para>
+    </section>
+</section>
+
+<section id='lttng-linux-trace-toolkit-next-generation'>
+    <title>LTTng (Linux Trace Toolkit, next generation)</title>
+
+    <section id='lttng-setup'>
+        <title>Setup</title>
+
+        <para>
+            For this section, we'll assume you've already performed the
+            basic setup outlined in the General Setup section.
+        </para>
+
+        <para>
+            LTTng is run on the target system by ssh'ing to it.
+            However, if you want to see the traces graphically,
+            install Eclipse as described in section
+            "<link linkend='manually-copying-a-trace-to-the-host-and-viewing-it-in-eclipse'>Manually copying a trace to the host and viewing it in Eclipse (i.e. using Eclipse without network support)</link>"
+            and follow the directions to manually copy traces to the host and
+            view them in Eclipse (i.e. using Eclipse without network support).
+        </para>
+
+        <note>
+            Be sure to download and install/run the 'SR1' or later Juno release
+            of eclipse e.g.:
+            <ulink url='http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/juno/SR1/eclipse-cpp-juno-SR1-linux-gtk-x86_64.tar.gz'>http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/juno/SR1/eclipse-cpp-juno-SR1-linux-gtk-x86_64.tar.gz</ulink>
+        </note>
+    </section>
+
+    <section id='collecting-and-viewing-traces'>
+        <title>Collecting and Viewing Traces</title>
+
+        <para>
+            Once you've applied the above commits and built and booted your
+            image (you need to build the core-image-sato-sdk image or use one of the
+            other methods described in the General Setup section), you're
+            ready to start tracing.
+        </para>
+
+        <section id='collecting-and-viewing-a-trace-on-the-target-inside-a-shell'>
+            <title>Collecting and viewing a trace on the target (inside a shell)</title>
+
+            <para>
+                First, from the host, ssh to the target:
+                <literallayout class='monospaced'>
+     $ ssh -l root 192.168.1.47
+     The authenticity of host '192.168.1.47 (192.168.1.47)' can't be established.
+     RSA key fingerprint is 23:bd:c8:b1:a8:71:52:00:ee:00:4f:64:9e:10:b9:7e.
+     Are you sure you want to continue connecting (yes/no)? yes
+     Warning: Permanently added '192.168.1.47' (RSA) to the list of known hosts.
+     root@192.168.1.47's password:
+                </literallayout>
+                Once on the target, use these steps to create a trace:
+                <literallayout class='monospaced'>
+     root@crownbay:~# lttng create
+     Spawning a session daemon
+     Session auto-20121015-232120 created.
+     Traces will be written in /home/root/lttng-traces/auto-20121015-232120
+                </literallayout>
+                Enable the events you want to trace (in this case all
+                kernel events):
+                <literallayout class='monospaced'>
+     root@crownbay:~# lttng enable-event --kernel --all
+     All kernel events are enabled in channel channel0
+                </literallayout>
+                Start the trace:
+                <literallayout class='monospaced'>
+     root@crownbay:~# lttng start
+     Tracing started for session auto-20121015-232120
+                </literallayout>
+                And then stop the trace after awhile or after running
+                a particular workload that you want to trace:
+                <literallayout class='monospaced'>
+     root@crownbay:~# lttng stop
+     Tracing stopped for session auto-20121015-232120
+                </literallayout>
+                You can now view the trace in text form on the target:
+                <literallayout class='monospaced'>
+     root@crownbay:~# lttng view
+     [23:21:56.989270399] (+?.?????????) sys_geteuid: { 1 }, { }
+     [23:21:56.989278081] (+0.000007682) exit_syscall: { 1 }, { ret = 0 }
+     [23:21:56.989286043] (+0.000007962) sys_pipe: { 1 }, { fildes = 0xB77B9E8C }
+     [23:21:56.989321802] (+0.000035759) exit_syscall: { 1 }, { ret = 0 }
+     [23:21:56.989329345] (+0.000007543) sys_mmap_pgoff: { 1 }, { addr = 0x0, len = 10485760, prot = 3, flags = 131362, fd = 4294967295, pgoff = 0 }
+     [23:21:56.989351694] (+0.000022349) exit_syscall: { 1 }, { ret = -1247805440 }
+     [23:21:56.989432989] (+0.000081295) sys_clone: { 1 }, { clone_flags = 0x411, newsp = 0xB5EFFFE4, parent_tid = 0xFFFFFFFF, child_tid = 0x0 }
+     [23:21:56.989477129] (+0.000044140) sched_stat_runtime: { 1 }, { comm = "lttng-consumerd", tid = 1193, runtime = 681660, vruntime = 43367983388 }
+     [23:21:56.989486697] (+0.000009568) sched_migrate_task: { 1 }, { comm = "lttng-consumerd", tid = 1193, prio = 20, orig_cpu = 1, dest_cpu = 1 }
+     [23:21:56.989508418] (+0.000021721) hrtimer_init: { 1 }, { hrtimer = 3970832076, clockid = 1, mode = 1 }
+     [23:21:56.989770462] (+0.000262044) hrtimer_cancel: { 1 }, { hrtimer = 3993865440 }
+     [23:21:56.989771580] (+0.000001118) hrtimer_cancel: { 0 }, { hrtimer = 3993812192 }
+     [23:21:56.989776957] (+0.000005377) hrtimer_expire_entry: { 1 }, { hrtimer = 3993865440, now = 79815980007057, function = 3238465232 }
+     [23:21:56.989778145] (+0.000001188) hrtimer_expire_entry: { 0 }, { hrtimer = 3993812192, now = 79815980008174, function = 3238465232 }
+     [23:21:56.989791695] (+0.000013550) softirq_raise: { 1 }, { vec = 1 }
+     [23:21:56.989795396] (+0.000003701) softirq_raise: { 0 }, { vec = 1 }
+     [23:21:56.989800635] (+0.000005239) softirq_raise: { 0 }, { vec = 9 }
+     [23:21:56.989807130] (+0.000006495) sched_stat_runtime: { 1 }, { comm = "lttng-consumerd", tid = 1193, runtime = 330710, vruntime = 43368314098 }
+     [23:21:56.989809993] (+0.000002863) sched_stat_runtime: { 0 }, { comm = "lttng-sessiond", tid = 1181, runtime = 1015313, vruntime = 36976733240 }
+     [23:21:56.989818514] (+0.000008521) hrtimer_expire_exit: { 0 }, { hrtimer = 3993812192 }
+     [23:21:56.989819631] (+0.000001117) hrtimer_expire_exit: { 1 }, { hrtimer = 3993865440 }
+     [23:21:56.989821866] (+0.000002235) hrtimer_start: { 0 }, { hrtimer = 3993812192, function = 3238465232, expires = 79815981000000, softexpires = 79815981000000 }
+     [23:21:56.989822984] (+0.000001118) hrtimer_start: { 1 }, { hrtimer = 3993865440, function = 3238465232, expires = 79815981000000, softexpires = 79815981000000 }
+     [23:21:56.989832762] (+0.000009778) softirq_entry: { 1 }, { vec = 1 }
+     [23:21:56.989833879] (+0.000001117) softirq_entry: { 0 }, { vec = 1 }
+     [23:21:56.989838069] (+0.000004190) timer_cancel: { 1 }, { timer = 3993871956 }
+     [23:21:56.989839187] (+0.000001118) timer_cancel: { 0 }, { timer = 3993818708 }
+     [23:21:56.989841492] (+0.000002305) timer_expire_entry: { 1 }, { timer = 3993871956, now = 79515980, function = 3238277552 }
+     [23:21:56.989842819] (+0.000001327) timer_expire_entry: { 0 }, { timer = 3993818708, now = 79515980, function = 3238277552 }
+     [23:21:56.989854831] (+0.000012012) sched_stat_runtime: { 1 }, { comm = "lttng-consumerd", tid = 1193, runtime = 49237, vruntime = 43368363335 }
+     [23:21:56.989855949] (+0.000001118) sched_stat_runtime: { 0 }, { comm = "lttng-sessiond", tid = 1181, runtime = 45121, vruntime = 36976778361 }
+     [23:21:56.989861257] (+0.000005308) sched_stat_sleep: { 1 }, { comm = "kworker/1:1", tid = 21, delay = 9451318 }
+     [23:21:56.989862374] (+0.000001117) sched_stat_sleep: { 0 }, { comm = "kworker/0:0", tid = 4, delay = 9958820 }
+     [23:21:56.989868241] (+0.000005867) sched_wakeup: { 0 }, { comm = "kworker/0:0", tid = 4, prio = 120, success = 1, target_cpu = 0 }
+     [23:21:56.989869358] (+0.000001117) sched_wakeup: { 1 }, { comm = "kworker/1:1", tid = 21, prio = 120, success = 1, target_cpu = 1 }
+     [23:21:56.989877460] (+0.000008102) timer_expire_exit: { 1 }, { timer = 3993871956 }
+     [23:21:56.989878577] (+0.000001117) timer_expire_exit: { 0 }, { timer = 3993818708 }
+     .
+     .
+     .
+                </literallayout>
+                You can now safely destroy the trace session (note that
+                this doesn't delete the trace - it's still there
+                in ~/lttng-traces):
+                <literallayout class='monospaced'>
+     root@crownbay:~# lttng destroy
+     Session auto-20121015-232120 destroyed at /home/root
+                </literallayout>
+                Note that the trace is saved in a directory of the same
+                name as returned by 'lttng create', under the ~/lttng-traces
+                directory (note that you can change this by supplying your
+                own name to 'lttng create'):
+                <literallayout class='monospaced'>
+     root@crownbay:~# ls -al ~/lttng-traces
+     drwxrwx---    3 root     root          1024 Oct 15 23:21 .
+     drwxr-xr-x    5 root     root          1024 Oct 15 23:57 ..
+     drwxrwx---    3 root     root          1024 Oct 15 23:21 auto-20121015-232120
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='collecting-and-viewing-a-userspace-trace-on-the-target-inside-a-shell'>
+            <title>Collecting and viewing a userspace trace on the target (inside a shell)</title>
+
+            <para>
+                For LTTng userspace tracing, you need to have a properly
+                instrumented userspace program. For this example, we'll use
+                the 'hello' test program generated by the lttng-ust build.
+            </para>
+
+            <para>
+                The 'hello' test program isn't installed on the rootfs by
+                the lttng-ust build, so we need to copy it over manually.
+                First cd into the build directory that contains the hello
+                executable:
+                <literallayout class='monospaced'>
+     $ cd build/tmp/work/core2_32-poky-linux/lttng-ust/2.0.5-r0/git/tests/hello/.libs
+                </literallayout>
+                Copy that over to the target machine:
+                <literallayout class='monospaced'>
+     $ scp hello root@192.168.1.20:
+                </literallayout>
+                You now have the instrumented lttng 'hello world' test
+                program on the target, ready to test.
+            </para>
+
+            <para>
+                First, from the host, ssh to the target:
+                <literallayout class='monospaced'>
+     $ ssh -l root 192.168.1.47
+     The authenticity of host '192.168.1.47 (192.168.1.47)' can't be established.
+     RSA key fingerprint is 23:bd:c8:b1:a8:71:52:00:ee:00:4f:64:9e:10:b9:7e.
+     Are you sure you want to continue connecting (yes/no)? yes
+     Warning: Permanently added '192.168.1.47' (RSA) to the list of known hosts.
+     root@192.168.1.47's password:
+                </literallayout>
+                Once on the target, use these steps to create a trace:
+                <literallayout class='monospaced'>
+     root@crownbay:~# lttng create
+     Session auto-20190303-021943 created.
+     Traces will be written in /home/root/lttng-traces/auto-20190303-021943
+                </literallayout>
+                Enable the events you want to trace (in this case all
+                userspace events):
+                <literallayout class='monospaced'>
+     root@crownbay:~# lttng enable-event --userspace --all
+     All UST events are enabled in channel channel0
+                </literallayout>
+                Start the trace:
+                <literallayout class='monospaced'>
+     root@crownbay:~# lttng start
+     Tracing started for session auto-20190303-021943
+                </literallayout>
+                Run the instrumented hello world program:
+                <literallayout class='monospaced'>
+     root@crownbay:~# ./hello
+     Hello, World!
+     Tracing...  done.
+                </literallayout>
+                And then stop the trace after awhile or after running a
+                particular workload that you want to trace:
+                <literallayout class='monospaced'>
+     root@crownbay:~# lttng stop
+     Tracing stopped for session auto-20190303-021943
+                </literallayout>
+                You can now view the trace in text form on the target:
+                <literallayout class='monospaced'>
+     root@crownbay:~# lttng view
+     [02:31:14.906146544] (+?.?????????) hello:1424 ust_tests_hello:tptest: { cpu_id = 1 }, { intfield = 0, intfield2 = 0x0, longfield = 0, netintfield = 0, netintfieldhex = 0x0, arrfield1 = [ [0] = 1, [1] = 2, [2] = 3 ], arrfield2 = "test", _seqfield1_length = 4, seqfield1 = [ [0] = 116, [1] = 101, [2] = 115, [3] = 116 ], _seqfield2_length = 4,  seqfield2 = "test", stringfield = "test", floatfield = 2222, doublefield = 2, boolfield = 1 }
+     [02:31:14.906170360] (+0.000023816) hello:1424 ust_tests_hello:tptest: { cpu_id = 1 }, { intfield = 1, intfield2 = 0x1, longfield = 1, netintfield = 1, netintfieldhex = 0x1, arrfield1 = [ [0] = 1, [1] = 2, [2] = 3 ], arrfield2 = "test", _seqfield1_length = 4, seqfield1 = [ [0] = 116, [1] = 101, [2] = 115, [3] = 116 ], _seqfield2_length = 4, seqfield2 = "test", stringfield = "test", floatfield = 2222, doublefield = 2, boolfield = 1 }
+     [02:31:14.906183140] (+0.000012780) hello:1424 ust_tests_hello:tptest: { cpu_id = 1 }, { intfield = 2, intfield2 = 0x2, longfield = 2, netintfield = 2, netintfieldhex = 0x2, arrfield1 = [ [0] = 1, [1] = 2, [2] = 3 ], arrfield2 = "test", _seqfield1_length = 4, seqfield1 = [ [0] = 116, [1] = 101, [2] = 115, [3] = 116 ], _seqfield2_length = 4, seqfield2 = "test", stringfield = "test", floatfield = 2222, doublefield = 2, boolfield = 1 }
+     [02:31:14.906194385] (+0.000011245) hello:1424 ust_tests_hello:tptest: { cpu_id = 1 }, { intfield = 3, intfield2 = 0x3, longfield = 3, netintfield = 3, netintfieldhex = 0x3, arrfield1 = [ [0] = 1, [1] = 2, [2] = 3 ], arrfield2 = "test", _seqfield1_length = 4, seqfield1 = [ [0] = 116, [1] = 101, [2] = 115, [3] = 116 ], _seqfield2_length = 4, seqfield2 = "test", stringfield = "test", floatfield = 2222, doublefield = 2, boolfield = 1 }
+     .
+     .
+     .
+                </literallayout>
+                You can now safely destroy the trace session (note that
+                this doesn't delete the trace - it's still
+                there in ~/lttng-traces):
+                <literallayout class='monospaced'>
+     root@crownbay:~# lttng destroy
+     Session auto-20190303-021943 destroyed at /home/root
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='manually-copying-a-trace-to-the-host-and-viewing-it-in-eclipse'>
+            <title>Manually copying a trace to the host and viewing it in Eclipse (i.e. using Eclipse without network support)</title>
+
+            <para>
+                If you already have an LTTng trace on a remote target and
+                would like to view it in Eclipse on the host, you can easily
+                copy it from the target to the host and import it into
+                Eclipse to view it using the LTTng Eclipse plug-in already
+                bundled in the Eclipse (Juno SR1 or greater).
+            </para>
+
+            <para>
+                Using the trace we created in the previous section, archive
+                it and copy it to your host system:
+                <literallayout class='monospaced'>
+     root@crownbay:~/lttng-traces# tar zcvf auto-20121015-232120.tar.gz auto-20121015-232120
+     auto-20121015-232120/
+     auto-20121015-232120/kernel/
+     auto-20121015-232120/kernel/metadata
+     auto-20121015-232120/kernel/channel0_1
+     auto-20121015-232120/kernel/channel0_0
+
+     $ scp root@192.168.1.47:lttng-traces/auto-20121015-232120.tar.gz .
+     root@192.168.1.47's password:
+     auto-20121015-232120.tar.gz                                             100% 1566KB   1.5MB/s   00:01
+                </literallayout>
+                Unarchive it on the host:
+                <literallayout class='monospaced'>
+     $ gunzip -c auto-20121015-232120.tar.gz | tar xvf -
+     auto-20121015-232120/
+     auto-20121015-232120/kernel/
+     auto-20121015-232120/kernel/metadata
+     auto-20121015-232120/kernel/channel0_1
+     auto-20121015-232120/kernel/channel0_0
+                </literallayout>
+                We can now import the trace into Eclipse and view it:
+                <orderedlist>
+                    <listitem><para>First, start eclipse and open the
+                        'LTTng Kernel' perspective by selecting the following
+                        menu item:
+                        <literallayout class='monospaced'>
+     Window | Open Perspective | Other...
+                        </literallayout></para></listitem>
+                    <listitem><para>In the dialog box that opens, select
+                        'LTTng Kernel' from the list.</para></listitem>
+                    <listitem><para>Back at the main menu, select the
+                        following menu item:
+                        <literallayout class='monospaced'>
+     File | New | Project...
+                        </literallayout></para></listitem>
+                    <listitem><para>In the dialog box that opens, select
+                        the 'Tracing | Tracing Project' wizard and press
+                        'Next>'.</para></listitem>
+                    <listitem><para>Give the project a name and press
+                        'Finish'.</para></listitem>
+                    <listitem><para>In the 'Project Explorer' pane under
+                        the project you created, right click on the
+                        'Traces' item.</para></listitem>
+                    <listitem><para>Select 'Import..." and in the dialog
+                        that's displayed:</para></listitem>
+                    <listitem><para>Browse the filesystem and find the
+                        select the 'kernel' directory containing the trace
+                        you copied from the target
+                        e.g. auto-20121015-232120/kernel</para></listitem>
+                    <listitem><para>'Checkmark' the directory in the tree
+                        that's displayed for the trace</para></listitem>
+                    <listitem><para>Below that, select 'Common Trace Format:
+                        Kernel Trace' for the 'Trace Type'</para></listitem>
+                    <listitem><para>Press 'Finish' to close the dialog
+                        </para></listitem>
+                    <listitem><para>Back in the 'Project Explorer' pane,
+                        double-click on the 'kernel' item for the
+                        trace you just imported under 'Traces'
+                        </para></listitem>
+                </orderedlist>
+                You should now see your trace data displayed graphically
+                in several different views in Eclipse:
+            </para>
+
+            <para>
+                <imagedata fileref="figures/lttngmain0.png" width="6in" depth="6in" align="center" scalefit="1" />
+            </para>
+
+            <para>
+                You can access extensive help information on how to use
+                the LTTng plug-in to search and analyze captured traces via
+                the Eclipse help system:
+                <literallayout class='monospaced'>
+     Help | Help Contents | LTTng Plug-in User Guide
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='collecting-and-viewing-a-trace-in-eclipse'>
+            <title>Collecting and viewing a trace in Eclipse</title>
+
+            <note>
+                This section on collecting traces remotely doesn't currently
+                work because of Eclipse 'RSE' connectivity problems. Manually
+                tracing on the target, copying the trace files to the host,
+                and viewing the trace in Eclipse on the host as outlined in
+                previous steps does work however - please use the manual
+                steps outlined above to view traces in Eclipse.
+            </note>
+
+            <para>
+                In order to trace a remote target, you also need to add
+                a 'tracing' group on the target and connect as a user
+                who's part of that group e.g:
+                <literallayout class='monospaced'>
+     # adduser tomz
+     # groupadd -r tracing
+     # usermod -a -G tracing tomz
+                </literallayout>
+                <orderedlist>
+                    <listitem><para>First, start eclipse and open the
+                        'LTTng Kernel' perspective by selecting the following
+                         menu item:
+                         <literallayout class='monospaced'>
+     Window | Open Perspective | Other...
+                         </literallayout></para></listitem>
+                    <listitem><para>In the dialog box that opens, select
+                        'LTTng Kernel' from the list.</para></listitem>
+                    <listitem><para>Back at the main menu, select the
+                        following menu item:
+                        <literallayout class='monospaced'>
+     File | New | Project...
+                        </literallayout></para></listitem>
+                    <listitem><para>In the dialog box that opens, select
+                        the 'Tracing | Tracing Project' wizard and
+                        press 'Next>'.</para></listitem>
+                    <listitem><para>Give the project a name and press
+                        'Finish'. That should result in an entry in the
+                        'Project' subwindow.</para></listitem>
+                    <listitem><para>In the 'Control' subwindow just below
+                        it, press 'New Connection'.</para></listitem>
+                    <listitem><para>Add a new connection, giving it the
+                        hostname or IP address of the target system.
+                        </para></listitem>
+                    <listitem><para>Provide the username and password
+                        of a qualified user (a member of the 'tracing' group)
+                        or root account on the target system.
+                        </para></listitem>
+                    <listitem><para>Provide appropriate answers to whatever
+                        else is asked for e.g. 'secure storage password'
+                        can be anything you want.
+                        If you get an 'RSE Error' it may be due to proxies.
+                        It may be possible to get around the problem by
+                        changing the following setting:
+                        <literallayout class='monospaced'>
+     Window | Preferences | Network Connections
+                        </literallayout>
+                        Switch 'Active Provider' to 'Direct'
+                        </para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+    </section>
+
+    <section id='lltng-documentation'>
+        <title>Documentation</title>
+
+        <para>
+            You can find the primary LTTng Documentation on the
+            <ulink url='https://lttng.org/docs/'>LTTng Documentation</ulink>
+            site.
+            The documentation on this site is appropriate for intermediate to
+            advanced software developers who are working in a Linux environment
+            and are interested in efficient software tracing.
+        </para>
+
+        <para>
+            For information on LTTng in general, visit the
+            <ulink url='http://lttng.org/lttng2.0'>LTTng Project</ulink>
+            site.
+            You can find a "Getting Started" link on this site that takes
+            you to an LTTng Quick Start.
+        </para>
+
+        <para>
+            Finally, you can access extensive help information on how to use
+            the LTTng plug-in to search and analyze captured traces via the
+            Eclipse help system:
+            <literallayout class='monospaced'>
+     Help | Help Contents | LTTng Plug-in User Guide
+            </literallayout>
+        </para>
+    </section>
+</section>
+
+<section id='profile-manual-blktrace'>
+    <title>blktrace</title>
+
+    <para>
+        blktrace is a tool for tracing and reporting low-level disk I/O.
+        blktrace provides the tracing half of the equation; its output can
+        be piped into the blkparse program, which renders the data in a
+        human-readable form and does some basic analysis:
+    </para>
+
+    <section id='blktrace-setup'>
+        <title>Setup</title>
+
+        <para>
+            For this section, we'll assume you've already performed the
+            basic setup outlined in the
+            "<link linkend='profile-manual-general-setup'>General Setup</link>"
+            section.
+        </para>
+
+        <para>
+            blktrace is an application that runs on the target system.
+            You can run the entire blktrace and blkparse pipeline on the
+            target, or you can run blktrace in 'listen' mode on the target
+            and have blktrace and blkparse collect and analyze the data on
+            the host (see the
+            "<link linkend='using-blktrace-remotely'>Using blktrace Remotely</link>"
+            section below).
+            For the rest of this section we assume you've ssh'ed to the
+            host and will be running blkrace on the target.
+        </para>
+    </section>
+
+    <section id='blktrace-basic-usage'>
+        <title>Basic Usage</title>
+
+        <para>
+            To record a trace, simply run the 'blktrace' command, giving it
+            the name of the block device you want to trace activity on:
+            <literallayout class='monospaced'>
+     root@crownbay:~# blktrace /dev/sdc
+            </literallayout>
+            In another shell, execute a workload you want to trace.
+            <literallayout class='monospaced'>
+     root@crownbay:/media/sdc# rm linux-2.6.19.2.tar.bz2; wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>; sync
+     Connecting to downloads.yoctoproject.org (140.211.169.59:80)
+     linux-2.6.19.2.tar.b 100% |*******************************| 41727k  0:00:00 ETA
+            </literallayout>
+            Press Ctrl-C in the blktrace shell to stop the trace. It will
+            display how many events were logged, along with the per-cpu file
+            sizes (blktrace records traces in per-cpu kernel buffers and
+            simply dumps them to userspace for blkparse to merge and sort
+            later).
+            <literallayout class='monospaced'>
+     ^C=== sdc ===
+      CPU  0:                 7082 events,      332 KiB data
+      CPU  1:                 1578 events,       74 KiB data
+      Total:                  8660 events (dropped 0),      406 KiB data
+            </literallayout>
+            If you examine the files saved to disk, you see multiple files,
+            one per CPU and with the device name as the first part of the
+            filename:
+            <literallayout class='monospaced'>
+     root@crownbay:~# ls -al
+     drwxr-xr-x    6 root     root          1024 Oct 27 22:39 .
+     drwxr-sr-x    4 root     root          1024 Oct 26 18:24 ..
+     -rw-r--r--    1 root     root        339938 Oct 27 22:40 sdc.blktrace.0
+     -rw-r--r--    1 root     root         75753 Oct 27 22:40 sdc.blktrace.1
+            </literallayout>
+            To view the trace events, simply invoke 'blkparse' in the
+            directory containing the trace files, giving it the device name
+            that forms the first part of the filenames:
+            <literallayout class='monospaced'>
+     root@crownbay:~# blkparse sdc
+
+      8,32   1        1     0.000000000  1225  Q  WS 3417048 + 8 [jbd2/sdc-8]
+      8,32   1        2     0.000025213  1225  G  WS 3417048 + 8 [jbd2/sdc-8]
+      8,32   1        3     0.000033384  1225  P   N [jbd2/sdc-8]
+      8,32   1        4     0.000043301  1225  I  WS 3417048 + 8 [jbd2/sdc-8]
+      8,32   1        0     0.000057270     0  m   N cfq1225 insert_request
+      8,32   1        0     0.000064813     0  m   N cfq1225 add_to_rr
+      8,32   1        5     0.000076336  1225  U   N [jbd2/sdc-8] 1
+      8,32   1        0     0.000088559     0  m   N cfq workload slice:150
+      8,32   1        0     0.000097359     0  m   N cfq1225 set_active wl_prio:0 wl_type:1
+      8,32   1        0     0.000104063     0  m   N cfq1225 Not idling. st->count:1
+      8,32   1        0     0.000112584     0  m   N cfq1225 fifo=  (null)
+      8,32   1        0     0.000118730     0  m   N cfq1225 dispatch_insert
+      8,32   1        0     0.000127390     0  m   N cfq1225 dispatched a request
+      8,32   1        0     0.000133536     0  m   N cfq1225 activate rq, drv=1
+      8,32   1        6     0.000136889  1225  D  WS 3417048 + 8 [jbd2/sdc-8]
+      8,32   1        7     0.000360381  1225  Q  WS 3417056 + 8 [jbd2/sdc-8]
+      8,32   1        8     0.000377422  1225  G  WS 3417056 + 8 [jbd2/sdc-8]
+      8,32   1        9     0.000388876  1225  P   N [jbd2/sdc-8]
+      8,32   1       10     0.000397886  1225  Q  WS 3417064 + 8 [jbd2/sdc-8]
+      8,32   1       11     0.000404800  1225  M  WS 3417064 + 8 [jbd2/sdc-8]
+      8,32   1       12     0.000412343  1225  Q  WS 3417072 + 8 [jbd2/sdc-8]
+      8,32   1       13     0.000416533  1225  M  WS 3417072 + 8 [jbd2/sdc-8]
+      8,32   1       14     0.000422121  1225  Q  WS 3417080 + 8 [jbd2/sdc-8]
+      8,32   1       15     0.000425194  1225  M  WS 3417080 + 8 [jbd2/sdc-8]
+      8,32   1       16     0.000431968  1225  Q  WS 3417088 + 8 [jbd2/sdc-8]
+      8,32   1       17     0.000435251  1225  M  WS 3417088 + 8 [jbd2/sdc-8]
+      8,32   1       18     0.000440279  1225  Q  WS 3417096 + 8 [jbd2/sdc-8]
+      8,32   1       19     0.000443911  1225  M  WS 3417096 + 8 [jbd2/sdc-8]
+      8,32   1       20     0.000450336  1225  Q  WS 3417104 + 8 [jbd2/sdc-8]
+      8,32   1       21     0.000454038  1225  M  WS 3417104 + 8 [jbd2/sdc-8]
+      8,32   1       22     0.000462070  1225  Q  WS 3417112 + 8 [jbd2/sdc-8]
+      8,32   1       23     0.000465422  1225  M  WS 3417112 + 8 [jbd2/sdc-8]
+      8,32   1       24     0.000474222  1225  I  WS 3417056 + 64 [jbd2/sdc-8]
+      8,32   1        0     0.000483022     0  m   N cfq1225 insert_request
+      8,32   1       25     0.000489727  1225  U   N [jbd2/sdc-8] 1
+      8,32   1        0     0.000498457     0  m   N cfq1225 Not idling. st->count:1
+      8,32   1        0     0.000503765     0  m   N cfq1225 dispatch_insert
+      8,32   1        0     0.000512914     0  m   N cfq1225 dispatched a request
+      8,32   1        0     0.000518851     0  m   N cfq1225 activate rq, drv=2
+      .
+      .
+      .
+      8,32   0        0    58.515006138     0  m   N cfq3551 complete rqnoidle 1
+      8,32   0     2024    58.516603269     3  C  WS 3156992 + 16 [0]
+      8,32   0        0    58.516626736     0  m   N cfq3551 complete rqnoidle 1
+      8,32   0        0    58.516634558     0  m   N cfq3551 arm_idle: 8 group_idle: 0
+      8,32   0        0    58.516636933     0  m   N cfq schedule dispatch
+      8,32   1        0    58.516971613     0  m   N cfq3551 slice expired t=0
+      8,32   1        0    58.516982089     0  m   N cfq3551 sl_used=13 disp=6 charge=13 iops=0 sect=80
+      8,32   1        0    58.516985511     0  m   N cfq3551 del_from_rr
+      8,32   1        0    58.516990819     0  m   N cfq3551 put_queue
+
+     CPU0 (sdc):
+      Reads Queued:           0,        0KiB     Writes Queued:         331,   26,284KiB
+      Read Dispatches:        0,        0KiB     Write Dispatches:      485,   40,484KiB
+      Reads Requeued:         0          Writes Requeued:         0
+      Reads Completed:        0,        0KiB     Writes Completed:      511,   41,000KiB
+      Read Merges:            0,        0KiB     Write Merges:           13,      160KiB
+      Read depth:             0          Write depth:             2
+      IO unplugs:            23          Timer unplugs:           0
+     CPU1 (sdc):
+      Reads Queued:           0,        0KiB     Writes Queued:         249,   15,800KiB
+      Read Dispatches:        0,        0KiB     Write Dispatches:       42,    1,600KiB
+      Reads Requeued:         0          Writes Requeued:         0
+      Reads Completed:        0,        0KiB     Writes Completed:       16,    1,084KiB
+      Read Merges:            0,        0KiB     Write Merges:           40,      276KiB
+      Read depth:             0          Write depth:             2
+      IO unplugs:            30          Timer unplugs:           1
+
+     Total (sdc):
+      Reads Queued:           0,        0KiB     Writes Queued:         580,   42,084KiB
+      Read Dispatches:        0,        0KiB     Write Dispatches:      527,   42,084KiB
+      Reads Requeued:         0          Writes Requeued:         0
+      Reads Completed:        0,        0KiB     Writes Completed:      527,   42,084KiB
+      Read Merges:            0,        0KiB     Write Merges:           53,      436KiB
+      IO unplugs:            53          Timer unplugs:           1
+
+     Throughput (R/W): 0KiB/s / 719KiB/s
+     Events (sdc): 6,592 entries
+     Skips: 0 forward (0 -   0.0%)
+     Input file sdc.blktrace.0 added
+     Input file sdc.blktrace.1 added
+            </literallayout>
+            The report shows each event that was found in the blktrace data,
+            along with a summary of the overall block I/O traffic during
+            the run. You can look at the
+            <ulink url='http://linux.die.net/man/1/blkparse'>blkparse</ulink>
+            manpage to learn the
+            meaning of each field displayed in the trace listing.
+        </para>
+
+        <section id='blktrace-live-mode'>
+            <title>Live Mode</title>
+
+            <para>
+                blktrace and blkparse are designed from the ground up to
+                be able to operate together in a 'pipe mode' where the
+                stdout of blktrace can be fed directly into the stdin of
+                blkparse:
+                <literallayout class='monospaced'>
+     root@crownbay:~# blktrace /dev/sdc -o - | blkparse -i -
+                </literallayout>
+                This enables long-lived tracing sessions to run without
+                writing anything to disk, and allows the user to look for
+                certain conditions in the trace data in 'real-time' by
+                viewing the trace output as it scrolls by on the screen or
+                by passing it along to yet another program in the pipeline
+                such as grep which can be used to identify and capture
+                conditions of interest.
+            </para>
+
+            <para>
+                There's actually another blktrace command that implements
+                the above pipeline as a single command, so the user doesn't
+                have to bother typing in the above command sequence:
+                <literallayout class='monospaced'>
+     root@crownbay:~# btrace /dev/sdc
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='using-blktrace-remotely'>
+            <title>Using blktrace Remotely</title>
+
+            <para>
+                Because blktrace traces block I/O and at the same time
+                normally writes its trace data to a block device, and
+                in general because it's not really a great idea to make
+                the device being traced the same as the device the tracer
+                writes to, blktrace provides a way to trace without
+                perturbing the traced device at all by providing native
+                support for sending all trace data over the network.
+            </para>
+
+            <para>
+                To have blktrace operate in this mode, start blktrace on
+                the target system being traced with the -l option, along with
+                the device to trace:
+                <literallayout class='monospaced'>
+     root@crownbay:~# blktrace -l /dev/sdc
+     server: waiting for connections...
+                </literallayout>
+                On the host system, use the -h option to connect to the
+                target system, also passing it the device to trace:
+                <literallayout class='monospaced'>
+     $ blktrace -d /dev/sdc -h 192.168.1.43
+     blktrace: connecting to 192.168.1.43
+     blktrace: connected!
+                </literallayout>
+                On the target system, you should see this:
+                <literallayout class='monospaced'>
+     server: connection from 192.168.1.43
+                </literallayout>
+                In another shell, execute a workload you want to trace.
+                <literallayout class='monospaced'>
+     root@crownbay:/media/sdc# rm linux-2.6.19.2.tar.bz2; wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>; sync
+     Connecting to downloads.yoctoproject.org (140.211.169.59:80)
+     linux-2.6.19.2.tar.b 100% |*******************************| 41727k  0:00:00 ETA
+                </literallayout>
+                When it's done, do a Ctrl-C on the host system to
+                stop the trace:
+                <literallayout class='monospaced'>
+     ^C=== sdc ===
+      CPU  0:                 7691 events,      361 KiB data
+      CPU  1:                 4109 events,      193 KiB data
+      Total:                 11800 events (dropped 0),      554 KiB data
+                </literallayout>
+                On the target system, you should also see a trace
+                summary for the trace just ended:
+                <literallayout class='monospaced'>
+     server: end of run for 192.168.1.43:sdc
+     === sdc ===
+      CPU  0:                 7691 events,      361 KiB data
+      CPU  1:                 4109 events,      193 KiB data
+      Total:                 11800 events (dropped 0),      554 KiB data
+                </literallayout>
+                The blktrace instance on the host will save the target
+                output inside a hostname-timestamp directory:
+                <literallayout class='monospaced'>
+     $ ls -al
+     drwxr-xr-x   10 root     root          1024 Oct 28 02:40 .
+     drwxr-sr-x    4 root     root          1024 Oct 26 18:24 ..
+     drwxr-xr-x    2 root     root          1024 Oct 28 02:40 192.168.1.43-2012-10-28-02:40:56
+                </literallayout>
+                cd into that directory to see the output files:
+                <literallayout class='monospaced'>
+     $ ls -l
+     -rw-r--r--    1 root     root        369193 Oct 28 02:44 sdc.blktrace.0
+     -rw-r--r--    1 root     root        197278 Oct 28 02:44 sdc.blktrace.1
+                </literallayout>
+                And run blkparse on the host system using the device name:
+                <literallayout class='monospaced'>
+     $ blkparse sdc
+
+      8,32   1        1     0.000000000  1263  Q  RM 6016 + 8 [ls]
+      8,32   1        0     0.000036038     0  m   N cfq1263 alloced
+      8,32   1        2     0.000039390  1263  G  RM 6016 + 8 [ls]
+      8,32   1        3     0.000049168  1263  I  RM 6016 + 8 [ls]
+      8,32   1        0     0.000056152     0  m   N cfq1263 insert_request
+      8,32   1        0     0.000061600     0  m   N cfq1263 add_to_rr
+      8,32   1        0     0.000075498     0  m   N cfq workload slice:300
+      .
+      .
+      .
+      8,32   0        0   177.266385696     0  m   N cfq1267 arm_idle: 8 group_idle: 0
+      8,32   0        0   177.266388140     0  m   N cfq schedule dispatch
+      8,32   1        0   177.266679239     0  m   N cfq1267 slice expired t=0
+      8,32   1        0   177.266689297     0  m   N cfq1267 sl_used=9 disp=6 charge=9 iops=0 sect=56
+      8,32   1        0   177.266692649     0  m   N cfq1267 del_from_rr
+      8,32   1        0   177.266696560     0  m   N cfq1267 put_queue
+
+     CPU0 (sdc):
+      Reads Queued:           0,        0KiB     Writes Queued:         270,   21,708KiB
+      Read Dispatches:       59,    2,628KiB     Write Dispatches:      495,   39,964KiB
+      Reads Requeued:         0          Writes Requeued:         0
+      Reads Completed:       90,    2,752KiB     Writes Completed:      543,   41,596KiB
+      Read Merges:            0,        0KiB     Write Merges:            9,      344KiB
+      Read depth:             2          Write depth:             2
+      IO unplugs:            20          Timer unplugs:           1
+     CPU1 (sdc):
+      Reads Queued:         688,    2,752KiB     Writes Queued:         381,   20,652KiB
+      Read Dispatches:       31,      124KiB     Write Dispatches:       59,    2,396KiB
+      Reads Requeued:         0          Writes Requeued:         0
+      Reads Completed:        0,        0KiB     Writes Completed:       11,      764KiB
+      Read Merges:          598,    2,392KiB     Write Merges:           88,      448KiB
+      Read depth:             2          Write depth:             2
+      IO unplugs:            52          Timer unplugs:           0
+
+     Total (sdc):
+      Reads Queued:         688,    2,752KiB     Writes Queued:         651,   42,360KiB
+      Read Dispatches:       90,    2,752KiB     Write Dispatches:      554,   42,360KiB
+      Reads Requeued:         0          Writes Requeued:         0
+      Reads Completed:       90,    2,752KiB     Writes Completed:      554,   42,360KiB
+      Read Merges:          598,    2,392KiB     Write Merges:           97,      792KiB
+      IO unplugs:            72          Timer unplugs:           1
+
+     Throughput (R/W): 15KiB/s / 238KiB/s
+     Events (sdc): 9,301 entries
+     Skips: 0 forward (0 -   0.0%)
+                </literallayout>
+                You should see the trace events and summary just as
+                you would have if you'd run the same command on the target.
+            </para>
+        </section>
+
+        <section id='tracing-block-io-via-ftrace'>
+            <title>Tracing Block I/O via 'ftrace'</title>
+
+            <para>
+                It's also possible to trace block I/O using only
+                <link linkend='the-trace-events-subsystem'>trace events subsystem</link>,
+                which can be useful for casual tracing
+                if you don't want to bother dealing with the userspace tools.
+            </para>
+
+            <para>
+                To enable tracing for a given device, use
+                /sys/block/xxx/trace/enable, where xxx is the device name.
+                This for example enables tracing for /dev/sdc:
+                <literallayout class='monospaced'>
+     root@crownbay:/sys/kernel/debug/tracing# echo 1 > /sys/block/sdc/trace/enable
+                </literallayout>
+                Once you've selected the device(s) you want to trace,
+                selecting the 'blk' tracer will turn the blk tracer on:
+                <literallayout class='monospaced'>
+     root@crownbay:/sys/kernel/debug/tracing# cat available_tracers
+     blk function_graph function nop
+
+     root@crownbay:/sys/kernel/debug/tracing# echo blk > current_tracer
+                </literallayout>
+                Execute the workload you're interested in:
+                <literallayout class='monospaced'>
+     root@crownbay:/sys/kernel/debug/tracing# cat /media/sdc/testfile.txt
+                </literallayout>
+                And look at the output (note here that we're using
+                'trace_pipe' instead of trace to capture this trace -
+                this allows us to wait around on the pipe for data to
+                appear):
+                <literallayout class='monospaced'>
+     root@crownbay:/sys/kernel/debug/tracing# cat trace_pipe
+                 cat-3587  [001] d..1  3023.276361:   8,32   Q   R 1699848 + 8 [cat]
+                 cat-3587  [001] d..1  3023.276410:   8,32   m   N cfq3587 alloced
+                 cat-3587  [001] d..1  3023.276415:   8,32   G   R 1699848 + 8 [cat]
+                 cat-3587  [001] d..1  3023.276424:   8,32   P   N [cat]
+                 cat-3587  [001] d..2  3023.276432:   8,32   I   R 1699848 + 8 [cat]
+                 cat-3587  [001] d..1  3023.276439:   8,32   m   N cfq3587 insert_request
+                 cat-3587  [001] d..1  3023.276445:   8,32   m   N cfq3587 add_to_rr
+                 cat-3587  [001] d..2  3023.276454:   8,32   U   N [cat] 1
+                 cat-3587  [001] d..1  3023.276464:   8,32   m   N cfq workload slice:150
+                 cat-3587  [001] d..1  3023.276471:   8,32   m   N cfq3587 set_active wl_prio:0 wl_type:2
+                 cat-3587  [001] d..1  3023.276478:   8,32   m   N cfq3587 fifo=  (null)
+                 cat-3587  [001] d..1  3023.276483:   8,32   m   N cfq3587 dispatch_insert
+                 cat-3587  [001] d..1  3023.276490:   8,32   m   N cfq3587 dispatched a request
+                 cat-3587  [001] d..1  3023.276497:   8,32   m   N cfq3587 activate rq, drv=1
+                 cat-3587  [001] d..2  3023.276500:   8,32   D   R 1699848 + 8 [cat]
+                </literallayout>
+                And this turns off tracing for the specified device:
+                <literallayout class='monospaced'>
+     root@crownbay:/sys/kernel/debug/tracing# echo 0 > /sys/block/sdc/trace/enable
+                </literallayout>
+            </para>
+        </section>
+    </section>
+
+    <section id='blktrace-documentation'>
+        <title>Documentation</title>
+
+        <para>
+            Online versions of the man pages for the commands discussed
+            in this section can be found here:
+            <itemizedlist>
+                <listitem><para><ulink url='http://linux.die.net/man/8/blktrace'>http://linux.die.net/man/8/blktrace</ulink>
+                    </para></listitem>
+                <listitem><para><ulink url='http://linux.die.net/man/1/blkparse'>http://linux.die.net/man/1/blkparse</ulink>
+                    </para></listitem>
+                <listitem><para><ulink url='http://linux.die.net/man/8/btrace'>http://linux.die.net/man/8/btrace</ulink>
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            The above manpages, along with manpages for the other
+            blktrace utilities (btt, blkiomon, etc) can be found in the
+            /doc directory of the blktrace tools git repo:
+            <literallayout class='monospaced'>
+     $ git clone git://git.kernel.dk/blktrace.git
+            </literallayout>
+        </para>
+    </section>
+</section>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/profile-manual/profile-manual.xml b/documentation/profile-manual/profile-manual.xml
new file mode 100644
index 0000000000..335457816f
--- /dev/null
+++ b/documentation/profile-manual/profile-manual.xml
@@ -0,0 +1,105 @@
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<book id='profile-manual' lang='en'
+      xmlns:xi="http://www.w3.org/2003/XInclude"
+      xmlns="http://docbook.org/ns/docbook"
+      >
+    <bookinfo>
+
+        <mediaobject>
+            <imageobject>
+                <imagedata fileref='figures/profile-title.png'
+                    format='SVG'
+                    align='left' scalefit='1' width='100%'/>
+            </imageobject>
+        </mediaobject>
+
+        <title>
+                  Yocto Project Profiling and Tracing Manual
+                </title>
+
+        <authorgroup>
+            <author>
+                <firstname>Tom</firstname> <surname>Zanussi</surname>
+                <affiliation>
+                    <orgname>Intel Corporation</orgname>
+                </affiliation>
+                <email>tom.zanussi@intel.com</email>
+            </author>
+        </authorgroup>
+
+        <revhistory>
+            <revision>
+                <revnumber>1.4</revnumber>
+                <date>April 2013</date>
+                <revremark>Released with the Yocto Project 1.4 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5</revnumber>
+                <date>October 2013</date>
+                <revremark>Released with the Yocto Project 1.5 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.1</revnumber>
+                <date>January 2014</date>
+                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.6</revnumber>
+                <date>April 2014</date>
+                <revremark>Released with the Yocto Project 1.6 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7</revnumber>
+                <date>October 2014</date>
+                <revremark>Released with the Yocto Project 1.7 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.1</revnumber>
+                <date>January 2015</date>
+                <revremark>Released with the Yocto Project 1.7.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.2</revnumber>
+                <date>June 2015</date>
+                <revremark>Released with the Yocto Project 1.7.2 Release.</revremark>
+            </revision>
+        </revhistory>
+
+    <copyright>
+     <year>&COPYRIGHT_YEAR;</year>
+      <holder>Linux Foundation</holder>
+    </copyright>
+
+    <legalnotice>
+      <para>
+          Permission is granted to copy, distribute and/or modify this document under
+          the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">
+          Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by
+          Creative Commons.
+      </para>
+
+      <note>
+          For the latest version of this manual associated with this
+          Yocto Project release, see the
+          <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Profiling and Tracing Manual</ulink>
+          from the Yocto Project website.
+      </note>
+    </legalnotice>
+
+    </bookinfo>
+
+    <xi:include href="profile-manual-intro.xml"/>
+
+    <xi:include href="profile-manual-arch.xml"/>
+
+    <xi:include href="profile-manual-usage.xml"/>
+
+    <xi:include href="profile-manual-examples.xml"/>
+
+</book>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/TODO b/documentation/ref-manual/TODO
new file mode 100644
index 0000000000..ee0db977cc
--- /dev/null
+++ b/documentation/ref-manual/TODO
@@ -0,0 +1,11 @@
+Handbook Todo List:
+
+  * Document adding a new IMAGE_FEATURE to the customising images section 
+  * Add instructions about using zaurus/openmoko emulation
+  * Add component overview/block diagrams
+  * Software Deevelopment intro should mention its software development for 
+    intended target and could be a different arch etc and thus special case. 
+  * Expand insane.bbclass documentation to cover tests
+  * Document remaining classes (see list in ref-classes)
+  * Document formfactor
+
diff --git a/documentation/ref-manual/closer-look.xml b/documentation/ref-manual/closer-look.xml
new file mode 100644
index 0000000000..c0c0d619a4
--- /dev/null
+++ b/documentation/ref-manual/closer-look.xml
@@ -0,0 +1,1304 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='closer-look'>
+<title>A Closer Look at the Yocto Project Development Environment</title>
+
+    <para>
+        This chapter takes a more detailed look at the Yocto Project
+        development environment.
+        The following diagram represents the development environment at a
+        high level.
+        The remainder of this chapter expands on the fundamental input, output,
+        process, and
+        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>) blocks
+        in the Yocto Project development environment.
+    </para>
+
+    <para id='general-yocto-environment-figure'>
+        <imagedata fileref="figures/yocto-environment-ref.png" align="center" width="8in" depth="4.25in" />
+    </para>
+
+    <para>
+        The generalized Yocto Project Development Environment consists of
+        several functional areas:
+        <itemizedlist>
+            <listitem><para><emphasis>User Configuration:</emphasis>
+                Metadata you can use to control the build process.
+                </para></listitem>
+            <listitem><para><emphasis>Metadata Layers:</emphasis>
+                Various layers that provide software, machine, and
+                distro Metadata.</para></listitem>
+            <listitem><para><emphasis>Source Files:</emphasis>
+                Upstream releases, local projects, and SCMs.</para></listitem>
+            <listitem><para><emphasis>Build System:</emphasis>
+                Processes under the control of
+                <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>.
+                This block expands on how BitBake fetches source, applies
+                patches, completes compilation, analyzes output for package
+                generation, creates and tests packages, generates images, and
+                generates cross-development tools.</para></listitem>
+            <listitem><para><emphasis>Package Feeds:</emphasis>
+                Directories containing output packages (RPM, DEB or IPK),
+                which are subsequently used in the construction of an image or
+                SDK, produced by the build system.
+                These feeds can also be copied and shared using a web server or
+                other means to facilitate extending or updating existing
+                images on devices at runtime if runtime package management is
+                enabled.</para></listitem>
+            <listitem><para><emphasis>Images:</emphasis>
+                Images produced by the development process.
+                </para></listitem>
+            <listitem><para><emphasis>Application Development SDK:</emphasis>
+                Cross-development tools that are produced along with an image
+                or separately with BitBake.</para></listitem>
+        </itemizedlist>
+    </para>
+
+    <section id="user-configuration">
+        <title>User Configuration</title>
+
+        <para>
+            User configuration helps define the build.
+            Through user configuration, you can tell BitBake the
+            target architecture for which you are building the image,
+            where to store downloaded source, and other build properties.
+        </para>
+
+        <para>
+            The following figure shows an expanded representation of the
+            "User Configuration" box of the
+            <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>:
+        </para>
+
+        <para>
+            <imagedata fileref="figures/user-configuration.png" align="center" width="5.5in" depth="3.5in" />
+        </para>
+
+        <para>
+            BitBake needs some basic configuration files in order to complete
+            a build.
+            These files are <filename>*.conf</filename> files.
+            The minimally necessary ones reside as example files in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            For simplicity, this section refers to the Source Directory as
+            the "Poky Directory."
+        </para>
+
+        <para>
+            When you clone the <filename>poky</filename> Git repository or you
+            download and unpack a Yocto Project release, you can set up the
+            Source Directory to be named anything you want.
+            For this discussion, the cloned repository uses the default
+            name <filename>poky</filename>.
+            <note>
+                The Poky repository is primarily an aggregation of existing
+                repositories.
+                It is not a canonical upstream source.
+            </note>
+        </para>
+
+        <para>
+            The <filename>meta-yocto</filename> layer inside Poky contains
+            a <filename>conf</filename> directory that has example
+            configuration files.
+            These example files are used as a basis for creating actual
+            configuration files when you source the build environment
+            script
+            (i.e.
+            <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+            or
+            <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
+        </para>
+
+        <para>
+            Sourcing the build environment script creates a
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            if one does not already exist.
+            BitBake uses the Build Directory for all its work during builds.
+            The Build Directory has a <filename>conf</filename> directory that
+            contains default versions of your <filename>local.conf</filename>
+            and <filename>bblayers.conf</filename> configuration files.
+            These default configuration files are created only if versions
+            do not already exist in the Build Directory at the time you
+            source the build environment setup script.
+        </para>
+
+        <para>
+            Because the Poky repository is fundamentally an aggregation of
+            existing repositories, some users might be familiar with running
+            the <filename>&OE_INIT_FILE;</filename> or
+            <filename>oe-init-build-env-memres</filename> script in the context
+            of separate OpenEmbedded-Core and BitBake repositories rather than a
+            single Poky repository.
+            This discussion assumes the script is executed from within a cloned
+            or unpacked version of Poky.
+        </para>
+
+        <para>
+            Depending on where the script is sourced, different sub-scripts
+            are called to set up the Build Directory (Yocto or OpenEmbedded).
+            Specifically, the script
+            <filename>scripts/oe-setup-builddir</filename> inside the
+            poky directory sets up the Build Directory and seeds the directory
+            (if necessary) with configuration files appropriate for the
+            Yocto Project development environment.
+            <note>
+                The <filename>scripts/oe-setup-builddir</filename> script
+                uses the <filename>$TEMPLATECONF</filename> variable to
+                determine which sample configuration files to locate.
+            </note>
+        </para>
+
+        <para>
+            The <filename>local.conf</filename> file provides many
+            basic variables that define a build environment.
+            Here is a list of a few.
+            To see the default configurations in a <filename>local.conf</filename>
+            file created by the build environment script, see the
+            <filename>local.conf.sample</filename> in the
+            <filename>meta-yocto</filename> layer:
+            <itemizedlist>
+                <listitem><para><emphasis>Parallelism Options:</emphasis>
+                    Controlled by the
+                    <link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
+                    and
+                    <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>
+                    variables.</para></listitem>
+                <listitem><para><emphasis>Target Machine Selection:</emphasis>
+                    Controlled by the
+                    <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+                    variable.</para></listitem>
+                <listitem><para><emphasis>Download Directory:</emphasis>
+                    Controlled by the
+                    <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
+                    variable.</para></listitem>
+                <listitem><para><emphasis>Shared State Directory:</emphasis>
+                    Controlled by the
+                    <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>
+                    variable.</para></listitem>
+                <listitem><para><emphasis>Build Output:</emphasis>
+                    Controlled by the
+                    <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
+                    variable.</para></listitem>
+            </itemizedlist>
+            <note>
+                Configurations set in the <filename>conf/local.conf</filename>
+                file can also be set in the
+                <filename>conf/site.conf</filename> and
+                <filename>conf/auto.conf</filename> configuration files.
+            </note>
+        </para>
+
+        <para>
+            The <filename>bblayers.conf</filename> file tells BitBake what
+            layers you want considered during the build.
+            By default, the layers listed in this file include layers
+            minimally needed by the build system.
+            However, you must manually add any custom layers you have created.
+            You can find more information on working with the
+            <filename>bblayers.conf</filename> file in the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#enabling-your-layer'>Enabling Your Layer</ulink>"
+            section in the Yocto Project Development Manual.
+        </para>
+
+        <para>
+            The files <filename>site.conf</filename> and
+            <filename>auto.conf</filename> are not created by the environment
+            initialization script.
+            If you want these configuration files, you must create them
+            yourself:
+            <itemizedlist>
+                <listitem><para><emphasis><filename>site.conf</filename>:</emphasis>
+                    You can use the <filename>conf/site.conf</filename>
+                    configuration file to configure multiple build directories.
+                    For example, suppose you had several build environments and
+                    they shared some common features.
+                    You can set these default build properties here.
+                    A good example is perhaps the level of parallelism you want
+                    to use through the
+                    <link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
+                    and
+                    <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>
+                    variables.</para>
+                    <para>One useful scenario for using the
+                    <filename>conf/site.conf</filename> file is to extend your
+                    <link linkend='var-BBPATH'><filename>BBPATH</filename></link>
+                    variable to include the path to a
+                    <filename>conf/site.conf</filename>.
+                    Then, when BitBake looks for Metadata using
+                    <filename>BBPATH</filename>, it finds the
+                    <filename>conf/site.conf</filename> file and applies your
+                    common configurations found in the file.
+                    To override configurations in a particular build directory,
+                    alter the similar configurations within that build
+                    directory's <filename>conf/local.conf</filename> file.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>auto.conf</filename>:</emphasis>
+                    This file is not hand-created.
+                    Rather, the file is usually created and written to by
+                    an autobuilder.
+                    The settings put into the file are typically the same as
+                    you would find in the <filename>conf/local.conf</filename>
+                    or the <filename>conf/site.conf</filename> files.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            You can edit all configuration files to further define
+            any particular build environment.
+            This process is represented by the "User Configuration Edits"
+            box in the figure.
+        </para>
+
+        <para>
+            When you launch your build with the
+            <filename>bitbake <replaceable>target</replaceable></filename> command, BitBake
+            sorts out the configurations to ultimately define your build
+            environment.
+        </para>
+    </section>
+
+    <section id="metadata-machine-configuration-and-policy-configuration">
+        <title>Metadata, Machine Configuration, and Policy Configuration</title>
+
+        <para>
+            The previous section described the user configurations that
+            define BitBake's global behavior.
+            This section takes a closer look at the layers the build system
+            uses to further control the build.
+            These layers provide Metadata for the software, machine, and
+            policy.
+        </para>
+
+        <para>
+            In general, three types of layer input exist:
+            <itemizedlist>
+                <listitem><para><emphasis>Policy Configuration:</emphasis>
+                    Distribution Layers provide top-level or general
+                    policies for the image or SDK being built.
+                    For example, this layer would dictate whether BitBake
+                    produces RPM or IPK packages.</para></listitem>
+                <listitem><para><emphasis>Machine Configuration:</emphasis>
+                    Board Support Package (BSP) layers provide machine
+                    configurations.
+                    This type of information is specific to a particular
+                    target architecture.</para></listitem>
+                <listitem><para><emphasis>Metadata:</emphasis>
+                    Software layers contain user-supplied recipe files,
+                    patches, and append files.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            The following figure shows an expanded representation of the
+            Metadata, Machine Configuration, and Policy Configuration input
+            (layers) boxes of the
+            <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>:
+        </para>
+
+        <para>
+            <imagedata fileref="figures/layer-input.png" align="center" width="8in" depth="7.5in" />
+        </para>
+
+        <para>
+            In general, all layers have a similar structure.
+            They all contain a licensing file
+            (e.g. <filename>COPYING</filename>) if the layer is to be
+            distributed, a <filename>README</filename> file as good practice
+            and especially if the layer is to be distributed, a
+            configuration directory, and recipe directories.
+        </para>
+
+        <para>
+            The Yocto Project has many layers that can be used.
+            You can see a web-interface listing of them on the
+            <ulink url="http://git.yoctoproject.org/">Source Repositories</ulink>
+            page.
+            The layers are shown at the bottom categorized under
+            "Yocto Metadata Layers."
+            These layers are fundamentally a subset of the
+            <ulink url="http://layers.openembedded.org/layerindex/layers/">OpenEmbedded Metadata Index</ulink>,
+            which lists all layers provided by the OpenEmbedded community.
+            <note>
+                Layers exist in the Yocto Project Source Repositories that
+                cannot be found in the OpenEmbedded Metadata Index.
+                These layers are either deprecated or experimental in nature.
+            </note>
+        </para>
+
+        <para>
+            BitBake uses the <filename>conf/bblayers.conf</filename> file,
+            which is part of the user configuration, to find what layers it
+            should be using as part of the build.
+        </para>
+
+        <para>
+            For more information on layers, see the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
+            section in the Yocto Project Development Manual.
+        </para>
+
+        <section id="distro-layer">
+            <title>Distro Layer</title>
+
+            <para>
+                The distribution layer provides policy configurations for your
+                distribution.
+                Best practices dictate that you isolate these types of
+                configurations into their own layer.
+                Settings you provide in
+                <filename>conf/distro/<replaceable>distro</replaceable>.conf</filename> override
+                similar
+                settings that BitBake finds in your
+                <filename>conf/local.conf</filename> file in the Build
+                Directory.
+            </para>
+
+            <para>
+                The following list provides some explanation and references
+                for what you typically find in the distribution layer:
+                <itemizedlist>
+                    <listitem><para><emphasis>classes:</emphasis>
+                        Class files (<filename>.bbclass</filename>) hold
+                        common functionality that can be shared among
+                        recipes in the distribution.
+                        When your recipes inherit a class, they take on the
+                        settings and functions for that class.
+                        You can read more about class files in the
+                        "<link linkend='ref-classes'>Classes</link>" section.
+                        </para></listitem>
+                    <listitem><para><emphasis>conf:</emphasis>
+                        This area holds configuration files for the
+                        layer (<filename>conf/layer.conf</filename>),
+                        the distribution
+                        (<filename>conf/distro/<replaceable>distro</replaceable>.conf</filename>),
+                        and any distribution-wide include files.
+                        </para></listitem>
+                    <listitem><para><emphasis>recipes-*:</emphasis>
+                        Recipes and append files that affect common
+                        functionality across the distribution.
+                        This area could include recipes and append files
+                        to add distribution-specific configuration,
+                        initialization scripts, custom image recipes,
+                        and so forth.</para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id="bsp-layer">
+            <title>BSP Layer</title>
+
+            <para>
+                The BSP Layer provides machine configurations.
+                Everything in this layer is specific to the machine for which
+                you are building the image or the SDK.
+                A common structure or form is defined for BSP layers.
+                You can learn more about this structure in the
+                <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
+                <note>
+                    In order for a BSP layer to be considered compliant with the
+                    Yocto Project, it must meet some structural requirements.
+                </note>
+            </para>
+
+            <para>
+                The BSP Layer's configuration directory contains
+                configuration files for the machine
+                (<filename>conf/machine/<replaceable>machine</replaceable>.conf</filename>) and,
+                of course, the layer (<filename>conf/layer.conf</filename>).
+            </para>
+
+            <para>
+                The remainder of the layer is dedicated to specific recipes
+                by function: <filename>recipes-bsp</filename>,
+                <filename>recipes-core</filename>,
+                <filename>recipes-graphics</filename>, and
+                <filename>recipes-kernel</filename>.
+                Metadata can exist for multiple formfactors, graphics
+                support systems, and so forth.
+                <note>
+                    While the figure shows several <filename>recipes-*</filename>
+                    directories, not all these directories appear in all
+                    BSP layers.
+                </note>
+            </para>
+        </section>
+
+        <section id="software-layer">
+            <title>Software Layer</title>
+
+            <para>
+                The software layer provides the Metadata for additional
+                software packages used during the build.
+                This layer does not include Metadata that is specific to the
+                distribution or the machine, which are found in their
+                respective layers.
+            </para>
+
+            <para>
+                This layer contains any new recipes that your project needs
+                in the form of recipe files.
+            </para>
+        </section>
+    </section>
+
+    <section id="sources-dev-environment">
+        <title>Sources</title>
+
+        <para>
+            In order for the OpenEmbedded build system to create an image or
+            any target, it must be able to access source files.
+            The
+            <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>
+            represents source files using the "Upstream Project Releases",
+            "Local Projects", and "SCMs (optional)" boxes.
+            The figure represents mirrors, which also play a role in locating
+            source files, with the "Source Mirror(s)" box.
+        </para>
+
+        <para>
+            The method by which source files are ultimately organized is
+            a function of the project.
+            For example, for released software, projects tend to use tarballs
+            or other archived files that can capture the state of a release
+            guaranteeing that it is statically represented.
+            On the other hand, for a project that is more dynamic or
+            experimental in nature, a project might keep source files in a
+            repository controlled by a Source Control Manager (SCM) such as
+            Git.
+            Pulling source from a repository allows you to control
+            the point in the repository (the revision) from which you want to
+            build software.
+            Finally, a combination of the two might exist, which would give the
+            consumer a choice when deciding where to get source files.
+        </para>
+
+        <para>
+            BitBake uses the
+            <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+            variable to point to source files regardless of their location.
+            Each recipe must have a <filename>SRC_URI</filename> variable
+            that points to the source.
+        </para>
+
+        <para>
+            Another area that plays a significant role in where source files
+            come from is pointed to by the
+            <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
+            variable.
+            This area is a cache that can hold previously downloaded source.
+            You can also instruct the OpenEmbedded build system to create
+            tarballs from Git repositories, which is not the default behavior,
+            and store them in the <filename>DL_DIR</filename> by using the
+            <link linkend='var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link>
+            variable.
+        </para>
+
+        <para>
+            Judicious use of a <filename>DL_DIR</filename> directory can
+            save the build system a trip across the Internet when looking
+            for files.
+            A good method for using a download directory is to have
+            <filename>DL_DIR</filename> point to an area outside of your
+            Build Directory.
+            Doing so allows you to safely delete the Build Directory
+            if needed without fear of removing any downloaded source file.
+        </para>
+
+        <para>
+            The remainder of this section provides a deeper look into the
+            source files and the mirrors.
+            Here is a more detailed look at the source file area of the
+            base figure:
+            <imagedata fileref="figures/source-input.png" align="center" width="7in" depth="7.5in" />
+        </para>
+
+        <section id='upstream-project-releases'>
+            <title>Upstream Project Releases</title>
+
+            <para>
+                Upstream project releases exist anywhere in the form of an
+                archived file (e.g. tarball or zip file).
+                These files correspond to individual recipes.
+                For example, the figure uses specific releases each for
+                BusyBox, Qt, and Dbus.
+                An archive file can be for any released product that can be
+                built using a recipe.
+            </para>
+        </section>
+
+        <section id='local-projects'>
+            <title>Local Projects</title>
+
+            <para>
+                Local projects are custom bits of software the user provides.
+                These bits reside somewhere local to a project - perhaps
+                a directory into which the user checks in items (e.g.
+                a local directory containing a development source tree
+                used by the group).
+            </para>
+
+            <para>
+                The canonical method through which to include a local project
+                is to use the
+                <link linkend='ref-classes-externalsrc'><filename>externalsrc</filename></link>
+                class to include that local project.
+                You use either the <filename>local.conf</filename> or a
+                recipe's append file to override or set the
+                recipe to point to the local directory on your disk to pull
+                in the whole source tree.
+            </para>
+
+            <para>
+                For information on how to use the
+                <filename>externalsrc</filename> class, see the
+                "<link linkend='ref-classes-externalsrc'><filename>externalsrc.bbclass</filename></link>"
+                section.
+            </para>
+        </section>
+
+        <section id='scms'>
+            <title>Source Control Managers (Optional)</title>
+
+            <para>
+                Another place the build system can get source files from is
+                through an SCM such as Git or Subversion.
+                In this case, a repository is cloned or checked out.
+                The
+                <link linkend='ref-tasks-fetch'><filename>do_fetch</filename></link>
+                task inside BitBake uses
+                the <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+                variable and the argument's prefix to determine the correct
+                fetcher module.
+            </para>
+
+            <note>
+                For information on how to have the OpenEmbedded build system
+                generate tarballs for Git repositories and place them in the
+                <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
+                directory, see the
+                <link linkend='var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link>
+                variable.
+            </note>
+
+            <para>
+                When fetching a repository, BitBake uses the
+                <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
+                variable to determine the specific revision from which to
+                build.
+            </para>
+        </section>
+
+        <section id='source-mirrors'>
+            <title>Source Mirror(s)</title>
+
+            <para>
+                Two kinds of mirrors exist: pre-mirrors and regular mirrors.
+                The <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>
+                and
+                <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
+                variables point to these, respectively.
+                BitBake checks pre-mirrors before looking upstream for any
+                source files.
+                Pre-mirrors are appropriate when you have a shared directory
+                that is not a directory defined by the
+                <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
+                variable.
+                A Pre-mirror typically points to a shared directory that is
+                local to your organization.
+            </para>
+
+            <para>
+                Regular mirrors can be any site across the Internet that is
+                used as an alternative location for source code should the
+                primary site not be functioning for some reason or another.
+            </para>
+        </section>
+    </section>
+
+    <section id="package-feeds-dev-environment">
+        <title>Package Feeds</title>
+
+        <para>
+            When the OpenEmbedded build system generates an image or an SDK,
+            it gets the packages from a package feed area located in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+            The
+            <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>
+            shows this package feeds area in the upper-right corner.
+        </para>
+
+        <para>
+            This section looks a little closer into the package feeds area used
+            by the build system.
+            Here is a more detailed look at the area:
+            <imagedata fileref="figures/package-feeds.png" align="center" width="7in" depth="6in" />
+        </para>
+
+        <para>
+            Package feeds are an intermediary step in the build process.
+            BitBake generates packages whose types are defined by the
+            <link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>
+            variable.
+            Before placing the packages into package feeds,
+            the build process validates them with generated output quality
+            assurance checks through the
+            <link linkend='ref-classes-insane'><filename>insane</filename></link>
+            class.
+        </para>
+
+        <para>
+            The package feed area resides in
+            <filename>tmp/deploy</filename> of the Build Directory.
+            Folders are created that correspond to the package type
+            (IPK, DEB, or RPM) created.
+            Further organization is derived through the value of the
+            <link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link>
+            variable for each package.
+            For example, packages can exist for the i586 or qemux86
+            architectures.
+            The package files themselves reside within the appropriate
+            architecture folder.
+        </para>
+
+        <para>
+            BitBake uses the <filename>do_package_write_*</filename> tasks to
+            place generated packages into the package holding area (e.g.
+            <filename>do_package_write_ipk</filename> for IPK packages).
+            See the
+            "<link linkend='ref-tasks-package_write_deb'><filename>do_package_write_deb</filename></link>",
+            "<link linkend='ref-tasks-package_write_ipk'><filename>do_package_write_ipk</filename></link>",
+            "<link linkend='ref-tasks-package_write_rpm'><filename>do_package_write_rpm</filename></link>",
+            and
+            "<link linkend='ref-tasks-package_write_tar'><filename>do_package_write_tar</filename></link>"
+            sections for additional information.
+        </para>
+    </section>
+
+    <section id='bitbake-dev-environment'>
+        <title>BitBake</title>
+
+        <para>
+            The OpenEmbedded build system uses
+            <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>
+            to produce images.
+            You can see from the
+            <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>,
+            the BitBake area consists of several functional areas.
+            This section takes a closer look at each of those areas.
+        </para>
+
+        <para>
+            Separate documentation exists for the BitBake tool.
+            See the
+            <ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual'>BitBake User Manual</ulink>
+            for reference material on BitBake.
+        </para>
+
+        <section id='source-fetching-dev-environment'>
+            <title>Source Fetching</title>
+
+            <para>
+                The first stages of building a recipe are to fetch and unpack
+                the source code:
+                <imagedata fileref="figures/source-fetching.png" align="center" width="6.5in" depth="5in" />
+            </para>
+
+            <para>
+                The
+                <link linkend='ref-tasks-fetch'><filename>do_fetch</filename></link>
+                and
+                <link linkend='ref-tasks-unpack'><filename>do_unpack</filename></link>
+                tasks fetch the source files and unpack them into the work
+                directory.
+                <note>
+                    For every local file (e.g. <filename>file://</filename>)
+                    that is part of a recipe's
+                    <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+                    statement, the OpenEmbedded build system takes a checksum
+                    of the file for the recipe and inserts the checksum into
+                    the signature for the <filename>do_fetch</filename>.
+                    If any local file has been modified, the
+                    <filename>do_fetch</filename> task and all tasks that
+                    depend on it are re-executed.
+                </note>
+                By default, everything is accomplished in the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
+                which has a defined structure.
+                For additional general information on the Build Directory,
+                see the
+                "<link linkend='structure-core-build'><filename>build/</filename></link>"
+                section.
+            </para>
+
+            <para>
+                Unpacked source files are pointed to by the
+                <link linkend='var-S'><filename>S</filename></link> variable.
+                Each recipe has an area in the Build Directory where the
+                unpacked source code resides.
+                The name of that directory for any given recipe is defined from
+                several different variables.
+                You can see the variables that define these directories
+                by looking at the figure:
+                <itemizedlist>
+                    <listitem><para><link linkend='var-TMPDIR'><filename>TMPDIR</filename></link> -
+                        The base directory where the OpenEmbedded build system
+                        performs all its work during the build.
+                        </para></listitem>
+                    <listitem><para><link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link> -
+                        The architecture of the built package or packages.
+                        </para></listitem>
+                    <listitem><para><link linkend='var-TARGET_OS'><filename>TARGET_OS</filename></link> -
+                        The operating system of the target device.
+                        </para></listitem>
+                    <listitem><para><link linkend='var-PN'><filename>PN</filename></link> -
+                        The name of the built package.
+                        </para></listitem>
+                    <listitem><para><link linkend='var-PV'><filename>PV</filename></link> -
+                        The version of the recipe used to build the package.
+                        </para></listitem>
+                    <listitem><para><link linkend='var-PR'><filename>PR</filename></link> -
+                        The revision of the recipe used to build the package.
+                        </para></listitem>
+                    <listitem><para><link linkend='var-WORKDIR'><filename>WORKDIR</filename></link> -
+                        The location within <filename>TMPDIR</filename> where
+                        a specific package is built.
+                        </para></listitem>
+                    <listitem><para><link linkend='var-S'><filename>S</filename></link> -
+                        Contains the unpacked source files for a given recipe.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='patching-dev-environment'>
+            <title>Patching</title>
+
+            <para>
+                Once source code is fetched and unpacked, BitBake locates
+                patch files and applies them to the source files:
+                <imagedata fileref="figures/patching.png" align="center" width="6in" depth="5in" />
+            </para>
+
+            <para>
+                The
+                <link linkend='ref-tasks-patch'><filename>do_patch</filename></link>
+                task processes recipes by
+                using the
+                <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+                variable to locate applicable patch files, which by default
+                are <filename>*.patch</filename> or
+                <filename>*.diff</filename> files, or any file if
+                "apply=yes" is specified for the file in
+                <filename>SRC_URI</filename>.
+            </para>
+
+            <para>
+                BitBake finds and applies multiple patches for a single recipe
+                in the order in which it finds the patches.
+                Patches are applied to the recipe's source files located in the
+                <link linkend='var-S'><filename>S</filename></link> directory.
+            </para>
+
+            <para>
+                For more information on how the source directories are
+                created, see the
+                "<link linkend='source-fetching-dev-environment'>Source Fetching</link>"
+                section.
+            </para>
+        </section>
+
+        <section id='configuration-and-compilation-dev-environment'>
+            <title>Configuration and Compilation</title>
+
+            <para>
+                After source code is patched, BitBake executes tasks that
+                configure and compile the source code:
+                <imagedata fileref="figures/configuration-compile-autoreconf.png" align="center" width="7in" depth="5in" />
+            </para>
+
+            <para>
+                This step in the build process consists of three tasks:
+                <itemizedlist>
+                    <listitem><para><emphasis><filename>do_configure</filename>:</emphasis>
+                        This task configures the source by enabling and
+                        disabling any build-time and configuration options for
+                        the software being built.
+                        Configurations can come from the recipe itself as well
+                        as from an inherited class.
+                        Additionally, the software itself might configure itself
+                        depending on the target for which it is being built.
+                        </para>
+
+                        <para>The configurations handled by the
+                        <link linkend='ref-tasks-configure'><filename>do_configure</filename></link>
+                        task are specific
+                        to source code configuration for the source code
+                        being built by the recipe.</para>
+
+                        <para>If you are using the
+                        <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
+                        class,
+                        you can add additional configuration options by using
+                        the <link linkend='var-EXTRA_OECONF'><filename>EXTRA_OECONF</filename></link>
+                        variable.
+                        For information on how this variable works within
+                        that class, see the
+                        <filename>meta/classes/autotools.bbclass</filename> file.
+                        </para></listitem>
+                    <listitem><para><emphasis><filename>do_compile</filename>:</emphasis>
+                        Once a configuration task has been satisfied, BitBake
+                        compiles the source using the
+                        <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
+                        task.
+                        Compilation occurs in the directory pointed to by the
+                        <link linkend='var-B'><filename>B</filename></link>
+                        variable.
+                        Realize that the <filename>B</filename> directory is, by
+                        default, the same as the
+                        <link linkend='var-S'><filename>S</filename></link>
+                        directory.</para></listitem>
+                    <listitem><para><emphasis><filename>do_install</filename>:</emphasis>
+                        Once compilation is done, BitBake executes the
+                        <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+                        task.
+                        This task copies files from the <filename>B</filename>
+                        directory and places them in a holding area pointed to
+                        by the
+                        <link linkend='var-D'><filename>D</filename></link>
+                        variable.</para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='package-splitting-dev-environment'>
+            <title>Package Splitting</title>
+
+            <para>
+                After source code is configured and compiled, the
+                OpenEmbedded build system analyzes
+                the results and splits the output into packages:
+                <imagedata fileref="figures/analysis-for-package-splitting.png" align="center" width="7in" depth="7in" />
+            </para>
+
+            <para>
+                The
+                <link linkend='ref-tasks-package'><filename>do_package</filename></link>
+                and
+                <link linkend='ref-tasks-packagedata'><filename>do_packagedata</filename></link>
+                tasks combine to analyze
+                the files found in the
+                <link linkend='var-D'><filename>D</filename></link> directory
+                and split them into subsets based on available packages and
+                files.
+                The analyzing process involves the following as well as other
+                items: splitting out debugging symbols,
+                looking at shared library dependencies between packages,
+                and looking at package relationships.
+                The <filename>do_packagedata</filename> task creates package
+                metadata based on the analysis such that the
+                OpenEmbedded build system can generate the final packages.
+                Working, staged, and intermediate results of the analysis
+                and package splitting process use these areas:
+                <itemizedlist>
+                    <listitem><para><link linkend='var-PKGD'><filename>PKGD</filename></link> -
+                        The destination directory for packages before they are
+                        split.
+                        </para></listitem>
+                    <listitem><para><link linkend='var-PKGDATA_DIR'><filename>PKGDATA_DIR</filename></link> -
+                        A shared, global-state directory that holds data
+                        generated during the packaging process.
+                        </para></listitem>
+                    <listitem><para><link linkend='var-PKGDESTWORK'><filename>PKGDESTWORK</filename></link> -
+                        A temporary work area used by the
+                        <filename>do_package</filename> task.
+                        </para></listitem>
+                    <listitem><para><link linkend='var-PKGDEST'><filename>PKGDEST</filename></link> -
+                        The parent directory for packages after they have
+                        been split.
+                        </para></listitem>
+                </itemizedlist>
+                The <link linkend='var-FILES'><filename>FILES</filename></link>
+                variable defines the files that go into each package in
+                <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>.
+                If you want details on how this is accomplished, you can
+                look at the
+                <link linkend='ref-classes-package'><filename>package</filename></link>
+                class.
+            </para>
+
+            <para>
+                Depending on the type of packages being created (RPM, DEB, or
+                IPK), the <filename>do_package_write_*</filename> task
+                creates the actual packages and places them in the
+                Package Feed area, which is
+                <filename>${TMPDIR}/deploy</filename>.
+                You can see the
+                "<link linkend='package-feeds-dev-environment'>Package Feeds</link>"
+                section for more detail on that part of the build process.
+                <note>
+                    Support for creating feeds directly from the
+                    <filename>deploy/*</filename> directories does not exist.
+                    Creating such feeds usually requires some kind of feed
+                    maintenance mechanism that would upload the new packages
+                    into an official package feed (e.g. the
+                    Ångström distribution).
+                    This functionality is highly distribution-specific
+                    and thus is not provided out of the box.
+                </note>
+            </para>
+        </section>
+
+        <section id='image-generation-dev-environment'>
+            <title>Image Generation</title>
+
+            <para>
+                Once packages are split and stored in the Package Feeds area,
+                the OpenEmbedded build system uses BitBake to generate the
+                root filesystem image:
+                <imagedata fileref="figures/image-generation.png" align="center" width="6in" depth="7in" />
+            </para>
+
+            <para>
+                The image generation process consists of several stages and
+                depends on many variables.
+                The
+                <link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>
+                task uses these key variables
+                to help create the list of packages to actually install:
+                <itemizedlist>
+                    <listitem><para><link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>:
+                        Lists out the base set of packages to install from
+                        the Package Feeds area.</para></listitem>
+                    <listitem><para><link linkend='var-PACKAGE_EXCLUDE'><filename>PACKAGE_EXCLUDE</filename></link>:
+                        Specifies packages that should not be installed.
+                        </para></listitem>
+                    <listitem><para><link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>:
+                        Specifies features to include in the image.
+                        Most of these features map to additional packages for
+                        installation.</para></listitem>
+                    <listitem><para><link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>:
+                        Specifies the package backend to use and consequently
+                        helps determine where to locate packages within the
+                        Package Feeds area.</para></listitem>
+                    <listitem><para><link linkend='var-IMAGE_LINGUAS'><filename>IMAGE_LINGUAS</filename></link>:
+                        Determines the language(s) for which additional
+                        language support packages are installed.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                Package installation is under control of the package manager
+                (e.g. smart/rpm, opkg, or apt/dpkg) regardless of whether or
+                not package management is enabled for the target.
+                At the end of the process, if package management is not
+                enabled for the target, the package manager's data files
+                are deleted from the root filesystem.
+            </para>
+
+            <para>
+                During image generation, the build system attempts to run
+                all post-installation scripts.
+                Any that fail to run on the build host are run on the
+                target when the target system is first booted.
+                If you are using a
+                <ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem'>read-only root filesystem</ulink>,
+                all the post installation scripts must succeed during the
+                package installation phase since the root filesystem is
+                read-only.
+            </para>
+
+            <para>
+                During Optimization, optimizing processes are run across
+                the image.
+                These processes include <filename>mklibs</filename> and
+                <filename>prelink</filename>.
+                The <filename>mklibs</filename> process optimizes the size
+                of the libraries.
+                A <filename>prelink</filename> process optimizes the dynamic
+                linking of shared libraries to reduce start up time of
+                executables.
+            </para>
+
+            <para>
+                Along with writing out the root filesystem image, the
+                <filename>do_rootfs</filename> task creates a manifest file
+                (<filename>.manifest</filename>) in the same directory as
+                the root filesystem image that lists out, line-by-line, the
+                installed packages.
+                This manifest file is useful for the
+                <link linkend='ref-classes-testimage'><filename>testimage</filename></link>
+                class, for example, to determine whether or not to run
+                specific tests.
+                See the
+                <link linkend='var-IMAGE_MANIFEST'><filename>IMAGE_MANIFEST</filename></link>
+                variable for additional information.
+            </para>
+
+            <para>
+                Part of the image generation process includes compressing the
+                root filesystem image.
+                Compression is accomplished through several optimization
+                routines designed to reduce the overall size of the image.
+            </para>
+
+            <para>
+                After the root filesystem has been constructed, the image
+                generation process turns everything into an image file or
+                a set of image files.
+                The formats used for the root filesystem depend on the
+                <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
+                variable.
+            </para>
+
+            <note>
+                The entire image generation process is run under Pseudo.
+                Running under Pseudo ensures that the files in the root
+                filesystem have correct ownership.
+            </note>
+        </section>
+
+        <section id='sdk-generation-dev-environment'>
+            <title>SDK Generation</title>
+
+            <para>
+                The OpenEmbedded build system uses BitBake to generate the
+                Software Development Kit (SDK) installer script:
+                <imagedata fileref="figures/sdk-generation.png" align="center" width="6in" depth="7in" />
+            </para>
+
+            <note>
+                For more information on the cross-development toolchain
+                generation, see the
+                "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
+                section.
+                For information on advantages gained when building a
+                cross-development toolchain using the
+                <link linkend='ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></link>
+                task, see the
+                "<ulink url='&YOCTO_DOCS_ADT_URL;#optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</ulink>"
+                section in the Yocto Project Application Developer's Guide.
+            </note>
+
+            <para>
+                Like image generation, the SDK script process consists of
+                several stages and depends on many variables.
+                The <filename>do_populate_sdk</filename> task uses these
+                key variables to help create the list of packages to actually
+                install.
+                For information on the variables listed in the figure, see the
+                "<link linkend='sdk-dev-environment'>Application Development SDK</link>"
+                section.
+            </para>
+
+            <para>
+                The <filename>do_populate_sdk</filename> task handles two
+                parts: a target part and a host part.
+                The target part is the part built for the target hardware and
+                includes libraries and headers.
+                The host part is the part of the SDK that runs on the
+                <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>.
+            </para>
+
+            <para>
+                Once both parts are constructed, the
+                <filename>do_populate_sdk</filename> task performs some cleanup
+                on both parts.
+                After the cleanup, the task creates a cross-development
+                environment setup script and any configuration files that
+                might be needed.
+            </para>
+
+            <para>
+                The final output of the task is the Cross-development
+                toolchain installation script (<filename>.sh</filename> file),
+                which includes the environment setup script.
+            </para>
+        </section>
+    </section>
+
+    <section id='images-dev-environment'>
+        <title>Images</title>
+
+        <para>
+            The images produced by the OpenEmbedded build system
+            are compressed forms of the
+            root filesystem that are ready to boot on a target device.
+            You can see from the
+            <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>
+            that BitBake output, in part, consists of images.
+            This section is going to look more closely at this output:
+            <imagedata fileref="figures/images.png" align="center" width="5.5in" depth="5.5in" />
+        </para>
+
+        <para>
+            For a list of example images that the Yocto Project provides,
+            see the
+            "<link linkend='ref-images'>Images</link>" chapter.
+        </para>
+
+        <para>
+            Images are written out to the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            inside the <filename>tmp/deploy/images/<replaceable>machine</replaceable>/</filename>
+            folder as shown in the figure.
+            This folder contains any files expected to be loaded on the
+            target device.
+            The
+            <link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>
+            variable points to the <filename>deploy</filename> directory,
+            while the
+            <link linkend='var-DEPLOY_DIR_IMAGE'><filename>DEPLOY_DIR_IMAGE</filename></link>
+            variable points to the appropriate directory containing images for
+            the current configuration.
+            <itemizedlist>
+                <listitem><para><filename><replaceable>kernel-image</replaceable></filename>:
+                    A kernel binary file.
+                    The <link linkend='var-KERNEL_IMAGETYPE'><filename>KERNEL_IMAGETYPE</filename></link>
+                    variable setting determines the naming scheme for the
+                    kernel image file.
+                    Depending on that variable, the file could begin with
+                    a variety of naming strings.
+                    The <filename>deploy/images/<replaceable>machine</replaceable></filename>
+                    directory can contain multiple image files for the
+                    machine.</para></listitem>
+                <listitem><para><filename><replaceable>root-filesystem-image</replaceable></filename>:
+                    Root filesystems for the target device (e.g.
+                    <filename>*.ext3</filename> or <filename>*.bz2</filename>
+                    files).
+                    The <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
+                    variable setting determines the root filesystem image
+                    type.
+                    The <filename>deploy/images/<replaceable>machine</replaceable></filename>
+                    directory can contain multiple root filesystems for the
+                    machine.</para></listitem>
+                <listitem><para><filename><replaceable>kernel-modules</replaceable></filename>:
+                    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>
+                    variable to "0".
+                    The <filename>deploy/images/<replaceable>machine</replaceable></filename>
+                    directory can contain multiple kernel module tarballs
+                    for the machine.</para></listitem>
+                <listitem><para><filename><replaceable>bootloaders</replaceable></filename>:
+                    Bootloaders supporting the image, if applicable to the
+                    target machine.
+                    The <filename>deploy/images/<replaceable>machine</replaceable></filename>
+                    directory can contain multiple bootloaders for the
+                    machine.</para></listitem>
+                <listitem><para><filename><replaceable>symlinks</replaceable></filename>:
+                    The <filename>deploy/images/<replaceable>machine</replaceable></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
+                    need to obtain the latest version of each file.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='sdk-dev-environment'>
+        <title>Application Development SDK</title>
+
+        <para>
+            In the
+            <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>,
+            the output labeled "Application Development SDK" represents an
+            SDK.
+            This section is going to take a closer look at this output:
+            <imagedata fileref="figures/sdk.png" align="center" width="5in" depth="4in" />
+        </para>
+
+        <para>
+            The specific form of this output is a self-extracting
+            SDK installer (<filename>*.sh</filename>) that, when run,
+            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-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
+            environment before using the tools.
+        </para>
+
+        <note>
+            <para>
+                The Yocto Project supports several methods by which you can
+                set up this cross-development environment.
+                These methods include downloading pre-built SDK installers,
+                building and installing your own SDK installer, or running
+                an Application Development Toolkit (ADT) installer to
+                install not just cross-development toolchains
+                but also additional tools to help in this type of
+                development.
+            </para>
+
+            <para>
+                For background information on cross-development toolchains
+                in the Yocto Project development environment, see the
+                "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
+                section.
+                For information on setting up a cross-development
+                environment, see the
+                "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
+                section in the Yocto Project Application Developer's Guide.
+            </para>
+        </note>
+
+        <para>
+            Once built, the SDK installers are written out to the
+            <filename>deploy/sdk</filename> folder inside the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            as shown in the figure at the beginning of this section.
+            Several variables exist that help configure these files:
+            <itemizedlist>
+                <listitem><para><link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>:
+                    Points to the <filename>deploy</filename>
+                    directory.</para></listitem>
+                <listitem><para><link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>:
+                    Specifies the architecture of the machine
+                    on which the cross-development tools are run to
+                    create packages for the target hardware.
+                    </para></listitem>
+                <listitem><para><link linkend='var-SDKIMAGE_FEATURES'><filename>SDKIMAGE_FEATURES</filename></link>:
+                    Lists the features to include in the "target" part
+                    of the SDK.
+                    </para></listitem>
+                <listitem><para><link linkend='var-TOOLCHAIN_HOST_TASK'><filename>TOOLCHAIN_HOST_TASK</filename></link>:
+                    Lists packages that make up the host
+                    part of the SDK (i.e. the part that runs on
+                    the <filename>SDKMACHINE</filename>).
+                    When you use
+                    <filename>bitbake -c populate_sdk <replaceable>imagename</replaceable></filename>
+                    to create the SDK, a set of default packages
+                    apply.
+                    This variable allows you to add more packages.
+                    </para></listitem>
+                <listitem><para><link linkend='var-TOOLCHAIN_TARGET_TASK'><filename>TOOLCHAIN_TARGET_TASK</filename></link>:
+                    Lists packages that make up the target part
+                    of the SDK (i.e. the part built for the
+                    target hardware).
+                    </para></listitem>
+                <listitem><para><link linkend='var-SDKPATH'><filename>SDKPATH</filename></link>:
+                    Defines the default SDK installation path offered by the
+                    installation script.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/examples/hello-autotools/hello_2.3.bb b/documentation/ref-manual/examples/hello-autotools/hello_2.3.bb
new file mode 100644
index 0000000000..5dfb0b30cf
--- /dev/null
+++ b/documentation/ref-manual/examples/hello-autotools/hello_2.3.bb
@@ -0,0 +1,8 @@
+DESCRIPTION = "GNU Helloworld application"
+SECTION = "examples"
+LICENSE = "GPLv3"
+LIC_FILES_CHKSUM = "file://COPYING;md5=adefda309052235aa5d1e99ce7557010"
+
+SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.bz2"
+
+inherit autotools
diff --git a/documentation/ref-manual/examples/hello-single/files/helloworld.c b/documentation/ref-manual/examples/hello-single/files/helloworld.c
new file mode 100644
index 0000000000..fc7169b7b8
--- /dev/null
+++ b/documentation/ref-manual/examples/hello-single/files/helloworld.c
@@ -0,0 +1,8 @@
+#include <stdio.h>
+
+int main(void)
+{
+        printf("Hello world!\n");
+
+        return 0;
+}
diff --git a/documentation/ref-manual/examples/hello-single/hello.bb b/documentation/ref-manual/examples/hello-single/hello.bb
new file mode 100644
index 0000000000..0812743e39
--- /dev/null
+++ b/documentation/ref-manual/examples/hello-single/hello.bb
@@ -0,0 +1,17 @@
+DESCRIPTION = "Simple helloworld application"
+SECTION = "examples"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
+
+SRC_URI = "file://helloworld.c"
+
+S = "${WORKDIR}"
+
+do_compile() {
+        ${CC} helloworld.c -o helloworld
+}
+
+do_install() {
+        install -d ${D}${bindir}
+        install -m 0755 helloworld ${D}${bindir}
+}
diff --git a/documentation/ref-manual/examples/libxpm/libxpm_3.5.6.bb b/documentation/ref-manual/examples/libxpm/libxpm_3.5.6.bb
new file mode 100644
index 0000000000..b58d4d7bd1
--- /dev/null
+++ b/documentation/ref-manual/examples/libxpm/libxpm_3.5.6.bb
@@ -0,0 +1,14 @@
+require xorg-lib-common.inc
+
+DESCRIPTION = "X11 Pixmap library"
+LICENSE = "X-BSD"
+LIC_FILES_CHKSUM = "file://COPYING;md5=3e07763d16963c3af12db271a31abaa5"
+DEPENDS += "libxext"
+PR = "r2"
+PE = "1"
+
+XORG_PN = "libXpm"
+
+PACKAGES =+ "sxpm cxpm"
+FILES_cxpm = "${bindir}/cxpm"
+FILES_sxpm = "${bindir}/sxpm"
diff --git a/documentation/ref-manual/examples/mtd-makefile/mtd-utils_1.0.0.bb b/documentation/ref-manual/examples/mtd-makefile/mtd-utils_1.0.0.bb
new file mode 100644
index 0000000000..5d05a437a4
--- /dev/null
+++ b/documentation/ref-manual/examples/mtd-makefile/mtd-utils_1.0.0.bb
@@ -0,0 +1,15 @@
+DESCRIPTION = "Tools for managing memory technology devices."
+SECTION = "base"
+DEPENDS = "zlib"
+HOMEPAGE = "http://www.linux-mtd.infradead.org/"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
+                    file://include/common.h;beginline=1;endline=17;md5=ba05b07912a44ea2bf81ce409380049c"
+
+SRC_URI = "ftp://ftp.infradead.org/pub/mtd-utils/mtd-utils-${PV}.tar.gz"
+
+CFLAGS_prepend = "-I ${S}/include "
+
+do_install() {
+        oe_runmake install DESTDIR=${D}
+}
diff --git a/documentation/ref-manual/faq.xml b/documentation/ref-manual/faq.xml
new file mode 100644
index 0000000000..da6ce20eef
--- /dev/null
+++ b/documentation/ref-manual/faq.xml
@@ -0,0 +1,799 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='faq'>
+<title>FAQ</title>
+<qandaset>
+    <qandaentry>
+        <question>
+            <para>
+                How does Poky differ from <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>?
+            </para>
+        </question>
+        <answer>
+            <para>
+                The term "<ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink>"
+                refers to the specific reference build system that
+                the Yocto Project provides.
+                Poky is based on <ulink url='&YOCTO_DOCS_DEV_URL;#oe-core'>OE-Core</ulink>
+                and <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>.
+                Thus, the generic term used here for the build system is
+                the "OpenEmbedded build system."
+                Development in the Yocto Project using Poky is closely tied to OpenEmbedded, with
+                changes always being merged to OE-Core or BitBake first before being pulled back
+                into Poky.
+                This practice benefits both projects immediately.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para id='faq-not-meeting-requirements'>
+                My development system does not meet the
+                required Git, tar, and Python versions.
+                In particular, I do not have Python 2.7.3 or greater, or
+                I do have Python 3.x, which is specifically not supported by
+                the Yocto Project.
+                Can I still use the Yocto Project?
+            </para>
+        </question>
+        <answer>
+            <para>
+                You can get the required tools on your host development
+                system a couple different ways (i.e. building a tarball or
+                downloading a tarball).
+                See the
+                "<link linkend='required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</link>"
+                section for steps on how to update your build tools.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                How can you claim Poky / OpenEmbedded-Core is stable?
+            </para>
+        </question>
+        <answer>
+            <para>
+                There are three areas that help with stability;
+                <itemizedlist>
+                    <listitem><para>The Yocto Project team keeps
+                        <ulink url='&YOCTO_DOCS_DEV_URL;#oe-core'>OE-Core</ulink> small
+                        and focused, containing around 830 recipes as opposed to the thousands
+                        available in other OpenEmbedded community layers.
+                        Keeping it small makes it easy to test and maintain.</para></listitem>
+                    <listitem><para>The Yocto Project team runs manual and automated tests
+                        using a small, fixed set of reference hardware as well as emulated
+                        targets.</para></listitem>
+                    <listitem><para>The Yocto Project uses an autobuilder,
+                        which provides continuous build and integration tests.</para></listitem>
+                </itemizedlist>
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                How do I get support for my board added to the Yocto Project?
+            </para>
+        </question>
+        <answer>
+            <para>
+                Support for an additional board is added by creating a
+                Board Support Package (BSP) layer for it.
+                For more information on how to create a BSP layer, see the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
+                section in the Yocto Project Development Manual and the
+                <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
+            </para>
+            <para>
+                Usually, if the board is not completely exotic, adding support in
+                the Yocto Project is fairly straightforward.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                Are there any products built using the OpenEmbedded build system?
+            </para>
+        </question>
+        <answer>
+            <para>
+                The software running on the <ulink url='http://vernier.com/labquest/'>Vernier LabQuest</ulink>
+                is built using the OpenEmbedded build system.
+                See the <ulink url='http://www.vernier.com/products/interfaces/labq/'>Vernier LabQuest</ulink>
+                website for more information.
+                There are a number of pre-production devices using the OpenEmbedded build system
+                and the Yocto Project team
+                announces them as soon as they are released.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                What does the OpenEmbedded build system produce as output?
+            </para>
+        </question>
+        <answer>
+            <para>
+                Because you can use the same set of recipes to create output of
+                various formats, the output of an OpenEmbedded build depends on
+                how you start it.
+                Usually, the output is a flashable image ready for the target
+                device.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                How do I add my package to the Yocto Project?
+            </para>
+        </question>
+        <answer>
+            <para>
+                To add a package, you need to create a BitBake recipe.
+                For information on how to create a BitBake recipe, see the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-writing-a-new-recipe'>Writing a New Recipe</ulink>"
+                in the Yocto Project Development Manual.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                Do I have to reflash my entire board with a new Yocto Project image when recompiling
+                a package?
+            </para>
+        </question>
+        <answer>
+            <para>
+                The OpenEmbedded build system can build packages in various
+                formats such as IPK for OPKG, Debian package
+                (<filename>.deb</filename>), or RPM.
+                You can then upgrade the packages using the package tools on
+                the device, much like on a desktop distribution such as
+                Ubuntu or Fedora.
+                However, package management on the target is entirely optional.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                What is GNOME Mobile and what is the difference between GNOME Mobile and GNOME?
+            </para>
+        </question>
+        <answer>
+            <para>
+                GNOME Mobile is a subset of the <ulink url='http://www.gnome.org'>GNOME</ulink>
+                platform targeted at mobile and embedded devices.
+                The main difference between GNOME Mobile and standard GNOME is that
+                desktop-orientated libraries have been removed, along with deprecated libraries,
+                creating a much smaller footprint.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                I see the error '<filename>chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x</filename>'.
+                What is wrong?
+            </para>
+        </question>
+        <answer>
+            <para>
+                You are probably running the build on an NTFS filesystem.
+                Use <filename>ext2</filename>, <filename>ext3</filename>, or <filename>ext4</filename> instead.
+            </para>
+        </answer>
+    </qandaentry>
+
+<!--    <qandaentry>
+        <question>
+            <para>
+                How do I make the Yocto Project work in RHEL/CentOS?
+            </para>
+        </question>
+        <answer>
+            <para>
+                To get the Yocto Project working under RHEL/CentOS 5.1 you need to first
+                install some required packages.
+                The standard CentOS packages needed are:
+                <itemizedlist>
+                    <listitem><para>"Development tools" (selected during installation)</para></listitem>
+                    <listitem><para><filename>texi2html</filename></para></listitem>
+                    <listitem><para><filename>compat-gcc-34</filename></para></listitem>
+                </itemizedlist>
+                On top of these, you need the following external packages:
+                <itemizedlist>
+                    <listitem><para><filename>python-sqlite2</filename> from
+                        <ulink url='http://dag.wieers.com/rpm/packages/python-sqlite2/'>DAG repository</ulink>
+                        </para></listitem>
+                    <listitem><para><filename>help2man</filename> from
+                        <ulink url='http://centos.karan.org/el4/extras/stable/x86_64/RPMS/repodata/repoview/help2man-0-1.33.1-2.html'>Karan repository</ulink></para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                Once these packages are installed, the OpenEmbedded build system will be able
+                to build standard images.
+                However, there might be a problem with the QEMU emulator segfaulting.
+                You can either disable the generation of binary locales by setting
+                <filename><link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>ENABLE_BINARY_LOCALE_GENERATION</link>
+                </filename> to "0" or by removing the <filename>linux-2.6-execshield.patch</filename>
+                from the kernel and rebuilding it since that is the patch that causes the problems with QEMU.
+            </para>
+
+            <note>
+                <para>For information on distributions that the Yocto Project
+                uses during validation, see the
+                <ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution Support</ulink>
+                Wiki page.</para>
+                <para>For notes about using the Yocto Project on a RHEL 4-based
+                host, see the
+                <ulink url='&YOCTO_WIKI_URL;/wiki/BuildingOnRHEL4'>Building on RHEL4</ulink>
+                Wiki page.</para>
+            </note>
+        </answer>
+    </qandaentry> -->
+
+    <qandaentry>
+        <question>
+            <para>
+                I see lots of 404 responses for files on
+                <filename>&YOCTO_HOME_URL;/sources/*</filename>. Is something wrong?
+            </para>
+        </question>
+        <answer>
+            <para>
+                Nothing is wrong.
+                The OpenEmbedded build system checks any configured source mirrors before downloading
+                from the upstream sources.
+                The build system does this searching for both source archives and
+                pre-checked out versions of SCM-managed software.
+                These checks help in large installations because it can reduce load on the SCM servers
+                themselves.
+                The address above is one of the default mirrors configured into the
+                build system.
+                Consequently, if an upstream source disappears, the team
+                can place sources there so builds continue to work.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                I have machine-specific data in a package for one machine only but the package is
+                being marked as machine-specific in all cases, how do I prevent this?
+            </para>
+        </question>
+        <answer>
+            <para>
+                Set <filename><link linkend='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'>SRC_URI_OVERRIDES_PACKAGE_ARCH</link>
+                </filename> = "0" in the <filename>.bb</filename> file but make sure the package is
+                manually marked as
+                machine-specific for the case that needs it.
+                The code that handles
+                <filename>SRC_URI_OVERRIDES_PACKAGE_ARCH</filename> is in
+                the <filename>meta/classes/base.bbclass</filename> file.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                I'm behind a firewall and need to use a proxy server. How do I do that?
+            </para>
+        </question>
+        <answer>
+            <para>
+                Most source fetching by the OpenEmbedded build system is done by <filename>wget</filename>
+                and you therefore need to specify the proxy settings in a
+                <filename>.wgetrc</filename> file in your home directory.
+                Here are some example settings:
+                <literallayout class='monospaced'>
+     http_proxy = http://proxy.yoyodyne.com:18023/
+     ftp_proxy = http://proxy.yoyodyne.com:18023/
+                </literallayout>
+                The Yocto Project also includes a
+                <filename>site.conf.sample</filename> file that shows how to
+                configure CVS and Git proxy servers if needed.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                What’s the difference between <replaceable>target</replaceable> and <replaceable>target</replaceable><filename>-native</filename>?
+            </para>
+        </question>
+        <answer>
+            <para>
+                The <filename>*-native</filename> targets are designed to run on the system
+                being used for the build.
+                These are usually tools that are needed to assist the build in some way such as
+                <filename>quilt-native</filename>, which is used to apply patches.
+                The non-native version is the one that runs on the target device.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                I'm seeing random build failures. Help?!
+            </para>
+        </question>
+        <answer>
+            <para>
+                If the same build is failing in totally different and random
+                ways, the most likely explanation is:
+                <itemizedlist>
+                    <listitem><para>The hardware you are running the build on
+                        has some problem.</para></listitem>
+                    <listitem><para>You are running the build under
+                        virtualization, in which case the virtualization
+                        probably has bugs.</para></listitem>
+                </itemizedlist>
+                The OpenEmbedded build system processes a massive amount of
+                data that causes lots of network, disk and CPU activity and
+                is sensitive to even single-bit failures in any of these areas.
+                True random failures have always been traced back to hardware
+                or virtualization issues.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                What do we need to ship for license compliance?
+            </para>
+        </question>
+        <answer>
+            <para>
+                This is a difficult question and you need to consult your lawyer
+                for the answer for your specific case.
+                It is worth bearing in mind that for GPL compliance, there needs
+                to be enough information shipped to allow someone else to
+                rebuild and produce the same end result you are shipping.
+                This means sharing the source code, any patches applied to it,
+                and also any configuration information about how that package
+                was configured and built.
+            </para>
+
+            <para>
+                You can find more information on licensing in the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#licensing'>Licensing</ulink>"
+                and "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
+                sections, both of which are in the Yocto Project Development
+                Manual.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                How do I disable the cursor on my touchscreen device?
+            </para>
+        </question>
+        <answer>
+            <para>
+                You need to create a form factor file as described in the
+                "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous BSP-Specific Recipe Files</ulink>"
+                section in the Yocto Project Board Support Packages (BSP)
+                Developer's Guide.
+                Set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to
+                one as follows:
+                <literallayout class='monospaced'>
+     HAVE_TOUCHSCREEN=1
+                </literallayout>
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                How do I make sure connected network interfaces are brought up by default?
+            </para>
+        </question>
+        <answer>
+            <para>
+                The default interfaces file provided by the netbase recipe does not
+                automatically bring up network interfaces.
+                Therefore, you will need to add a BSP-specific netbase that includes an interfaces
+                file.
+                See the "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous BSP-Specific Recipe Files</ulink>"
+                section in the Yocto Project Board Support Packages (BSP)
+                Developer's Guide for information on creating these types of
+                miscellaneous recipe files.
+            </para>
+            <para>
+                For example, add the following files to your layer:
+                <literallayout class='monospaced'>
+     meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces
+     meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend
+                </literallayout>
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                How do I create images with more free space?
+            </para>
+        </question>
+        <answer>
+            <para>
+                By default, the OpenEmbedded build system creates images
+                that are 1.3 times the size of the populated root filesystem.
+                To affect the image size, you need to set various
+                configurations:
+                <itemizedlist>
+                    <listitem><para><emphasis>Image Size:</emphasis>
+                        The OpenEmbedded build system uses the
+                        <link linkend='var-IMAGE_ROOTFS_SIZE'><filename>IMAGE_ROOTFS_SIZE</filename></link>
+                        variable to define the size of the image in Kbytes.
+                        The build system determines the size by taking into
+                        account the initial root filesystem size before any
+                        modifications such as requested size for the image and
+                        any requested additional free disk space to be
+                        added to the image.</para></listitem>
+                    <listitem><para><emphasis>Overhead:</emphasis>
+                        Use the
+                        <link linkend='var-IMAGE_OVERHEAD_FACTOR'><filename>IMAGE_OVERHEAD_FACTOR</filename></link>
+                        variable to define the multiplier that the build system
+                        applies to the initial image size, which is 1.3 by
+                        default.</para></listitem>
+                    <listitem><para><emphasis>Additional Free Space:</emphasis>
+                        Use the
+                        <link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'><filename>IMAGE_ROOTFS_EXTRA_SPACE</filename></link>
+                        variable to add additional free space to the image.
+                        The build system adds this space to the image after
+                        it determines its
+                        <filename>IMAGE_ROOTFS_SIZE</filename>.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                Why don't you support directories with spaces in the pathnames?
+            </para>
+        </question>
+        <answer>
+            <para>
+                The Yocto Project team has tried to do this before but too
+                many of the tools the OpenEmbedded build system depends on,
+                such as <filename>autoconf</filename>, break when they find
+                spaces in pathnames.
+                Until that situation changes, the team will not support spaces
+                in pathnames.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                How do I use an external toolchain?
+            </para>
+        </question>
+        <answer>
+            <para>
+                The toolchain configuration is very flexible and customizable.
+                It is primarily controlled with the
+                <filename><link linkend='var-TCMODE'>TCMODE</link></filename>
+                variable.
+                This variable controls which <filename>tcmode-*.inc</filename>
+                file to include from the
+                <filename>meta/conf/distro/include</filename> directory within
+                the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            </para>
+
+            <para>
+                The default value of <filename>TCMODE</filename> is "default",
+                which tells the OpenEmbedded build system to use its internally
+                built toolchain (i.e. <filename>tcmode-default.inc</filename>).
+                However, other patterns are accepted.
+                In particular, "external-*" refers to external toolchains.
+                One example is the Sourcery G++ Toolchain.
+                The support for this toolchain resides in the separate
+                <filename>meta-sourcery</filename> layer at
+                <ulink url='http://github.com/MentorEmbedded/meta-sourcery/'></ulink>.
+            </para>
+
+            <para>
+                In addition to the toolchain configuration, you also need a
+                corresponding toolchain recipe file.
+                This recipe file needs to package up any pre-built objects in
+                the toolchain such as <filename>libgcc</filename>,
+                <filename>libstdcc++</filename>, any locales, and
+                <filename>libc</filename>.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para id='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>
+                How does the OpenEmbedded build system obtain source code and
+                will it work behind my firewall or proxy server?
+            </para>
+        </question>
+        <answer>
+            <para>
+                The way the build system obtains source code is highly
+                configurable.
+                You can setup the build system to get source code in most
+                environments if HTTP transport is available.
+            </para>
+            <para>
+                When the build system searches for source code, it first
+                tries the local download directory.
+                If that location fails, Poky tries
+                <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>,
+                the upstream source, and then
+                <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
+                in that order.
+            </para>
+            <para>
+                Assuming your distribution is "poky", the OpenEmbedded build
+                system uses the Yocto Project source
+                <filename>PREMIRRORS</filename> by default for SCM-based
+                sources, upstreams for normal tarballs, and then falls back
+                to a number of other mirrors including the Yocto Project
+                source mirror if those fail.
+            </para>
+            <para>
+                As an example, you could add a specific server for the
+                build system to attempt before any others by adding something
+                like the following to the <filename>local.conf</filename>
+                configuration file:
+                <literallayout class='monospaced'>
+     PREMIRRORS_prepend = "\
+     git://.*/.* http://www.yoctoproject.org/sources/ \n \
+     ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
+     http://.*/.* http://www.yoctoproject.org/sources/ \n \
+     https://.*/.* http://www.yoctoproject.org/sources/ \n"
+                </literallayout>
+            </para>
+            <para>
+                These changes cause the build system to intercept Git, FTP,
+                HTTP, and HTTPS requests and direct them to the
+                <filename>http://</filename> sources mirror.
+                You can use <filename>file://</filename> URLs to point to
+                local directories or network shares as well.
+            </para>
+            <para>
+                Aside from the previous technique, these options also exist:
+                <literallayout class='monospaced'>
+     BB_NO_NETWORK = "1"
+                </literallayout>
+                This statement tells BitBake to issue an error instead of
+                trying to access the Internet.
+                This technique is useful if you want to ensure code builds
+                only from local sources.
+            </para>
+            <para>
+                Here is another technique:
+                <literallayout class='monospaced'>
+     BB_FETCH_PREMIRRORONLY = "1"
+                </literallayout>
+                This statement limits the build system to pulling source
+                from the <filename>PREMIRRORS</filename> only.
+                Again, this technique is useful for reproducing builds.
+            </para>
+            <para>
+                Here is another technique:
+                <literallayout class='monospaced'>
+     BB_GENERATE_MIRROR_TARBALLS = "1"
+                </literallayout>
+                This statement tells the build system to generate mirror
+                tarballs.
+                This technique is useful if you want to create a mirror server.
+                If not, however, the technique can simply waste time during
+                the build.
+            </para>
+            <para>
+                Finally, consider an example where you are behind an
+                HTTP-only firewall.
+                You could make the following changes to the
+                <filename>local.conf</filename> configuration file as long as
+                the <filename>PREMIRRORS</filename> server is current:
+                <literallayout class='monospaced'>
+     PREMIRRORS_prepend = "\
+     ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
+     http://.*/.* http://www.yoctoproject.org/sources/ \n \
+     https://.*/.* http://www.yoctoproject.org/sources/ \n"
+     BB_FETCH_PREMIRRORONLY = "1"
+                </literallayout>
+                These changes would cause the build system to successfully
+                fetch source over HTTP and any network accesses to anything
+                other than the <filename>PREMIRRORS</filename> would fail.
+            </para>
+            <para>
+                The build system also honors the standard shell environment
+                variables <filename>http_proxy</filename>,
+                <filename>ftp_proxy</filename>,
+                <filename>https_proxy</filename>, and
+                <filename>all_proxy</filename> to redirect requests through
+                proxy servers.
+            </para>
+            <note>
+                 You can find more information on the
+                 "<ulink url='&YOCTO_WIKI_URL;/wiki/Working_Behind_a_Network_Proxy'>Working Behind a Network Proxy</ulink>"
+                 Wiki page.
+            </note>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                Can I get rid of build output so I can start over?
+            </para>
+        </question>
+        <answer>
+            <para>
+                Yes - you can easily do this.
+                When you use BitBake to build an image, all the build output
+                goes into the directory created when you run the
+                build environment setup script (i.e.
+                <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+                or
+                <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
+                By default, this <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                is named <filename>build</filename> but can be named
+                anything you want.
+            </para>
+
+            <para>
+                Within the Build Directory, is the <filename>tmp</filename>
+                directory.
+                To remove all the build output yet preserve any source code or
+                downloaded files from previous builds, simply remove the
+                <filename>tmp</filename> directory.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                Why do <filename>${bindir}</filename> and <filename>${libdir}</filename> have strange values for <filename>-native</filename> recipes?
+            </para>
+        </question>
+        <answer>
+            <para>
+                Executables and libraries might need to be used from a
+                directory other than the directory into which they were
+                initially installed.
+                Complicating this situation is the fact that sometimes these
+                executables and libraries are compiled with the expectation
+                of being run from that initial installation target directory.
+                If this is the case, moving them causes problems.
+            </para>
+
+            <para>
+                This scenario is a fundamental problem for package maintainers
+                of mainstream Linux distributions as well as for the
+                OpenEmbedded build system.
+                As such, a well-established solution exists.
+                Makefiles, Autotools configuration scripts, and other build
+                systems are expected to respect environment variables such as
+                <filename>bindir</filename>, <filename>libdir</filename>,
+                and <filename>sysconfdir</filename> that indicate where
+                executables, libraries, and data reside when a program is
+                actually run.
+                They are also expected to respect a
+                <filename>DESTDIR</filename> environment variable, which is
+                prepended to all the other variables when the build system
+                actually installs the files.
+                It is understood that the program does not actually run from
+                within <filename>DESTDIR</filename>.
+            </para>
+
+            <para>
+                When the OpenEmbedded build system uses a recipe to build a
+                target-architecture program (i.e. one that is intended for
+                inclusion on the image being built), that program eventually
+                runs from the root file system of that image.
+                Thus, the build system provides a value of "/usr/bin" for
+                <filename>bindir</filename>, a value of "/usr/lib" for
+                <filename>libdir</filename>, and so forth.
+            </para>
+
+            <para>
+                Meanwhile, <filename>DESTDIR</filename> is a path within the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                However, when the recipe builds a native program (i.e. one
+                that is intended to run on the build machine), that program
+                is never installed directly to the build machine's root
+                file system.
+                Consequently, the build system uses paths within the Build
+                Directory for <filename>DESTDIR</filename>,
+                <filename>bindir</filename> and related variables.
+                To better understand this, consider the following two paths
+                where the first is relatively normal and the second is not:
+                <note>
+                    Due to these lengthy examples, the paths are artificially
+                    broken across lines for readability.
+                </note>
+                <literallayout class='monospaced'>
+     /home/maxtothemax/poky-bootchart2/build/tmp/work/i586-poky-linux/zlib/
+        1.2.8-r0/sysroot-destdir/usr/bin
+
+     /home/maxtothemax/poky-bootchart2/build/tmp/work/x86_64-linux/
+        zlib-native/1.2.8-r0/sysroot-destdir/home/maxtothemax/poky-bootchart2/
+        build/tmp/sysroots/x86_64-linux/usr/bin
+                </literallayout>
+                Even if the paths look unusual, they both are correct -
+                the first for a target and the second for a native recipe.
+                These paths are a consequence of the
+                <filename>DESTDIR</filename> mechanism and while they
+                appear strange, they are correct and in practice very effective.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                The files provided by my <filename>-native</filename> recipe do
+                not appear to be available to other recipes.
+                Files are missing from the native sysroot, my recipe is
+                installing to the wrong place, or I am getting permissions
+                errors during the do_install task in my recipe! What is wrong?
+            </para>
+        </question>
+        <answer>
+            <para>
+                This situation results when a build system does
+                not recognize the environment variables supplied to it by
+                <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>.
+                The incident that prompted this FAQ entry involved a Makefile
+                that used an environment variable named
+                <filename>BINDIR</filename> instead of the more standard
+                variable <filename>bindir</filename>.
+                The makefile's hardcoded default value of "/usr/bin" worked
+                most of the time, but not for the recipe's
+                <filename>-native</filename> variant.
+                For another example, permissions errors might be caused
+                by a Makefile that ignores <filename>DESTDIR</filename> or uses
+                a different name for that environment variable.
+                Check the the build system to see if these kinds of
+                issues exist.
+            </para>
+        </answer>
+    </qandaentry>
+
+</qandaset>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/figures/analysis-for-package-splitting.png b/documentation/ref-manual/figures/analysis-for-package-splitting.png
new file mode 100644
index 0000000000..04f2794ea9
--- /dev/null
+++ b/documentation/ref-manual/figures/analysis-for-package-splitting.png
diff --git a/documentation/ref-manual/figures/buildhistory-web.png b/documentation/ref-manual/figures/buildhistory-web.png
new file mode 100644
index 0000000000..f6db86c977
--- /dev/null
+++ b/documentation/ref-manual/figures/buildhistory-web.png
diff --git a/documentation/ref-manual/figures/buildhistory.png b/documentation/ref-manual/figures/buildhistory.png
new file mode 100644
index 0000000000..9a77bde68b
--- /dev/null
+++ b/documentation/ref-manual/figures/buildhistory.png
diff --git a/documentation/ref-manual/figures/configuration-compile-autoreconf.png b/documentation/ref-manual/figures/configuration-compile-autoreconf.png
new file mode 100644
index 0000000000..a07464f04c
--- /dev/null
+++ b/documentation/ref-manual/figures/configuration-compile-autoreconf.png
diff --git a/documentation/ref-manual/figures/cross-development-toolchains.png b/documentation/ref-manual/figures/cross-development-toolchains.png
new file mode 100644
index 0000000000..d36670a198
--- /dev/null
+++ b/documentation/ref-manual/figures/cross-development-toolchains.png
diff --git a/documentation/ref-manual/figures/image-generation.png b/documentation/ref-manual/figures/image-generation.png
new file mode 100644
index 0000000000..ab962580c3
--- /dev/null
+++ b/documentation/ref-manual/figures/image-generation.png
diff --git a/documentation/ref-manual/figures/images.png b/documentation/ref-manual/figures/images.png
new file mode 100644
index 0000000000..d99eac1fbf
--- /dev/null
+++ b/documentation/ref-manual/figures/images.png
diff --git a/documentation/ref-manual/figures/layer-input.png b/documentation/ref-manual/figures/layer-input.png
new file mode 100644
index 0000000000..0a4f2e74f3
--- /dev/null
+++ b/documentation/ref-manual/figures/layer-input.png
diff --git a/documentation/ref-manual/figures/package-feeds.png b/documentation/ref-manual/figures/package-feeds.png
new file mode 100644
index 0000000000..4bc311f3d6
--- /dev/null
+++ b/documentation/ref-manual/figures/package-feeds.png
diff --git a/documentation/ref-manual/figures/patching.png b/documentation/ref-manual/figures/patching.png
new file mode 100644
index 0000000000..8ecd018502
--- /dev/null
+++ b/documentation/ref-manual/figures/patching.png
diff --git a/documentation/ref-manual/figures/poky-title.png b/documentation/ref-manual/figures/poky-title.png
new file mode 100644
index 0000000000..2893d84620
--- /dev/null
+++ b/documentation/ref-manual/figures/poky-title.png
diff --git a/documentation/ref-manual/figures/sdk-generation.png b/documentation/ref-manual/figures/sdk-generation.png
new file mode 100644
index 0000000000..c37e2748ca
--- /dev/null
+++ b/documentation/ref-manual/figures/sdk-generation.png
diff --git a/documentation/ref-manual/figures/sdk.png b/documentation/ref-manual/figures/sdk.png
new file mode 100644
index 0000000000..a539cc52f0
--- /dev/null
+++ b/documentation/ref-manual/figures/sdk.png
diff --git a/documentation/ref-manual/figures/source-fetching.png b/documentation/ref-manual/figures/source-fetching.png
new file mode 100644
index 0000000000..26aefb50c2
--- /dev/null
+++ b/documentation/ref-manual/figures/source-fetching.png
diff --git a/documentation/ref-manual/figures/source-input.png b/documentation/ref-manual/figures/source-input.png
new file mode 100644
index 0000000000..f7515058ef
--- /dev/null
+++ b/documentation/ref-manual/figures/source-input.png
diff --git a/documentation/ref-manual/figures/user-configuration.png b/documentation/ref-manual/figures/user-configuration.png
new file mode 100644
index 0000000000..f2b3f8e7fe
--- /dev/null
+++ b/documentation/ref-manual/figures/user-configuration.png
diff --git a/documentation/ref-manual/figures/yocto-environment-ref.png b/documentation/ref-manual/figures/yocto-environment-ref.png
new file mode 100644
index 0000000000..650c6c8030
--- /dev/null
+++ b/documentation/ref-manual/figures/yocto-environment-ref.png
diff --git a/documentation/ref-manual/introduction.xml b/documentation/ref-manual/introduction.xml
new file mode 100644
index 0000000000..19e9895ee6
--- /dev/null
+++ b/documentation/ref-manual/introduction.xml
@@ -0,0 +1,572 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='intro'>
+<title>Introduction</title>
+
+<section id='intro-welcome'>
+    <title>Introduction</title>
+
+    <para>
+        This manual provides reference information for the current release of the Yocto Project.
+        The Yocto Project is an open-source collaboration project focused on embedded Linux
+        developers.
+        Amongst other things, the Yocto Project uses the OpenEmbedded build system, which
+        is based on the Poky project, to construct complete Linux images.
+        You can find complete introductory and getting started information on the Yocto Project
+        by reading the
+        <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>.
+        For task-based information using the Yocto Project, see the
+        <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Manual</ulink>
+        and the <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>.
+        For Board Support Package (BSP) structure information, see the
+        <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
+        You can find information on tracing and profiling in the
+        <ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual'>Yocto Project Profiling and Tracing Manual</ulink>.
+        For information on BitBake, which is the task execution tool the
+        OpenEmbedded build system is based on, see the
+        <ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual'>BitBake User Manual</ulink>.
+        Finally, you can also find lots of Yocto Project information on the
+        <ulink url="&YOCTO_HOME_URL;">Yocto Project website</ulink>.
+    </para>
+</section>
+
+<section id='intro-manualoverview'>
+    <title>Documentation Overview</title>
+    <para>
+        This reference manual consists of the following:
+        <itemizedlist>
+            <listitem><para><emphasis>
+                <link linkend='usingpoky'>Using the Yocto Project</link>:</emphasis>
+                Provides an overview of the components that make up the Yocto Project
+                followed by information about debugging images created in the Yocto Project.
+                </para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='closer-look'>A Closer Look at the Yocto Project Development Environment</link>:</emphasis>
+                Provides a more detailed look at the Yocto Project development
+                environment within the context of development.
+                </para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='technical-details'>Technical Details</link>:</emphasis>
+                Describes fundamental Yocto Project components as well as an explanation
+                behind how the Yocto Project uses shared state (sstate) cache to speed build time.
+                </para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='migration'>Migrating to a Newer Yocto Project Release</link>:</emphasis>
+                Describes release-specific information that helps you move from
+                one Yocto Project Release to another.
+                </para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='ref-structure'>Directory Structure</link>:</emphasis>
+                Describes the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> created
+                either by unpacking a released Yocto Project tarball on your host development system,
+                or by cloning the upstream
+                <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> Git repository.
+                </para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='ref-classes'>Classes</link>:</emphasis>
+                Describes the classes used in the Yocto Project.</para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='ref-tasks'>Tasks</link>:</emphasis>
+                Describes the tasks defined by the OpenEmbedded build system.
+                </para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='ref-qa-checks'>QA Error and Warning Messages</link>:</emphasis>
+                Lists and describes QA warning and error messages.
+                </para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='ref-images'>Images</link>:</emphasis>
+                Describes the standard images that the Yocto Project supports.
+                </para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='ref-features'>Features</link>:</emphasis>
+                Describes mechanisms for creating distribution, machine, and image
+                features during the build process using the OpenEmbedded build system.</para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='ref-variables-glos'>Variables Glossary</link>:</emphasis>
+                Presents most variables used by the OpenEmbedded build system, which
+                uses BitBake.
+                Entries describe the function of the variable and how to apply them.
+                </para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='ref-varlocality'>Variable Context</link>:</emphasis>
+                Provides variable locality or context.</para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='faq'>FAQ</link>:</emphasis>
+                Provides answers for commonly asked questions in the Yocto Project
+                development environment.</para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='resources'>Contributing to the Yocto Project</link>:</emphasis>
+                Provides guidance on how you can contribute back to the Yocto
+                Project.</para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+
+<section id='intro-requirements'>
+<title>System Requirements</title>
+    <para>
+        For general Yocto Project system requirements, see the
+        "<ulink url='&YOCTO_DOCS_QS_URL;#yp-resources'>What You Need and How You Get It</ulink>" section
+        in the Yocto Project Quick Start.
+        The remainder of this section provides details on system requirements
+        not covered in the Yocto Project Quick Start.
+    </para>
+
+    <section id='detailed-supported-distros'>
+        <title>Supported Linux Distributions</title>
+
+        <para>
+            Currently, the Yocto Project is supported on the following
+            distributions:
+            <note>
+                <para>
+                    Yocto Project releases are tested against the stable Linux
+                    distributions in the following list.
+                    The Yocto Project should work on other distributions but
+                    validation is not performed against them.
+                </para>
+
+                <para>
+                    In particular, the Yocto Project does not support
+                    and currently has no plans to support
+                    rolling-releases or development distributions due to their
+                    constantly changing nature.
+                    We welcome patches and bug reports, but keep in mind that
+                    our priority is on the supported platforms listed below.
+                </para>
+
+                <para>
+                    If you encounter problems, please go to
+                    <ulink url='&YOCTO_BUGZILLA_URL;'>Yocto Project Bugzilla</ulink>
+                    and submit a bug.
+                    We are interested in hearing about your experience.
+                </para>
+            </note>
+            <itemizedlist>
+<!--                <listitem><para>Ubuntu 10.04</para></listitem>
+                <listitem><para>Ubuntu 11.10</para></listitem> -->
+                <listitem><para>Ubuntu 12.04 (LTS)</para></listitem>
+                <listitem><para>Ubuntu 13.10</para></listitem>
+                <listitem><para>Ubuntu 14.04 (LTS)</para></listitem>
+<!--                <listitem><para>Fedora 16 (Verne)</para></listitem>
+                <listitem><para>Fedora 17 (Spherical)</para></listitem> -->
+                <listitem><para>Fedora release 19 (Schrödinger's Cat)</para></listitem>
+                <listitem><para>Fedora release 20 (Heisenbug)</para></listitem>
+<!--                <listitem><para>CentOS release 5.6 (Final)</para></listitem>
+                <listitem><para>CentOS release 5.7 (Final)</para></listitem>
+                <listitem><para>CentOS release 5.8 (Final)</para></listitem>
+                <listitem><para>CentOS release 6.3 (Final)</para></listitem> -->
+                <listitem><para>CentOS release 6.4</para></listitem>
+                <listitem><para>CentOS release 6.5</para></listitem>
+<!--                <listitem><para>Debian GNU/Linux 6.0 (Squeeze)</para></listitem> -->
+                <listitem><para>Debian GNU/Linux 7.0 (Wheezy)</para></listitem>
+                <listitem><para>Debian GNU/Linux 7.1 (Wheezy)</para></listitem>
+                <listitem><para>Debian GNU/Linux 7.2 (Wheezy)</para></listitem>
+                <listitem><para>Debian GNU/Linux 7.3 (Wheezy)</para></listitem>
+                <listitem><para>Debian GNU/Linux 7.4 (Wheezy)</para></listitem>
+                <listitem><para>Debian GNU/Linux 7.5 (Wheezy)</para></listitem>
+                <listitem><para>Debian GNU/Linux 7.6 (Wheezy)</para></listitem>
+<!--                <listitem><para>openSUSE 11.4</para></listitem>
+                <listitem><para>openSUSE 12.1</para></listitem> -->
+                <listitem><para>openSUSE 12.2</para></listitem>
+                <listitem><para>openSUSE 12.3</para></listitem>
+                <listitem><para>openSUSE 13.1</para></listitem>
+            </itemizedlist>
+        </para>
+
+        <note>
+            While the Yocto Project Team attempts to ensure all Yocto Project
+            releases are one hundred percent compatible with each officially
+            supported Linux distribution, instances might exist where you
+            encounter a problem while using the Yocto Project on a specific
+            distribution.
+            For example, the CentOS 6.4 distribution does not include the
+            Gtk+ 2.20.0 and PyGtk 2.21.0 (or higher) packages, which are
+            required to run
+            <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink>.
+        </note>
+    </section>
+
+    <section id='required-packages-for-the-host-development-system'>
+    <title>Required Packages for the Host Development System</title>
+
+        <para>
+            The list of packages you need on the host development system can
+            be large when covering all build scenarios using the Yocto Project.
+            This section provides required packages according to
+            Linux distribution and function.
+        </para>
+
+        <section id='ubuntu-packages'>
+            <title>Ubuntu and Debian</title>
+
+            <para>
+                The following list shows the required packages by function
+                given a supported Ubuntu or Debian Linux distribution:
+                <itemizedlist>
+                    <listitem><para><emphasis>Essentials:</emphasis>
+                        Packages needed to build an image on a headless
+                        system:
+                        <literallayout class='monospaced'>
+     $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL;
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Graphical and Eclipse Plug-In Extras:</emphasis>
+                        Packages recommended if the host system has graphics
+                        support or if you are going to use the Eclipse
+                        IDE:
+                        <literallayout class='monospaced'>
+     $ sudo apt-get install libsdl1.2-dev xterm
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Documentation:</emphasis>
+                        Packages needed if you are going to build out the
+                        Yocto Project documentation manuals:
+                        <literallayout class='monospaced'>
+     $ sudo apt-get install make xsltproc docbook-utils fop dblatex xmlto
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                        Packages needed if you are going to be using the
+                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        <literallayout class='monospaced'>
+     $ sudo apt-get install autoconf automake libtool libglib2.0-dev
+                        </literallayout></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='fedora-packages'>
+            <title>Fedora Packages</title>
+
+            <para>
+                The following list shows the required packages by function
+                given a supported Fedora Linux distribution:
+                <itemizedlist>
+                    <listitem><para><emphasis>Essentials:</emphasis>
+                        Packages needed to build an image for a headless
+                        system:
+                        <literallayout class='monospaced'>
+     $ sudo yum install &FEDORA_HOST_PACKAGES_ESSENTIAL;
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Graphical and Eclipse Plug-In Extras:</emphasis>
+                        Packages recommended if the host system has graphics
+                        support or if you are going to use the Eclipse
+                        IDE:
+                        <literallayout class='monospaced'>
+     $ sudo yum install SDL-devel xterm perl-Thread-Queue
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Documentation:</emphasis>
+                        Packages needed if you are going to build out the
+                        Yocto Project documentation manuals:
+                        <literallayout class='monospaced'>
+     $ sudo yum install make docbook-style-dsssl docbook-style-xsl \
+     docbook-dtds docbook-utils fop libxslt dblatex xmlto
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                        Packages needed if you are going to be using the
+                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        <literallayout class='monospaced'>
+     $ sudo yum install autoconf automake libtool glib2-devel
+                        </literallayout></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='opensuse-packages'>
+            <title>openSUSE Packages</title>
+
+            <para>
+                The following list shows the required packages by function
+                given a supported openSUSE Linux distribution:
+                <itemizedlist>
+                    <listitem><para><emphasis>Essentials:</emphasis>
+                        Packages needed to build an image for a headless
+                        system:
+                        <literallayout class='monospaced'>
+     $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL;
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Graphical and Eclipse Plug-In Extras:</emphasis>
+                        Packages recommended if the host system has graphics
+                        support or if you are going to use the Eclipse
+                        IDE:
+                        <literallayout class='monospaced'>
+     $ sudo zypper install libSDL-devel xterm
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Documentation:</emphasis>
+                        Packages needed if you are going to build out the
+                        Yocto Project documentation manuals:
+                        <literallayout class='monospaced'>
+     $ sudo zypper install make fop xsltproc dblatex xmlto
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                        Packages needed if you are going to be using the
+                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        <literallayout class='monospaced'>
+     $ sudo zypper install autoconf automake libtool glib2-devel
+                        </literallayout></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='centos-packages'>
+            <title>CentOS Packages</title>
+
+            <para>
+                The following list shows the required packages by function
+                given a supported CentOS Linux distribution:
+                <note>
+                    For CentOS 6.x, some of the versions of the components
+                    provided by the distribution are too old (e.g. Git, Python,
+                    and tar).
+                    It is recommended that you install the buildtools in order
+                    to provide versions that will work with the OpenEmbedded
+                    build system.
+                    For information on how to install the buildtools tarball,
+                    see the
+                    "<link linkend='required-git-tar-and-python-versions'>Required Git, Tar, and Python Versions</link>"
+                    section.
+                </note>
+                <itemizedlist>
+                    <listitem><para><emphasis>Essentials:</emphasis>
+                        Packages needed to build an image for a headless
+                        system:
+                        <literallayout class='monospaced'>
+     $ sudo yum install &CENTOS_HOST_PACKAGES_ESSENTIAL;
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Graphical and Eclipse Plug-In Extras:</emphasis>
+                        Packages recommended if the host system has graphics
+                        support or if you are going to use the Eclipse
+                        IDE:
+                        <literallayout class='monospaced'>
+     $ sudo yum install SDL-devel xterm
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Documentation:</emphasis>
+                        Packages needed if you are going to build out the
+                        Yocto Project documentation manuals:
+                        <literallayout class='monospaced'>
+     $ sudo yum install make docbook-style-dsssl docbook-style-xsl \
+     docbook-dtds docbook-utils fop libxslt dblatex xmlto
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                        Packages needed if you are going to be using the
+                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        <literallayout class='monospaced'>
+     $ sudo yum install autoconf automake libtool glib2-devel
+                        </literallayout></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+    </section>
+
+    <section id='required-git-tar-and-python-versions'>
+        <title>Required Git, tar, and Python Versions</title>
+
+        <para>
+            In order to use the build system, your host development system
+            must meet the following version requirements for Git, tar, and
+            Python:
+            <itemizedlist>
+                <listitem><para>Git 1.7.8 or greater</para></listitem>
+                <listitem><para>tar 1.24 or greater</para></listitem>
+                <listitem><para>Python 2.7.3 or greater not including
+                    Python 3.x, which is not supported.</para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            If your host development system does not meet all these requirements,
+            you can resolve this by installing a <filename>buildtools</filename>
+            tarball that contains these tools.
+            You can get the tarball one of two ways: download a pre-built
+            tarball or use BitBake to build the tarball.
+        </para>
+
+        <section id='downloading-a-pre-built-buildtools-tarball'>
+            <title>Downloading a Pre-Built <filename>buildtools</filename> Tarball</title>
+
+            <para>
+                Downloading and running a pre-built buildtools installer is
+                the easiest of the two methods by which you can get these tools:
+                <orderedlist>
+                    <listitem><para>
+                        Locate and download the <filename>*.sh</filename> at
+                        <ulink url='&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;/buildtools/'></ulink>.
+                        </para></listitem>
+                    <listitem><para>
+                        Execute the installation script.
+                        Here is an example:
+                        <literallayout class='monospaced'>
+     $ sh poky-glibc-x86_64-buildtools-tarball-x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
+                        </literallayout>
+                        During execution, a prompt appears that allows you to
+                        choose the installation directory.
+                        For example, you could choose the following:
+                        <literallayout class='monospaced'>
+     /home/<replaceable>your-username</replaceable>/buildtools
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para>
+                        Source the tools environment setup script by using a
+                        command like the following:
+                        <literallayout class='monospaced'>
+     $ source /home/<replaceable>your-username</replaceable>/buildtools/environment-setup-i586-poky-linux
+                        </literallayout>
+                        Of course, you need to supply your installation directory and be
+                        sure to use the right file (i.e. i585 or x86-64).
+                        </para>
+                        <para>
+                        After you have sourced the setup script,
+                        the tools are added to <filename>PATH</filename>
+                        and any other environment variables required to run the
+                        tools are initialized.
+                        The results are working versions versions of Git, tar,
+                        Python and <filename>chrpath</filename>.
+                        </para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+
+        <section id='building-your-own-buildtools-tarball'>
+            <title>Building Your Own <filename>buildtools</filename> Tarball</title>
+
+            <para>
+                Building and running your own buildtools installer applies
+                only when you have a build host that can already run BitBake.
+                In this case, you use that machine to build the
+                <filename>.sh</filename> file and then
+                take steps to transfer and run it on a
+                machine that does not meet the minimal Git, tar, and Python
+                requirements.
+            </para>
+
+            <para>
+                Here are the steps to take to build and run your own
+                buildtools installer:
+                <orderedlist>
+                    <listitem><para>
+                        On the machine that is able to run BitBake,
+                        be sure you have set up your build environment with
+                        the setup script
+                        (<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+                        or
+                        <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
+                        </para></listitem>
+                    <listitem><para>
+                        Run the BitBake command to build the tarball:
+                        <literallayout class='monospaced'>
+     $ bitbake buildtools-tarball
+                        </literallayout>
+                        <note>
+                        The
+                        <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>
+                        variable in your <filename>local.conf</filename> file
+                        determines whether you build tools for a 32-bit
+                        or 64-bit system.
+                       </note>
+                       Once the build completes, you can find the
+                       <filename>.sh</filename> file that installs
+                       the tools in the <filename>tmp/deploy/sdk</filename>
+                       subdirectory of the
+                       <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                       The installer file has the string "buildtools"
+                       in the name.
+                       </para></listitem>
+                   <listitem><para>
+                       Transfer the <filename>.sh</filename> file from the
+                       build host to the machine that does not meet the
+                       Git, tar, or Python requirements.
+                       </para></listitem>
+                   <listitem><para>
+                       On the machine that does not meet the requirements,
+                       run the <filename>.sh</filename> file
+                       to install the tools.
+                       Here is an example:
+                       <literallayout class='monospaced'>
+     $ sh poky-glibc-x86_64-buildtools-tarball-x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
+                       </literallayout>
+                       During execution, a prompt appears that allows you to
+                       choose the installation directory.
+                       For example, you could choose the following:
+                       <literallayout class='monospaced'>
+     /home/<replaceable>your-username</replaceable>/buildtools
+                       </literallayout>
+                       </para></listitem>
+                    <listitem><para>
+                        Source the tools environment setup script by using a
+                        command like the following:
+                        <literallayout class='monospaced'>
+     $ source /home/<replaceable>your-username</replaceable>/buildtools/environment-setup-i586-poky-linux
+                        </literallayout>
+                        Of course, you need to supply your installation directory and be
+                        sure to use the right file (i.e. i585 or x86-64).
+                        </para>
+                        <para>
+                        After you have sourced the setup script,
+                        the tools are added to <filename>PATH</filename>
+                        and any other environment variables required to run the
+                        tools are initialized.
+                        The results are working versions versions of Git, tar,
+                        Python and <filename>chrpath</filename>.
+                        </para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+    </section>
+</section>
+
+<section id='intro-getit'>
+    <title>Obtaining the Yocto Project</title>
+    <para>
+        The Yocto Project development team makes the Yocto Project available through a number
+        of methods:
+        <itemizedlist>
+            <listitem><para><emphasis>Source Repositories:</emphasis>
+                Working from a copy of the upstream
+                <filename>poky</filename> repository is the
+                preferred method for obtaining and using a Yocto Project
+                release.
+                You can view the Yocto Project Source Repositories at
+                <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.
+                In particular, you can find the
+                <filename>poky</filename> repository at
+                <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/'></ulink>.
+                </para></listitem>
+            <listitem><para><emphasis>Releases:</emphasis> Stable, tested
+                releases are available as tarballs through
+                <ulink url='&YOCTO_DL_URL;/releases/yocto/'/>.</para></listitem>
+            <listitem><para><emphasis>Nightly Builds:</emphasis> These
+                tarball releases are available at
+                <ulink url='http://autobuilder.yoctoproject.org/nightly'/>.
+                These builds include Yocto Project releases, meta-toolchain
+                tarball installation scripts, and experimental builds.
+                </para></listitem>
+            <listitem><para><emphasis>Yocto Project Website:</emphasis> You can
+                find tarball releases of the Yocto Project and supported BSPs
+                at the
+                <ulink url='&YOCTO_HOME_URL;'>Yocto Project website</ulink>.
+                Along with these downloads, you can find lots of other
+                information at this site.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='intro-getit-dev'>
+    <title>Development Checkouts</title>
+    <para>
+        Development using the Yocto Project requires a local
+        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        You can set up the Source Directory by cloning a copy of the upstream
+        <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>poky</ulink> Git repository.
+        For information on how to do this, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Set Up</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/migration.xml b/documentation/ref-manual/migration.xml
new file mode 100644
index 0000000000..d072ecfa0e
--- /dev/null
+++ b/documentation/ref-manual/migration.xml
@@ -0,0 +1,2019 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='migration'>
+<title>Migrating to a Newer Yocto Project Release</title>
+
+    <para>
+        This chapter provides information you can use to migrate work to a
+        newer Yocto Project release.  You can find the same information in the
+        release notes for a given release.
+    </para>
+
+<section id='general-migration-considerations'>
+    <title>General Migration Considerations</title>
+
+    <para>
+        Some considerations are not tied to a specific Yocto Project
+        release.
+        This section presents information you should consider when
+        migrating to any new Yocto Project release.
+        <itemizedlist>
+            <listitem><para><emphasis>Dealing with Customized Recipes</emphasis>:
+                Issues could arise if you take older recipes that contain
+                customizations and simply copy them forward expecting them
+                to work after you migrate to new Yocto Project metadata.
+                For example, suppose you have a recipe in your layer that is
+                a customized version of a core recipe copied from the earlier
+                release, rather than through the use of an append file.
+                When you migrate to a newer version of Yocto Project, the
+                metadata (e.g. perhaps an include file used by the recipe)
+                could have changed in a way that would break the build.
+                Say, for example, a function is removed from an include file
+                and the customized recipe tries to call that function.
+                </para>
+
+                <para>You could "forward-port" all your customizations in your
+                recipe so that everything works for the new release.
+                However, this is not the optimal solution as you would have
+                to repeat this process with each new release if changes
+                occur that give rise to problems.</para>
+
+                <para>The better solution (where practical) is to use append
+                files (<filename>*.bbappend</filename>) to capture any
+                customizations you want to make to a recipe.
+                Doing so, isolates your changes from the main recipe making
+                them much more manageable.
+                However, sometimes it is not practical to use an append
+                file.
+                A good example of this is when introducing a newer or older
+                version of a recipe in another layer.</para>
+                </listitem>
+            <listitem><para><emphasis>Updating Append Files</emphasis>:
+                Since append files generally only contain your customizations,
+                they often do not need to be adjusted for new releases.
+                However, if the <filename>.bbappend</filename> file is
+                specific to a particular version of the recipe (i.e. its
+                name does not use the % wildcard) and the version of the
+                recipe to which it is appending has changed, then you will
+                at a minimum need to rename the append file to match the
+                name of the recipe file.
+                A mismatch between an append file and its corresponding
+                recipe file (<filename>.bb</filename>) will
+                trigger an error during parsing.</para>
+                <para>Depending on the type of customization the append file
+                applies, other incompatibilities might occur when you
+                upgrade.
+                For example, if your append file applies a patch and the
+                recipe to which it is appending is updated to a newer
+                version, the patch might no longer apply.
+                If this is the case and assuming the patch is still needed,
+                you must modify the patch file so that it does apply.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='moving-to-the-yocto-project-1.3-release'>
+    <title>Moving to the Yocto Project 1.3 Release</title>
+
+    <para>
+        This section provides migration information for moving to the
+        Yocto Project 1.3 Release from the prior release.
+    </para>
+
+    <section id='1.3-local-configuration'>
+        <title>Local Configuration</title>
+
+        <para>
+            Differences include changes for
+            <link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>
+            and <filename>bblayers.conf</filename>.
+        </para>
+
+        <section id='migration-1.3-sstate-mirrors'>
+            <title>SSTATE_MIRRORS</title>
+
+            <para>
+                The shared state cache (sstate-cache), as pointed to by
+                <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>, by default
+                now has two-character subdirectories to prevent issues arising
+                from too many files in the same directory.
+                Also, native sstate-cache packages will go into a subdirectory named using
+                the distro ID string.
+                If you copy the newly structured sstate-cache to a mirror location
+                (either local or remote) and then point to it in
+                <link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>,
+                you need to append "PATH" to the end of the mirror URL so that
+                the path used by BitBake before the mirror substitution is
+                appended to the path used to access the mirror.
+                Here is an example:
+                <literallayout class='monospaced'>
+     SSTATE_MIRRORS = "file://.* http://<replaceable>someserver</replaceable>.tld/share/sstate/PATH"
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='migration-1.3-bblayers-conf'>
+            <title>bblayers.conf</title>
+
+            <para>
+                The <filename>meta-yocto</filename> layer consists of two parts
+                that correspond to the Poky reference distribution and the
+                reference hardware Board Support Packages (BSPs), respectively:
+                <filename>meta-yocto</filename> and
+                <filename>meta-yocto-bsp</filename>.
+                When running BitBake or Hob for the first time after upgrading,
+                your <filename>conf/bblayers.conf</filename> file will be
+                updated to handle this change and you will be asked to
+                re-run or restart for the changes to take effect.
+            </para>
+        </section>
+    </section>
+
+    <section id='1.3-recipes'>
+        <title>Recipes</title>
+
+        <para>
+            Differences include changes for the following:
+            <itemizedlist>
+                <listitem><para>Python function whitespace</para></listitem>
+                <listitem><para><filename>proto=</filename> in <filename>SRC_URI</filename></para></listitem>
+                <listitem><para><filename>nativesdk</filename></para></listitem>
+                <listitem><para>Task recipes</para></listitem>
+                <listitem><para><filename>IMAGE_FEATURES</filename></para></listitem>
+                <listitem><para>Removed recipes</para></listitem>
+            </itemizedlist>
+        </para>
+
+        <section id='migration-1.3-python-function-whitespace'>
+            <title>Python Function Whitespace</title>
+
+            <para>
+                All Python functions must now use four spaces for indentation.
+                Previously, an inconsistent mix of spaces and tabs existed,
+                which made extending these functions using
+                <filename>_append</filename> or <filename>_prepend</filename>
+                complicated given that Python treats whitespace as
+                syntactically significant.
+                If you are defining or extending any Python functions (e.g.
+                <filename>populate_packages</filename>, <filename>do_unpack</filename>,
+                <filename>do_patch</filename> and so forth) in custom recipes
+                or classes, you need to ensure you are using consistent
+                four-space indentation.
+            </para>
+        </section>
+
+        <section id='migration-1.3-proto=-in-src-uri'>
+            <title>proto= in SRC_URI</title>
+
+            <para>
+                Any use of <filename>proto=</filename> in
+                <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+                needs to be changed to <filename>protocol=</filename>.
+                In particular, this applies to the following URIs:
+                <itemizedlist>
+                    <listitem><para><filename>svn://</filename></para></listitem>
+                    <listitem><para><filename>bzr://</filename></para></listitem>
+                    <listitem><para><filename>hg://</filename></para></listitem>
+                    <listitem><para><filename>osc://</filename></para></listitem>
+                </itemizedlist>
+                Other URIs were already using <filename>protocol=</filename>.
+                This change improves consistency.
+            </para>
+        </section>
+
+        <section id='migration-1.3-nativesdk'>
+            <title>nativesdk</title>
+
+            <para>
+                The suffix <filename>nativesdk</filename> is now implemented
+                as a prefix, which simplifies a lot of the packaging code for
+                <filename>nativesdk</filename> recipes.
+                All custom <filename>nativesdk</filename> recipes and any
+                references need to be updated to use
+                <filename>nativesdk-*</filename> instead of
+                <filename>*-nativesdk</filename>.
+            </para>
+        </section>
+
+        <section id='migration-1.3-task-recipes'>
+            <title>Task Recipes</title>
+
+            <para>
+                "Task" recipes are now known as "Package groups" and have
+                been renamed from <filename>task-*.bb</filename> to
+                <filename>packagegroup-*.bb</filename>.
+                Existing references to the previous <filename>task-*</filename>
+                names should work in most cases as there is an automatic
+                upgrade path for most packages.
+                However, you should update references in your own recipes and
+                configurations as they could be removed in future releases.
+                You should also rename any custom <filename>task-*</filename>
+                recipes to <filename>packagegroup-*</filename>, and change
+                them to inherit <filename>packagegroup</filename> instead of
+                <filename>task</filename>, as well as taking the opportunity
+                to remove anything now handled by
+                <filename>packagegroup.bbclass</filename>, such as providing
+                <filename>-dev</filename> and <filename>-dbg</filename>
+                packages, setting
+                <link linkend='var-LIC_FILES_CHKSUM'><filename>LIC_FILES_CHKSUM</filename></link>,
+                and so forth.
+                See the
+                "<link linkend='ref-classes-packagegroup'><filename>packagegroup.bbclass</filename></link>"
+                section for further details.
+            </para>
+        </section>
+
+        <section id='migration-1.3-image-features'>
+            <title>IMAGE_FEATURES</title>
+
+            <para>
+                Image recipes that previously included "apps-console-core"
+                in <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
+                should now include "splash" instead to enable the boot-up
+                splash screen.
+                Retaining "apps-console-core" will still include the splash
+                screen but generates a warning.
+                The "apps-x11-core" and "apps-x11-games"
+                <filename>IMAGE_FEATURES</filename> features have been removed.
+            </para>
+        </section>
+
+        <section id='migration-1.3-removed-recipes'>
+            <title>Removed Recipes</title>
+
+            <para>
+                The following recipes have been removed.
+                For most of them, it is unlikely that you would have any
+                references to them in your own
+                <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>.
+                However, you should check your metadata against this list to be sure:
+                <itemizedlist>
+                    <listitem><para><emphasis><filename>libx11-trim</filename></emphasis>:
+                        Replaced by <filename>libx11</filename>, which has a negligible
+                        size difference with modern Xorg.</para></listitem>
+                    <listitem><para><emphasis><filename>xserver-xorg-lite</filename></emphasis>:
+                        Use <filename>xserver-xorg</filename>, which has a negligible
+                        size difference when DRI and GLX modules are not installed.</para></listitem>
+                    <listitem><para><emphasis><filename>xserver-kdrive</filename></emphasis>:
+                        Effectively unmaintained for many years.</para></listitem>
+                    <listitem><para><emphasis><filename>mesa-xlib</filename></emphasis>:
+                        No longer serves any purpose.</para></listitem>
+                    <listitem><para><emphasis><filename>galago</filename></emphasis>:
+                        Replaced by telepathy.</para></listitem>
+                    <listitem><para><emphasis><filename>gail</filename></emphasis>:
+                        Functionality was integrated into GTK+ 2.13.</para></listitem>
+                    <listitem><para><emphasis><filename>eggdbus</filename></emphasis>:
+                        No longer needed.</para></listitem>
+                    <listitem><para><emphasis><filename>gcc-*-intermediate</filename></emphasis>:
+                        The build has been restructured to avoid the need for
+                        this step.</para></listitem>
+                    <listitem><para><emphasis><filename>libgsmd</filename></emphasis>:
+                        Unmaintained for many years.
+                        Functionality now provided by
+                        <filename>ofono</filename> instead.</para></listitem>
+                    <listitem><para><emphasis>contacts, dates, tasks, eds-tools</emphasis>:
+                        Largely unmaintained PIM application suite.
+                        It has been moved to <filename>meta-gnome</filename>
+                        in <filename>meta-openembedded</filename>.</para></listitem>
+                </itemizedlist>
+                In addition to the previously listed changes, the
+                <filename>meta-demoapps</filename> directory has also been removed
+                because the recipes in it were not being maintained and many
+                had become obsolete or broken.
+                Additionally, these recipes were not parsed in the default configuration.
+                Many of these recipes are already provided in an updated and
+                maintained form within the OpenEmbedded community layers such as
+                <filename>meta-oe</filename> and <filename>meta-gnome</filename>.
+                For the remainder, you can now find them in the
+                <filename>meta-extras</filename> repository, which is in the
+                Yocto Project
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-repositories'>Source Repositories</ulink>.
+            </para>
+        </section>
+    </section>
+
+    <section id='1.3-linux-kernel-naming'>
+        <title>Linux Kernel Naming</title>
+
+        <para>
+            The naming scheme for kernel output binaries has been changed to
+            now include
+            <link linkend='var-PE'><filename>PE</filename></link> as part of the
+            filename:
+            <literallayout class='monospaced'>
+     KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
+            </literallayout>
+        </para>
+
+        <para>
+            Because the <filename>PE</filename> variable is not set by default,
+            these binary files could result with names that include two dash
+            characters.
+            Here is an example:
+            <literallayout class='monospaced'>
+     bzImage--3.10.9+git0+cd502a8814_7144bcc4b8-r0-qemux86-64-20130830085431.bin
+            </literallayout>
+        </para>
+    </section>
+</section>
+
+<section id='moving-to-the-yocto-project-1.4-release'>
+    <title>Moving to the Yocto Project 1.4 Release</title>
+
+    <para>
+        This section provides migration information for moving to the
+        Yocto Project 1.4 Release from the prior release.
+    </para>
+
+    <section id='migration-1.4-bitbake'>
+        <title>BitBake</title>
+
+        <para>
+            Differences include the following:
+            <itemizedlist>
+                <listitem><para><emphasis>Comment Continuation:</emphasis>
+                    If a comment ends with a line continuation (\) character,
+                    then the next line must also be a comment.
+                    Any instance where this is not the case, now triggers
+                    a warning.
+                    You must either remove the continuation character, or be
+                    sure the next line is a comment.
+                    </para></listitem>
+                <listitem><para><emphasis>Package Name Overrides:</emphasis>
+                    The runtime package specific variables
+                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>,
+                    <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
+                    <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>,
+                    <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
+                    <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>,
+                    <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>,
+                    <link linkend='var-FILES'><filename>FILES</filename></link>,
+                    <link linkend='var-ALLOW_EMPTY'><filename>ALLOW_EMPTY</filename></link>,
+                    and the pre, post, install, and uninstall script functions
+                    <filename>pkg_preinst</filename>,
+                    <filename>pkg_postinst</filename>,
+                    <filename>pkg_prerm</filename>, and
+                    <filename>pkg_postrm</filename> should always have a
+                    package name override.
+                    For example, use <filename>RDEPENDS_${PN}</filename> for
+                    the main package instead of <filename>RDEPENDS</filename>.
+                    BitBake uses more strict checks when it parses recipes.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.4-build-behavior'>
+        <title>Build Behavior</title>
+
+        <para>
+            Differences include the following:
+            <itemizedlist>
+                <listitem><para><emphasis>Shared State Code:</emphasis>
+                    The shared state code has been optimized to avoid running
+                    unnecessary tasks.
+                    For example, the following no longer populates the target
+                    sysroot since that is not necessary:
+                    <literallayout class='monospaced'>
+     $ bitbake -c rootfs <replaceable>some-image</replaceable>
+                    </literallayout>
+                    Instead, the system just needs to extract the output
+                    package contents, re-create the packages, and construct
+                    the root filesystem.
+                    This change is unlikely to cause any problems unless
+                    you have missing declared dependencies.
+                    </para></listitem>
+                <listitem><para><emphasis>Scanning Directory Names:</emphasis>
+                    When scanning for files in
+                    <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>,
+                    the build system now uses
+                    <link linkend='var-FILESOVERRIDES'><filename>FILESOVERRIDES</filename></link>
+                    instead of <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>
+                    for the directory names.
+                    In general, the values previously in
+                    <filename>OVERRIDES</filename> are now in
+                    <filename>FILESOVERRIDES</filename> as well.
+                    However, if you relied upon an additional value
+                    you previously added to <filename>OVERRIDES</filename>,
+                    you might now need to add it to
+                    <filename>FILESOVERRIDES</filename> unless you are already
+                    adding it through the
+                    <link linkend='var-MACHINEOVERRIDES'><filename>MACHINEOVERRIDES</filename></link>
+                    or <link linkend='var-DISTROOVERRIDES'><filename>DISTROOVERRIDES</filename></link>
+                    variables, as appropriate.
+                    For more related changes, see the
+                    "<link linkend='migration-1.4-variables'>Variables</link>"
+                    section.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+
+    <section id='migration-1.4-proxies-and-fetching-source'>
+        <title>Proxies and Fetching Source</title>
+
+        <para>
+            A new <filename>oe-git-proxy</filename> script has been added to
+            replace previous methods of handling proxies and fetching source
+            from Git.
+            See the <filename>meta-yocto/conf/site.conf.sample</filename> file
+            for information on how to use this script.
+        </para>
+    </section>
+
+    <section id='migration-1.4-custom-interfaces-file-netbase-change'>
+        <title>Custom Interfaces File (netbase change)</title>
+
+        <para>
+            If you have created your own custom
+            <filename>etc/network/interfaces</filename> file by creating
+            an append file for the <filename>netbase</filename> recipe,
+            you now need to create an append file for the
+            <filename>init-ifupdown</filename> recipe instead, which you can
+            find in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            at <filename>meta/recipes-core/init-ifupdown</filename>.
+            For information on how to use append files, see the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files</ulink>"
+            in the Yocto Project Development Manual.
+        </para>
+    </section>
+
+    <section id='migration-1.4-remote-debugging'>
+        <title>Remote Debugging</title>
+
+        <para>
+            Support for remote debugging with the Eclipse IDE is now
+            separated into an image feature
+            (<filename>eclipse-debug</filename>) that corresponds to the
+            <filename>packagegroup-core-eclipse-debug</filename> package group.
+            Previously, the debugging feature was included through the
+            <filename>tools-debug</filename> image feature, which corresponds
+            to the <filename>packagegroup-core-tools-debug</filename>
+            package group.
+        </para>
+    </section>
+
+    <section id='migration-1.4-variables'>
+        <title>Variables</title>
+
+        <para>
+            The following variables have changed:
+            <itemizedlist>
+                <listitem><para><emphasis><filename>SANITY_TESTED_DISTROS</filename>:</emphasis>
+                    This variable now uses a distribution ID, which is composed
+                    of the host distributor ID followed by the release.
+                    Previously,
+                    <link linkend='var-SANITY_TESTED_DISTROS'><filename>SANITY_TESTED_DISTROS</filename></link>
+                    was composed of the description field.
+                    For example, "Ubuntu 12.10" becomes "Ubuntu-12.10".
+                    You do not need to worry about this change if you are not
+                    specifically setting this variable, or if you are
+                    specifically setting it to "".
+                    </para></listitem>
+                <listitem><para><emphasis><filename>SRC_URI</filename>:</emphasis>
+                    The <filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename>,
+                    <filename>${</filename><link linkend='var-PF'><filename>PF</filename></link><filename>}</filename>,
+                    <filename>${</filename><link linkend='var-P'><filename>P</filename></link><filename>}</filename>,
+                    and <filename>FILE_DIRNAME</filename> directories have been
+                    dropped from the default value of the
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
+                    variable, which is used as the search path for finding files
+                    referred to in
+                    <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>.
+                    If you have a recipe that relied upon these directories,
+                    which would be unusual, then you will need to add the
+                    appropriate paths within the recipe or, alternatively,
+                    rearrange the files.
+                    The most common locations are still covered by
+                    <filename>${BP}</filename>, <filename>${BPN}</filename>,
+                    and "files", which all remain in the default value of
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-target-package-management-with-rpm'>
+        <title>Target Package Management with RPM</title>
+
+        <para>
+            If runtime package management is enabled and the RPM backend
+            is selected, Smart is now installed for package download, dependency
+            resolution, and upgrades instead of Zypper.
+            For more information on how to use Smart, run the following command
+            on the target:
+            <literallayout class='monospaced'>
+     smart --help
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='migration-1.4-recipes-moved'>
+        <title>Recipes Moved</title>
+
+        <para>
+            The following recipes were moved from their previous locations
+            because they are no longer used by anything in
+            the OpenEmbedded-Core:
+            <itemizedlist>
+                <listitem><para><emphasis><filename>clutter-box2d</filename>:</emphasis>
+                    Now resides in the <filename>meta-oe</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>evolution-data-server</filename>:</emphasis>
+                    Now resides in the <filename>meta-gnome</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>gthumb</filename>:</emphasis>
+                    Now resides in the <filename>meta-gnome</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>gtkhtml2</filename>:</emphasis>
+                    Now resides in the <filename>meta-oe</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>gupnp</filename>:</emphasis>
+                    Now resides in the <filename>meta-multimedia</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>gypsy</filename>:</emphasis>
+                    Now resides in the <filename>meta-oe</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>libcanberra</filename>:</emphasis>
+                    Now resides in the <filename>meta-gnome</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>libgdata</filename>:</emphasis>
+                    Now resides in the <filename>meta-gnome</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>libmusicbrainz</filename>:</emphasis>
+                    Now resides in the <filename>meta-multimedia</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>metacity</filename>:</emphasis>
+                    Now resides in the <filename>meta-gnome</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>polkit</filename>:</emphasis>
+                    Now resides in the <filename>meta-oe</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>zeroconf</filename>:</emphasis>
+                    Now resides in the <filename>meta-networking</filename> layer.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.4-removals-and-renames'>
+        <title>Removals and Renames</title>
+
+        <para>
+            The following list shows what has been removed or renamed:
+            <itemizedlist>
+                <listitem><para><emphasis><filename>evieext</filename>:</emphasis>
+                    Removed because it has been removed from
+                    <filename>xserver</filename> since 2008.
+                    </para></listitem>
+                <listitem><para><emphasis>Gtk+ DirectFB:</emphasis>
+                    Removed support because upstream Gtk+ no longer supports it
+                    as of version 2.18.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>libxfontcache / xfontcacheproto</filename>:</emphasis>
+                    Removed because they were removed from the Xorg server in 2008.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>libxp / libxprintapputil / libxprintutil / printproto</filename>:</emphasis>
+                    Removed because the XPrint server was removed from
+                    Xorg in 2008.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>libxtrap / xtrapproto</filename>:</emphasis>
+                    Removed because their functionality was broken upstream.
+                    </para></listitem>
+                <listitem><para><emphasis>linux-yocto 3.0 kernel:</emphasis>
+                    Removed with linux-yocto 3.8 kernel being added.
+                    The linux-yocto 3.2 and linux-yocto 3.4 kernels remain
+                    as part of the release.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>lsbsetup</filename>:</emphasis>
+                    Removed with functionality now provided by
+                    <filename>lsbtest</filename>.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>matchbox-stroke</filename>:</emphasis>
+                    Removed because it was never more than a proof-of-concept.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>matchbox-wm-2 / matchbox-theme-sato-2</filename>:</emphasis>
+                    Removed because they are not maintained.
+                    However, <filename>matchbox-wm</filename> and
+                    <filename>matchbox-theme-sato</filename> are still
+                    provided.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>mesa-dri</filename>:</emphasis>
+                    Renamed to <filename>mesa</filename>.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>mesa-xlib</filename>:</emphasis>
+                    Removed because it was no longer useful.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>mutter</filename>:</emphasis>
+                    Removed because nothing ever uses it and the recipe is
+                    very old.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>orinoco-conf</filename>:</emphasis>
+                    Removed because it has become obsolete.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>update-modules</filename>:</emphasis>
+                    Removed because it is no longer used.
+                    The kernel module <filename>postinstall</filename> and
+                    <filename>postrm</filename> scripts can now do the same
+                    task without the use of this script.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>web</filename>:</emphasis>
+                    Removed because it is not maintained.  Superseded by
+                    <filename>web-webkit</filename>.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>xf86bigfontproto</filename>:</emphasis>
+                    Removed because upstream it has been disabled by default
+                    since 2007.
+                    Nothing uses <filename>xf86bigfontproto</filename>.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>xf86rushproto</filename>:</emphasis>
+                    Removed because its dependency in
+                    <filename>xserver</filename> was spurious and it was
+                    removed in 2005.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>zypper / libzypp / sat-solver</filename>:</emphasis>
+                    Removed and been functionally replaced with Smart
+                    (<filename>python-smartpm</filename>) when RPM packaging
+                    is used and package management is enabled on the target.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
+
+<section id='moving-to-the-yocto-project-1.5-release'>
+    <title>Moving to the Yocto Project 1.5 Release</title>
+
+    <para>
+        This section provides migration information for moving to the
+        Yocto Project 1.5 Release from the prior release.
+    </para>
+
+    <section id='migration-1.5-host-dependency-changes'>
+        <title>Host Dependency Changes</title>
+
+        <para>
+            The OpenEmbedded build system now has some additional requirements
+            on the host system:
+            <itemizedlist>
+                <listitem><para>Python 2.7.3+</para></listitem>
+                <listitem><para>Tar 1.24+</para></listitem>
+                <listitem><para>Git 1.7.8+</para></listitem>
+                <listitem><para>Patched version of Make if you are using
+                    3.82.
+                    Most distributions that provide Make 3.82 use the patched
+                    version.</para></listitem>
+            </itemizedlist>
+            If the Linux distribution you are using on your build host
+            does not provide packages for these, you can install and use
+            the Buildtools tarball, which provides an SDK-like environment
+            containing them.
+        </para>
+
+        <para>
+            For more information on this requirement, see the
+            "<link linkend='required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</link>"
+            section.
+        </para>
+    </section>
+
+    <section id='migration-1.5-atom-pc-bsp'>
+        <title><filename>atom-pc</filename> Board Support Package (BSP)</title>
+
+        <para>
+            The <filename>atom-pc</filename> hardware reference BSP has been
+            replaced by a <filename>genericx86</filename> BSP.
+            This BSP is not necessarily guaranteed to work on all x86
+            hardware, but it will run on a wider range of systems than the
+            <filename>atom-pc</filename> did.
+            <note>
+                Additionally, a <filename>genericx86-64</filename> BSP has
+                been added for 64-bit Atom systems.
+            </note>
+        </para>
+    </section>
+
+    <section id='migration-1.5-bitbake'>
+        <title>BitBake</title>
+
+        <para>
+            The following changes have been made that relate to BitBake:
+            <itemizedlist>
+                <listitem><para>
+                    BitBake now supports a <filename>_remove</filename>
+                    operator.
+                    The addition of this operator means you will have to
+                    rename any items in recipe space (functions, variables)
+                    whose names currently contain
+                    <filename>_remove_</filename> or end with
+                    <filename>_remove</filename> to avoid unexpected behavior.
+                    </para></listitem>
+                <listitem><para>
+                    BitBake's global method pool has been removed.
+                    This method is not particularly useful and led to clashes
+                    between recipes containing functions that had the
+                    same name.</para></listitem>
+                <listitem><para>
+                    The "none" server backend has been removed.
+                    The "process" server backend has been serving well as the
+                    default for a long time now.</para></listitem>
+                <listitem><para>
+                    The <filename>bitbake-runtask</filename> script has been
+                    removed.</para></listitem>
+                <listitem><para>
+                    <filename>${</filename><link linkend='var-P'><filename>P</filename></link><filename>}</filename>
+                    and
+                    <filename>${</filename><link linkend='var-PF'><filename>PF</filename></link><filename>}</filename>
+                    are no longer added to
+                    <link linkend='var-PROVIDES'><filename>PROVIDES</filename></link>
+                    by default in <filename>bitbake.conf</filename>.
+                    These version-specific <filename>PROVIDES</filename>
+                    items were seldom used.
+                    Attempting to use them could result in two versions being
+                    built simultaneously rather than just one version due to
+                    the way BitBake resolves dependencies.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.5-qa-warnings'>
+        <title>QA Warnings</title>
+
+        <para>
+            The following changes have been made to the package QA checks:
+            <itemizedlist>
+                <listitem><para>
+                    If you have customized
+                    <link linkend='var-ERROR_QA'><filename>ERROR_QA</filename></link>
+                    or <link linkend='var-WARN_QA'><filename>WARN_QA</filename></link>
+                    values in your configuration, check that they contain all of
+                    the issues that you wish to be reported.
+                    Previous Yocto Project versions contained a bug that meant
+                    that any item not mentioned in <filename>ERROR_QA</filename>
+                    or <filename>WARN_QA</filename> would be treated as a
+                    warning.
+                    Consequently, several important items were not already in
+                    the default value of <filename>WARN_QA</filename>.
+                    All of the possible QA checks are now documented in the
+                    "<link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>"
+                    section.</para></listitem>
+                <listitem><para>
+                    An additional QA check has been added to check if
+                    <filename>/usr/share/info/dir</filename> is being installed.
+                    Your recipe should delete this file within
+                    <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+                    if "make install" is installing it.
+                    </para></listitem>
+                <listitem><para>
+                    If you are using the buildhistory class, the check for the
+                    package version going backwards is now controlled using a
+                    standard QA check.
+                    Thus, if you have customized your
+                    <filename>ERROR_QA</filename> or
+                    <filename>WARN_QA</filename> values and still wish to have
+                    this check performed, you should add
+                    "version-going-backwards" to your value for one or the
+                    other variables depending on how you wish it to be handled.
+                    See the documented QA checks in the
+                    "<link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>"
+                    section.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.5-directory-layout-changes'>
+        <title>Directory Layout Changes</title>
+
+        <para>
+            The following directory changes exist:
+            <itemizedlist>
+                <listitem><para>
+                    Output SDK installer files are now named to include the
+                    image name and tuning architecture through the
+                    <link linkend='var-SDK_NAME'><filename>SDK_NAME</filename></link>
+                    variable.</para></listitem>
+                <listitem><para>
+                    Images and related files are now installed into a directory
+                    that is specific to the machine, instead of a parent
+                    directory containing output files for multiple machines.
+                    The
+                    <link linkend='var-DEPLOY_DIR_IMAGE'><filename>DEPLOY_DIR_IMAGE</filename></link>
+                    variable continues to point to the directory containing
+                    images for the current
+                    <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+                    and should be used anywhere there is a need to refer to
+                    this directory.
+                    The <filename>runqemu</filename> script now uses this
+                    variable to find images and kernel binaries and will use
+                    BitBake to determine the directory.
+                    Alternatively, you can set the
+                    <filename>DEPLOY_DIR_IMAGE</filename> variable in the
+                    external environment.</para></listitem>
+                <listitem><para>
+                    When buildhistory is enabled, its output is now written
+                    under the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                    rather than
+                    <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>.
+                    Doing so makes it easier to delete
+                    <filename>TMPDIR</filename> and preserve the build history.
+                    Additionally, data for produced SDKs is now split by
+                    <link linkend='var-IMAGE_NAME'><filename>IMAGE_NAME</filename></link>.
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>pkgdata</filename> directory produced as
+                    part of the packaging process has been collapsed into a
+                    single machine-specific directory.
+                    This directory is located under
+                    <filename>sysroots</filename> and uses a machine-specific
+                    name (i.e.
+                    <filename>tmp/sysroots/<replaceable>machine</replaceable>/pkgdata</filename>).
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.5-shortened-git-srcrev-values'>
+        <title>Shortened Git <filename>SRCREV</filename> Values</title>
+
+        <para>
+            BitBake will now shorten revisions from Git repositories from the
+            normal 40 characters down to 10 characters within
+            <link linkend='var-SRCPV'><filename>SRCPV</filename></link>
+            for improved usability in path and file names.
+            This change should be safe within contexts where these revisions
+            are used because the chances of spatially close collisions
+            is very low.
+            Distant collisions are not a major issue in the way
+            the values are used.
+        </para>
+    </section>
+
+    <section id='migration-1.5-image-features'>
+        <title><filename>IMAGE_FEATURES</filename></title>
+
+        <para>
+            The following changes have been made that relate to
+            <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>:
+            <itemizedlist>
+                <listitem><para>
+                    The value of
+                    <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
+                    is now validated to ensure invalid feature items are not
+                    added.
+                    Some users mistakenly add package names to this variable
+                    instead of using
+                    <link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>
+                    in order to have the package added to the image, which does
+                    not work.
+                    This change is intended to catch those kinds of situations.
+                    Valid <filename>IMAGE_FEATURES</filename> are drawn from
+                    <link linkend='var-PACKAGE_GROUP'><filename>PACKAGE_GROUP</filename></link>
+                    definitions,
+                    <link linkend='var-COMPLEMENTARY_GLOB'><filename>COMPLEMENTARY_GLOB</filename></link>
+                    and a new "validitems" varflag on
+                    <filename>IMAGE_FEATURES</filename>.
+                    The "validitems" varflag change allows additional features
+                    to be added if they are not provided using the previous
+                    two mechanisms.
+                    </para></listitem>
+                <listitem><para>
+                    The previously deprecated "apps-console-core"
+                    <filename>IMAGE_FEATURES</filename> item is no longer
+                    supported.
+                    Add "splash" to <filename>IMAGE_FEATURES</filename> if you
+                    wish to have the splash screen enabled, since this is
+                    all that apps-console-core was doing.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.5-run'>
+        <title><filename>/run</filename></title>
+
+        <para>
+            The <filename>/run</filename> directory from the Filesystem
+            Hierarchy Standard 3.0 has been introduced.
+            You can find some of the implications for this change
+            <ulink url='http://cgit.openembedded.org/openembedded-core/commit/?id=0e326280a15b0f2c4ef2ef4ec441f63f55b75873'>here</ulink>.
+            The change also means that recipes that install files to
+            <filename>/var/run</filename> must be changed.
+            You can find a guide on how to make these changes
+            <ulink url='http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58530'>here</ulink>.
+        </para>
+    </section>
+
+    <section id='migration-1.5-removal-of-package-manager-database-within-image-recipes'>
+        <title>Removal of Package Manager Database Within Image Recipes</title>
+
+        <para>
+            The image <filename>core-image-minimal</filename> no longer adds
+            <filename>remove_packaging_data_files</filename> to
+            <link linkend='var-ROOTFS_POSTPROCESS_COMMAND'><filename>ROOTFS_POSTPROCESS_COMMAND</filename></link>.
+            This addition is now handled automatically when "package-management"
+            is not in
+            <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>.
+            If you have custom image recipes that make this addition,
+            you should remove the lines, as they are not needed and might
+            interfere with correct operation of postinstall scripts.
+        </para>
+    </section>
+
+    <section id='migration-1.5-images-now-rebuild-only-on-changes-instead-of-every-time'>
+        <title>Images Now Rebuild Only on Changes Instead of Every Time</title>
+
+        <para>
+            The
+            <link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>
+            and other related image
+            construction tasks are no longer marked as "nostamp".
+            Consequently, they will only be re-executed when their inputs have
+            changed.
+            Previous versions of the OpenEmbedded build system always rebuilt
+            the image when requested rather when necessary.
+        </para>
+    </section>
+
+    <section id='migration-1.5-task-recipes'>
+        <title>Task Recipes</title>
+
+        <para>
+            The previously deprecated <filename>task.bbclass</filename> has
+            now been dropped.
+            For recipes that previously inherited from this class, you should
+            rename them from <filename>task-*</filename> to
+            <filename>packagegroup-*</filename> and inherit packagegroup
+            instead.
+        </para>
+
+        <para>
+            For more information, see the
+            "<link linkend='ref-classes-packagegroup'><filename>packagegroup.bbclass</filename></link>"
+            section.
+        </para>
+    </section>
+
+    <section id='migration-1.5-busybox'>
+        <title>BusyBox</title>
+
+        <para>
+            By default, we now split BusyBox into two binaries:
+            one that is suid root for those components that need it, and
+            another for the rest of the components.
+            Splitting BusyBox allows for optimization that eliminates the
+            <filename>tinylogin</filename> recipe as recommended by upstream.
+            You can disable this split by setting
+            <link linkend='var-BUSYBOX_SPLIT_SUID'><filename>BUSYBOX_SPLIT_SUID</filename></link>
+            to "0".
+        </para>
+    </section>
+
+    <section id='migration-1.5-automated-image-testing'>
+        <title>Automated Image Testing</title>
+
+        <para>
+            A new automated image testing framework has been added
+            through the
+            <link linkend='ref-classes-testimage'><filename>testimage*.bbclass</filename></link>
+            class.
+            This framework replaces the older
+            <filename>imagetest-qemu</filename> framework.
+        </para>
+
+        <para>
+            You can learn more about performing automated image tests in the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
+            section.
+        </para>
+    </section>
+
+    <section id='migration-1.5-build-history'>
+        <title>Build History</title>
+
+        <para>
+            Following are changes to Build History:
+            <itemizedlist>
+                <listitem><para>
+                     Installed package sizes:
+                     <filename>installed-package-sizes.txt</filename> for an
+                     image now records the size of the files installed by each
+                     package instead of the size of each compressed package
+                     archive file.</para></listitem>
+                <listitem><para>
+                    The dependency graphs (<filename>depends*.dot</filename>)
+                    now use the actual package names instead of replacing
+                    dashes, dots and plus signs with underscores.
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>buildhistory-diff</filename> and
+                    <filename>buildhistory-collect-srcrevs</filename>
+                    utilities have improved command-line handling.
+                    Use the <filename>&dash;&dash;help</filename> option for
+                    each utility for more information on the new syntax.
+                    </para></listitem>
+            </itemizedlist>
+            For more information on Build History, see the
+            "<link linkend='maintaining-build-output-quality'>Maintaining Build Output Quality</link>"
+            section.
+        </para>
+    </section>
+
+    <section id='migration-1.5-udev'>
+        <title><filename>udev</filename></title>
+
+        <para>
+            Following are changes to <filename>udev</filename>:
+            <itemizedlist>
+                <listitem><para>
+                    <filename>udev</filename> no longer brings in
+                    <filename>udev-extraconf</filename> automatically
+                    through
+                    <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
+                    since this was originally intended to be optional.
+                    If you need the extra rules, then add
+                    <filename>udev-extraconf</filename> to your image.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>udev</filename> no longer brings in
+                    <filename>pciutils-ids</filename> or
+                    <filename>usbutils-ids</filename> through
+                    <filename>RRECOMMENDS</filename>.
+                    These are not needed by <filename>udev</filename> itself
+                    and removing them saves around 350KB.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.5-removed-renamed-recipes'>
+        <title>Removed and Renamed Recipes</title>
+
+        <itemizedlist>
+            <listitem><para>
+                The <filename>linux-yocto</filename> 3.2 kernel has been
+                removed.</para></listitem>
+            <listitem><para>
+                <filename>libtool-nativesdk</filename> has been renamed to
+                <filename>nativesdk-libtool</filename>.</para></listitem>
+            <listitem><para>
+                <filename>tinylogin</filename> has been removed.
+                It has been replaced by a suid portion of Busybox.
+                See the
+                "<link linkend='migration-1.5-busybox'>BusyBox</link>" section
+                for more information.</para></listitem>
+            <listitem><para>
+                <filename>external-python-tarball</filename> has been renamed
+                to <filename>buildtools-tarball</filename>.
+                </para></listitem>
+            <listitem><para>
+                <filename>web-webkit</filename> has been removed.
+                It has been functionally replaced by
+                <filename>midori</filename>.</para></listitem>
+            <listitem><para>
+                <filename>imake</filename> has been removed.
+                It is no longer needed by any other recipe.
+                </para></listitem>
+            <listitem><para>
+                <filename>transfig-native</filename> has been removed.
+                It is no longer needed by any other recipe.
+                </para></listitem>
+            <listitem><para>
+                <filename>anjuta-remote-run</filename> has been removed.
+                Anjuta IDE integration has not been officially supported for
+                several releases.</para></listitem>
+        </itemizedlist>
+    </section>
+
+    <section id='migration-1.5-other-changes'>
+        <title>Other Changes</title>
+
+        <para>
+            Following is a list of short entries describing other changes:
+            <itemizedlist>
+                <listitem><para>
+                    <filename>run-postinsts</filename>: Make this generic.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>base-files</filename>: Remove the unnecessary
+                    <filename>media/</filename><replaceable>xxx</replaceable> directories.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>alsa-state</filename>: Provide an empty
+                    <filename>asound.conf</filename> by default.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>classes/image</filename>: Ensure
+                    <link linkend='var-BAD_RECOMMENDATIONS'><filename>BAD_RECOMMENDATIONS</filename></link>
+                    supports pre-renamed package names.</para></listitem>
+                <listitem><para>
+                    <filename>classes/rootfs_rpm</filename>: Implement
+                    <link linkend='var-BAD_RECOMMENDATIONS'><filename>BAD_RECOMMENDATIONS</filename></link>
+                    for RPM.</para></listitem>
+                <listitem><para>
+                    <filename>systemd</filename>: Remove
+                    <filename>systemd_unitdir</filename> if
+                    <filename>systemd</filename> is not in
+                    <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>systemd</filename>: Remove
+                    <filename>init.d</filename> dir if
+                    <filename>systemd</filename> unit file is present and
+                    <filename>sysvinit</filename> is not a distro feature.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>libpam</filename>: Deny all services for the
+                    <filename>OTHER</filename> entries.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>image.bbclass</filename>: Move
+                    <filename>runtime_mapping_rename</filename> to avoid
+                    conflict with <filename>multilib</filename>.
+                    See
+                    <ulink url='https://bugzilla.yoctoproject.org/show_bug.cgi?id=4993'><filename>YOCTO #4993</filename></ulink>
+                    in Bugzilla for more information.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>linux-dtb</filename>: Use kernel build system
+                    to generate the <filename>dtb</filename> files.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>kern-tools</filename>: Switch from guilt to
+                    new <filename>kgit-s2q</filename> tool.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
+
+<section id='moving-to-the-yocto-project-1.6-release'>
+    <title>Moving to the Yocto Project 1.6 Release</title>
+
+    <para>
+        This section provides migration information for moving to the
+        Yocto Project 1.6 Release from the prior release.
+    </para>
+
+
+    <section id='migration-1.6-archiver-class'>
+        <title><filename>archiver</filename> Class</title>
+
+        <para>
+            The
+            <link linkend='ref-classes-archiver'><filename>archiver</filename></link>
+            class has been rewritten and its configuration has been simplified.
+            For more details on the source archiver, see the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
+            section in the Yocto Project Development Manual.
+        </para>
+    </section>
+
+    <section id='migration-1.6-packaging-changes'>
+        <title>Packaging Changes</title>
+
+        <para>
+            The following packaging changes have been made:
+            <itemizedlist>
+                <listitem><para>
+                    The <filename>binutils</filename> recipe no longer produces
+                    a <filename>binutils-symlinks</filename> package.
+                    <filename>update-alternatives</filename> is now used to
+                    handle the preferred <filename>binutils</filename>
+                    variant on the target instead.
+                    </para></listitem>
+                <listitem><para>
+                    The tc (traffic control) utilities have been split out of
+                    the main <filename>iproute2</filename> package and put
+                    into the <filename>iproute2-tc</filename> package.
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>gtk-engines</filename> schemas have been
+                    moved to a dedicated
+                    <filename>gtk-engines-schemas</filename> package.
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>armv7a</filename> with thumb package
+                    architecture suffix has changed.
+                    The suffix for these packages with the thumb
+                    optimization enabled is "t2" as it should be.
+                    Use of this suffix was not the case in the 1.5 release.
+                    Architecture names will change within package feeds as a
+                    result.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.6-bitbake'>
+        <title>BitBake</title>
+
+        <para>
+            The following changes have been made to
+            <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>.
+        </para>
+
+        <section id='migration-1.6-matching-branch-requirement-for-git-fetching'>
+            <title>Matching Branch Requirement for Git Fetching</title>
+
+            <para>
+                When fetching source from a Git repository using
+                <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>,
+                BitBake will now validate the
+                <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
+                value against the branch.
+                You can specify the branch using the following form:
+                <literallayout class='monospaced'>
+     SRC_URI = "git://server.name/repository;branch=<replaceable>branchname</replaceable>"
+                </literallayout>
+                If you do not specify a branch, BitBake looks
+                in the default "master" branch.
+            </para>
+
+            <para>
+                Alternatively, if you need to bypass this check (e.g.
+                if you are fetching a revision corresponding to a tag that
+                is not on any branch), you can add ";nobranch=1" to
+                the end of the URL within <filename>SRC_URI</filename>.
+            </para>
+        </section>
+
+        <section id='migration-1.6-bitbake-deps'>
+            <title>Python Definition substitutions</title>
+
+            <para>
+                BitBake had some previously deprecated Python definitions
+                within its <filename>bb</filename> module removed.
+                You should use their sub-module counterparts instead:
+                <itemizedlist>
+                    <listitem><para><filename>bb.MalformedUrl</filename>:
+                        Use <filename>bb.fetch.MalformedUrl</filename>.
+                        </para></listitem>
+                    <listitem><para><filename>bb.fetch.encodeurl</filename>:
+                        Use <filename>bb.fetch.encodeurl</filename>.
+                        </para></listitem>
+                    <listitem><para><filename>bb.decodeurl</filename>:
+                        Use <filename>bb.fetch.decodeurl</filename>
+                        </para></listitem>
+                    <listitem><para><filename>bb.mkdirhier</filename>:
+                        Use <filename>bb.utils.mkdirhier</filename>.
+                        </para></listitem>
+                    <listitem><para><filename>bb.movefile</filename>:
+                        Use <filename>bb.utils.movefile</filename>.
+                        </para></listitem>
+                    <listitem><para><filename>bb.copyfile</filename>:
+                        Use <filename>bb.utils.copyfile</filename>.
+                        </para></listitem>
+                    <listitem><para><filename>bb.which</filename>:
+                        Use <filename>bb.utils.which</filename>.
+                        </para></listitem>
+                    <listitem><para><filename>bb.vercmp_string</filename>:
+                        Use <filename>bb.utils.vercmp_string</filename>.
+                        </para></listitem>
+                    <listitem><para><filename>bb.vercmp</filename>:
+                        Use <filename>bb.utils.vercmp</filename>.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='migration-1.6-bitbake-fetcher'>
+            <title>SVK Fetcher</title>
+
+            <para>
+                The SVK fetcher has been removed from BitBake.
+            </para>
+        </section>
+
+        <section id='migration-1.6-bitbake-console-output'>
+            <title>Console Output Error Redirection</title>
+
+            <para>
+                The BitBake console UI will now output errors to
+                <filename>stderr</filename> instead of
+                <filename>stdout</filename>.
+                Consequently, if you are piping or redirecting the output of
+                <filename>bitbake</filename> to somewhere else, and you wish
+                to retain the errors, you will need to add
+                <filename>2>&amp;1</filename> (or something similar) to the
+                end of your <filename>bitbake</filename> command line.
+            </para>
+        </section>
+
+        <section id='migration-1.6-task-taskname-overrides'>
+            <title><filename>task-</filename><replaceable>taskname</replaceable> Overrides</title>
+
+            <para>
+                <filename>task-</filename><replaceable>taskname</replaceable> overrides have been
+                adjusted so that tasks whose names contain underscores have the
+                underscores replaced by hyphens for the override so that they
+                now function properly.
+                For example, the task override for
+                <link linkend='ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></link>
+                is <filename>task-populate-sdk</filename>.
+            </para>
+        </section>
+    </section>
+
+    <section id='migration-1.6-variable-changes'>
+        <title>Changes to Variables</title>
+
+        <para>
+            The following variables have changed.
+            For information on the OpenEmbedded build system variables, see the
+            "<link linkend='ref-variables-glos'>Variables Glossary</link>" Chapter.
+        </para>
+
+        <section id='migration-1.6-variable-changes-TMPDIR'>
+            <title><filename>TMPDIR</filename></title>
+
+            <para>
+                <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
+                can no longer be on an NFS mount.
+                NFS does not offer full POSIX locking and inode consistency
+                and can cause unexpected issues if used to store
+                <filename>TMPDIR</filename>.
+            </para>
+
+            <para>
+                The check for this occurs on startup.
+                If <filename>TMPDIR</filename> is detected on an NFS mount,
+                an error occurs.
+            </para>
+        </section>
+
+        <section id='migration-1.6-variable-changes-PRINC'>
+            <title><filename>PRINC</filename></title>
+
+            <para>
+                The
+                <link linkend='var-PRINC'><filename>PRINC</filename></link>
+                variable has been deprecated and triggers a warning if
+                detected during a build.
+                For
+                <link linkend='var-PR'><filename>PR</filename></link>
+                increments on changes, use the PR service instead.
+                You can find out more about this service in the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service'>Working With a PR Service</ulink>"
+                section in the Yocto Project Development Manual.
+            </para>
+        </section>
+
+        <section id='migration-1.6-variable-changes-IMAGE_TYPES'>
+            <title><filename>IMAGE_TYPES</filename></title>
+
+            <para>
+                The "sum.jffs2" option for
+                <link linkend='var-IMAGE_TYPES'><filename>IMAGE_TYPES</filename></link>
+                has been replaced by the "jffs2.sum" option, which fits the
+                processing order.
+            </para>
+        </section>
+
+        <section id='migration-1.6-variable-changes-COPY_LIC_MANIFEST'>
+            <title><filename>COPY_LIC_MANIFEST</filename></title>
+
+            <para>
+                The
+                <link linkend='var-COPY_LIC_MANIFEST'><filename>COPY_LIC_MANIFEST</filename></link>
+                variable must
+                now be set to "1" rather than any value in order to enable
+                it.
+            </para>
+        </section>
+
+        <section id='migration-1.6-variable-changes-COPY_LIC_DIRS'>
+            <title><filename>COPY_LIC_DIRS</filename></title>
+
+            <para>
+                The
+                <link linkend='var-COPY_LIC_DIRS'><filename>COPY_LIC_DIRS</filename></link>
+                variable must
+                now be set to "1" rather than any value in order to enable
+                it.
+            </para>
+        </section>
+
+        <section id='migration-1.6-variable-changes-PACKAGE_GROUP'>
+            <title><filename>PACKAGE_GROUP</filename></title>
+
+            <para>
+                The
+                <link linkend='var-PACKAGE_GROUP'><filename>PACKAGE_GROUP</filename></link>
+                variable has been renamed to
+                <link linkend='var-FEATURE_PACKAGES'><filename>FEATURE_PACKAGES</filename></link>
+                to more accurately reflect its purpose.
+                You can still use <filename>PACKAGE_GROUP</filename> but
+                the OpenEmbedded build system produces a warning message when
+                it encounters the variable.
+            </para>
+        </section>
+    </section>
+
+    <section id='migration-1.6-directory-layout-changes'>
+        <title>Directory Layout Changes</title>
+
+        <para>
+            The <filename>meta-hob</filename> layer has been removed from
+            the top-level of the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            The contents of this layer are no longer needed by the Hob
+            user interface for building images and toolchains.
+        </para>
+    </section>
+
+    <section id='migration-1.6-package-test-ptest'>
+        <title>Package Test (ptest)</title>
+
+        <para>
+            Package Tests (ptest) are built but not installed by default.
+            For information on using Package Tests, see the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest'>Setting up and running package test (ptest)</ulink>"
+            section in the Yocto Project Development Manual.
+            For information on the <filename>ptest</filename> class, see the
+            "<link linkend='ref-classes-ptest'><filename>ptest.bbclass</filename></link>"
+            section.
+        </para>
+    </section>
+
+    <section id='migration-1.6-build-changes'>
+        <title>Build Changes</title>
+
+        <para>
+            Separate build and source directories have been enabled
+            by default for selected recipes where it is known to work
+            (a whitelist) and for all recipes that inherit the
+            <link linkend='ref-classes-cmake'><filename>cmake</filename></link>
+            class.
+            In future releases the
+            <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
+            class will enable a separate build directory by default as
+            well.
+            Recipes building Autotools-based
+            software that fails to build with a separate build directory
+            should be changed to inherit from the
+            <link linkend='ref-classes-autotools-brokensep'><filename>autotools-brokensep</filename></link>
+            class instead of the <filename>autotools</filename> class.
+        </para>
+    </section>
+
+    <section id='migration-1.6-building-qemu-native'>
+        <title><filename>qemu-native</filename></title>
+
+        <para>
+            <filename>qemu-native</filename> now builds without
+            SDL-based graphical output support by default.
+            The following additional lines are needed in your
+            <filename>local.conf</filename> to enable it:
+            <literallayout class='monospaced'>
+     PACKAGECONFIG_pn-qemu-native = "sdl"
+     ASSUME_PROVIDED += "libsdl-native"
+            </literallayout>
+            <note>
+                The default <filename>local.conf</filename>
+                contains these statements.
+                Consequently, if you are building a headless system and using
+                a default <filename>local.conf</filename> file, you will need
+                comment these two lines out.
+            </note>
+        </para>
+    </section>
+
+    <section id='migration-1.6-core-image-basic'>
+        <title><filename>core-image-basic</filename></title>
+
+        <para>
+            <filename>core-image-basic</filename> has been renamed to
+            <filename>core-image-full-cmdline</filename>.
+        </para>
+
+        <para>
+            In addition to <filename>core-image-basic</filename> being renamed,
+            <filename>packagegroup-core-basic</filename> has been renamed to
+            <filename>packagegroup-core-full-cmdline</filename> to match.
+        </para>
+    </section>
+
+    <section id='migration-1.6-licensing'>
+        <title>Licensing</title>
+
+        <para>
+            The top-level <filename>LICENSE</filename> file has been changed
+            to better describe the license of the various components of
+            OE-Core.
+            However, the licensing itself remains unchanged.
+        </para>
+
+        <para>
+            Normally, this change would not cause any side-effects.
+            However, some recipes point to this file within
+            <link linkend='var-LIC_FILES_CHKSUM'><filename>LIC_FILES_CHKSUM</filename></link>
+            (as <filename>${COREBASE}/LICENSE</filename>) and thus the
+            accompanying checksum must be changed from
+            3f40d7994397109285ec7b81fdeb3b58 to
+            4d92cd373abda3937c2bc47fbc49d690.
+            A better alternative is to have
+            <filename>LIC_FILES_CHKSUM</filename> point to a file
+            describing the license that is distributed with the source
+            that the recipe is building, if possible, rather than pointing
+            to <filename>${COREBASE}/LICENSE</filename>.
+        </para>
+    </section>
+
+    <section id='migration-1.6-cflags-options'>
+        <title><filename>CFLAGS</filename> Options</title>
+
+        <para>
+            The "-fpermissive" option has been removed from the default
+            <link linkend='var-CFLAGS'><filename>CFLAGS</filename></link>
+            value.
+            You need to take action on individual recipes that fail when
+            building with this option.
+            You need to either patch the recipes to fix the issues reported by
+            the compiler, or you need to add "-fpermissive" to
+            <filename>CFLAGS</filename> in the recipes.
+        </para>
+    </section>
+
+    <section id='migration-1.6-custom-images'>
+        <title>Custom Image Output Types</title>
+
+        <para>
+            Custom image output types, as selected using
+            <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>,
+            must declare their dependencies on other image types (if any) using
+            a new
+            <link linkend='var-IMAGE_TYPEDEP'><filename>IMAGE_TYPEDEP</filename></link>
+            variable.
+        </para>
+    </section>
+
+    <section id='migration-1.6-do-package-write-task'>
+        <title>Tasks</title>
+
+        <para>
+            The <filename>do_package_write</filename> task has been removed.
+            The task is no longer needed.
+        </para>
+    </section>
+
+    <section id='migration-1.6-update-alternatives-provider'>
+        <title><filename>update-alternative</filename> Provider</title>
+
+        <para>
+            The default <filename>update-alternatives</filename> provider has
+            been changed from <filename>opkg</filename> to
+            <filename>opkg-utils</filename>.
+            This change resolves some troublesome circular dependencies.
+            The runtime package has also been renamed from
+            <filename>update-alternatives-cworth</filename>
+            to <filename>update-alternatives-opkg</filename>.
+        </para>
+    </section>
+
+    <section id='migration-1.6-virtclass-overrides'>
+        <title><filename>virtclass</filename> Overrides</title>
+
+        <para>
+            The <filename>virtclass</filename> overrides are now deprecated.
+            Use the equivalent class overrides instead (e.g.
+            <filename>virtclass-native</filename> becomes
+            <filename>class-native</filename>.)
+        </para>
+    </section>
+
+    <section id='migration-1.6-removed-renamed-recipes'>
+        <title>Removed and Renamed Recipes</title>
+
+        <para>
+            The following recipes have been removed:
+            <itemizedlist>
+                <listitem><para><filename>packagegroup-toolset-native</filename> -
+                    This recipe is largely unused.
+                    </para></listitem>
+                <listitem><para><filename>linux-yocto-3.8</filename> -
+                    Support for the Linux yocto 3.8 kernel has been dropped.
+                    Support for the 3.10 and 3.14 kernels have been added
+                    with the <filename>linux-yocto-3.10</filename> and
+                    <filename>linux-yocto-3.14</filename> recipes.
+                    </para></listitem>
+                <listitem><para><filename>ocf-linux</filename> -
+                    This recipe has been functionally replaced using
+                    <filename>cryptodev-linux</filename>.
+                    </para></listitem>
+                <listitem><para><filename>genext2fs</filename> -
+                    <filename>genext2fs</filename> is no longer used by the
+                    build system and is unmaintained upstream.
+                    </para></listitem>
+                <listitem><para><filename>js</filename> -
+                    This provided an ancient version of Mozilla's javascript
+                    engine that is no longer needed.
+                    </para></listitem>
+                <listitem><para><filename>zaurusd</filename> -
+                    The recipe has been moved to the
+                    <filename>meta-handheld</filename> layer.
+                    </para></listitem>
+                <listitem><para><filename>eglibc 2.17</filename> -
+                    Replaced by the <filename>eglibc 2.19</filename>
+                    recipe.
+                    </para></listitem>
+                <listitem><para><filename>gcc 4.7.2</filename> -
+                    Replaced by the now stable
+                    <filename>gcc 4.8.2</filename>.
+                    </para></listitem>
+                <listitem><para><filename>external-sourcery-toolchain</filename> -
+                    this recipe is now maintained in the
+                    <filename>meta-sourcery</filename> layer.
+                    </para></listitem>
+                <listitem><para><filename>linux-libc-headers-yocto 3.4+git</filename> -
+                    Now using version 3.10 of the
+                    <filename>linux-libc-headers</filename> by default.
+                    </para></listitem>
+                <listitem><para><filename>meta-toolchain-gmae</filename> -
+                    This recipe is obsolete.
+                    </para></listitem>
+                <listitem><para><filename>packagegroup-core-sdk-gmae</filename> -
+                    This recipe is obsolete.
+                    </para></listitem>
+                <listitem><para><filename>packagegroup-core-standalone-gmae-sdk-target</filename> -
+                    This recipe is obsolete.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.6-removed-classes'>
+        <title>Removed Classes</title>
+
+        <para>
+            The following classes have become obsolete and have been removed:
+            <itemizedlist>
+                <listitem><para><filename>module_strip</filename>
+                    </para></listitem>
+                <listitem><para><filename>pkg_metainfo</filename>
+                    </para></listitem>
+                <listitem><para><filename>pkg_distribute</filename>
+                    </para></listitem>
+                <listitem><para><filename>image-empty</filename>
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.6-reference-bsps'>
+        <title>Reference Board Support Packages (BSPs)</title>
+
+        <para>
+            The following reference BSPs changes occurred:
+            <itemizedlist>
+                <listitem><para>The BeagleBoard
+                    (<filename>beagleboard</filename>) ARM reference hardware
+                    has been replaced by the BeagleBone
+                    (<filename>beaglebone</filename>) hardware.
+                    </para></listitem>
+                <listitem><para>The RouterStation Pro
+                    (<filename>routerstationpro</filename>) MIPS reference
+                    hardware has been replaced by the EdgeRouter Lite
+                    (<filename>edgerouter</filename>) hardware.
+                    </para></listitem>
+            </itemizedlist>
+            The previous reference BSPs for the
+            <filename>beagleboard</filename> and
+            <filename>routerstationpro</filename> machines are still available
+            in a new <filename>meta-yocto-bsp-old</filename> layer in the
+            <ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink>
+            at
+            <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto-bsp-old/'>http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto-bsp-old/</ulink>.
+        </para>
+    </section>
+</section>
+
+<section id='moving-to-the-yocto-project-1.7-release'>
+    <title>Moving to the Yocto Project 1.7 Release</title>
+
+    <para>
+        This section provides migration information for moving to the
+        Yocto Project 1.7 Release from the prior release.
+    </para>
+
+    <section id='migration-1.7-changes-to-setting-qemu-packageconfig-options'>
+        <title>Changes to Setting QEMU <filename>PACKAGECONFIG</filename> Options in <filename>local.conf</filename></title>
+
+        <para>
+            The QEMU recipe now uses a number of
+            <link linkend='var-PACKAGECONFIG'><filename>PACKAGECONFIG</filename></link>
+            options to enable various optional features.
+            The method used to set defaults for these options means that
+            existing
+            <filename>local.conf</filename> files will need to be be
+            modified to append to <filename>PACKAGECONFIG</filename> for
+            <filename>qemu-native</filename> and
+            <filename>nativesdk-qemu</filename> instead of setting it.
+            In other words, to enable graphical output for QEMU, you should
+            now have these lines in <filename>local.conf</filename>:
+            <literallayout class='monospaced'>
+     PACKAGECONFIG_append_pn-qemu-native = " sdl"
+     PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='migration-1.7-minimum-git-version'>
+        <title>Minimum Git version</title>
+
+        <para>
+            The minimum
+            <ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink> version required
+            on the build host is now 1.7.8 because the
+            <filename>&dash;&dash;list</filename> option is now required by
+            BitBake's Git fetcher.
+            As always, if your host distribution does not provide a version of
+            Git that meets this requirement, you can use the
+            <filename>buildtools-tarball</filename> that does.
+            See the
+            "<link linkend='required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</link>"
+            section for more information.
+        </para>
+    </section>
+
+    <section id='migration-1.7-autotools-class-changes'>
+        <title>Autotools Class Changes</title>
+
+        <para>
+            The following
+            <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
+            class changes occurred:
+            <itemizedlist>
+                <listitem><para><emphasis>
+                    A separate build directory is now used by default:</emphasis>
+                    The <filename>autotools</filename> class has been changed
+                    to use a directory for building
+                    (<link linkend='var-B'><filename>B</filename></link>),
+                    which is separate from the source directory
+                    (<link linkend='var-S'><filename>S</filename></link>).
+                    This is commonly referred to as
+                    <filename>B != S</filename>, or an out-of-tree build.</para>
+                    <para>If the software being built is already capable of
+                    building in a directory separate from the source, you
+                    do not need to do anything.
+                    However, if the software is not capable of being built
+                    in this manner, you will
+                    need to either patch the software so that it can build
+                    separately, or you will need to change the recipe to
+                    inherit the
+                    <link linkend='ref-classes-autotools-brokensep'><filename>autotools-brokensep</filename></link>
+                    class instead of the <filename>autotools</filename> class.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    The <filename>&dash;&dash;foreign</filename> option is
+                    no longer passed to <filename>automake</filename> when
+                    running <filename>autoconf</filename>:</emphasis>
+                    This option tells <filename>automake</filename> that a
+                    particular software package does not follow the GNU
+                    standards and therefore should not be expected
+                    to distribute certain files such as
+                    <filename>ChangeLog</filename>,
+                    <filename>AUTHORS</filename>, and so forth.
+                    Because the majority of upstream software packages already
+                    tell <filename>automake</filename> to enable foreign mode
+                    themselves, the option is mostly superfluous.
+                    However, some recipes will need patches for this change.
+                    You can easily make the change by patching
+                    <filename>configure.ac</filename> so that it passes
+                    "foreign" to <filename>AM_INIT_AUTOMAKE()</filename>.
+                    See
+                    <ulink url='http://cgit.openembedded.org/openembedded-core/commit/?id=01943188f85ce6411717fb5bf702d609f55813f2'>this commit</ulink>
+                    for an example showing how to make the patch.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.7-binary-configuration-scripts-disabled'>
+        <title>Binary Configuration Scripts Disabled</title>
+
+        <para>
+            Some of the core recipes that package binary configuration scripts
+            now disable the scripts due to the
+            scripts previously requiring error-prone path substitution.
+            Software that links against these libraries using these scripts
+            should use the much more robust <filename>pkg-config</filename>
+            instead.
+            The list of recipes changed in this version (and their
+            configuration scripts) is as follows:
+            <literallayout class='monospaced'>
+     directfb (directfb-config)
+     freetype (freetype-config)
+     gpgme (gpgme-config)
+     libassuan (libassuan-config)
+     libcroco (croco-6.0-config)
+     libgcrypt (libgcrypt-config)
+     libgpg-error (gpg-error-config)
+     libksba (ksba-config)
+     libpcap (pcap-config)
+     libpcre (pcre-config)
+     libpng (libpng-config, libpng16-config)
+     libsdl (sdl-config)
+     libusb-compat (libusb-config)
+     libxml2 (xml2-config)
+     libxslt (xslt-config)
+     ncurses (ncurses-config)
+     neon (neon-config)
+     npth (npth-config)
+     pth (pth-config)
+     taglib (taglib-config)
+            </literallayout>
+            Additionally, support for <filename>pkg-config</filename> has been
+            added to some recipes in the previous list in the rare cases
+            where the upstream software package does not already provide
+            it.
+        </para>
+    </section>
+
+    <section id='migration-1.7-glibc-replaces-eglibc'>
+        <title><filename>eglibc 2.19</filename> Replaced with <filename>glibc 2.20</filename></title>
+
+        <para>
+            Because <filename>eglibc</filename> and
+            <filename>glibc</filename> were already fairly close, this
+            replacement should not require any significant changes to other
+            software that links to <filename>eglibc</filename>.
+            However, there were a number of minor changes in
+            <filename>glibc 2.20</filename> upstream that could require
+            patching some software (e.g. the removal of the
+            <filename>_BSD_SOURCE</filename> feature test macro).
+        </para>
+
+        <para>
+            <filename>glibc 2.20</filename> requires version 2.6.32 or greater
+            of the Linux kernel.
+            Thus, older kernels will no longer be usable in conjunction with it.
+        </para>
+
+        <para>
+            For full details on the changes in <filename>glibc 2.20</filename>,
+            see the upstream release notes
+            <ulink url='https://sourceware.org/ml/libc-alpha/2014-09/msg00088.html'>here</ulink>.
+        </para>
+    </section>
+
+    <section id='migration-1.7-kernel-module-autoloading'>
+        <title>Kernel Module Autoloading</title>
+
+        <para>
+            The
+            <link linkend='var-module_autoload'><filename>module_autoload_*</filename></link>
+            variable is now deprecated and a new
+            <link linkend='var-KERNEL_MODULE_AUTOLOAD'><filename>KERNEL_MODULE_AUTOLOAD</filename></link>
+            variable should be used instead.
+            Also,
+            <link linkend='var-module_conf'><filename>module_conf_*</filename></link>
+            must now be used in conjunction with a new
+            <link linkend='var-KERNEL_MODULE_PROBECONF'><filename>KERNEL_MODULE_PROBECONF</filename></link>
+            variable.
+            The new variables no longer require you to specify the module name
+            as part of the variable name.
+            This change not only simplifies usage but also allows the values
+            of these variables to be appropriately incorporated into task
+            signatures and thus trigger the appropriate tasks to re-execute
+            when changed.
+            You should replace any references to
+            <filename>module_autoload_*</filename> with
+            <filename>KERNEL_MODULE_AUTOLOAD</filename>, and add any modules
+            for which <filename>module_conf_*</filename> is specified to
+            <filename>KERNEL_MODULE_PROBECONF</filename>.
+        </para>
+
+        <para>
+            For more information, see the
+            <link linkend='var-KERNEL_MODULE_AUTOLOAD'><filename>KERNEL_MODULE_AUTOLOAD</filename></link>
+            and
+            <link linkend='var-KERNEL_MODULE_PROBECONF'><filename>KERNEL_MODULE_PROBECONF</filename></link>
+            variables.
+        </para>
+    </section>
+
+    <section id='migration-1.7-qa-check-changes'>
+        <title>QA Check Changes</title>
+
+        <para>
+            The following changes have occurred to the QA check process:
+            <itemizedlist>
+                <listitem><para>
+                    Additional QA checks <filename>file-rdeps</filename>
+                    and <filename>build-deps</filename> have been added in
+                    order to verify that file dependencies are satisfied
+                    (e.g. package contains a script requiring
+                    <filename>/bin/bash</filename>) and build-time dependencies
+                    are declared, respectively.
+                    For more information, please see the
+                    "<link linkend='ref-qa-checks'>QA Error and Warning Messages</link>"
+                    chapter.
+                    </para></listitem>
+                <listitem><para>
+                    Package QA checks are now performed during a new
+                    <link linkend='ref-tasks-package_qa'><filename>do_package_qa</filename></link>
+                    task rather than being part of the
+                    <link linkend='ref-tasks-package'><filename>do_package</filename></link>
+                    task.
+                    This allows more parallel execution.
+                    This change is unlikely to be an issue except for highly
+                    customized recipes that disable packaging tasks themselves
+                    by marking them as <filename>noexec</filename>.
+                    For those packages, you will need to disable the
+                    <filename>do_package_qa</filename> task as well.
+                    </para></listitem>
+                <listitem><para>
+                    Files being overwritten during the
+                    <link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link>
+                    task now trigger an error instead of a warning.
+                    Recipes should not be overwriting files written to the
+                    sysroot by other recipes.
+                    If you have these types of recipes, you need to alter them
+                    so that they do not overwrite these files.</para>
+                    <para>You might now receive this error after changes in
+                    configuration or metadata resulting in orphaned files
+                    being left in the sysroot.
+                    If you do receive this error, the way to resolve the issue
+                    is to delete your
+                    <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
+                    or to move it out of the way and then re-start the build.
+                    Anything that has been fully built up to that point and
+                    does not need rebuilding will be restored from the shared
+                    state cache and the rest of the build will be able to
+                    proceed as normal.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.7-removed-recipes'>
+        <title>Removed Recipes</title>
+
+        <para>
+            The following recipes have been removed:
+            <itemizedlist>
+                <listitem><para>
+                    <filename>x-load</filename>:
+                    This recipe has been superseded by
+                    U-boot SPL for all Cortex-based TI SoCs.
+                    For legacy boards, the <filename>meta-ti</filename>
+                    layer, which contains a maintained recipe, should be used
+                    instead.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>ubootchart</filename>:
+                    This recipe is obsolete.
+                    A <filename>bootchart2</filename> recipe has been added
+                    to functionally replace it.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>linux-yocto 3.4</filename>:
+                    Support for the linux-yocto 3.4 kernel has been dropped.
+                    Support for the 3.10 and 3.14 kernels remains, while
+                    support for version 3.17 has been added.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>eglibc</filename> has been removed in favor of
+                    <filename>glibc</filename>.
+                    See the
+                    "<link linkend='migration-1.7-glibc-replaces-eglibc'><filename>eglibc 2.19</filename> Replaced with <filename>glibc 2.20</filename></link>"
+                    section for more information.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.7-miscellaneous-changes'>
+        <title>Miscellaneous Changes</title>
+
+        <para>
+            The following miscellaneous change occurred:
+            <itemizedlist>
+                <listitem><para>
+                    The build history feature now writes
+                    <filename>build-id.txt</filename> instead of
+                    <filename>build-id</filename>.
+                    Additionally, <filename>build-id.txt</filename>
+                    now contains the full build header as printed by
+                    BitBake upon starting the build.
+                    You should manually remove old "build-id" files from your
+                    existing build history repositories to avoid confusion.
+                    For information on the build history feature, see the
+                    "<link linkend='maintaining-build-output-quality'>Maintaining Build Output Quality</link>"
+                    section.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/ref-bitbake.xml b/documentation/ref-manual/ref-bitbake.xml
new file mode 100644
index 0000000000..30aff6431f
--- /dev/null
+++ b/documentation/ref-manual/ref-bitbake.xml
@@ -0,0 +1,472 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='ref-bitbake'>
+
+    <title>BitBake</title>
+
+    <para>
+        BitBake is a program written in Python that interprets the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> used by
+        the OpenEmbedded build system.
+        At some point, developers wonder what actually happens when you enter:
+        <literallayout class='monospaced'>
+     $ bitbake core-image-sato
+        </literallayout>
+    </para>
+
+    <para>
+        This chapter provides an overview of what happens behind the scenes from BitBake's perspective.
+    </para>
+
+    <note>
+        BitBake strives to be a generic "task" executor that is capable of handling complex dependency relationships.
+        As such, it has no real knowledge of what the tasks being executed actually do.
+        BitBake just considers a list of tasks with dependencies and handles
+        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+        consisting of variables in a certain format that get passed to the tasks.
+    </note>
+
+    <section id='ref-bitbake-parsing'>
+        <title>Parsing</title>
+
+        <para>
+            BitBake parses configuration files, classes, and <filename>.bb</filename> files.
+        </para>
+
+        <para>
+            The first thing BitBake does is look for the <filename>bitbake.conf</filename> file.
+            This file resides in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            within the <filename>meta/conf/</filename> directory.
+            BitBake finds it by examining its
+            <link linkend='var-BBPATH'><filename>BBPATH</filename></link> environment
+            variable and looking for the <filename>meta/conf/</filename>
+            directory.
+        </para>
+
+        <para>
+            The <filename>bitbake.conf</filename> file lists other configuration
+            files to include from a <filename>conf/</filename>
+            directory below the directories listed in <filename>BBPATH</filename>.
+            In general, the most important configuration file from a user's perspective
+            is <filename>local.conf</filename>, which contains a user's customized
+            settings for the OpenEmbedded build environment.
+            Other notable configuration files are the distribution
+            configuration file (set by the
+            <filename><link linkend='var-DISTRO'>DISTRO</link></filename> variable)
+            and the machine configuration file
+            (set by the
+            <filename><link linkend='var-MACHINE'>MACHINE</link></filename> variable).
+            The <filename>DISTRO</filename> and <filename>MACHINE</filename> BitBake environment
+            variables are both usually set in
+            the <filename>local.conf</filename> file.
+            Valid distribution
+            configuration files are available in the <filename>meta/conf/distro/</filename> directory
+            and valid machine configuration
+            files in the <filename>meta/conf/machine/</filename> directory.
+            Within the <filename>meta/conf/machine/include/</filename>
+            directory are various <filename>tune-*.inc</filename> configuration files that provide common
+            "tuning" settings specific to and shared between particular architectures and machines.
+        </para>
+
+        <para>
+            After the parsing of the configuration files, some standard classes are included.
+            The <filename>base.bbclass</filename> file is always included.
+            Other classes that are specified in the configuration using the
+            <filename><link linkend='var-INHERIT'>INHERIT</link></filename>
+            variable are also included.
+            Class files are searched for in a <filename>classes</filename> subdirectory
+            under the paths in <filename>BBPATH</filename> in the same way as
+            configuration files.
+        </para>
+
+        <para>
+            After classes are included, the variable
+            <filename><link linkend='var-BBFILES'>BBFILES</link></filename>
+            is set, usually in
+            <filename>local.conf</filename>, and defines the list of places to search for
+            <filename>.bb</filename> files.
+            By default, the <filename>BBFILES</filename> variable specifies the
+            <filename>meta/recipes-*/</filename> directory within Poky.
+            Adding extra content to <filename>BBFILES</filename> is best achieved through the use of
+            BitBake layers as described in the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and
+            Creating Layers</ulink>" section of the Yocto Project Development Manual.
+        </para>
+
+        <para>
+            BitBake parses each <filename>.bb</filename> file in <filename>BBFILES</filename> and
+            stores the values of various variables.
+            In summary, for each <filename>.bb</filename>
+            file the configuration plus the base class of variables are set, followed
+            by the data in the <filename>.bb</filename> file
+            itself, followed by any inherit commands that
+            <filename>.bb</filename> file might contain.
+        </para>
+
+        <para>
+            Because parsing <filename>.bb</filename> files is a time
+            consuming process, a cache is kept to speed up subsequent parsing.
+            This cache is invalid if the timestamp of the <filename>.bb</filename>
+            file itself changes, or if the timestamps of any of the include,
+            configuration files or class files on which the
+            <filename>.bb</filename> file depends change.
+        </para>
+
+        <note>
+            <para>
+                You need to be aware of how BitBake parses curly braces.
+                If a recipe uses a closing curly brace within the function and
+                the character has no leading spaces, BitBake produces a parsing
+                error.
+                If you use a pair of curly brace in a shell function, the
+                closing curly brace must not be located at the start of the line
+                without leading spaces.
+            </para>
+
+            <para>
+                Here is an example that causes BitBake to produce a parsing
+                error:
+                <literallayout class='monospaced'>
+     fakeroot create_shar() {
+         cat &lt;&lt; "EOF" &gt; ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
+     usage()
+     {
+       echo "test"
+       ###### The following "}" at the start of the line causes a parsing error ######
+     }
+     EOF
+     }
+                </literallayout>
+                Writing the recipe this way avoids the error:
+                <literallayout class='monospaced'>
+     fakeroot create_shar() {
+         cat &lt;&lt; "EOF" &gt; ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
+     usage()
+     {
+       echo "test"
+       ######The following "}" with a leading space at the start of the line avoids the error ######
+      }
+     EOF
+     }
+                </literallayout>
+            </para>
+        </note>
+    </section>
+
+    <section id='ref-bitbake-providers'>
+        <title>Preferences and Providers</title>
+
+        <para>
+            Once all the <filename>.bb</filename> files have been
+            parsed, BitBake starts to build the target (<filename>core-image-sato</filename>
+            in the previous section's example) and looks for providers of that target.
+            Once a provider is selected, BitBake resolves all the dependencies for
+            the target.
+            In the case of <filename>core-image-sato</filename>, it would lead to
+            <filename>packagegroup-core-x11-sato</filename>,
+            which in turn leads to recipes like <filename>matchbox-terminal</filename>,
+            <filename>pcmanfm</filename> and <filename>gthumb</filename>.
+            These recipes in turn depend on <filename>glibc</filename> and the toolchain.
+        </para>
+
+        <para>
+            Sometimes a target might have multiple providers.
+            A common example is "virtual/kernel", which is provided by each kernel package.
+            Each machine often selects the best kernel provider by using a line similar to the
+            following in the machine configuration file:
+        </para>
+
+        <literallayout class='monospaced'>
+     PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+        </literallayout>
+
+        <para>
+            The default <filename><link linkend='var-PREFERRED_PROVIDER'>PREFERRED_PROVIDER</link></filename>
+            is the provider with the same name as the target.
+        </para>
+
+        <para>
+            Understanding how providers are chosen is made complicated by the fact
+            that multiple versions might exist.
+            BitBake defaults to the highest version of a provider.
+            Version comparisons are made using the same method as Debian.
+            You can use the
+            <filename><link linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></filename>
+            variable to specify a particular version (usually in the distro configuration).
+            You can influence the order by using the
+            <filename><link linkend='var-DEFAULT_PREFERENCE'>DEFAULT_PREFERENCE</link></filename>
+            variable.
+            By default, files have a preference of "0".
+            Setting the <filename>DEFAULT_PREFERENCE</filename> to "-1" makes the
+            package unlikely to be used unless it is explicitly referenced.
+            Setting the <filename>DEFAULT_PREFERENCE</filename> to "1" makes it likely the package is used.
+            <filename>PREFERRED_VERSION</filename> overrides any <filename>DEFAULT_PREFERENCE</filename> setting.
+            <filename>DEFAULT_PREFERENCE</filename> is often used to mark newer and more experimental package
+            versions until they have undergone sufficient testing to be considered stable.
+        </para>
+
+        <para>
+            In summary, BitBake has created a list of providers, which is prioritized, for each target.
+        </para>
+    </section>
+
+    <section id='ref-bitbake-dependencies'>
+        <title>Dependencies</title>
+
+        <para>
+            Each target BitBake builds consists of multiple tasks such as
+            <filename>fetch</filename>, <filename>unpack</filename>,
+            <filename>patch</filename>, <filename>configure</filename>,
+            and <filename>compile</filename>.
+            For best performance on multi-core systems, BitBake considers each task as an independent
+            entity with its own set of dependencies.
+        </para>
+
+        <para>
+            Dependencies are defined through several variables.
+            You can find information about variables BitBake uses in the BitBake documentation,
+            which is found in the <filename>bitbake/doc/manual</filename> directory within the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            At a basic level, it is sufficient to know that BitBake uses the
+            <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename> and
+            <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename> variables when
+            calculating dependencies.
+        </para>
+    </section>
+
+    <section id='ref-bitbake-tasklist'>
+        <title>The Task List</title>
+
+        <para>
+            Based on the generated list of providers and the dependency information,
+            BitBake can now calculate exactly what tasks it needs to run and in what
+            order it needs to run them.
+            The build now starts with BitBake forking off threads up to the limit set in the
+            <filename><link linkend='var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</link></filename> variable.
+            BitBake continues to fork threads as long as there are tasks ready to run,
+            those tasks have all their dependencies met, and the thread threshold has not been
+            exceeded.
+        </para>
+
+        <para>
+            It is worth noting that you can greatly speed up the build time by properly setting
+            the <filename>BB_NUMBER_THREADS</filename> variable.
+            See the
+            "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>"
+            section in the Yocto Project Quick Start for more information.
+        </para>
+
+        <para>
+            As each task completes, a timestamp is written to the directory specified by the
+            <filename><link linkend='var-STAMP'>STAMP</link></filename> variable.
+            On subsequent runs, BitBake looks within the <filename>build/tmp/stamps</filename>
+            directory and does not rerun
+            tasks that are already completed unless a timestamp is found to be invalid.
+            Currently, invalid timestamps are only considered on a per
+            <filename>.bb</filename> file basis.
+            So, for example, if the configure stamp has a timestamp greater than the
+            compile timestamp for a given target, then the compile task would rerun.
+            Running the compile task again, however, has no effect on other providers
+            that depend on that target.
+            This behavior could change or become configurable in future versions of BitBake.
+        </para>
+
+        <note>
+            Some tasks are marked as "nostamp" tasks.
+            No timestamp file is created when these tasks are run.
+            Consequently, "nostamp" tasks are always rerun.
+        </note>
+    </section>
+
+    <section id='ref-bitbake-runtask'>
+        <title>Running a Task</title>
+
+        <para>
+            Tasks can either be a shell task or a Python task.
+            For shell tasks, BitBake writes a shell script to
+            <filename>${WORKDIR}/temp/run.do_taskname.pid</filename> and then executes the script.
+            The generated shell script contains all the exported variables, and the shell functions
+            with all variables expanded.
+            Output from the shell script goes to the file <filename>${WORKDIR}/temp/log.do_taskname.pid</filename>.
+            Looking at the expanded shell functions in the run file and the output in the log files
+            is a useful debugging technique.
+        </para>
+
+        <para>
+            For Python tasks, BitBake executes the task internally and logs information to the
+            controlling terminal.
+            Future versions of BitBake will write the functions to files similar to the way
+            shell tasks are handled.
+            Logging will be handled in a way similar to shell tasks as well.
+        </para>
+
+        <para>
+            Once all the tasks have been completed BitBake exits.
+        </para>
+
+        <para>
+            When running a task, BitBake tightly controls the execution environment
+            of the build tasks to make sure unwanted contamination from the build machine
+            cannot influence the build.
+            Consequently, if you do want something to get passed into the build
+            task's environment, you must take a few steps:
+            <orderedlist>
+                <listitem><para>Tell BitBake to load what you want from the environment
+                    into the data store.
+                    You can do so through the <filename>BB_ENV_EXTRAWHITE</filename>
+                    variable.
+                    For example, assume you want to prevent the build system from
+                    accessing your <filename>$HOME/.ccache</filename> directory.
+                    The following command tells BitBake to load
+                    <filename>CCACHE_DIR</filename> from the environment into the data
+                    store:
+                    <literallayout class='monospaced'>
+     export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR"
+                    </literallayout></para></listitem>
+                <listitem><para>Tell BitBake to export what you have loaded into the
+                    environment store to the task environment of every running task.
+                    Loading something from the environment into the data store
+                    (previous step) only makes it available in the datastore.
+                    To export it to the task environment of every running task,
+                    use a command similar to the following in your
+                    <filename>local.conf</filename> or distro configuration file:
+                    <literallayout class='monospaced'>
+     export CCACHE_DIR
+                    </literallayout></para></listitem>
+            </orderedlist>
+        </para>
+
+        <note>
+            A side effect of the previous steps is that BitBake records the variable
+            as a dependency of the build process in things like the shared state
+            checksums.
+            If doing so results in unnecessary rebuilds of tasks, you can whitelist the
+            variable so that the shared state code ignores the dependency when it creates
+            checksums.
+            For information on this process, see the <filename>BB_HASHBASE_WHITELIST</filename>
+            example in the "<link linkend='checksums'>Checksums (Signatures)</link>" section.
+        </note>
+    </section>
+
+    <section id='ref-bitbake-commandline'>
+        <title>BitBake Command Line</title>
+
+        <para>
+            Following is the BitBake help output:
+        </para>
+
+        <screen>
+$ bitbake --help
+Usage: bitbake [options] [recipename/target ...]
+
+    Executes the specified task (default is 'build') for a given set of target recipes (.bb files).
+    It is assumed there is a conf/bblayers.conf available in cwd or in BBPATH which
+    will provide the layer, BBFILES and other configuration information.
+
+Options:
+  --version             show program's version number and exit
+  -h, --help            show this help message and exit
+  -b BUILDFILE, --buildfile=BUILDFILE
+                        Execute tasks from a specific .bb recipe directly.
+                        WARNING: Does not handle any dependencies from other
+                        recipes.
+  -k, --continue        Continue as much as possible after an error. While the
+                        target that failed and anything depending on it cannot
+                        be built, as much as possible will be built before
+                        stopping.
+  -a, --tryaltconfigs   Continue with builds by trying to use alternative
+                        providers where possible.
+  -f, --force           Force the specified targets/task to run (invalidating
+                        any existing stamp file).
+  -c CMD, --cmd=CMD     Specify the task to execute. The exact options
+                        available depend on the metadata. Some examples might
+                        be 'compile' or 'populate_sysroot' or 'listtasks' may
+                        give a list of the tasks available.
+  -C INVALIDATE_STAMP, --clear-stamp=INVALIDATE_STAMP
+                        Invalidate the stamp for the specified task such as
+                        'compile' and then run the default task for the
+                        specified target(s).
+  -r PREFILE, --read=PREFILE
+                        Read the specified file before bitbake.conf.
+  -R POSTFILE, --postread=POSTFILE
+                        Read the specified file after bitbake.conf.
+  -v, --verbose         Output more log message data to the terminal.
+  -D, --debug           Increase the debug level. You can specify this more
+                        than once.
+  -n, --dry-run         Don't execute, just go through the motions.
+  -S, --dump-signatures
+                        Don't execute, just dump out the signature
+                        construction information.
+  -p, --parse-only      Quit after parsing the BB recipes.
+  -s, --show-versions   Show current and preferred versions of all recipes.
+  -e, --environment     Show the global or per-package environment complete
+                        with information about where variables were
+                        set/changed.
+  -g, --graphviz        Save dependency tree information for the specified
+                        targets in the dot syntax.
+  -I EXTRA_ASSUME_PROVIDED, --ignore-deps=EXTRA_ASSUME_PROVIDED
+                        Assume these dependencies don't exist and are already
+                        provided (equivalent to ASSUME_PROVIDED). Useful to
+                        make dependency graphs more appealing
+  -l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS
+                        Show debug logging for the specified logging domains
+  -P, --profile         Profile the command and save reports.
+  -u UI, --ui=UI        The user interface to use (e.g. knotty, hob, depexp).
+  -t SERVERTYPE, --servertype=SERVERTYPE
+                        Choose which server to use, process or xmlrpc.
+  --revisions-changed   Set the exit code depending on whether upstream
+                        floating revisions have changed or not.
+  --server-only         Run bitbake without a UI, only starting a server
+                        (cooker) process.
+  -B BIND, --bind=BIND  The name/address for the bitbake server to bind to.
+  --no-setscene         Do not run any setscene tasks. sstate will be ignored
+                        and everything needed, built.
+  --remote-server=REMOTE_SERVER
+                        Connect to the specified server.
+  -m, --kill-server     Terminate the remote server.
+  --observe-only        Connect to a server as an observing-only client.
+        </screen>
+    </section>
+
+    <section id='ref-bitbake-fetchers'>
+        <title>Fetchers</title>
+
+        <para>
+            BitBake also contains a set of "fetcher" modules that allow
+            retrieval of source code from various types of sources.
+            For example, BitBake can get source code from a disk with the metadata, from websites,
+            from remote shell accounts, or from Source Code Management (SCM) systems
+            like <filename>cvs/subversion/git</filename>.
+        </para>
+
+        <para>
+            Fetchers are usually triggered by entries in
+            <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename>.
+            You can find information about the options and formats of entries for specific
+            fetchers in the BitBake manual located in the
+            <filename>bitbake/doc/manual</filename> directory of the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        </para>
+
+        <para>
+            One useful feature for certain Source Code Manager (SCM) fetchers is the ability to
+            "auto-update" when the upstream SCM changes version.
+            Since this ability requires certain functionality from the SCM, not all
+            systems support it.
+            Currently Subversion, Bazaar and to a limited extent, Git support the ability to "auto-update".
+            This feature works using the <filename><link linkend='var-SRCREV'>SRCREV</link></filename>
+            variable.
+            See the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-srcrev'>Using an External SCM</ulink>" section
+            in the Yocto Project Development Manual for more information.
+        </para>
+
+    </section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4 spell spelllang=en_gb
+-->
diff --git a/documentation/ref-manual/ref-classes.xml b/documentation/ref-manual/ref-classes.xml
new file mode 100644
index 0000000000..f60b907e85
--- /dev/null
+++ b/documentation/ref-manual/ref-classes.xml
@@ -0,0 +1,3489 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='ref-classes'>
+<title>Classes</title>
+
+<para>
+    Class files are used to abstract common functionality and share it amongst
+    multiple recipe (<filename>.bb</filename>) files.
+    To use a class file, you simply make sure the recipe inherits the class.
+    In most cases, when a recipe inherits a class it is enough to enable its
+    features.
+    There are cases, however, where in the recipe you might need to set
+    variables or override some default behavior.
+</para>
+
+<para>
+    Any <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> usually
+    found in a recipe can also be placed in a class file.
+    Class files are identified by the extension <filename>.bbclass</filename>
+    and are usually placed in a <filename>classes/</filename> directory beneath
+    the <filename>meta*/</filename> directory found in the
+    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+    Class files can also be pointed to by
+    <link linkend='var-BUILDDIR'><filename>BUILDDIR</filename></link>
+    (e.g. <filename>build/</filename>) in the same way as
+    <filename>.conf</filename> files in the <filename>conf</filename> directory.
+    Class files are searched for in
+    <link linkend='var-BBPATH'><filename>BBPATH</filename></link>
+    using the same method by which <filename>.conf</filename> files are
+    searched.
+</para>
+
+<para>
+    This chapter discusses only the most useful and important classes.
+    Other classes do exist within the <filename>meta/classes</filename>
+    directory in the
+    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+    You can reference the <filename>.bbclass</filename> files directly
+    for more information.
+</para>
+
+<section id='ref-classes-allarch'>
+    <title><filename>allarch.bbclass</filename></title>
+
+    <para>
+        The <filename>allarch</filename> class is inherited
+        by recipes that do not produce architecture-specific output.
+        The class disables functionality that is normally needed for recipes
+        that produce executable binaries (such as building the cross-compiler
+        and a C library as pre-requisites, and splitting out of debug symbols
+        during packaging).
+    </para>
+
+    <para>
+        By default, all recipes inherit the
+        <link linkend='ref-classes-base'><filename>base</filename></link> and
+        <link linkend='ref-classes-package'><filename>package</filename></link>
+        classes, which enable functionality
+        needed for recipes that produce executable output.
+        If your recipe, for example, only produces packages that contain
+        configuration files, media files, or scripts (e.g. Python and Perl),
+        then it should inherit the <filename>allarch</filename> class.
+    </para>
+</section>
+
+<section id='ref-classes-archiver'>
+    <title><filename>archiver.bbclass</filename></title>
+
+    <para>
+        The <filename>archiver</filename> class supports releasing
+        source code and other materials with the binaries.
+    </para>
+
+    <para>
+        For more details on the source archiver, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+</section>
+
+<section id='ref-classes-autotools'>
+    <title><filename>autotools.bbclass</filename></title>
+
+    <para>
+        The <filename>autotools</filename> class supports Autotooled
+        packages.
+    </para>
+
+    <para>
+        The <filename>autoconf</filename>, <filename>automake</filename>,
+        and <filename>libtool</filename> bring standardization.
+        This class defines a set of tasks (configure, compile etc.) that
+        work for all Autotooled packages.
+        It should usually be enough to define a few standard variables
+        and then simply <filename>inherit autotools</filename>.
+        This class can also work with software that emulates Autotools.
+        For more information, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-autotooled-package'>Autotooled Package</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+
+    <para>
+        By default, the <filename>autotools</filename> class
+        uses out-of-tree builds
+        (<link linkend='var-B'><filename>B</filename></link> <filename>!=</filename>
+        <link linkend='var-S'><filename>S</filename></link>).
+        If the software being built by a recipe does not support
+        using out-of-tree builds, you should have the recipe inherit the
+        <link linkend='ref-classes-autotools-brokensep'><filename>autotools-brokensep</filename></link>
+        class.
+    </para>
+
+    <para>
+        It's useful to have some idea of how the tasks defined by this class work
+        and what they do behind the scenes.
+        <itemizedlist>
+            <listitem><para><link linkend='ref-tasks-configure'><filename>do_configure</filename></link> &dash;
+                Regenerates the
+                configure script (using <filename>autoreconf</filename>) and then launches it
+                with a standard set of arguments used during cross-compilation.
+                You can pass additional parameters to <filename>configure</filename> through the
+                <filename><link linkend='var-EXTRA_OECONF'>EXTRA_OECONF</link></filename> variable.
+                </para></listitem>
+            <listitem><para><link linkend='ref-tasks-compile'><filename>do_compile</filename></link> &dash; Runs <filename>make</filename> with
+                arguments that specify the compiler and linker.
+                You can pass additional arguments through
+                the <filename><link linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link></filename> variable.
+                </para></listitem>
+            <listitem><para><link linkend='ref-tasks-install'><filename>do_install</filename></link> &dash; Runs <filename>make install</filename>
+                and passes in
+                <filename>${</filename><link linkend='var-D'><filename>D</filename></link><filename>}</filename>
+                as <filename>DESTDIR</filename>.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='ref-classes-autotools-brokensep'>
+    <title><filename>autotools-brokensep.bbclass</filename></title>
+
+    <para>
+        The <filename>autotools-brokensep</filename> class behaves the same
+        as the
+        <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
+        class but builds with
+        <link linkend='var-B'><filename>B</filename></link> ==
+        <link linkend='var-S'><filename>S</filename></link>.
+        This method is useful when out-of-tree build support is either not
+        present or is broken.
+        <note>
+            It is recommended that out-of-tree support be fixed and used
+            if at all possible.
+        </note>
+    </para>
+</section>
+
+<section id='ref-classes-base'>
+    <title><filename>base.bbclass</filename></title>
+
+    <para>
+        The <filename>base</filename> class is special in that every
+        <filename>.bb</filename> file implicitly inherits the class.
+        This class contains definitions for standard basic
+        tasks such as fetching, unpacking, configuring (empty by default),
+        compiling (runs any <filename>Makefile</filename> present), installing
+        (empty by default) and packaging (empty by default).
+        These classes are often overridden or extended by other classes
+        such as the
+        <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
+        class or the
+        <link linkend='ref-classes-package'><filename>package</filename></link>
+        class.
+        The class also contains some commonly used functions such as
+        <filename>oe_runmake</filename>.
+    </para>
+</section>
+
+<section id='ref-classes-bin-package'>
+    <title><filename>bin_package.bbclass</filename></title>
+
+    <para>
+        The <filename>bin_package</filename> class is a
+        helper class for recipes that extract the contents of a binary package
+        (e.g. an RPM) and install those contents rather than building the
+        binary from source.
+        The binary package is extracted and new packages in the configured
+        output package format are created.
+        Extraction and installation of proprietary binaries is a good example
+        use for this class.
+        <note>
+            For RPMs and other packages that do not contain a subdirectory,
+            you should specify a "subdir" parameter.
+            Here is an example where <filename>${BP}</filename> is used so that
+            the files are extracted into the subdirectory expected by the
+            default value of
+            <link linkend='var-S'><filename>S</filename></link>:
+            <literallayout class='monospaced'>
+     SRC_URI = "http://example.com/downloads/somepackage.rpm;subdir=${BP}"
+            </literallayout>
+        </note>
+    </para>
+</section>
+
+<section id='ref-classes-binconfig'>
+    <title><filename>binconfig.bbclass</filename></title>
+
+    <para>
+        The <filename>binconfig</filename> class helps to correct paths in
+        shell scripts.
+    </para>
+
+    <para>
+        Before <filename>pkg-config</filename> had become widespread, libraries
+        shipped shell scripts to give information about the libraries and
+        include paths needed to build software (usually named
+        <filename>LIBNAME-config</filename>).
+        This class assists any recipe using such scripts.
+    </para>
+
+    <para>
+        During staging, the OpenEmbedded build system installs such scripts
+        into the <filename>sysroots/</filename> directory.
+        Inheriting this class results in all paths in these scripts being
+        changed to point into the <filename>sysroots/</filename> directory so
+        that all builds that use the script use the correct directories
+        for the cross compiling layout.
+        See the
+        <link linkend='var-BINCONFIG_GLOB'><filename>BINCONFIG_GLOB</filename></link>
+        variable for more information.
+    </para>
+</section>
+
+<section id='ref-classes-binconfig-disabled'>
+    <title><filename>binconfig-disabled.bbclass</filename></title>
+
+    <para>
+        An alternative version of the
+        <link linkend='ref-classes-binconfig'><filename>binconfig</filename></link>
+        class, which disables binary configuration scripts by making them
+        return an error in favor of using <filename>pkg-config</filename>
+        to query the information.
+        The scripts to be disabled should be specified using the
+        <link linkend='var-BINCONFIG'><filename>BINCONFIG</filename></link>
+        variable within the recipe inheriting the class.
+    </para>
+</section>
+
+<section id='ref-classes-blacklist'>
+    <title><filename>blacklist.bbclass</filename></title>
+
+    <para>
+        The <filename>blacklist</filename> class prevents
+        the OpenEmbedded build system from building specific recipes
+        (blacklists them).
+        To use this class, inherit the class globally and set
+        <link linkend='var-PNBLACKLIST'><filename>PNBLACKLIST</filename></link>
+        for each recipe you wish to blacklist.
+        Specify the <link linkend='var-PN'><filename>PN</filename></link>
+        value as a variable flag (varflag) and provide a reason, which is
+        reported, if the package is requested to be built as the value.
+        For example, if you want to blacklist a recipe called "exoticware",
+        you add the following to your <filename>local.conf</filename>
+        or distribution configuration:
+        <literallayout class='monospaced'>
+     INHERIT += "blacklist"
+     PNBLACKLIST[exoticware] = "Not supported by our organization."
+        </literallayout>
+    </para>
+</section>
+
+<section id='ref-classes-boot-directdisk'>
+    <title><filename>boot-directdisk.bbclass</filename></title>
+
+    <para>
+        The <filename>boot-directdisk</filename> class
+        creates an image that can be placed directly onto a hard disk using
+        <filename>dd</filename> and then booted.
+        The image uses SYSLINUX.
+    </para>
+
+    <para>
+        The end result is a 512 boot sector populated with a
+        Master Boot Record (MBR) and partition table followed by an MSDOS
+        FAT16 partition containing SYSLINUX and a Linux kernel completed by
+        the <filename>ext2</filename> and <filename>ext3</filename>
+        root filesystems.
+    </para>
+</section>
+
+<section id='ref-classes-bootimg'>
+    <title><filename>bootimg.bbclass</filename></title>
+
+    <para>
+        The <filename>bootimg</filename> class creates a bootable
+        image using SYSLINUX, your kernel, and an optional initial RAM disk
+        (<filename>initrd</filename>).
+    </para>
+
+    <para>
+        When you use this class, two things happen:
+        <itemizedlist>
+            <listitem><para>
+                A <filename>.hddimg</filename> file is created.
+                This file is an MSDOS filesystem that contains SYSLINUX,
+                a kernel, an <filename>initrd</filename>, and a root filesystem
+                image.
+                All three of these can be written to hard drives directly and
+                also booted on a USB flash disks using <filename>dd</filename>.
+                </para></listitem>
+            <listitem><para>
+                A CD <filename>.iso</filename> image is created.
+                When this file is booted, the <filename>initrd</filename>
+                boots and processes the label selected in SYSLINUX.
+                Actions based on the label are then performed (e.g. installing
+                to a hard drive).</para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        The <filename>bootimg</filename> class supports the
+        <link linkend='var-INITRD'><filename>INITRD</filename></link>,
+        <link linkend='var-NOISO'><filename>NOISO</filename></link>,
+        <link linkend='var-NOHDD'><filename>NOHDD</filename></link>, and
+        <link linkend='var-ROOTFS'><filename>ROOTFS</filename></link>
+        variables.
+    </para>
+</section>
+
+<section id='ref-classes-bugzilla'>
+    <title><filename>bugzilla.bbclass</filename></title>
+
+    <para>
+        The <filename>bugzilla</filename> class supports setting up an
+        instance of Bugzilla in which you can automatically files bug reports
+        in response to build failures.
+        For this class to work, you need to enable the XML-RPC interface in
+        the instance of Bugzilla.
+    </para>
+</section>
+
+<section id='ref-classes-buildhistory'>
+    <title><filename>buildhistory.bbclass</filename></title>
+
+    <para>
+        The <filename>buildhistory</filename> class records a
+        history of build output metadata, which can be used to detect possible
+        regressions as well as used for analysis of the build output.
+        For more information on using Build History, see the
+        "<link linkend='maintaining-build-output-quality'>Maintaining Build Output Quality</link>"
+        section.
+    </para>
+</section>
+
+<section id='ref-classes-buildstats'>
+    <title><filename>buildstats.bbclass</filename></title>
+
+    <para>
+        The <filename>buildstats</filename> class records
+        performance statistics about each task executed during the build
+        (e.g. elapsed time, CPU usage, and I/O usage).
+    </para>
+
+    <para>
+        When you use this class, the output goes into the
+        <link linkend='var-BUILDSTATS_BASE'><filename>BUILDSTATS_BASE</filename></link>
+        directory, which defaults to <filename>${TMPDIR}/buildstats/</filename>.
+        You can analyze the elapsed time using
+        <filename>scripts/pybootchartgui/pybootchartgui.py</filename>, which
+        produces a cascading chart of the entire build process and can be
+        useful for highlighting bottlenecks.
+    </para>
+
+    <para>
+        Collecting build statistics is enabled by default through the
+        <link linkend='var-USER_CLASSES'><filename>USER_CLASSES</filename></link>
+        variable from your <filename>local.conf</filename> file.
+        Consequently, you do not have to do anything to enable the class.
+        However, if you want to disable the class, simply remove "buildstats"
+        from the <filename>USER_CLASSES</filename> list.
+    </para>
+</section>
+
+<section id='ref-classes-buildstats-summary'>
+    <title><filename>buildstats-summary.bbclass</filename></title>
+
+    <para>
+        When inherited globally, prints statistics at the end of the build
+        on sstate re-use.
+        In order to function, this class requires the
+        <link linkend='ref-classes-buildstats'><filename>buildstats</filename></link>
+        class be enabled.
+    </para>
+</section>
+
+<section id='ref-classes-ccache'>
+    <title><filename>ccache.bbclass</filename></title>
+
+    <para>
+        The <filename>ccache</filename> class enables the
+        <ulink url='http://ccache.samba.org/'>C/C++ Compiler Cache</ulink>
+        for the build.
+        This class is used to give a minor performance boost during the build.
+        However, using the class can lead to unexpected side-effects.
+        Thus, it is recommended that you do not use this class.
+        See <ulink url='http://ccache.samba.org/'></ulink> for information on
+        the C/C++ Compiler Cache.
+    </para>
+</section>
+
+<section id='ref-classes-chrpath'>
+    <title><filename>chrpath.bbclass</filename></title>
+
+    <para>
+        The <filename>chrpath</filename> class
+        is a wrapper around the "chrpath" utility, which is used during the
+        build process for <filename>nativesdk</filename>,
+        <filename>cross</filename>, and
+        <filename>cross-canadian</filename> recipes to change
+        <filename>RPATH</filename> records within binaries in order to make
+        them relocatable.
+    </para>
+</section>
+
+<section id='ref-classes-clutter'>
+    <title><filename>clutter.bbclass</filename></title>
+
+    <para>
+        The <filename>clutter</filename> class consolidates the
+        major and minor version naming and other common items used by Clutter
+        and related recipes.
+        <note>
+            Unlike some other classes related to specific libraries, recipes
+            building other software that uses Clutter do not need to
+            inherit this class unless they use the same recipe versioning
+            scheme that the Clutter and related recipes do.
+        </note>
+    </para>
+</section>
+
+<section id='ref-classes-cmake'>
+    <title><filename>cmake.bbclass</filename></title>
+
+    <para>
+        The <filename>cmake</filename> class allows for
+        recipes that need to build software using the CMake build system.
+        You can use the
+        <link linkend='var-EXTRA_OECMAKE'><filename>EXTRA_OECMAKE</filename></link>
+        variable to specify additional configuration options to be passed on
+        the <filename>cmake</filename> command line.
+    </para>
+</section>
+
+<section id='ref-classes-cml1'>
+    <title><filename>cml1.bbclass</filename></title>
+
+    <para>
+        The <filename>cml1</filename> class provides basic support for the
+        Linux kernel style build configuration system.
+    </para>
+</section>
+
+<section id='ref-classes-compress_doc'>
+    <title><filename>compress_doc.bbclass</filename></title>
+
+    <para>
+        Enables compression for man pages and info pages.
+        This class is intended to be inherited globally.
+        The default compression mechanism is gz (gzip) but you can
+        select an alternative mechanism by setting the
+        <link linkend='var-DOC_COMPRESS'><filename>DOC_COMPRESS</filename></link>
+        variable.
+    </para>
+</section>
+
+<section id='ref-classes-copyleft_compliance'>
+    <title><filename>copyleft_compliance.bbclass</filename></title>
+
+    <para>
+        The <filename>copyleft_compliance</filename> class
+        preserves source code for the purposes of license compliance.
+        This class is an alternative to the <filename>archiver</filename>
+        class and is still used by some users even though it has been
+        deprecated in favor of the
+        <link linkend='ref-classes-archiver'><filename>archiver</filename></link>
+        class.
+    </para>
+</section>
+
+<section id='ref-classes-copyleft_filter'>
+    <title><filename>copyleft_filter.bbclass</filename></title>
+
+    <para>
+        A class used by the
+        <link linkend='ref-classes-archiver'><filename>archiver</filename></link>
+        and
+        <link linkend='ref-classes-copyleft_compliance'><filename>copyleft_compliance</filename></link>
+        classes for filtering licenses.
+        The <filename>copyleft_filter</filename> class is an internal class
+        and is not intended to be used directly.
+    </para>
+</section>
+
+<section id='ref-classes-core-image'>
+    <title><filename>core-image.bbclass</filename></title>
+
+    <para>
+        The <filename>core-image</filename> class
+        provides common definitions for the
+        <filename>core-image-*</filename> image recipes, such as support for
+        additional
+        <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>.
+    </para>
+</section>
+
+<section id='ref-classes-cpan'>
+    <title><filename>cpan.bbclass</filename></title>
+
+    <para>
+        The <filename>cpan</filename> class supports Perl modules.
+    </para>
+
+    <para>
+        Recipes for Perl modules are simple.
+        These recipes usually only need to point to the source's archive and
+        then inherit the proper class file.
+        Building is split into two methods depending on which method the module
+        authors used.
+        <itemizedlist>
+            <listitem><para>Modules that use old
+                <filename>Makefile.PL</filename>-based build system require
+                <filename>cpan.bbclass</filename> in their recipes.
+                </para></listitem>
+            <listitem><para>Modules that use
+                <filename>Build.PL</filename>-based build system require
+                using <filename>cpan_build.bbclass</filename> in their recipes.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='ref-classes-cross'>
+    <title><filename>cross.bbclass</filename></title>
+
+    <para>
+        The <filename>cross</filename> class provides support for the recipes
+        that build the cross-compilation tools.
+    </para>
+</section>
+
+<section id='ref-classes-cross-canadian'>
+    <title><filename>cross-canadian.bbclass</filename></title>
+
+    <para>
+        The <filename>cross-canadian</filename> class
+        provides support for the recipes that build the Canadian
+        Cross-compilation tools for SDKs.
+        See the
+        "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
+        section for more discussion on these cross-compilation tools.
+    </para>
+</section>
+
+<section id='ref-classes-crosssdk'>
+    <title><filename>crosssdk.bbclass</filename></title>
+
+    <para>
+        The <filename>crosssdk</filename> class
+        provides support for the recipes that build the cross-compilation
+        tools used for building SDKs.
+        See the
+        "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
+        section for more discussion on these cross-compilation tools.
+    </para>
+</section>
+
+<section id='ref-classes-debian'>
+    <title><filename>debian.bbclass</filename></title>
+
+    <para>
+        The <filename>debian</filename> class renames output packages so that
+        they follow the Debian naming policy (i.e. <filename>glibc</filename>
+        becomes <filename>libc6</filename> and <filename>glibc-devel</filename>
+        becomes <filename>libc6-dev</filename>.)
+        Renaming includes the library name and version as part of the package
+        name.
+    </para>
+
+    <para>
+        If a recipe creates packages for multiple libraries
+        (shared object files of <filename>.so</filename> type), use the
+        <link linkend='var-LEAD_SONAME'><filename>LEAD_SONAME</filename></link>
+        variable in the recipe to specify the library on which to apply the
+        naming scheme.
+    </para>
+</section>
+
+<section id='ref-classes-deploy'>
+    <title><filename>deploy.bbclass</filename></title>
+
+    <para>
+        The <filename>deploy</filename> class handles deploying files
+        to the
+        <link linkend='var-DEPLOY_DIR_IMAGE'><filename>DEPLOY_DIR_IMAGE</filename></link>
+        directory.
+        The main function of this class is to allow the deploy step to be
+        accelerated by shared state.
+        Recipes that inherit this class should define their own
+        <link linkend='ref-tasks-deploy'><filename>do_deploy</filename></link>
+        function to copy the files to be deployed to
+        <link linkend='var-DEPLOYDIR'><filename>DEPLOYDIR</filename></link>,
+        and use <filename>addtask</filename> to add the task at the appropriate
+        place, which is usually after
+        <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
+        or
+        <link linkend='ref-tasks-install'><filename>do_install</filename></link>.
+        The class then takes care of staging the files from
+        <filename>DEPLOYDIR</filename> to
+        <filename>DEPLOY_DIR_IMAGE</filename>.
+    </para>
+</section>
+
+<section id='ref-classes-devshell'>
+    <title><filename>devshell.bbclass</filename></title>
+
+    <para>
+        The <filename>devshell</filename> class adds the
+        <filename>do_devshell</filename> task.
+        Distribution policy dictates whether to include this class.
+        See the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-devshell'>Using a Development Shell</ulink>" section
+        in the Yocto Project Development Manual for more information about
+        using <filename>devshell</filename>.
+    </para>
+</section>
+
+<section id='ref-classes-distro_features_check'>
+    <title><filename>distro_features_check.bbclass</filename></title>
+
+    <para>
+        The <filename>distro_features_check</filename> class
+        allows individual recipes to check for required and conflicting
+        <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
+    </para>
+
+    <para>
+        This class provides support for the
+        <link linkend='var-REQUIRED_DISTRO_FEATURES'><filename>REQUIRED_DISTRO_FEATURES</filename></link>
+        and
+        <link linkend='var-CONFLICT_DISTRO_FEATURES'><filename>CONFLICT_DISTRO_FEATURES</filename></link>
+        variables.
+        If any conditions specified in the recipe using the above variables are
+        not met, the recipe will be skipped.
+    </para>
+</section>
+
+<section id='ref-classes-distrodata'>
+    <title><filename>distrodata.bbclass</filename></title>
+
+    <para>
+        The <filename>distrodata</filename> class
+        provides for automatic checking for upstream recipe updates.
+        The class creates a comma-separated value (CSV) spreadsheet that
+        contains information about the recipes.
+        The information provides the <filename>do_distrodata</filename> and
+        <filename>do_distro_check</filename> tasks, which do upstream checking
+        and also verify if a package is used in multiple major distributions.
+    </para>
+
+    <para>
+        The class is not included by default.
+        To use it, you must include the following files and set the
+        <link linkend='var-INHERIT'><filename>INHERIT</filename></link>
+        variable:
+        <literallayout class='monospaced'>
+     include conf/distro/include/distro_alias.inc
+     include conf/distro/include/recipe_color.inc
+     include conf/distro/include/maintainers.inc
+     include conf/distro/include/upstream_tracking.inc
+     include conf/distro/include/package_regex.inc
+     INHERIT+= "distrodata"
+        </literallayout>
+    </para>
+</section>
+
+<section id='ref-classes-distutils'>
+    <title><filename>distutils.bbclass</filename></title>
+
+    <para>
+        The <filename>distutils</filename> class supports recipes for Python
+        version 2.x extensions, which are simple.
+        These recipes usually only need to point to the source's archive and
+        then inherit the proper class.
+        Building is split into two methods depending on which method the
+        module authors used.
+        <itemizedlist>
+            <listitem><para>Extensions that use an Autotools-based build system
+                require Autotools and
+                <filename>distutils</filename>-based classes in their recipes.
+                </para></listitem>
+            <listitem><para>Extensions that use build systems based on
+                <filename>distutils</filename> require
+                the <filename>distutils</filename> class in their recipes.
+                </para></listitem>
+            <listitem><para>Extensions that use build systems based on
+                <filename>setuptools</filename> require the
+                <link linkend='ref-classes-setuptools'><filename>setuptools</filename></link>
+                class in their recipes.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='ref-classes-distutils3'>
+    <title><filename>distutils3.bbclass</filename></title>
+
+    <para>
+        The <filename>distutils3</filename> class supports recipes for Python
+        version 3.x extensions, which are simple.
+        These recipes usually only need to point to the source's archive and
+        then inherit the proper class.
+        Building is split into two methods depending on which method the
+        module authors used.
+        <itemizedlist>
+            <listitem><para>Extensions that use an Autotools-based build system
+                require Autotools and
+                <filename>distutils</filename>-based classes in their recipes.
+                </para></listitem>
+            <listitem><para>Extensions that use
+                <filename>distutils</filename>-based build systems require
+                the <filename>distutils</filename> class in their recipes.
+                </para></listitem>
+            <listitem><para>Extensions that use build systems based on
+                <filename>setuptools3</filename> require the
+                <link linkend='ref-classes-setuptools'><filename>setuptools3</filename></link>
+                class in their recipes.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='ref-classes-externalsrc'>
+    <title><filename>externalsrc.bbclass</filename></title>
+
+    <para>
+        The <filename>externalsrc</filename> class supports building software
+        from source code that is external to the OpenEmbedded build system.
+        Building software from an external source tree means that the build
+        system's normal fetch, unpack, and patch process is not used.
+    </para>
+
+    <para>
+        By default, the OpenEmbedded build system uses the
+        <link linkend='var-S'><filename>S</filename></link> and
+        <link linkend='var-B'><filename>B</filename></link> variables to
+        locate unpacked recipe source code and to build it, respectively.
+        When your recipe inherits the <filename>externalsrc</filename> class,
+        you use the
+        <link linkend='var-EXTERNALSRC'><filename>EXTERNALSRC</filename></link>
+        and
+        <link linkend='var-EXTERNALSRC_BUILD'><filename>EXTERNALSRC_BUILD</filename></link>
+        variables to ultimately define <filename>S</filename> and
+        <filename>B</filename>.
+    </para>
+
+    <para>
+        By default, this class expects the source code to support recipe builds
+        that use the <link linkend='var-B'><filename>B</filename></link>
+        variable to point to the directory in which the OpenEmbedded build
+        system places the generated objects built from the recipes.
+        By default, the <filename>B</filename> directory is set to the
+        following, which is separate from the source directory
+        (<filename>S</filename>):
+        <literallayout class='monospaced'>
+     ${WORKDIR}/${BPN}/{PV}/
+        </literallayout>
+        See these variables for more information:
+        <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>,
+        <link linkend='var-BPN'><filename>BPN</filename></link>, and
+        <link linkend='var-PV'><filename>PV</filename></link>,
+    </para>
+
+    <para>
+        For more information on the
+        <filename>externalsrc</filename> class, see the comments in
+        <filename>meta/classes/externalsrc.bbclass</filename> in the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        For information on how to use the <filename>externalsrc</filename>
+        class, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source'>Building Software from an External Source</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+</section>
+
+<section id='ref-classes-extrausers'>
+    <title><filename>extrausers.bbclass</filename></title>
+
+    <para>
+        The <filename>extrausers</filename> class allows
+        additional user and group configuration to be applied at the image
+        level.
+        Inheriting this class either globally or from an image recipe allows
+        additional user and group operations to be performed using the
+        <link linkend='var-EXTRA_USERS_PARAMS'><filename>EXTRA_USERS_PARAMS</filename></link>
+        variable.
+        <note>
+            The user and group operations added using the
+            <filename>extrausers</filename> class are not tied to a specific
+            recipe outside of the recipe for the image.
+            Thus, the operations can be performed across the image as a whole.
+            Use the
+            <link linkend='ref-classes-useradd'><filename>useradd</filename></link>
+            class to add user and group configuration to a specific recipe.
+        </note>
+        Here is an example that uses this class in an image recipe:
+        <literallayout class='monospaced'>
+     inherit extrausers
+     EXTRA_USERS_PARAMS = "\
+         useradd -p '' tester; \
+         groupadd developers; \
+         userdel nobody; \
+         groupdel -g video; \
+         groupmod -g 1020 developers; \
+         usermod -s /bin/sh tester; \
+         "
+        </literallayout>
+        Here is an example that adds two users named "tester-jim" and
+        "tester-sue" and assigns passwords:
+        <literallayout class='monospaced'>
+     inherit extrausers
+     EXTRA_USERS_PARAMS = "\
+         useradd -P tester01 tester-jim; \
+         useradd -P tester01 tester-sue; \
+         "
+        </literallayout>
+        Finally, here is an example that sets the root password to
+        "1876*18":
+        <literallayout class='monospaced'>
+     inherit extrausers
+     EXTRA_USERS_PARAMS = "\
+         useradd -P 1876*18 root; \
+         "
+        </literallayout>
+    </para>
+</section>
+
+<section id='ref-classes-fontcache'>
+    <title><filename>fontcache.bbclass</filename></title>
+
+    <para>
+        The <filename>fontcache</filename> class generates the
+        proper post-install and post-remove (postinst and postrm)
+        scriptlets for font packages.
+        These scriptlets call <filename>fc-cache</filename> (part of
+        <filename>Fontconfig</filename>) to add the fonts to the font
+        information cache.
+        Since the cache files are architecture-specific,
+        <filename>fc-cache</filename> runs using QEMU if the postinst
+        scriptlets need to be run on the build host during image creation.
+    </para>
+
+    <para>
+        If the fonts being installed are in packages other than the main
+        package, set
+        <link linkend='var-FONT_PACKAGES'><filename>FONT_PACKAGES</filename></link>
+        to specify the packages containing the fonts.
+    </para>
+</section>
+
+<section id='ref-classes-gconf'>
+    <title><filename>gconf.bbclass</filename></title>
+
+    <para>
+        The <filename>gconf</filename> class provides common
+        functionality for recipes that need to install GConf schemas.
+        The schemas will be put into a separate package
+        (<filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}-gconf</filename>)
+        that is created automatically when this class is inherited.
+        This package uses the appropriate post-install and post-remove
+        (postinst/postrm) scriptlets to register and unregister the schemas
+        in the target image.
+    </para>
+</section>
+
+<section id='ref-classes-gettext'>
+    <title><filename>gettext.bbclass</filename></title>
+
+    <para>
+        The <filename>gettext</filename> class provides support for
+        building software that uses the GNU <filename>gettext</filename>
+        internationalization and localization system.
+        All recipes building software that use
+        <filename>gettext</filename> should inherit this class.
+    </para>
+</section>
+
+<section id='ref-classes-gnome'>
+    <title><filename>gnome.bbclass</filename></title>
+
+    <para>
+        The <filename>gnome</filename> class supports recipes that
+        build software from the GNOME stack.
+        This class inherits the
+        <link linkend='ref-classes-gnomebase'><filename>gnomebase</filename></link>,
+        <link linkend='ref-classes-gtk-icon-cache'><filename>gtk-icon-cache</filename></link>,
+        <link linkend='ref-classes-gconf'><filename>gconf</filename></link> and
+        <link linkend='ref-classes-mime'><filename>mime</filename></link> classes.
+        The class also disables GObject introspection where applicable.
+    </para>
+</section>
+
+<section id='ref-classes-gnomebase'>
+    <title><filename>gnomebase.bbclass</filename></title>
+
+    <para>
+        The <filename>gnomebase</filename> class is the base
+        class for recipes that build software from the GNOME stack.
+        This class sets
+        <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link> to
+        download the source from the GNOME mirrors as well as extending
+        <link linkend='var-FILES'><filename>FILES</filename></link>
+        with the typical GNOME installation paths.
+    </para>
+</section>
+
+<section id='ref-classes-grub-efi'>
+    <title><filename>grub-efi.bbclass</filename></title>
+
+    <para>
+        The <filename>grub-efi</filename>
+        class provides <filename>grub-efi</filename>-specific functions for
+        building bootable images.
+    </para>
+
+    <para>
+        This class supports several variables:
+        <itemizedlist>
+            <listitem><para>
+                <link linkend='var-INITRD'><filename>INITRD</filename></link>:
+                Indicates list of filesystem images to concatenate and use
+                as an initial RAM disk (initrd) (optional).
+                </para></listitem>
+            <listitem><para>
+                <link linkend='var-ROOTFS'><filename>ROOTFS</filename></link>:
+                Indicates a filesystem image to include as the root filesystem
+                (optional).</para></listitem>
+            <listitem><para>
+                <link linkend='var-GRUB_GFXSERIAL'><filename>GRUB_GFXSERIAL</filename></link>:
+                Set this to "1" to have graphics and serial in the boot menu.
+                </para></listitem>
+            <listitem><para>
+                <link linkend='var-LABELS'><filename>LABELS</filename></link>:
+                A list of targets for the automatic configuration.
+                </para></listitem>
+            <listitem><para>
+                <link linkend='var-APPEND'><filename>APPEND</filename></link>:
+                An override list of append strings for each
+                <filename>LABEL</filename>.
+                </para></listitem>
+            <listitem><para>
+                <link linkend='var-GRUB_OPTS'><filename>GRUB_OPTS</filename></link>:
+                Additional options to add to the configuration (optional).
+                Options are delimited using semi-colon characters
+                (<filename>;</filename>).</para></listitem>
+            <listitem><para>
+                <link linkend='var-GRUB_TIMEOUT'><filename>GRUB_TIMEOUT</filename></link>:
+                Timeout before executing the default <filename>LABEL</filename>
+                (optional).
+                </para></listitem>
+       </itemizedlist>
+   </para>
+</section>
+
+<section id='ref-classes-gsettings'>
+    <title><filename>gsettings.bbclass</filename></title>
+
+    <para>
+        The <filename>gsettings</filename> class
+        provides common functionality for recipes that need to install
+        GSettings (glib) schemas.
+        The schemas are assumed to be part of the main package.
+        Appropriate post-install and post-remove (postinst/postrm)
+        scriptlets are added to register and unregister the schemas in the
+        target image.
+    </para>
+</section>
+
+<section id='ref-classes-gtk-doc'>
+    <title><filename>gtk-doc.bbclass</filename></title>
+
+    <para>
+        The <filename>gtk-doc</filename> class
+        is a helper class to pull in the appropriate
+        <filename>gtk-doc</filename> dependencies and disable
+        <filename>gtk-doc</filename>.
+    </para>
+</section>
+
+<section id='ref-classes-gtk-icon-cache'>
+    <title><filename>gtk-icon-cache.bbclass</filename></title>
+
+    <para>
+        The <filename>gtk-icon-cache</filename> class
+        generates the proper post-install and post-remove (postinst/postrm)
+        scriptlets for packages that use GTK+ and install icons.
+        These scriptlets call <filename>gtk-update-icon-cache</filename> to add
+        the fonts to GTK+'s icon cache.
+        Since the cache files are architecture-specific,
+        <filename>gtk-update-icon-cache</filename> is run using QEMU if the
+        postinst scriptlets need to be run on the build host during image
+        creation.
+    </para>
+</section>
+
+<section id='ref-classes-gtk-immodules-cache'>
+    <title><filename>gtk-immodules-cache.bbclass</filename></title>
+
+    <para>
+        The <filename>gtk-immodules-cache</filename> class
+        generates the proper post-install and post-remove (postinst/postrm)
+        scriptlets for packages that install GTK+ input method modules for
+        virtual keyboards.
+        These scriptlets call <filename>gtk-update-icon-cache</filename> to add
+        the input method modules to the cache.
+        Since the cache files are architecture-specific,
+        <filename>gtk-update-icon-cache</filename> is run using QEMU if the
+        postinst scriptlets need to be run on the build host during image
+        creation.
+    </para>
+
+    <para>
+        If the input method modules being installed are in packages other than
+        the main package, set
+        <link linkend='var-GTKIMMODULES_PACKAGES'><filename>GTKIMMODULES_PACKAGES</filename></link>
+        to specify the packages containing the modules.
+    </para>
+</section>
+
+<section id='ref-classes-gummiboot'>
+    <title><filename>gummiboot.bbclass</filename></title>
+
+    <para>
+        The <filename>gummiboot</filename> class provides functions specific
+        to the gummiboot bootloader for building bootable images.
+        This is an internal class and is not intended to be
+        used directly.
+        Set the
+        <link linkend='var-EFI_PROVIDER'><filename>EFI_PROVIDER</filename></link>
+        variable to "gummiboot" to use this class.
+    </para>
+
+    <para>
+        For information on more variables used and supported in this class,
+        see the
+        <link linkend='var-GUMMIBOOT_CFG'><filename>GUMMIBOOT_CFG</filename></link>,
+        <link linkend='var-GUMMIBOOT_ENTRIES'><filename>GUMMIBOOT_ENTRIES</filename></link>,
+        and
+        <link linkend='var-GUMMIBOOT_TIMEOUT'><filename>GUMMIBOOT_TIMEOUT</filename></link>
+        variables.
+    </para>
+
+    <para>
+        You can also see the
+        <ulink url='http://freedesktop.org/wiki/Software/gummiboot/'>Gummiboot documentation</ulink>
+        for more information.
+    </para>
+</section>
+
+<section id='ref-classes-gzipnative'>
+    <title><filename>gzipnative.bbclass</filename></title>
+
+    <para>
+        The <filename>gzipnative</filename>
+        class enables the use of native versions of <filename>gzip</filename>
+        and <filename>pigz</filename> rather than the versions of these tools
+        from the build host.
+    </para>
+</section>
+
+<section id='ref-classes-icecc'>
+    <title><filename>icecc.bbclass</filename></title>
+
+    <para>
+        The <filename>icecc</filename> class supports
+        <ulink url='https://github.com/icecc/icecream'>Icecream</ulink>, which
+        facilitates taking compile jobs and distributing them among remote
+        machines.
+    </para>
+
+    <para>
+        The class stages directories with symlinks from <filename>gcc</filename>
+        and <filename>g++</filename> to <filename>icecc</filename>, for both
+        native and cross compilers.
+        Depending on each configure or compile, the OpenEmbedded build system
+        adds the directories at the head of the <filename>PATH</filename> list
+        and then sets the <filename>ICECC_CXX</filename> and
+        <filename>ICEC_CC</filename> variables, which are the paths to the
+        <filename>g++</filename> and <filename>gcc</filename> compilers,
+        respectively.
+    </para>
+
+    <para>
+        For the cross compiler, the class creates a <filename>tar.gz</filename>
+        file that contains the Yocto Project toolchain and sets
+        <filename>ICECC_VERSION</filename>, which is the version of the
+        cross-compiler used in the cross-development toolchain, accordingly.
+    </para>
+
+    <para>
+        The class handles all three different compile stages
+        (i.e native ,cross-kernel and target) and creates the necessary
+        environment <filename>tar.gz</filename> file to be used by the remote
+        machines.
+        The class also supports SDK generation.
+    </para>
+
+    <para>
+        If <link linkend='var-ICECC_PATH'><filename>ICECC_PATH</filename></link>
+        is not set in your <filename>local.conf</filename> file, then the
+        class tries to locate the <filename>icecc</filename> binary
+        using <filename>which</filename>.
+
+        If
+        <link linkend='var-ICECC_ENV_EXEC'><filename>ICECC_ENV_EXEC</filename></link>
+        is set in your <filename>local.conf</filename> file, the variable should
+        point to the <filename>icecc-create-env</filename> script
+        provided by the user.
+        If you do not point to a user-provided script, the build system
+        uses the default script provided by the recipe
+        <filename>icecc-create-env-native.bb</filename>.
+        <note>
+            This script is a modified version and not the one that comes with
+            <filename>icecc</filename>.
+        </note>
+    </para>
+
+    <para>
+        If you do not want the Icecream distributed compile support to apply
+        to specific recipes or classes, you can effectively "blacklist" them
+        by listing the recipes and classes using the
+        <link linkend='var-ICECC_USER_PACKAGE_BL'><filename>ICECC_USER_PACKAGE_BL</filename></link>
+        and
+        <link linkend='var-ICECC_USER_CLASS_BL'><filename>ICECC_USER_CLASS_BL</filename></link>,
+        variables, respectively, in your <filename>local.conf</filename> file.
+        Doing so causes the OpenEmbedded build system to handle these
+        compilations locally.
+    </para>
+
+    <para>
+        Additionally, you can list recipes using the
+        <link linkend='var-ICECC_USER_PACKAGE_WL'><filename>ICECC_USER_PACKAGE_WL</filename></link>
+        variable in your <filename>local.conf</filename> file to force
+        <filename>icecc</filename> to be enabled for recipes using an empty
+        <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>
+        variable.
+    </para>
+
+    <para>
+        Inheriting the <filename>icecc</filename> class changes all sstate
+        signatures.
+        Consequently, if a development team has a dedicated build system
+        that populates
+        <link linkend='var-SSTATE_MIRRORS'><filename>STATE_MIRRORS</filename></link>
+        and they want to reuse sstate from
+        <filename>STATE_MIRRORS</filename>, then all developers and the
+        build system need to either inherit the <filename>icecc</filename>
+        class or nobody should.
+    </para>
+
+    <para>
+        At the distribution level, you can inherit the
+        <filename>icecc</filename> class to be sure that all builders start
+        with the same sstate signatures.
+        After inheriting the class, you can then disable the feature by setting
+        the
+        <link linkend='var-ICECC_DISABLED'><filename>ICECC_DISABLED</filename></link>
+        variable to "1" as follows:
+        <literallayout class='monospaced'>
+     INHERIT_DISTRO_append = " icecc"
+     ICECC_DISABLED ??= "1"
+        </literallayout>
+        This practice makes sure everyone is using the same signatures but also
+        requires individuals that do want to use Icecream to enable the feature
+        individually as follows in your <filename>local.conf</filename> file:
+        <literallayout class='monospaced'>
+     ICECC_DISABLED = ""
+        </literallayout>
+    </para>
+</section>
+
+<section id='ref-classes-image'>
+    <title><filename>image.bbclass</filename></title>
+
+    <para>
+        The <filename>image</filename> class helps support creating images
+        in different formats.
+        First, the root filesystem is created from packages using
+        one of the <filename>rootfs*.bbclass</filename>
+        files (depending on the package format used) and then one or more image
+        files are created.
+        <itemizedlist>
+            <listitem><para>The
+                <filename><link linkend='var-IMAGE_FSTYPES'>IMAGE_FSTYPES</link></filename>
+                variable controls the types of images to generate.
+                </para></listitem>
+            <listitem><para>The
+                <filename><link linkend='var-IMAGE_INSTALL'>IMAGE_INSTALL</link></filename>
+                variable controls the list of packages to install into the
+                image.</para></listitem>
+        </itemizedlist>
+        For information on customizing images, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage'>Customizing Images</ulink>"
+        section in the Yocto Project Development Manual.
+        For information on how images are created, see the
+        "<link linkend='images-dev-environment'>Images</link>" section elsewhere
+        in this manual.
+    </para>
+</section>
+
+<section id='ref-classes-image_types'>
+    <title><filename>image_types.bbclass</filename></title>
+
+    <para>
+        The <filename>image_types</filename> class defines all of
+        the standard image output types that you can enable through the
+        <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
+        variable.
+        You can use this class as a reference on how to add support for custom
+        image output types.
+    </para>
+
+    <para>
+        By default, this class is enabled through the
+        <link linkend='var-IMAGE_CLASSES'><filename>IMAGE_CLASSES</filename></link>
+        variable in
+        <link linkend='ref-classes-image'><filename>image.bbclass</filename></link>.
+        If you define your own image types using a custom BitBake class and
+        then use <filename>IMAGE_CLASSES</filename> to enable it, the custom
+        class must either inherit <filename>image_types</filename> or
+        <filename>image_types</filename> must also appear in
+        <filename>IMAGE_CLASSES</filename>.
+    </para>
+</section>
+
+<section id='ref-classes-image_types_uboot'>
+    <title><filename>image_types_uboot.bbclass</filename></title>
+
+    <para>
+        The <filename>image_types_uboot</filename> class
+        defines additional image types specifically for the U-Boot bootloader.
+    </para>
+</section>
+
+<section id='ref-classes-image-live'>
+    <title><filename>image-live.bbclass</filename></title>
+
+    <para>
+        The <filename>image-live</filename> class supports building "live"
+        images.
+    </para>
+
+    <para>
+        Normally, you do not use this class directly.
+        Instead, you add "live" to
+        <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>.
+        For example, if you were building an ISO image, you would add "live"
+        to <filename>IMAGE_FSTYPES</filename>, set the
+        <link linkend='var-NOISO'><filename>NOISO</filename></link> variable to
+        "0" and the build system would use the <filename>image-live</filename>
+        class to build the ISO image.
+    </para>
+</section>
+
+<section id='ref-classes-image-mklibs'>
+    <title><filename>image-mklibs.bbclass</filename></title>
+
+    <para>
+        The <filename>image-mklibs</filename> class
+        enables the use of the <filename>mklibs</filename> utility during the
+        <link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>
+        task, which optimizes the size of
+        libraries contained in the image.
+    </para>
+
+    <para>
+        By default, the class is enabled in the
+        <filename>local.conf.template</filename> using the
+        <link linkend='var-USER_CLASSES'><filename>USER_CLASSES</filename></link>
+        variable as follows:
+        <literallayout class='monospaced'>
+     USER_CLASSES ?= "buildstats image-mklibs image-prelink"
+        </literallayout>
+    </para>
+</section>
+
+<section id='ref-classes-image-prelink'>
+    <title><filename>image-prelink.bbclass</filename></title>
+
+    <para>
+        The <filename>image-prelink</filename> class
+        enables the use of the <filename>prelink</filename> utility during
+        the
+        <link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>
+        task, which optimizes the dynamic
+        linking of shared libraries to reduce executable startup time.
+    </para>
+
+    <para>
+        By default, the class is enabled in the
+        <filename>local.conf.template</filename> using the
+        <link linkend='var-USER_CLASSES'><filename>USER_CLASSES</filename></link>
+        variable as follows:
+        <literallayout class='monospaced'>
+     USER_CLASSES ?= "buildstats image-mklibs image-prelink"
+        </literallayout>
+    </para>
+</section>
+
+<section id='ref-classes-image-swab'>
+    <title><filename>image-swab.bbclass</filename></title>
+
+    <para>
+        The <filename>image-swab</filename> class enables the
+        <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/swabber'>Swabber</ulink>
+        tool in order to detect and log accesses to the host system during
+        the OpenEmbedded build process.
+        <note>
+            This class is currently unmaintained.
+        </note>
+    </para>
+</section>
+
+<section id='ref-classes-image-vmdk'>
+    <title><filename>image-vmdk.bbclass</filename></title>
+
+    <para>
+        The <filename>image-vmdk</filename> class supports building VMware
+        VMDK images.
+        Normally, you do not use this class directly.
+        Instead, you add "vmdk" to
+        <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>.
+    </para>
+</section>
+
+<section id='ref-classes-insane'>
+    <title><filename>insane.bbclass</filename></title>
+
+    <para>
+        The <filename>insane</filename> class adds a step to the package
+        generation process so that output quality assurance checks are
+        generated by the OpenEmbedded build system.
+        A range of checks are performed that check the build's output
+        for common problems that show up during runtime.
+        Distribution policy usually dictates whether to include this class.
+    </para>
+
+    <para>
+        You can configure the sanity checks so that specific test failures
+        either raise a warning or an error message.
+        Typically, failures for new tests generate a warning.
+        Subsequent failures for the same test would then generate an error
+        message once the metadata is in a known and good condition.
+        See the
+        "<link linkend='ref-qa-checks'>QA Error and Warning Messages</link>"
+        Chapter for a list of all the warning and error messages
+        you might encounter using a default configuration.
+    </para>
+
+    <para>
+        Use the
+        <link linkend='var-WARN_QA'><filename>WARN_QA</filename></link> and
+        <link linkend='var-ERROR_QA'><filename>ERROR_QA</filename></link>
+        variables to control the behavior of
+        these checks at the global level (i.e. in your custom distro
+        configuration).
+        However, to skip one or more checks in recipes, you should use
+        <link linkend='var-INSANE_SKIP'><filename>INSANE_SKIP</filename></link>.
+        For example, to skip the check for symbolic link
+        <filename>.so</filename> files in the main package of a recipe,
+        add the following to the recipe.
+        You need to realize that the package name override, in this example
+        <filename>${PN}</filename>, must be used:
+        <literallayout class='monospaced'>
+     INSANE_SKIP_${PN} += "dev-so"
+        </literallayout>
+        Please keep in mind that the QA checks exist in order to detect real
+        or potential problems in the packaged output.
+        So exercise caution when disabling these checks.
+    </para>
+
+    <para>
+        The following list shows the tests you can list with the
+        <filename>WARN_QA</filename> and <filename>ERROR_QA</filename>
+        variables:
+        <itemizedlist>
+            <listitem><para><emphasis><filename>already-stripped:</filename></emphasis>
+                Checks that produced binaries have not already been
+                stripped prior to the build system extracting debug symbols.
+                It is common for upstream software projects to default to
+                stripping debug symbols for output binaries.
+                In order for debugging to work on the target using
+                <filename>-dbg</filename> packages, this stripping must be
+                disabled.
+                </para></listitem>
+            <listitem><para><emphasis><filename>arch:</filename></emphasis>
+                Checks the Executable and Linkable Format (ELF) type, bit size,
+                and endianness of any binaries to ensure they match the target
+                architecture.
+                This test fails if any binaries do not match the type since
+                there would be an incompatibility.
+                The test could indicate that the
+                wrong compiler or compiler options have been used.
+                Sometimes software, like bootloaders, might need to bypass
+                this check.
+                </para></listitem>
+            <listitem><para><emphasis><filename>buildpaths:</filename></emphasis>
+                Checks for paths to locations on the build host inside the
+                output files.
+                Currently, this test triggers too many false positives and
+                thus is not normally enabled.
+                </para></listitem>
+            <listitem><para><emphasis><filename>build-deps:</filename></emphasis>
+                Determines if a build-time dependency that is specified through
+                <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>,
+                explicit
+                <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>,
+                or task-level dependencies exists to match any runtime
+                dependency.
+                This determination is particularly useful to discover where
+                runtime dependencies are detected and added during packaging.
+                If no explicit dependency has been specified within the
+                metadata, at the packaging stage it is too late to ensure that
+                the dependency is built, and thus you can end up with an
+                error when the package is installed into the image during the
+                <link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>
+                task because the auto-detected dependency was not satisfied.
+                An example of this would be where the
+                <link linkend='ref-classes-update-rc.d'><filename>update-rc.d</filename></link>
+                class automatically adds a dependency on the
+                <filename>initscripts-functions</filename> package to packages
+                that install an initscript that refers to
+                <filename>/etc/init.d/functions</filename>.
+                The recipe should really have an explicit
+                <filename>RDEPENDS</filename> for the package in question on
+                <filename>initscripts-functions</filename> so that the
+                OpenEmbedded build system is able to ensure that the
+                <filename>initscripts</filename> recipe is actually built and
+                thus the <filename>initscripts-functions</filename> package is
+                made available.
+                </para></listitem>
+            <listitem><para><emphasis><filename>compile-host-path:</filename></emphasis>
+                Checks the
+                <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
+                log for indications
+                that paths to locations on the build host were used.
+                Using such paths might result in host contamination of the
+                build output.
+                </para></listitem>
+            <listitem><para><emphasis><filename>debug-deps:</filename></emphasis>
+                Checks that all packages except <filename>-dbg</filename>
+                packages do not depend on <filename>-dbg</filename>
+                packages, which would cause a packaging bug.
+                </para></listitem>
+            <listitem><para><emphasis><filename>debug-files:</filename></emphasis>
+                Checks for <filename>.debug</filename> directories in anything but the
+                <filename>-dbg</filename> package.
+                The debug files should all be in the <filename>-dbg</filename> package.
+                Thus, anything packaged elsewhere is incorrect packaging.</para></listitem>
+            <listitem><para><emphasis><filename>dep-cmp:</filename></emphasis>
+                Checks for invalid version comparison statements in runtime
+                dependency relationships between packages (i.e. in
+                <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>,
+                <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
+                <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>,
+                <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
+                <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>,
+                and
+                <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>
+                variable values).
+                Any invalid comparisons might trigger failures or undesirable
+                behavior when passed to the package manager.
+                </para></listitem>
+            <listitem><para><emphasis><filename>desktop:</filename></emphasis>
+                Runs the <filename>desktop-file-validate</filename> program
+                against any <filename>.desktop</filename> files to validate
+                their contents against the specification for
+                <filename>.desktop</filename> files.</para></listitem>
+            <listitem><para><emphasis><filename>dev-deps:</filename></emphasis>
+                Checks that all packages except <filename>-dev</filename>
+                or <filename>-staticdev</filename> packages do not depend on
+                <filename>-dev</filename> packages, which would be a
+                packaging bug.</para></listitem>
+            <listitem><para><emphasis><filename>dev-so:</filename></emphasis>
+                Checks that the <filename>.so</filename> symbolic links are in the
+                <filename>-dev</filename> package and not in any of the other packages.
+                In general, these symlinks are only useful for development purposes.
+                Thus, the <filename>-dev</filename> package is the correct location for
+                them.
+                Some very rare cases do exist for dynamically loaded modules where
+                these symlinks are needed instead in the main package.
+                </para></listitem>
+            <listitem><para><emphasis><filename>file-rdeps:</filename></emphasis>
+                Checks that file-level dependencies identified by the
+                OpenEmbedded build system at packaging time are satisfied.
+                For example, a shell script might start with the line
+                <filename>#!/bin/bash</filename>.
+                This line would translate to a file dependency on
+                <filename>/bin/bash</filename>.
+                Of the three package managers that the OpenEmbedded build
+                system supports, only RPM directly handles file-level
+                dependencies, resolving them automatically to packages
+                providing the files.
+                However, the lack of that functionality in the other two
+                package managers does not mean the dependencies do not still
+                need resolving.
+                This QA check attempts to ensure that explicitly declared
+                <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
+                exist to handle any file-level dependency detected in
+                packaged files.
+                </para></listitem>
+            <listitem><para><emphasis><filename>files-invalid:</filename></emphasis>
+                Checks for
+                <link linkend='var-FILES'><filename>FILES</filename></link>
+                variable values that contain "//", which is invalid.
+                </para></listitem>
+            <listitem><para><emphasis><filename>incompatible-license:</filename></emphasis>
+                Report when packages are excluded from being created due to
+                being marked with a license that is in
+                <link linkend='var-INCOMPATIBLE_LICENSE'><filename>INCOMPATIBLE_LICENSE</filename></link>.
+                </para></listitem>
+            <listitem><para><emphasis><filename>install-host-path:</filename></emphasis>
+                Checks the
+                <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+                log for indications
+                that paths to locations on the build host were used.
+                Using such paths might result in host contamination of the
+                build output.
+                </para></listitem>
+            <listitem><para><emphasis><filename>installed-vs-shipped:</filename></emphasis>
+                Reports when files have been installed within
+                <filename>do_install</filename> but have not been included in
+                any package by way of the
+                <link linkend='var-FILES'><filename>FILES</filename></link>
+                variable.
+                Files that do not appear in any package cannot be present in
+                an image later on in the build process.
+                Ideally, all installed files should be packaged or not
+                installed at all.
+                These files can be deleted at the end of
+                <filename>do_install</filename> if the files are not
+                needed in any package.
+                </para></listitem>
+            <listitem><para><emphasis><filename>la:</filename></emphasis>
+                Checks <filename>.la</filename> files for any <filename>TMPDIR</filename>
+                paths.
+                Any <filename>.la</filename> file containing these paths is incorrect since
+                <filename>libtool</filename> adds the correct sysroot prefix when using the
+                files automatically itself.</para></listitem>
+            <listitem><para><emphasis><filename>ldflags:</filename></emphasis>
+                Ensures that the binaries were linked with the
+                <link linkend='var-LDFLAGS'><filename>LDFLAGS</filename></link>
+                options provided by the build system.
+                If this test fails, check that the <filename>LDFLAGS</filename> variable
+                is being passed to the linker command.</para></listitem>
+            <listitem><para><emphasis><filename>libdir:</filename></emphasis>
+                Checks for libraries being installed into incorrect
+                (possibly hardcoded) installation paths.
+                For example, this test will catch recipes that install
+                <filename>/lib/bar.so</filename> when
+                <filename>${base_libdir}</filename> is "lib32".
+                Another example is when recipes install
+                <filename>/usr/lib64/foo.so</filename> when
+                <filename>${libdir}</filename> is "/usr/lib".
+                </para></listitem>
+            <listitem><para><emphasis><filename>libexec:</filename></emphasis>
+                Checks if a package contains files in
+                <filename>/usr/libexec</filename>.
+                This check is not performed if the
+                <filename>libexecdir</filename> variable has been set
+                explicitly to <filename>/usr/libexec</filename>.
+                </para></listitem>
+            <listitem><para><emphasis><filename>packages-list:</filename></emphasis>
+                Checks for the same package being listed multiple times through
+                the <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>
+                variable value.
+                Installing the package in this manner can cause errors during
+                packaging.
+                </para></listitem>
+            <listitem><para><emphasis><filename>perm-config:</filename></emphasis>
+                Reports lines in <filename>fs-perms.txt</filename> that have
+                an invalid format.
+                </para></listitem>
+            <listitem><para><emphasis><filename>perm-line:</filename></emphasis>
+                Reports lines in <filename>fs-perms.txt</filename> that have
+                an invalid format.
+                </para></listitem>
+            <listitem><para><emphasis><filename>perm-link:</filename></emphasis>
+                Reports lines in <filename>fs-perms.txt</filename> that
+                specify 'link' where the specified target already exists.
+                </para></listitem>
+            <listitem><para><emphasis><filename>perms:</filename></emphasis>
+                Currently, this check is unused but reserved.
+                </para></listitem>
+            <listitem><para><emphasis><filename>pkgconfig:</filename></emphasis>
+                Checks <filename>.pc</filename> files for any
+                <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>/<link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
+                paths.
+                Any <filename>.pc</filename> file containing these paths is incorrect
+                since <filename>pkg-config</filename> itself adds the correct sysroot prefix
+                when the files are accessed.</para></listitem>
+            <listitem><para><emphasis><filename>pkgname:</filename></emphasis>
+                Checks that all packages in
+                <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>
+                have names that do not contain invalid characters (i.e.
+                characters other than 0-9, a-z, ., +, and -).
+                </para></listitem>
+            <listitem><para><emphasis><filename>pkgv-undefined:</filename></emphasis>
+                Checks to see if the <filename>PKGV</filename> variable
+                is undefined during
+                <link linkend='ref-tasks-package'><filename>do_package</filename></link>.
+                </para></listitem>
+            <listitem><para><emphasis><filename>pkgvarcheck:</filename></emphasis>
+                Checks through the variables
+                <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>,
+                <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
+                <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>,
+                <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>,
+                <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
+                <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>,
+                <link linkend='var-FILES'><filename>FILES</filename></link>,
+                <link linkend='var-ALLOW_EMPTY'><filename>ALLOW_EMPTY</filename></link>,
+                <filename>pkg_preinst</filename>,
+                <filename>pkg_postinst</filename>,
+                <filename>pkg_prerm</filename>
+                and <filename>pkg_postrm</filename>, and reports if there are
+                variable sets that are not package-specific.
+                Using these variables without a package suffix is bad practice,
+                and might unnecessarily complicate dependencies of other packages
+                within the same recipe or have other unintended consequences.
+                </para></listitem>
+            <listitem><para><emphasis><filename>pn-overrides:</filename></emphasis>
+                Checks that a recipe does not have a name
+                (<link linkend='var-PN'><filename>PN</filename></link>) value
+                that appears in
+                <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>.
+                If a recipe is named such that its <filename>PN</filename>
+                value matches something already in
+                <filename>OVERRIDES</filename> (e.g. <filename>PN</filename>
+                happens to be the same as
+                <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+                or
+                <link linkend='var-DISTRO'><filename>DISTRO</filename></link>),
+                it can have unexpected consequences.
+                For example, assignments such as
+                <filename>FILES_${PN} = "xyz"</filename> effectively turn into
+                <filename>FILES = "xyz"</filename>.
+                </para></listitem>
+           <listitem><para><emphasis><filename>rpaths:</filename></emphasis>
+                Checks for rpaths in the binaries that contain build system paths such
+                as <filename>TMPDIR</filename>.
+                If this test fails, bad <filename>-rpath</filename> options are being
+                passed to the linker commands and your binaries have potential security
+                issues.</para></listitem>
+            <listitem><para><emphasis><filename>split-strip:</filename></emphasis>
+                Reports that splitting or stripping debug symbols from binaries
+                has failed.
+                </para></listitem>
+            <listitem><para><emphasis><filename>staticdev:</filename></emphasis>
+                Checks for static library files (<filename>*.a</filename>) in
+                non-<filename>staticdev</filename> packages.
+                </para></listitem>
+            <listitem><para><emphasis><filename>symlink-to-sysroot:</filename></emphasis>
+                Checks for symlinks in packages that point into
+                <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
+                on the host.
+                Such symlinks will work on the host, but are clearly invalid
+                when running on the target.
+                </para></listitem>
+            <listitem><para><emphasis><filename>textrel:</filename></emphasis>
+                Checks for ELF binaries that contain relocations in their
+                <filename>.text</filename> sections, which can result in a
+                performance impact at runtime.</para></listitem>
+            <listitem><para><emphasis><filename>unsafe-references-in-binaries:</filename></emphasis>
+                Reports when a binary installed in
+                <filename>${base_libdir}</filename>,
+                <filename>${base_bindir}</filename>, or
+                <filename>${base_sbindir}</filename>, depends on another
+                binary installed under <filename>${exec_prefix}</filename>.
+                This dependency is a concern if you want the system to remain
+                basically operable if <filename>/usr</filename> is mounted
+                separately and is not mounted.
+                <note>
+                    Defaults for binaries installed in
+                    <filename>${base_libdir}</filename>,
+                    <filename>${base_bindir}</filename>, and
+                    <filename>${base_sbindir}</filename> are
+                    <filename>/lib</filename>, <filename>/bin</filename>, and
+                    <filename>/sbin</filename>, respectively.
+                    The default for a binary installed
+                    under <filename>${exec_prefix}</filename> is
+                    <filename>/usr</filename>.
+                </note>
+                </para></listitem>
+            <listitem><para><emphasis><filename>unsafe-references-in-scripts:</filename></emphasis>
+                Reports when a script file installed in
+                <filename>${base_libdir}</filename>,
+                <filename>${base_bindir}</filename>, or
+                <filename>${base_sbindir}</filename>, depends on files
+                installed under <filename>${exec_prefix}</filename>.
+                This dependency is a concern if you want the system to remain
+                basically operable if <filename>/usr</filename> is mounted
+                separately and is not mounted.
+                <note>
+                    Defaults for binaries installed in
+                    <filename>${base_libdir}</filename>,
+                    <filename>${base_bindir}</filename>, and
+                    <filename>${base_sbindir}</filename> are
+                    <filename>/lib</filename>, <filename>/bin</filename>, and
+                    <filename>/sbin</filename>, respectively.
+                    The default for a binary installed
+                    under <filename>${exec_prefix}</filename> is
+                    <filename>/usr</filename>.
+                </note>
+                </para></listitem>
+            <listitem><para><emphasis><filename>useless-rpaths:</filename></emphasis>
+                Checks for dynamic library load paths (rpaths) in the binaries that
+                by default on a standard system are searched by the linker (e.g.
+                <filename>/lib</filename> and <filename>/usr/lib</filename>).
+                While these paths will not cause any breakage, they do waste space and
+                are unnecessary.</para></listitem>
+            <listitem><para><emphasis><filename>var-undefined:</filename></emphasis>
+                Reports when variables fundamental to packaging (i.e.
+                <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>,
+                <link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>,
+                <link linkend='var-D'><filename>D</filename></link>,
+                <link linkend='var-PN'><filename>PN</filename></link>, and
+                <link linkend='var-PKGD'><filename>PKGD</filename></link>) are
+                undefined during
+                <link linkend='ref-tasks-package'><filename>do_package</filename></link>.
+                </para></listitem>
+            <listitem><para><emphasis><filename>version-going-backwards:</filename></emphasis>
+                If Build History is enabled, reports when a package
+                being written out has a lower version than the previously
+                written package under the same name.
+                If you are placing output packages into a feed and
+                upgrading packages on a target system using that feed, the
+                version of a package going backwards can result in the target
+                system not correctly upgrading to the "new" version of the
+                package.
+                <note>
+                    If you are not using runtime package management on your
+                    target system, then you do not need to worry about
+                    this situation.
+                </note>
+                </para></listitem>
+            <listitem><para><emphasis><filename>xorg-driver-abi:</filename></emphasis>
+                Checks that all packages containing Xorg drivers have ABI
+                dependencies.
+                The <filename>xserver-xorg</filename> recipe provides driver
+                ABI names.
+                All drivers should depend on the ABI versions that they have
+                been built against.
+                Driver recipes that include
+                <filename>xorg-driver-input.inc</filename>
+                or <filename>xorg-driver-video.inc</filename> will
+                automatically get these versions.
+                Consequently, you should only need to explicitly add
+                dependencies to binary driver recipes.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='ref-classes-insserv'>
+    <title><filename>insserv.bbclass</filename></title>
+
+    <para>
+        The <filename>insserv</filename> class
+        uses the <filename>insserv</filename> utility to update the order of
+        symbolic links in <filename>/etc/rc?.d/</filename> within an image
+        based on dependencies specified by LSB headers in the
+        <filename>init.d</filename> scripts themselves.
+    </para>
+</section>
+
+<section id='ref-classes-kernel'>
+    <title><filename>kernel.bbclass</filename></title>
+
+    <para>
+        The <filename>kernel</filename> class handles building Linux kernels.
+        The class contains code to build all kernel trees.
+        All needed headers are staged into the
+        <filename><link linkend='var-STAGING_KERNEL_DIR'>STAGING_KERNEL_DIR</link></filename>
+        directory to allow out-of-tree module builds using
+        the
+        <link linkend='ref-classes-module'><filename>module</filename></link>
+        class.
+    </para>
+
+    <para>
+        This means that each built kernel module is packaged separately and inter-module
+        dependencies are created by parsing the <filename>modinfo</filename> output.
+        If all modules are required, then installing the <filename>kernel-modules</filename>
+        package installs all packages with modules and various other kernel packages
+        such as <filename>kernel-vmlinux</filename>.
+    </para>
+
+    <para>
+        Various other classes are used by the <filename>kernel</filename>
+        and <filename>module</filename> classes internally including the
+        <link linkend='ref-classes-kernel-arch'><filename>kernel-arch</filename></link>,
+        <link linkend='ref-classes-module-base'><filename>module-base</filename></link>,
+        and
+        <link linkend='ref-classes-linux-kernel-base'><filename>linux-kernel-base</filename></link>
+        classes.
+    </para>
+</section>
+
+<section id='ref-classes-kernel-arch'>
+    <title><filename>kernel-arch.bbclass</filename></title>
+
+    <para>
+        The <filename>kernel-arch</filename> class
+        sets the <filename>ARCH</filename> environment variable for Linux
+        kernel compilation (including modules).
+    </para>
+</section>
+
+<section id='ref-classes-kernel-module-split'>
+    <title><filename>kernel-module-split.bbclass</filename></title>
+
+    <para>
+        The <filename>kernel-module-split</filename> class
+        provides common functionality for splitting Linux kernel modules into
+        separate packages.
+    </para>
+</section>
+
+<section id='ref-classes-kernel-yocto'>
+    <title><filename>kernel-yocto.bbclass</filename></title>
+
+    <para>
+        The <filename>kernel-yocto</filename> class
+        provides common functionality for building from linux-yocto style
+        kernel source repositories.
+    </para>
+</section>
+
+<section id='ref-classes-lib_package'>
+    <title><filename>lib_package.bbclass</filename></title>
+
+    <para>
+        The <filename>lib_package</filename> class
+        supports recipes that build libraries and produce executable
+        binaries, where those binaries should not be installed by default
+        along with the library.
+        Instead, the binaries are added to a separate
+        <filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}-bin</filename>
+        package to make their installation optional.
+    </para>
+</section>
+
+<section id='ref-classes-license'>
+    <title><filename>license.bbclass</filename></title>
+
+    <para>
+        The <filename>license</filename> class provides license
+        manifest creation and license exclusion.
+        This class is enabled by default using the default value for the
+        <link linkend='var-INHERIT_DISTRO'><filename>INHERIT_DISTRO</filename></link>
+        variable.
+    </para>
+</section>
+
+<section id='ref-classes-linux-kernel-base'>
+    <title><filename>linux-kernel-base.bbclass</filename></title>
+
+    <para>
+        The <filename>linux-kernel-base</filename> class
+        provides common functionality for recipes that build out of the Linux
+        kernel source tree.
+        These builds goes beyond the kernel itself.
+        For example, the Perf recipe also inherits this class.
+    </para>
+</section>
+
+<section id='ref-classes-logging'>
+    <title><filename>logging.bbclass</filename></title>
+
+    <para>
+        The <filename>logging</filename> class provides the standard
+        shell functions used to log messages for various BitBake severity levels
+        (i.e. <filename>bbplain</filename>, <filename>bbnote</filename>,
+        <filename>bbwarn</filename>, <filename>bberror</filename>,
+        <filename>bbfatal</filename>, and <filename>bbdebug</filename>).
+    </para>
+
+    <para>
+        This class is enabled by default since it is inherited by
+        the <filename>base</filename> class.
+    </para>
+</section>
+
+<section id='ref-classes-meta'>
+    <title><filename>meta.bbclass</filename></title>
+
+    <para>
+        The <filename>meta</filename> class is inherited by recipes
+        that do not build any output packages themselves, but act as a "meta"
+        target for building other recipes.
+    </para>
+</section>
+
+<section id='ref-classes-metadata_scm'>
+    <title><filename>metadata_scm.bbclass</filename></title>
+
+    <para>
+        The <filename>metadata_scm</filename> class provides functionality for
+        querying the branch and revision of a Source Code Manager (SCM)
+        repository.
+    </para>
+
+    <para>
+        The <link linkend='ref-classes-base'><filename>base</filename></link>
+        class uses this class to print the revisions of each layer before
+        starting every build.
+        The <filename>metadata_scm</filename> class is enabled by default
+        because it is inherited by the <filename>base</filename> class.
+    </para>
+</section>
+
+<section id='ref-classes-mime'>
+    <title><filename>mime.bbclass</filename></title>
+
+    <para>
+        The <filename>mime</filename> class generates the proper
+        post-install and post-remove (postinst/postrm) scriptlets for packages
+        that install MIME type files.
+        These scriptlets call <filename>update-mime-database</filename> to add
+        the MIME types to the shared database.
+    </para>
+</section>
+
+<section id='ref-classes-mirrors'>
+    <title><filename>mirrors.bbclass</filename></title>
+
+    <para>
+        The <filename>mirrors</filename> class sets up some standard
+        <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link> entries
+        for source code mirrors.
+        These mirrors provide a fall-back path in case the upstream source
+        specified in
+        <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+        within recipes is unavailable.
+    </para>
+
+    <para>
+        This class is enabled by default since it is inherited by the
+        <link linkend='ref-classes-base'><filename>base</filename></link> class.
+    </para>
+</section>
+
+<section id='ref-classes-module'>
+    <title><filename>module.bbclass</filename></title>
+
+    <para>
+        The <filename>module</filename> class provides support for building
+        out-of-tree Linux kernel modules.
+        The class inherits the
+        <link linkend='ref-classes-module-base'><filename>module-base</filename></link>
+        and
+        <link linkend='ref-classes-kernel-module-split'><filename>kernel-module-split</filename></link>
+        classes, and implements the
+        <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
+        and
+        <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+        tasks.
+        The class provides everything needed to build and package a kernel
+        module.
+    </para>
+
+    <para>
+        For general information on out-of-tree Linux kernel modules, see the
+        "<ulink url='&YOCTO_DOCS_KERNEL_URL;#incorporating-out-of-tree-modules'>Incorporating Out-of-Tree Modules</ulink>"
+        section in the Yocto Project Linux Kernel Development Manual.
+    </para>
+</section>
+
+<section id='ref-classes-module-base'>
+    <title><filename>module-base.bbclass</filename></title>
+
+    <para>
+        The <filename>module-base</filename> class provides the base
+        functionality for building Linux kernel modules.
+        Typically, a recipe that builds software that includes one or
+        more kernel modules and has its own means of building
+        the module inherits this class as opposed to inheriting the
+        <link linkend='ref-classes-module'><filename>module</filename></link>
+        class.
+    </para>
+</section>
+
+<section id='ref-classes-multilib*'>
+    <title><filename>multilib*.bbclass</filename></title>
+
+    <para>
+        The <filename>multilib*</filename> classes provide support
+        for building libraries with different target optimizations or target
+        architectures and installing them side-by-side in the same image.
+    </para>
+
+    <para>
+        For more information on using the Multilib feature, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#combining-multiple-versions-library-files-into-one-image'>Combining Multiple Versions of Library Files into One Image</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+</section>
+
+<section id='ref-classes-native'>
+    <title><filename>native.bbclass</filename></title>
+
+    <para>
+        The <filename>native</filename> class provides common
+        functionality for recipes that wish to build tools to run on the build
+        host (i.e. tools that use the compiler or other tools from the
+        build host).
+    </para>
+
+    <para>
+        You can create a recipe that builds tools that run natively on the
+        host a couple different ways:
+        <itemizedlist>
+            <listitem><para>Create a <replaceable>myrecipe</replaceable><filename>-native.bb</filename>
+                that inherits the <filename>native</filename> class.
+                If you use this method, you must order the inherit statement
+                in the recipe after all other inherit statements so that the
+                <filename>native</filename> class is inherited last.
+                </para></listitem>
+            <listitem><para>Create or modify a target recipe that contains
+                the following:
+                <literallayout class='monospaced'>
+     <link linkend='var-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></link> = "native"
+                </literallayout>
+                Inside the recipe, use <filename>_class-native</filename> and
+                <filename>_class-target</filename> overrides to specify any
+                functionality specific to the respective native or target
+                case.</para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        Although applied differently, the <filename>native</filename> class is
+        used with both methods.
+        The advantage of the second method is that you do not need to have two
+        separate recipes (assuming you need both) for native and target.
+        All common parts of the recipe are automatically shared.
+    </para>
+</section>
+
+<section id='ref-classes-nativesdk'>
+    <title><filename>nativesdk.bbclass</filename></title>
+
+    <para>
+        The <filename>nativesdk</filename> class provides common
+        functionality for recipes that wish to build tools to run as part of
+        an SDK (i.e. tools that run on
+        <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>).
+    </para>
+
+    <para>
+        You can create a recipe that builds tools that run on the SDK machine
+        a couple different ways:
+        <itemizedlist>
+            <listitem><para>Create a <replaceable>myrecipe</replaceable><filename>-nativesdk.bb</filename>
+                recipe that inherits the <filename>nativesdk</filename> class.
+                If you use this method, you must order the inherit statement
+                in the recipe after all other inherit statements so that the
+                <filename>nativesdk</filename> class is inherited last.
+                </para></listitem>
+            <listitem><para>Create a <filename>nativesdk</filename> variant
+                of any recipe by adding the following:
+                <literallayout class='monospaced'>
+     <link linkend='var-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></link> = "nativesdk"
+                </literallayout>
+                Inside the recipe, use <filename>_class-nativesdk</filename> and
+                <filename>_class-target</filename> overrides to specify any
+                functionality specific to the respective SDK machine or target
+                case.</para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        Although applied differently, the <filename>nativesdk</filename> class
+        is used with both methods.
+        The advantage of the second method is that you do not need to have two
+        separate recipes (assuming you need both) for the SDK machine and the
+        target.
+        All common parts of the recipe are automatically shared.
+    </para>
+</section>
+
+<section id='ref-classes-oelint'>
+    <title><filename>oelint.bbclass</filename></title>
+
+    <para>
+        The <filename>oelint</filename> class is an
+        obsolete lint checking tool that exists in
+        <filename>meta/classes</filename> in the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+    </para>
+
+    <para>
+        A number of classes exist that are could be generally useful in
+        OE-Core but are never actually used within OE-Core itself.
+        The <filename>oelint</filename> class is one such example.
+        However, being aware of this class can reduce the proliferation of
+        different versions of similar classes across multiple layers.
+    </para>
+</section>
+
+<section id='ref-classes-own-mirrors'>
+    <title><filename>own-mirrors.bbclass</filename></title>
+
+    <para>
+        The <filename>own-mirrors</filename> class makes it
+        easier to set up your own
+        <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>
+        from which to first fetch source before attempting to fetch it from the
+        upstream specified in
+        <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+        within each recipe.
+    </para>
+
+    <para>
+        To use this class, inherit it globally and specify
+        <link linkend='var-SOURCE_MIRROR_URL'><filename>SOURCE_MIRROR_URL</filename></link>.
+        Here is an example:
+        <literallayout class='monospaced'>
+     INHERIT += "own-mirrors"
+     SOURCE_MIRROR_URL = "http://example.com/my-source-mirror"
+        </literallayout>
+        You can specify only a single URL in
+        <filename>SOURCE_MIRROR_URL</filename>.
+    </para>
+</section>
+
+<section id='ref-classes-package'>
+    <title><filename>package.bbclass</filename></title>
+
+    <para>
+        The <filename>package</filename> class supports generating
+        packages from a build's output.
+        The core generic functionality is in
+        <filename>package.bbclass</filename>.
+        The code specific to particular package types resides in these
+        package-specific classes:
+        <link linkend='ref-classes-package_deb'><filename>package_deb</filename></link>,
+        <link linkend='ref-classes-package_rpm'><filename>package_rpm</filename></link>,
+        <link linkend='ref-classes-package_ipk'><filename>package_ipk</filename></link>,
+        and
+        <link linkend='ref-classes-package_tar'><filename>package_tar</filename></link>.
+    </para>
+
+    <para>
+        You can control the list of resulting package formats by using the
+        <filename><link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link></filename>
+        variable defined in your <filename>conf/local.conf</filename>
+        configuration file, which is located in the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+        When defining the variable, you can specify one or more package types.
+        Since images are generated from packages, a packaging class is
+        needed to enable image generation.
+        The first class listed in this variable is used for image generation.
+    </para>
+
+    <para>
+        If you take the optional step to set up a repository (package feed)
+        on the development host that can be used by Smart, you can
+        install packages from the feed while you are running the image
+        on the target (i.e. runtime installation of packages).
+        For more information, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#using-runtime-package-management'>Using Runtime Package Management</ulink>"
+         section in the Yocto Project Development Manual.
+    </para>
+
+    <para>
+        The package-specific class you choose can affect build-time performance
+        and has space ramifications.
+        In general, building a package with IPK takes about thirty percent less
+        time as compared to using RPM to build the same or similar package.
+        This comparison takes into account a complete build of the package with
+        all dependencies previously built.
+        The reason for this discrepancy is because the RPM package manager
+        creates and processes more
+        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> than the
+        IPK package manager.
+        Consequently, you might consider setting
+        <filename>PACKAGE_CLASSES</filename> to "package_ipk" if you are
+        building smaller systems.
+    </para>
+
+    <para>
+        Before making your package manager decision, however, you should
+        consider some further things about using RPM:
+        <itemizedlist>
+            <listitem><para>
+                RPM starts to provide more abilities than IPK due to
+                the fact that it processes more Metadata.
+                For example, this information includes individual file types,
+                file checksum generation and evaluation on install, sparse file
+                support, conflict detection and resolution for Multilib systems,
+                ACID style upgrade, and repackaging abilities for rollbacks.
+                </para></listitem>
+            <listitem><para>
+                For smaller systems, the extra space used for the Berkeley
+                Database and the amount of metadata when using RPM can affect
+                your ability to perform on-device upgrades.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        You can find additional information on the effects of the package
+        class at these two Yocto Project mailing list links:
+        <itemizedlist>
+            <listitem><para><ulink url='&YOCTO_LISTS_URL;/pipermail/poky/2011-May/006362.html'>
+                https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html</ulink></para></listitem>
+            <listitem><para><ulink url='&YOCTO_LISTS_URL;/pipermail/poky/2011-May/006363.html'>
+                https://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html</ulink></para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='ref-classes-package_deb'>
+    <title><filename>package_deb.bbclass</filename></title>
+
+    <para>
+        The <filename>package_deb</filename> class
+        provides support for creating packages that use the
+        <filename>.deb</filename> file format.
+        The class ensures the packages are written out to the
+        <filename>${</filename><link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link><filename>}/deb</filename>
+        directory in a <filename>.deb</filename> file format.
+    </para>
+
+    <para>
+        This class inherits the
+        <link linkend='ref-classes-package'><filename>package</filename></link>
+        class and is enabled through the
+        <link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>
+        variable in the <filename>local.conf</filename> file.
+    </para>
+</section>
+
+<section id='ref-classes-package_ipk'>
+    <title><filename>package_ipk.bbclass</filename></title>
+
+    <para>
+        The <filename>package_ipk</filename> class
+        provides support for creating packages that use the
+        <filename>.ipk</filename> file format.
+        The class ensures the packages are written out to the
+        <filename>${</filename><link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link><filename>}/ipk</filename>
+        directory in a <filename>.ipk</filename> file format.
+    </para>
+
+    <para>
+        This class inherits the
+        <link linkend='ref-classes-package'><filename>package</filename></link>
+        class and is enabled through the
+        <link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>
+        variable in the <filename>local.conf</filename> file.
+    </para>
+</section>
+
+<section id='ref-classes-package_rpm'>
+    <title><filename>package_rpm.bbclass</filename></title>
+
+    <para>
+        The <filename>package_rpm</filename> class
+        provides support for creating packages that use the
+        <filename>.rpm</filename> file format.
+        The class ensures the packages are written out to the
+        <filename>${</filename><link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link><filename>}/rpm</filename>
+        directory in a <filename>.rpm</filename> file format.
+    </para>
+
+    <para>
+        This class inherits the
+        <link linkend='ref-classes-package'><filename>package</filename></link>
+        class and is enabled through the
+        <link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>
+        variable in the <filename>local.conf</filename> file.
+    </para>
+</section>
+
+<section id='ref-classes-package_tar'>
+    <title><filename>package_tar.bbclass</filename></title>
+
+    <para>
+        The <filename>package_tar</filename>
+        class provides support for creating packages that use the
+        <filename>.tar</filename> file format.
+        The class ensures the packages are written out to the
+        <filename>${</filename><link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link><filename>}/tar</filename>
+        directory in a <filename>.tar</filename> file format.
+    </para>
+
+    <para>
+        This class inherits the
+        <link linkend='ref-classes-package'><filename>package</filename></link>
+        class and is enabled through the
+        <link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>
+        variable in the <filename>local.conf</filename> file.
+        <note>
+            You cannot specify the <filename>package_tar</filename> class
+            first using the <filename>PACKAGE_CLASSES</filename> variable.
+            You must use <filename>.deb</filename>,
+            <filename>.ipk</filename>, or <filename>.rpm</filename> file
+            formats for your image or SDK.
+        </note>
+    </para>
+</section>
+
+<section id='ref-classes-packagedata'>
+    <title><filename>packagedata.bbclass</filename></title>
+
+    <para>
+        The <filename>packagedata</filename> class provides
+        common functionality for reading <filename>pkgdata</filename> files
+        found in
+        <link linkend='var-PKGDATA_DIR'><filename>PKGDATA_DIR</filename></link>.
+        These files contain information about each output package produced by
+        the OpenEmbedded build system.
+    </para>
+
+    <para>
+        This class is enabled by default because it is inherited by the
+        <link linkend='ref-classes-package'><filename>package</filename></link>
+        class.
+    </para>
+</section>
+
+<section id='ref-classes-packagegroup'>
+    <title><filename>packagegroup.bbclass</filename></title>
+
+    <para>
+        The <filename>packagegroup</filename> class sets default values
+        appropriate for package group recipes (e.g.
+        <filename><link linkend='var-PACKAGES'>PACKAGES</link></filename>,
+        <filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename>,
+        <filename><link linkend='var-ALLOW_EMPTY'>ALLOW_EMPTY</link></filename>,
+        and so forth).
+        It is highly recommended that all package group recipes inherit this class.
+    </para>
+
+    <para>
+        For information on how to use this class, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-customtasks'>Customizing Images Using Custom Package Groups</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+
+    <para>
+        Previously, this class was called the <filename>task</filename> class.
+    </para>
+</section>
+
+<section id='ref-classes-packageinfo'>
+    <title><filename>packageinfo.bbclass</filename></title>
+
+    <para>
+        The <filename>packageinfo</filename> class
+        gives a BitBake user interface the ability to retrieve information
+        about output packages from the <filename>pkgdata</filename> files.
+    </para>
+
+    <para>
+        This class is enabled automatically when using the
+        <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink>
+        user interface.
+    </para>
+</section>
+
+<section id='ref-classes-patch'>
+    <title><filename>patch.bbclass</filename></title>
+
+    <para>
+        The <filename>patch</filename> class provides all functionality for
+        applying patches during the
+        <link linkend='ref-tasks-patch'><filename>do_patch</filename></link>
+        task.
+    </para>
+
+    <para>
+        This class is enabled by default because it is inherited by the
+        <link linkend='ref-classes-base'><filename>base</filename></link>
+        class.
+    </para>
+</section>
+
+<section id='ref-classes-perlnative'>
+    <title><filename>perlnative.bbclass</filename></title>
+
+    <para>
+        When inherited by a recipe, the <filename>perlnative</filename> class
+        supports using the native version of Perl built by the build system
+        rather than using the version provided by the build host.
+    </para>
+</section>
+
+<section id='ref-classes-pixbufcache'>
+    <title><filename>pixbufcache.bbclass</filename></title>
+
+    <para>
+        The <filename>pixbufcache</filename> class generates the proper
+        post-install and post-remove (postinst/postrm) scriptlets for packages
+        that install pixbuf loaders, which are used with
+        <filename>gdk-pixbuf</filename>.
+        These scriptlets call <filename>update_pixbuf_cache</filename>
+        to add the pixbuf loaders to the cache.
+        Since the cache files are architecture-specific,
+        <filename>update_pixbuf_cache</filename> is run using QEMU if the
+        postinst scriptlets need to be run on the build host during image
+        creation.
+    </para>
+
+    <para>
+        If the pixbuf loaders being installed are in packages other
+        than the recipe's main package, set
+        <link linkend='var-PIXBUF_PACKAGES'><filename>PIXBUF_PACKAGES</filename></link>
+        to specify the packages containing the loaders.
+    </para>
+</section>
+
+<section id='ref-classes-pkgconfig'>
+    <title><filename>pkgconfig.bbclass</filename></title>
+
+    <para>
+        The <filename>pkg-config</filename> class provides a standard way to get
+        header and library information.
+        This class aims to smooth integration of
+        <filename>pkg-config</filename> into libraries that use it.
+    </para>
+
+    <para>
+        During staging, BitBake installs <filename>pkg-config</filename> data into the
+        <filename>sysroots/</filename> directory.
+        By making use of sysroot functionality within <filename>pkg-config</filename>,
+        this class no longer has to manipulate the files.
+    </para>
+</section>
+
+<section id='ref-classes-populate-sdk'>
+    <title><filename>populate_sdk.bbclass</filename></title>
+
+    <para>
+        The <filename>populate_sdk</filename> class provides support for
+        SDK-only recipes.
+        For information on advantages gained when building a cross-development
+        toolchain using the
+        <link linkend='ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></link>
+        task, see the
+        "<ulink url='&YOCTO_DOCS_ADT_URL;#optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</ulink>"
+        section in the Yocto Project Application Developer's Guide.
+    </para>
+</section>
+
+<section id='ref-classes-populate-sdk-*'>
+    <title><filename>populate_sdk_*.bbclass</filename></title>
+
+    <para>
+        The <filename>populate_sdk_*</filename> classes support SDK creation
+        and consist of the following classes:
+        <itemizedlist>
+            <listitem><para><emphasis><filename>populate_sdk_base</filename>:</emphasis>
+                The base class supporting SDK creation under all package
+                managers (i.e. DEB, RPM, and opkg).</para></listitem>
+            <listitem><para><emphasis><filename>populate_sdk_deb</filename>:</emphasis>
+                Supports creation of the SDK given the Debian package manager.
+                </para></listitem>
+            <listitem><para><emphasis><filename>populate_sdk_rpm</filename>:</emphasis>
+                Supports creation of the SDK given the RPM package manager.
+                </para></listitem>
+            <listitem><para><emphasis><filename>populate_sdk_ipk</filename>:</emphasis>
+                Supports creation of the SDK given the opkg (IPK format)
+                package manager.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        The <filename>populate_sdk_base</filename> class inherits the
+        appropriate <filename>populate_sdk_*</filename> (i.e.
+        <filename>deb</filename>, <filename>rpm</filename>, and
+        <filename>ipk</filename>) based on
+        <link linkend='var-IMAGE_PKGTYPE'><filename>IMAGE_PKGTYPE</filename></link>.
+    </para>
+
+    <para>
+        The base class ensures all source and destination directories are
+        established and then populates the SDK.
+        After populating the SDK, the <filename>populate_sdk_base</filename>
+        class constructs two sysroots:
+        <filename>${</filename><link linkend='var-SDK_ARCH'><filename>SDK_ARCH</filename></link><filename>}-nativesdk</filename>,
+        which contains the cross-compiler and associated tooling, and the
+        target, which contains a target root filesystem that is configured for
+        the SDK usage.
+        These two images reside in
+        <link linkend='var-SDK_OUTPUT'><filename>SDK_OUTPUT</filename></link>,
+        which consists of the following:
+        <literallayout class='monospaced'>
+     ${SDK_OUTPUT}/${SDK_ARCH}<replaceable>-nativesdk-pkgs</replaceable>
+     ${SDK_OUTPUT}/${SDKTARGETSYSROOT}/<replaceable>target-pkgs</replaceable>
+        </literallayout>
+    </para>
+
+    <para>
+        Finally, the base populate SDK class creates the toolchain
+        environment setup script, the tarball of the SDK, and the installer.
+    </para>
+
+    <para>
+        The respective <filename>populate_sdk_deb</filename>,
+        <filename>populate_sdk_rpm</filename>, and
+        <filename>populate_sdk_ipk</filename> classes each support the
+        specific type of SDK.
+        These classes are inherited by and used with the
+        <filename>populate_sdk_base</filename> class.
+    </para>
+
+    <para>
+        For more information on the cross-development toolchain
+        generation, see the
+        "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
+        section.
+        For information on advantages gained when building a
+        cross-development toolchain using the
+        <link linkend='ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></link>
+        task, see the
+        "<ulink url='&YOCTO_DOCS_ADT_URL;#optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</ulink>"
+        section in the Yocto Project Application Developer's Guide.
+    </para>
+</section>
+
+<section id='ref-classes-prexport'>
+    <title><filename>prexport.bbclass</filename></title>
+
+    <para>
+        The <filename>prexport</filename> class provides functionality for
+        exporting
+        <link linkend='var-PR'><filename>PR</filename></link> values.
+        <note>
+            This class is not intended to be used directly.
+            Rather, it is enabled when using
+            "<filename>bitbake-prserv-tool export</filename>".
+        </note>
+    </para>
+</section>
+
+<section id='ref-classes-primport'>
+    <title><filename>primport.bbclass</filename></title>
+
+    <para>
+        The <filename>primport</filename> class provides functionality for
+        importing
+        <link linkend='var-PR'><filename>PR</filename></link> values.
+        <note>
+            This class is not intended to be used directly.
+            Rather, it is enabled when using
+            "<filename>bitbake-prserv-tool import</filename>".
+        </note>
+    </para>
+</section>
+
+<section id='ref-classes-prserv'>
+    <title><filename>prserv.bbclass</filename></title>
+
+    <para>
+        The <filename>prserv</filename> class provides functionality for
+        using a
+        <ulink url='&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service'>PR service</ulink>
+        in order to automatically manage the incrementing of the
+        <link linkend='var-PR'><filename>PR</filename></link> variable for
+        each recipe.
+    </para>
+
+    <para>
+        This class is enabled by default because it is inherited by the
+        <link linkend='ref-classes-package'><filename>package</filename></link>
+        class.
+        However, the OpenEmbedded build system will not enable the
+        functionality of this class unless
+        <link linkend='var-PRSERV_HOST'><filename>PRSERV_HOST</filename></link>
+        has been set.
+    </para>
+</section>
+
+<section id='ref-classes-ptest'>
+    <title><filename>ptest.bbclass</filename></title>
+
+    <para>
+        The <filename>ptest</filename> class provides functionality for
+        packaging and installing runtime tests for recipes that build software
+        that provides these tests.
+    </para>
+
+    <para>
+        This class is intended to be inherited by individual recipes.
+        However, the class' functionality is largely disabled unless "ptest"
+        appears in
+        <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
+        See the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest'>Testing Packages With ptest</ulink>"
+        section in the Yocto Project Development Manual for more information
+        on ptest.
+    </para>
+</section>
+
+<section id='ref-classes-ptest-gnome'>
+    <title><filename>ptest-gnome.bbclass</filename></title>
+
+    <para>
+        Enables package tests (ptests) specifically for GNOME packages,
+        which have tests intended to be executed with
+        <filename>gnome-desktop-testing</filename>.
+    </para>
+
+    <para>
+        For information on setting up and running ptests, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest'>Testing Packages With ptest</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+</section>
+
+<section id='ref-classes-python-dir'>
+    <title><filename>python-dir.bbclass</filename></title>
+
+    <para>
+        The <filename>python-dir</filename> class provides the base version,
+        location, and site package location for Python.
+    </para>
+</section>
+
+<section id='ref-classes-pythonnative'>
+    <title><filename>pythonnative.bbclass</filename></title>
+
+    <para>
+        When inherited by a recipe, the <filename>pythonnative</filename> class
+        supports using the native version of Python built by the build system
+        rather than using the version provided by the build host.
+    </para>
+</section>
+
+<section id='ref-classes-qemu'>
+    <title><filename>qemu.bbclass</filename></title>
+
+    <para>
+        The <filename>qemu</filename> class provides functionality for recipes
+        that either need QEMU or test for the existence of QEMU.
+        Typically, this class is used to run programs for a target system on
+        the build host using QEMU's application emulation mode.
+    </para>
+</section>
+
+<section id='ref-classes-qmake*'>
+    <title><filename>qmake*.bbclass</filename></title>
+
+    <para>
+        The <filename>qmake*</filename> classes support recipes that
+        need to build software that uses Qt's <filename>qmake</filename>
+        build system and are comprised of the following:
+        <itemizedlist>
+            <listitem><para><emphasis><filename>qmake_base</filename>:</emphasis>
+                Provides base functionality for all versions of
+                <filename>qmake</filename>.</para></listitem>
+            <listitem><para><emphasis><filename>qmake2</filename>:</emphasis>
+                Extends base functionality for <filename>qmake</filename> 2.x as
+                used by Qt 4.x.</para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        If you need to set any configuration variables or pass any options to
+        <filename>qmake</filename>, you can add these to the
+        <link linkend='var-EXTRA_QMAKEVARS_PRE'><filename>EXTRA_QMAKEVARS_PRE</filename></link>
+        or
+        <link linkend='var-EXTRA_QMAKEVARS_POST'><filename>EXTRA_QMAKEVARS_POST</filename></link>
+        variables, depending on whether the arguments need to be before or
+        after the <filename>.pro</filename> file list on the command line,
+        respectively.
+    </para>
+
+    <para>
+        By default, all <filename>.pro</filename> files are built.
+        If you want to specify your own subset of <filename>.pro</filename>
+        files to be built, specify them in the
+        <link linkend='var-QMAKE_PROFILES'><filename>QMAKE_PROFILES</filename></link>
+        variable.
+    </para>
+</section>
+
+<section id='ref-classes-qt4*'>
+    <title><filename>qt4*.bbclass</filename></title>
+
+    <para>
+        The <filename>qt4*</filename> classes support recipes that need to
+        build software that uses the Qt development framework version 4.x
+        and consist of the following:
+        <itemizedlist>
+            <listitem><para><emphasis><filename>qt4e</filename>:</emphasis>
+                Supports building against Qt/Embedded, which uses the
+                framebuffer for graphical output.</para></listitem>
+            <listitem><para><emphasis><filename>qt4x11</filename>:</emphasis>
+                Supports building against Qt/X11.</para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        The classes inherit the
+        <link linkend='ref-classes-qmake*'><filename>qmake2</filename></link>
+        class.
+    </para>
+</section>
+
+<section id='ref-classes-relocatable'>
+    <title><filename>relocatable.bbclass</filename></title>
+
+    <para>
+        The <filename>relocatable</filename> class enables relocation of
+        binaries when they are installed into the sysroot.
+    </para>
+
+    <para>
+        This class makes use of the
+        <link linkend='ref-classes-chrpath'><filename>chrpath</filename></link>
+        class and is used by both the
+        <link linkend='ref-classes-cross'><filename>cross</filename></link>
+        and
+        <link linkend='ref-classes-native'><filename>native</filename></link>
+        classes.
+    </para>
+</section>
+
+<section id='ref-classes-report-error'>
+    <title><filename>report-error.bbclass</filename></title>
+
+    <para>
+        The <filename>report-error</filename> class supports enabling the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#using-the-error-reporting-tool'>error reporting tool</ulink>,
+        which allows you to submit build error information to a central
+        database.
+    </para>
+
+    <para>
+        The class collects debug information for recipe, recipe version, task,
+        machine, distro, build system, target system, host distro, branch,
+        commit, and log.
+        From the information, report files using a JSON format are created and
+        stored in
+        <filename>${</filename><link linkend='var-LOG_DIR'><filename>LOG_DIR</filename></link><filename>}/error-report</filename>.
+    </para>
+</section>
+
+<section id='ref-classes-rm-work'>
+    <title><filename>rm_work.bbclass</filename></title>
+
+    <para>
+        The <filename>rm_work</filename> class supports deletion of temporary
+        workspace, which can ease your hard drive demands during builds.
+    </para>
+
+    <para>
+        The OpenEmbedded build system can use a substantial amount of disk
+        space during the build process.
+        A portion of this space is the work files under the
+        <filename>${TMPDIR}/work</filename> directory for each recipe.
+        Once the build system generates the packages for a recipe, the work
+        files for that recipe are no longer needed.
+        However, by default, the build system preserves these files
+        for inspection and possible debugging purposes.
+        If you would rather have these files deleted to save disk space
+        as the build progresses, you can enable <filename>rm_work</filename>
+        by adding the following to your <filename>local.conf</filename> file,
+        which is found in the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+        <literallayout class='monospaced'>
+    INHERIT += "rm_work"
+        </literallayout>
+        If you are modifying and building source code out of the work directory
+        for a recipe, enabling <filename>rm_work</filename> will potentially
+        result in your changes to the source being lost.
+        To exclude some recipes from having their work directories deleted by
+        <filename>rm_work</filename>, you can add the names of the recipe or
+        recipes you are working on to the <filename>RM_WORK_EXCLUDE</filename>
+        variable, which can also be set in your <filename>local.conf</filename>
+        file.
+        Here is an example:
+        <literallayout class='monospaced'>
+    RM_WORK_EXCLUDE += "busybox glibc"
+        </literallayout>
+    </para>
+</section>
+
+<section id='ref-classes-rootfs*'>
+    <title><filename>rootfs*.bbclass</filename></title>
+
+    <para>
+        The <filename>rootfs*</filename> classes support creating
+        the root filesystem for an image and consist of the following classes:
+        <itemizedlist>
+            <listitem><para>
+                The <filename>rootfs_deb</filename> class, which supports
+                creation of root filesystems for images built using
+                <filename>.deb</filename> packages.</para></listitem>
+            <listitem><para>
+                The <filename>rootfs_rpm</filename> class, which supports
+                creation of root filesystems for images built using
+                <filename>.rpm</filename> packages.</para></listitem>
+            <listitem><para>
+                The <filename>rootfs_ipk</filename> class, which supports
+                creation of root filesystems for images built using
+                <filename>.ipk</filename> packages.</para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        The root filesystem is created from packages using one of the
+        <filename>rootfs*.bbclass</filename> files as determined by the
+        <link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>
+        variable.
+    </para>
+
+    <para>
+        For information on how root filesystem images are created, see the
+        "<link linkend='image-generation-dev-environment'>Image Generation</link>"
+        section.
+    </para>
+</section>
+
+<section id='ref-classes-sanity'>
+    <title><filename>sanity.bbclass</filename></title>
+
+    <para>
+        The <filename>sanity</filename> class checks to see if prerequisite
+        software is present on the host system so that users can be notified
+        of potential problems that might affect their build.
+        The class also performs basic user configuration checks from
+        the <filename>local.conf</filename> configuration file to
+        prevent common mistakes that cause build failures.
+        Distribution policy usually determines whether to include this class.
+    </para>
+</section>
+
+<section id='ref-classes-scons'>
+    <title><filename>scons.bbclass</filename></title>
+
+    <para>
+        The <filename>scons</filename> class supports recipes that need to
+        build software that uses the SCons build system.
+        You can use the
+        <link linkend='var-EXTRA_OESCONS'><filename>EXTRA_OESCONS</filename></link>
+        variable to specify additional configuration options you want to pass
+        SCons command line.
+    </para>
+</section>
+
+<section id='ref-classes-sdl'>
+    <title><filename>sdl.bbclass</filename></title>
+
+    <para>
+        The <filename>sdl</filename> class supports recipes that need to build
+        software that uses the Simple DirectMedia Layer (SDL) library.
+    </para>
+</section>
+
+<section id='ref-classes-setuptools'>
+    <title><filename>setuptools.bbclass</filename></title>
+
+    <para>
+        The <filename>setuptools</filename> class supports Python
+        version 2.x extensions that use build systems based on
+        <filename>setuptools</filename>.
+        If your recipe uses these build systems, the recipe needs to
+        inherit the <filename>setuptools</filename> class.
+    </para>
+</section>
+
+<section id='ref-classes-setuptools3'>
+    <title><filename>setuptools3.bbclass</filename></title>
+
+    <para>
+        The <filename>setuptools3</filename> class supports Python
+        version 3.x extensions that use build systems based on
+        <filename>setuptools3</filename>.
+        If your recipe uses these build systems, the recipe needs to
+        inherit the <filename>setuptools3</filename> class.
+    </para>
+</section>
+
+<section id='ref-classes-sip'>
+    <title><filename>sip.bbclass</filename></title>
+
+    <para>
+        The <filename>sip</filename> class
+        supports recipes that build or package SIP-based Python bindings.
+    </para>
+</section>
+
+<section id='ref-classes-siteconfig'>
+    <title><filename>siteconfig.bbclass</filename></title>
+
+    <para>
+        The <filename>siteconfig</filename> class
+        provides functionality for handling site configuration.
+        The class is used by the
+        <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
+        class to accelerate the
+        <link linkend='ref-tasks-configure'><filename>do_configure</filename></link>
+        task.
+    </para>
+</section>
+
+<section id='ref-classes-siteinfo'>
+    <title><filename>siteinfo.bbclass</filename></title>
+
+    <para>
+        The <filename>siteinfo</filename> class provides information about
+        the targets that might be needed by other classes or recipes.
+    </para>
+
+    <para>
+        As an example, consider Autotools, which can require tests that must
+        execute on the target hardware.
+        Since this is not possible in general when cross compiling, site
+        information is used to provide cached test results so these tests can
+        be skipped over but still make the correct values available.
+        The
+        <filename><link linkend='structure-meta-site'>meta/site directory</link></filename>
+        contains test results sorted into different categories such as
+        architecture, endianness, and the <filename>libc</filename> used.
+        Site information provides a list of files containing data relevant to
+        the current build in the
+        <filename><link linkend='var-CONFIG_SITE'>CONFIG_SITE</link></filename> variable
+        that Autotools automatically picks up.
+    </para>
+
+    <para>
+        The class also provides variables like
+        <filename><link linkend='var-SITEINFO_ENDIANNESS'>SITEINFO_ENDIANNESS</link></filename>
+        and <filename><link linkend='var-SITEINFO_BITS'>SITEINFO_BITS</link></filename>
+        that can be used elsewhere in the metadata.
+    </para>
+
+    <para>
+        Because the
+        <link linkend='ref-classes-base'><filename>base</filename></link> class
+        includes the <filename>siteinfo</filename> class, it is always active.
+    </para>
+</section>
+
+<section id='ref-classes-spdx'>
+    <title><filename>spdx.bbclass</filename></title>
+
+    <para>
+        The <filename>spdx</filename> class integrates real-time license
+        scanning, generation of SPDX standard output, and verification
+        of license information during the build.
+        <note>
+            This class is currently at the prototype stage in the 1.6
+            release.
+        </note>
+    </para>
+</section>
+
+<section id='ref-classes-sstate'>
+    <title><filename>sstate.bbclass</filename></title>
+
+    <para>
+        The <filename>sstate</filename> class provides support for Shared
+        State (sstate).
+        By default, the class is enabled through the
+        <link linkend='var-INHERIT_DISTRO'><filename>INHERIT_DISTRO</filename></link>
+        variable's default value.
+    </para>
+
+    <para>
+        For more information on sstate, see the
+        "<link linkend='shared-state-cache'>Shared State Cache</link>"
+        section.
+    </para>
+</section>
+
+<section id='ref-classes-staging'>
+    <title><filename>staging.bbclass</filename></title>
+
+    <para>
+        The <filename>staging</filename> class provides support for staging
+        files into the sysroot during the
+        <link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link>
+        task.
+        The class is enabled by default because it is inherited by the
+        <link linkend='ref-classes-base'><filename>base</filename></link>
+        class.
+    </para>
+</section>
+
+<section id='ref-classes-syslinux'>
+    <title><filename>syslinux.bbclass</filename></title>
+
+    <para>
+        The <filename>syslinux</filename> class provides syslinux-specific
+        functions for building bootable images.
+    </para>
+
+    <para>
+        The class supports the following variables:
+        <itemizedlist>
+            <listitem><para><link linkend='var-INITRD'><filename>INITRD</filename></link>:
+                Indicates list of filesystem images to concatenate and use as
+                an initial RAM disk (initrd).
+                This variable is optional.</para></listitem>
+            <listitem><para><link linkend='var-ROOTFS'><filename>ROOTFS</filename></link>:
+                Indicates a filesystem image to include as the root filesystem.
+                This variable is optional.</para></listitem>
+            <listitem><para><link linkend='var-AUTO_SYSLINUXMENU'><filename>AUTO_SYSLINUXMENU</filename></link>:
+                Enables creating an automatic menu when set to "1".
+                </para></listitem>
+            <listitem><para><link linkend='var-LABELS'><filename>LABELS</filename></link>:
+                Lists targets for automatic configuration.
+                </para></listitem>
+            <listitem><para><link linkend='var-APPEND'><filename>APPEND</filename></link>:
+                Lists append string overrides for each label.
+                </para></listitem>
+            <listitem><para><link linkend='var-SYSLINUX_OPTS'><filename>SYSLINUX_OPTS</filename></link>:
+                Lists additional options to add to the syslinux file.
+                Semicolon characters separate multiple options.
+                </para></listitem>
+            <listitem><para><link linkend='var-SYSLINUX_SPLASH'><filename>SYSLINUX_SPLASH</filename></link>:
+                Lists a background for the VGA boot menu when you are using the
+                boot menu.</para></listitem>
+            <listitem><para><link linkend='var-SYSLINUX_DEFAULT_CONSOLE'><filename>SYSLINUX_DEFAULT_CONSOLE</filename></link>:
+                Set to "console=ttyX" to change kernel boot default console.
+                </para></listitem>
+            <listitem><para><link linkend='var-SYSLINUX_SERIAL'><filename>SYSLINUX_SERIAL</filename></link>:
+                Sets an alternate serial port.
+                Or, turns off serial when the variable is set with an
+                empty string.</para></listitem>
+            <listitem><para><link linkend='var-SYSLINUX_SERIAL_TTY'><filename>SYSLINUX_SERIAL_TTY</filename></link>:
+                Sets an alternate "console=tty..." kernel boot argument.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='ref-classes-systemd'>
+    <title><filename>systemd.bbclass</filename></title>
+
+    <para>
+        The <filename>systemd</filename> class provides support for recipes
+        that install systemd unit files.
+    </para>
+
+    <para>
+        The functionality for this class is disabled unless you have "systemd"
+        in
+        <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
+    </para>
+
+    <para>
+        Under this class, the recipe or Makefile (i.e. whatever the recipe is
+        calling during the
+        <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+        task) installs unit files into
+        <filename>${</filename><link linkend='var-D'><filename>D</filename></link><filename>}${systemd_unitdir}/system</filename>.
+        If the unit files being installed go into packages other than the
+        main package, you need to set
+        <link linkend='var-SYSTEMD_PACKAGES'><filename>SYSTEMD_PACKAGES</filename></link>
+        in your recipe to identify the packages in which the files will be
+        installed.
+    </para>
+
+    <para>
+        You should set
+        <link linkend='var-SYSTEMD_SERVICE'><filename>SYSTEMD_SERVICE</filename></link>
+        to the name of the service file.
+        You should also use a package name override to indicate the package
+        to which the value applies.
+        If the value applies to the recipe's main package, use
+        <filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename>.
+        Here is an example from the connman recipe:
+        <literallayout class='monospaced'>
+     SYSTEMD_SERVICE_${PN} = "connman.service"
+        </literallayout>
+        Services are set up to start on boot automatically unless
+        you have set
+        <link linkend='var-SYSTEMD_AUTO_ENABLE'><filename>SYSTEMD_AUTO_ENABLE</filename></link>
+        to "disable".
+    </para>
+
+    <para>
+        For more information on <filename>systemd</filename>, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#selecting-an-initialization-manager'>Selecting an Initialization Manager</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+</section>
+
+<section id='ref-classes-terminal'>
+    <title><filename>terminal.bbclass</filename></title>
+
+    <para>
+        The <filename>terminal</filename> class provides support for starting
+        a terminal session.
+        The
+        <link linkend='var-OE_TERMINAL'><filename>OE_TERMINAL</filename></link>
+        variable controls which terminal emulator is used for the session.
+    </para>
+
+    <para>
+        Other classes use the <filename>terminal</filename> class anywhere a
+        separate terminal session needs to be started.
+        For example, the
+        <link linkend='ref-classes-patch'><filename>patch</filename></link>
+        class assuming
+        <link linkend='var-PATCHRESOLVE'><filename>PATCHRESOLVE</filename></link>
+        is set to "user", the
+        <link linkend='ref-classes-cml1'><filename>cml1</filename></link>
+        class, and the
+        <link linkend='ref-classes-devshell'><filename>devshell</filename></link>
+        class all use the <filename>terminal</filename> class.
+    </para>
+</section>
+
+<section id='ref-classes-testimage'>
+    <title><filename>testimage.bbclass</filename></title>
+
+    <para>
+        The <filename>testimage</filename> class supports running automated
+        tests against images using QEMU and on actual hardware.
+        The class handles loading the tests and starting the image.
+    </para>
+
+    <para>
+        To use the class, you need to perform steps to set up the
+        environment.
+        The tests are commands that run on the target system over
+        <filename>ssh</filename>.
+        they are written in Python and make use of the
+        <filename>unittest</filename> module.
+    </para>
+
+    <para>
+        For information on how to enable, run, and create new tests, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
+        section.
+    </para>
+</section>
+
+<section id='ref-classes-texinfo'>
+    <title><filename>texinfo.bbclass</filename></title>
+
+    <para>
+        This class should be inherited by recipes whose upstream packages
+        invoke the <filename>texinfo</filename> utilities at build-time.
+        Native and cross recipes are made to use the dummy scripts provided
+        by <filename>texinfo-dummy-native</filename>, for improved performance.
+        Target architecture recipes use the genuine
+        Texinfo utilities.
+        By default, they use the Texinfo utilities on the host system.
+        <note>
+            If you want to use the Texinfo recipe shipped with the build
+            system, you can remove "texinfo-native" from
+            <link linkend='var-ASSUME_PROVIDED'><filename>ASSUME_PROVIDED</filename></link>
+            and makeinfo from
+            <link linkend='var-SANITY_REQUIRED_UTILITIES'><filename>SANITY_REQUIRED_UTILITIES</filename></link>.
+        </note>
+    </para>
+</section>
+
+<section id='ref-classes-tinderclient'>
+    <title><filename>tinderclient.bbclass</filename></title>
+
+    <para>
+        The <filename>tinderclient</filename> class submits build results to
+        an external Tinderbox instance.
+        <note>
+            This class is currently unmaintained.
+        </note>
+    </para>
+</section>
+
+<section id='ref-classes-toaster'>
+    <title><filename>toaster.bbclass</filename></title>
+
+    <para>
+        The <filename>toaster</filename> class collects information about
+        packages and images and sends them as events that the BitBake
+        user interface can receive.
+        The class is enabled when the Toaster user interface is running.
+    </para>
+
+    <para>
+        This class is not intended to be used directly.
+    </para>
+</section>
+
+<section id='ref-classes-toolchain-scripts'>
+    <title><filename>toolchain-scripts.bbclass</filename></title>
+
+    <para>
+        The <filename>toolchain-scripts</filename> class provides the scripts
+        used for setting up the environment for installed SDKs.
+    </para>
+</section>
+
+<section id='ref-classes-typecheck'>
+    <title><filename>typecheck.bbclass</filename></title>
+
+    <para>
+        The <filename>typecheck</filename> class provides support for
+        validating the values of variables set at the configuration level
+        against their defined types.
+        The OpenEmbedded build system allows you to define the type of a
+        variable using the "type" varflag.
+        Here is an example:
+        <literallayout class='monospaced'>
+     IMAGE_FEATURES[type] = "list"
+        </literallayout>
+    </para>
+</section>
+
+<section id='ref-classes-uboot-config'>
+    <title><filename>uboot-config.bbclass</filename></title>
+
+    <para>
+        The <filename>uboot-config</filename> class provides support for
+        U-Boot configuration for a machine.
+        Specify the machine in your recipe as follows:
+        <literallayout class='monospaced'>
+     UBOOT_CONFIG ??= &lt;default&gt;
+     UBOOT_CONFIG[foo] = "config,images"
+        </literallayout>
+        You can also specify the machine using this method:
+        <literallayout class='monospaced'>
+     UBOOT_MACHINE = "config"
+        </literallayout>
+        See the
+        <link linkend='var-UBOOT_CONFIG'><filename>UBOOT_CONFIG</filename></link>
+        and
+        <link linkend='var-UBOOT_MACHINE'><filename>UBOOT_MACHINE</filename></link>
+        variables for additional information.
+    </para>
+</section>
+
+<section id='ref-classes-uninative'>
+    <title><filename>uninative.bbclass</filename></title>
+
+    <para>
+        Provides a means of reusing <filename>native/cross</filename> over
+        multiple distros.
+        <note>
+            Currently, the method used by the <filename>uninative</filename>
+            class is experimental.
+        </note>
+        For more information, see the commit message
+        <ulink url='http://cgit.openembedded.org/openembedded-core/commit/?id=e66c96ae9c7ba21ebd04a4807390f0031238a85a'>here</ulink>.
+    </para>
+</section>
+
+<section id='ref-classes-update-alternatives'>
+    <title><filename>update-alternatives.bbclass</filename></title>
+
+    <para>
+        The <filename>update-alternatives</filename> class helps the
+        alternatives system when multiple sources provide the same command.
+        This situation occurs when several programs that have the same or
+        similar function are installed with the same name.
+        For example, the <filename>ar</filename> command is available from the
+        <filename>busybox</filename>, <filename>binutils</filename> and
+        <filename>elfutils</filename> packages.
+        The <filename>update-alternatives</filename> class handles
+        renaming the binaries so that multiple packages can be installed
+        without conflicts.
+        The <filename>ar</filename> command still works regardless of which
+        packages are installed or subsequently removed.
+        The class renames the conflicting binary in each package and symlinks
+        the highest priority binary during installation or removal of packages.
+    </para>
+
+    <para>
+        To use this class, you need to define a number of variables:
+        <itemizedlist>
+            <listitem><para><link linkend='var-ALTERNATIVE'><filename>ALTERNATIVE</filename></link>
+                </para></listitem>
+            <listitem><para><link linkend='var-ALTERNATIVE_LINK_NAME'><filename>ALTERNATIVE_LINK_NAME</filename></link>
+                </para></listitem>
+            <listitem><para><link linkend='var-ALTERNATIVE_TARGET'><filename>ALTERNATIVE_TARGET</filename></link>
+                </para></listitem>
+            <listitem><para><link linkend='var-ALTERNATIVE_PRIORITY'><filename>ALTERNATIVE_PRIORITY</filename></link>
+                </para></listitem>
+        </itemizedlist>
+        These variables list alternative commands needed by a package,
+        provide pathnames for links, default links for targets, and
+        so forth.
+        For details on how to use this class, see the comments in the
+        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/update-alternatives.bbclass'><filename>update-alternatives.bbclass</filename></ulink>.
+    </para>
+
+    <note>
+        You can use the <filename>update-alternatives</filename> command
+        directly in your recipes.
+        However, this class simplifies things in most cases.
+    </note>
+</section>
+
+<section id='ref-classes-update-rc.d'>
+    <title><filename>update-rc.d.bbclass</filename></title>
+
+    <para>
+        The <filename>update-rc.d</filename> class uses
+        <filename>update-rc.d</filename> to safely install an
+        initialization script on behalf of the package.
+        The OpenEmbedded build system takes care of details such as making
+        sure the script is stopped before a package is removed and started when
+        the package is installed.
+    </para>
+
+    <para>
+        Three variables control this class:
+        <filename><link linkend='var-INITSCRIPT_PACKAGES'>INITSCRIPT_PACKAGES</link></filename>,
+        <filename><link linkend='var-INITSCRIPT_NAME'>INITSCRIPT_NAME</link></filename> and
+        <filename><link linkend='var-INITSCRIPT_PARAMS'>INITSCRIPT_PARAMS</link></filename>.
+        See the variable links for details.
+    </para>
+</section>
+
+<section id='ref-classes-useradd'>
+    <title><filename>useradd.bbclass</filename></title>
+
+    <para>
+        The <filename>useradd</filename> class supports the addition of users
+        or groups for usage by the package on the target.
+        For example, if you have packages that contain system services that
+        should be run under their own user or group, you can use this class to
+        enable creation of the user or group.
+        The <filename>meta-skeleton/recipes-skeleton/useradd/useradd-example.bb</filename>
+        recipe in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+        provides a simple example that shows how to add three
+        users and groups to two packages.
+        See the <filename>useradd-example.bb</filename> recipe for more
+        information on how to use this class.
+    </para>
+
+    <para>
+        The <filename>useradd</filename> class supports the
+        <link linkend='var-USERADD_PACKAGES'><filename>USERADD_PACKAGES</filename></link>,
+        <link linkend='var-USERADD_PARAM'><filename>USERADD_PARAM</filename></link>,
+        <link linkend='var-GROUPADD_PARAM'><filename>GROUPADD_PARAM</filename></link>,
+        and
+        <link linkend='var-GROUPMEMS_PARAM'><filename>GROUPMEMS_PARAM</filename></link>
+        variables.
+    </para>
+</section>
+
+<section id='ref-classes-useradd-staticids'>
+    <title><filename>useradd-staticids.bbclass</filename></title>
+
+    <para>
+        The <filename>useradd-staticids</filename> class supports the addition
+        of users or groups that have static user identification
+        (<filename>uid</filename>) and group identification
+        (<filename>gid</filename>) values.
+    </para>
+
+    <para>
+        The default behavior of the OpenEmbedded build system for assigning
+        <filename>uid</filename> and <filename>gid</filename> values when
+        packages add users and groups during package install time is to
+        add them dynamically.
+        This works fine for programs that do not care what the values of the
+        resulting users and groups become.
+        In these cases, the order of the installation determines the final
+        <filename>uid</filename> and <filename>gid</filename> values.
+        However, if non-deterministic
+        <filename>uid</filename> and <filename>gid</filename> values are a
+        problem, you can override the default, dynamic application of these
+        values by setting static values.
+        When you set static values, the OpenEmbedded build system looks in
+        <link linkend='var-BBPATH'><filename>BBPATH</filename></link> for
+        <filename>files/passwd</filename> and <filename>files/group</filename>
+        files for the values.
+    </para>
+
+    <para>
+        To use static <filename>uid</filename> and <filename>gid</filename>
+        values, you need to set some variables.
+        See the
+        <link linkend='var-USERADDEXTENSION'><filename>USERADDEXTENSION</filename></link>,
+        <link linkend='var-USERADD_UID_TABLES'><filename>USERADD_UID_TABLES</filename></link>,
+        <link linkend='var-USERADD_GID_TABLES'><filename>USERADD_GID_TABLES</filename></link>,
+        and
+        <link linkend='var-USERADD_ERROR_DYNAMIC'><filename>USERADD_ERROR_DYNAMIC</filename></link>
+        variables.
+        You can also see the
+        <link linkend='ref-classes-useradd'><filename>useradd</filename></link>
+        class for additional information.
+    </para>
+
+    <note><title>Notes</title>
+        You do not use this class directly.
+        You either enable or disable the class by setting the
+        <filename>USERADDEXTENSION</filename> variable.
+        If you enable or disable the class in a configured system,
+        <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
+        might contain incorrect <filename>uid</filename> and
+        <filename>gid</filename> values.
+        Deleting the <filename>TMPDIR</filename> directory
+        will correct this condition.
+    </note>
+</section>
+
+<section id='ref-classes-utility-tasks'>
+    <title><filename>utility-tasks.bbclass</filename></title>
+
+    <para>
+        The <filename>utility-tasks</filename> class provides support for
+        various "utility" type tasks that are applicable to all recipes,
+        such as
+        <link linkend='ref-tasks-clean'><filename>do_clean</filename></link> and
+        <link linkend='ref-tasks-listtasks'><filename>do_listtasks</filename></link>.
+    </para>
+
+    <para>
+        This class is enabled by default because it is inherited by
+        the
+        <link linkend='ref-classes-base'><filename>base</filename></link>
+        class.
+    </para>
+</section>
+
+<section id='ref-classes-utils'>
+    <title><filename>utils.bbclass</filename></title>
+
+    <para>
+        The <filename>utils</filename> class provides some useful Python
+        functions that are typically used in inline Python expressions
+        (e.g. <filename>${@...}</filename>).
+        One example use is for <filename>bb.utils.contains()</filename>.
+    </para>
+
+    <para>
+        This class is enabled by default because it is inherited by the
+        <link linkend='ref-classes-base'><filename>base</filename></link>
+        class.
+    </para>
+</section>
+
+<section id='ref-classes-vala'>
+    <title><filename>vala.bbclass</filename></title>
+
+    <para>
+        The <filename>vala</filename> class supports recipes that need to
+        build software written using the Vala programming language.
+    </para>
+</section>
+
+<section id='ref-classes-waf'>
+    <title><filename>waf.bbclass</filename></title>
+
+    <para>
+        The <filename>waf</filename> class supports recipes that need to build
+        software that uses the Waf build system.
+        You can use the
+        <link linkend='var-EXTRA_OECONF'><filename>EXTRA_OECONF</filename></link>
+        variable to specify additional configuration options to be passed on
+        the Waf command line.
+    </para>
+</section>
+
+<!-- Undocumented classes are:
+        image-empty.bbclass (possibly being dropped)
+        migrate_localcount.bbclass (still need a description)
+-->
+
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/ref-features.xml b/documentation/ref-manual/ref-features.xml
new file mode 100644
index 0000000000..230cabd155
--- /dev/null
+++ b/documentation/ref-manual/ref-features.xml
@@ -0,0 +1,420 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='ref-features'>
+    <title>Features</title>
+
+    <para>
+        This chapter provides a reference of shipped machine and distro features
+        you can include as part of your image, a reference on image features you can
+        select, and a reference on feature backfilling.
+    </para>
+
+    <para>
+        Features provide a mechanism for working out which packages
+        should be included in the generated images.
+        Distributions can select which features they want to support through the
+        <filename><link linkend='var-DISTRO_FEATURES'>DISTRO_FEATURES</link></filename>
+        variable, which is set or appended to in a distribution's configuration file such as
+        <filename>poky.conf</filename>,
+        <filename>poky-tiny.conf</filename>,
+        <filename>poky-lsb.conf</filename> and so forth.
+        Machine features are set in the
+        <filename><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link></filename>
+        variable, which is set in the machine configuration file and
+        specifies the hardware features for a given machine.
+    </para>
+
+    <para>
+        These two variables combine to work out which kernel modules,
+        utilities, and other packages to include.
+        A given distribution can support a selected subset of features so some machine features might not
+        be included if the distribution itself does not support them.
+    </para>
+
+    <para>
+        One method you can use to determine which recipes are checking to see if a
+        particular feature is contained or not is to <filename>grep</filename> through
+        the <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+        for the feature.
+        Here is an example that discovers the recipes whose build is potentially
+        changed based on a given feature:
+        <literallayout class='monospaced'>
+     $ cd poky
+     $ git grep 'contains.*MACHINE_FEATURES.*<replaceable>feature</replaceable>'
+        </literallayout>
+    </para>
+
+    <section id='ref-features-machine'>
+        <title>Machine Features</title>
+
+        <para>
+            The items below are features you can use with
+            <link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>.
+            Features do not have a one-to-one correspondence to packages, and they can
+            go beyond simply controlling the installation of a package or packages.
+            Sometimes a feature can influence how certain recipes are built.
+            For example, a feature might determine whether a particular configure option
+            is specified within the
+            <link linkend='ref-tasks-configure'><filename>do_configure</filename></link>
+            task for a particular recipe.
+        </para>
+
+        <para>
+            This feature list only represents features as shipped with the Yocto Project metadata:
+            <itemizedlist>
+                <listitem><para><emphasis>acpi:</emphasis> Hardware has ACPI (x86/x86_64 only)
+                    </para></listitem>
+                <listitem><para><emphasis>alsa:</emphasis> Hardware has ALSA audio drivers
+                    </para></listitem>
+                <listitem><para><emphasis>apm:</emphasis> Hardware uses APM (or APM emulation)
+                    </para></listitem>
+                <listitem><para><emphasis>bluetooth:</emphasis> Hardware has integrated BT
+                    </para></listitem>
+                <listitem><para><emphasis>efi:</emphasis> Support for booting through EFI
+                    </para></listitem>
+                <listitem><para><emphasis>ext2:</emphasis> Hardware HDD or Microdrive
+                    </para></listitem>
+                <listitem><para><emphasis>irda:</emphasis> Hardware has IrDA support
+                    </para></listitem>
+                <listitem><para><emphasis>keyboard:</emphasis> Hardware has a keyboard
+                    </para></listitem>
+                <listitem><para><emphasis>pcbios:</emphasis> Support for booting through BIOS
+                    </para></listitem>
+                <listitem><para><emphasis>pci:</emphasis> Hardware has a PCI bus
+                    </para></listitem>
+                <listitem><para><emphasis>pcmcia:</emphasis> Hardware has PCMCIA or CompactFlash sockets
+                    </para></listitem>
+                <listitem><para><emphasis>phone:</emphasis> Mobile phone (voice) support
+                    </para></listitem>
+                <listitem><para><emphasis>qvga:</emphasis> Machine has a QVGA (320x240) display
+                    </para></listitem>
+                <listitem><para><emphasis>rtc:</emphasis> Machine has a Real-Time Clock
+                    </para></listitem>
+                <listitem><para><emphasis>screen:</emphasis> Hardware has a screen
+                    </para></listitem>
+                <listitem><para><emphasis>serial:</emphasis> Hardware has serial support (usually RS232)
+                    </para></listitem>
+                <listitem><para><emphasis>touchscreen:</emphasis> Hardware has a touchscreen
+                    </para></listitem>
+                <listitem><para><emphasis>usbgadget:</emphasis> Hardware is USB gadget device capable
+                    </para></listitem>
+                <listitem><para><emphasis>usbhost:</emphasis> Hardware is USB Host capable
+                    </para></listitem>
+                <listitem><para><emphasis>vfat:</emphasis> FAT file system support
+                    </para></listitem>
+                <listitem><para><emphasis>wifi:</emphasis> Hardware has integrated WiFi
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='ref-features-distro'>
+        <title>Distro Features</title>
+
+        <para>
+            The items below are features you can use with
+            <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
+            to enable features across your distribution.
+            Features do not have a one-to-one correspondence to packages,
+            and they can go beyond simply controlling the installation of a
+            package or packages.
+            In most cases, the presence or absence of a feature translates to
+            the appropriate option supplied to the configure script during the
+            <link linkend='ref-tasks-configure'><filename>do_configure</filename></link>
+            task for the recipes that optionally
+            support the feature.
+        </para>
+
+        <para>
+            Some distro features are also machine features.
+            These select features make sense to be controlled both at
+            the machine and distribution configuration level.
+            See the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-COMBINED_FEATURES'><filename>COMBINED_FEATURES</filename></ulink>
+            variable for more information.
+        </para>
+
+        <para>
+            This list only represents features as shipped with the Yocto Project metadata:
+            <itemizedlist>
+                <listitem><para><emphasis>alsa:</emphasis> Include ALSA support
+                    (OSS compatibility kernel modules installed if available).
+                    </para></listitem>
+                <listitem><para><emphasis>bluetooth:</emphasis> Include
+                    bluetooth support (integrated BT only).</para></listitem>
+                <listitem><para><emphasis>cramfs:</emphasis> Include CramFS
+                    support.</para></listitem>
+                <listitem><para><emphasis>directfb:</emphasis>
+                    Include DirectFB support.
+                    </para></listitem>
+                <listitem><para><emphasis>ext2:</emphasis> Include tools for
+                    supporting for devices with internal HDD/Microdrive for
+                    storing files (instead of Flash only devices).
+                    </para></listitem>
+                <listitem><para><emphasis>ipsec:</emphasis> Include IPSec
+                    support.</para></listitem>
+                <listitem><para><emphasis>ipv6:</emphasis> Include IPv6 support.
+                    </para></listitem>
+                <listitem><para><emphasis>irda:</emphasis> Include IrDA support.
+                    </para></listitem>
+                <listitem><para><emphasis>keyboard:</emphasis> Include keyboard
+                    support (e.g. keymaps will be loaded during boot).
+                    </para></listitem>
+                <listitem><para><emphasis>nfs:</emphasis> Include NFS client
+                    support (for mounting NFS exports on device).
+                    </para></listitem>
+                <listitem><para><emphasis>opengl:</emphasis>
+                    Include the Open Graphics Library, which is a
+                    cross-language, multi-platform application programming
+                    interface used for rendering two and three-dimensional
+                    graphics.</para></listitem>
+                <listitem><para><emphasis>pci:</emphasis> Include PCI bus
+                    support.</para></listitem>
+                <listitem><para><emphasis>pcmcia:</emphasis> Include
+                    PCMCIA/CompactFlash support.</para></listitem>
+                <listitem><para><emphasis>ppp:</emphasis> Include PPP dialup
+                    support.</para></listitem>
+                <listitem><para><emphasis>smbfs:</emphasis> Include SMB networks
+                    client support (for mounting Samba/Microsoft Windows shares
+                    on device).</para></listitem>
+                <listitem><para><emphasis>systemd:</emphasis> Include support
+                    for this <filename>init</filename> manager, which is a full
+                    replacement of for <filename>init</filename> with parallel
+                    starting of services, reduced shell overhead, and other
+                    features.
+                    This <filename>init</filename> manager is used by many
+                    distributions.</para></listitem>
+                <listitem><para><emphasis>usbgadget:</emphasis> Include USB
+                    Gadget Device support (for USB networking/serial/storage).
+                    </para></listitem>
+                <listitem><para><emphasis>usbhost:</emphasis> Include USB Host
+                    support (allows to connect external keyboard, mouse,
+                    storage, network etc).</para></listitem>
+                <listitem><para><emphasis>wayland:</emphasis> Include the
+                    Wayland display server protocol and the library that
+                    supports it.</para></listitem>
+                <listitem><para><emphasis>wifi:</emphasis> Include WiFi support
+                    (integrated only).</para></listitem>
+                <listitem><para><emphasis>x11:</emphasis> Include the X server
+                    and libraries.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='ref-features-image'>
+        <title>Image Features</title>
+
+        <para>
+            The contents of images generated by the OpenEmbedded build system
+            can be controlled by the
+            <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
+            and
+            <link linkend='var-EXTRA_IMAGE_FEATURES'><filename>EXTRA_IMAGE_FEATURES</filename></link>
+            variables that you typically configure in your image recipes.
+            Through these variables, you can add several different
+            predefined packages such as development utilities or packages with
+            debug information needed to investigate application problems or
+            profile applications.
+        </para>
+
+        <para>
+            The following image features are available for all images:
+            <itemizedlist>
+                <listitem><para><emphasis>dbg-pkgs:</emphasis>
+                    Installs debug symbol packages for all packages installed
+                    in a given image.
+                    </para></listitem>
+                <listitem><para><emphasis>debug-tweaks:</emphasis>
+                    Makes an image suitable for development (e.g.
+                    allows root logins without passwords).
+                    </para></listitem>
+                <listitem><para><emphasis>dev-pkgs:</emphasis>
+                    Installs development packages (headers and extra library
+                    links) for all packages installed in a given image.
+                    </para></listitem>
+                <listitem><para><emphasis>doc-pkgs:</emphasis> Installs
+                    documentation packages for all packages installed in a
+                    given image.
+                    </para></listitem>
+                <listitem><para><emphasis>package-management:</emphasis>
+                    Installs package management tools and preserves the package
+                    manager database.
+                    </para></listitem>
+                <listitem><para><emphasis>ptest-pkgs:</emphasis>
+                    Installs ptest packages for all ptest-enabled recipes.
+                    </para></listitem>
+                <listitem><para><emphasis>read-only-rootfs:</emphasis>
+                    Creates an image whose root filesystem is read-only.
+                    See the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem'>Creating a Read-Only Root Filesystem</ulink>"
+                    section in the Yocto Project Development Manual for more
+                    information.
+                    </para></listitem>
+                <listitem><para><emphasis>splash:</emphasis>
+                    Enables showing a splash screen during boot.
+                    By default, this screen is provided by
+                    <filename>psplash</filename>, which does allow
+                    customization.
+                    If you prefer to use an alternative splash screen package,
+                    you can do so by setting the <filename>SPLASH</filename>
+                    variable to a different package name (or names) within the
+                    image recipe or at the distro configuration level.
+                    </para></listitem>
+                <listitem><para><emphasis>staticdev-pkgs:</emphasis>
+                    Installs static development packages, which are
+                    static libraries (i.e. <filename>*.a</filename> files), for
+                    all packages installed in a given image.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            Some image features are available only when you inherit the
+            <link linkend='ref-classes-core-image'><filename>core-image</filename></link>
+            class.
+            The current list of these valid features is as follows:
+            <itemizedlist>
+                <listitem><para><emphasis>eclipse-debug:</emphasis> Provides
+                    Eclipse remote debugging support.
+                    </para></listitem>
+                <listitem><para><emphasis>hwcodecs:</emphasis> Installs
+                    hardware acceleration codecs.
+                    </para></listitem>
+                <listitem><para><emphasis>nfs-server:</emphasis>
+                    Installs an NFS server.
+                    </para></listitem>
+                <listitem><para><emphasis>qt4-pkgs:</emphasis>
+                    Supports Qt4/X11 and demo applications.
+                    </para></listitem>
+                <listitem><para><emphasis>ssh-server-dropbear:</emphasis>
+                    Installs the Dropbear minimal SSH server.
+                    </para></listitem>
+                <listitem><para><emphasis>ssh-server-openssh:</emphasis>
+                    Installs the OpenSSH SSH server, which is more
+                    full-featured than Dropbear.
+                    Note that if both the OpenSSH SSH server and the Dropbear
+                    minimal SSH server are present in
+                    <filename>IMAGE_FEATURES</filename>, then OpenSSH will take
+                    precedence and Dropbear will not be installed.
+                    </para></listitem>
+                <listitem><para><emphasis>tools-debug:</emphasis>
+                    Installs debugging tools such as
+                    <filename>strace</filename> and <filename>gdb</filename>.
+                    For information on GDB, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug'>Debugging With the GNU Project Debugger (GDB) Remotely</ulink>"
+                    section in the Yocto Project Development Manual.
+                    For information on tracing and profiling, see the
+                    <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Profiling and Tracing Manual</ulink>.
+                    </para></listitem>
+                <listitem><para><emphasis>tools-profile:</emphasis>
+                    Installs profiling tools such as
+                    <filename>oprofile</filename>, <filename>exmap</filename>,
+                    and <filename>LTTng</filename>.
+                    For general information on user-space tools, see the
+                    "<ulink url='&YOCTO_DOCS_ADT_URL;#user-space-tools'>User-Space Tools</ulink>"
+                    section in the Yocto Project Application Developer's
+                    Guide.
+                    </para></listitem>
+                <listitem><para><emphasis>tools-sdk:</emphasis>
+                    Installs a full SDK that runs on the device.
+                    </para></listitem>
+                <listitem><para><emphasis>tools-testapps:</emphasis>
+                    Installs device testing tools (e.g. touchscreen debugging).
+                    </para></listitem>
+                <listitem><para><emphasis>x11:</emphasis>
+                    Installs the X server.
+                    </para></listitem>
+                <listitem><para><emphasis>x11-base:</emphasis>
+                    Installs the X server with a minimal environment.
+                    </para></listitem>
+                <listitem><para><emphasis>x11-sato:</emphasis>
+                    Installs the OpenedHand Sato environment.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+
+    </section>
+
+    <section id='ref-features-backfill'>
+        <title>Feature Backfilling</title>
+
+        <para>
+            Sometimes it is necessary in the OpenEmbedded build system to extend
+            <link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>
+            or <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
+            to control functionality that was previously enabled and not able
+            to be disabled.
+            For these cases, we need to add an
+            additional feature item to appear in one of these variables,
+            but we do not want to force developers who have existing values
+            of the variables in their configuration to add the new feature
+            in order to retain the same overall level of functionality.
+            Thus, the OpenEmbedded build system has a mechanism to
+            automatically "backfill" these added features into existing
+            distro or machine configurations.
+            You can see the list of features for which this is done by
+            finding the
+            <link linkend='var-DISTRO_FEATURES_BACKFILL'><filename>DISTRO_FEATURES_BACKFILL</filename></link>
+            and <link linkend='var-MACHINE_FEATURES_BACKFILL'><filename>MACHINE_FEATURES_BACKFILL</filename></link>
+            variables in the <filename>meta/conf/bitbake.conf</filename> file.
+        </para>
+
+        <para>
+            Because such features are backfilled by default into all
+            configurations as described in the previous paragraph, developers
+            who wish to disable the new features need to be able to selectively
+            prevent the backfilling from occurring.
+            They can do this by adding the undesired feature or features to the
+            <link linkend='var-DISTRO_FEATURES_BACKFILL_CONSIDERED'><filename>DISTRO_FEATURES_BACKFILL_CONSIDERED</filename></link>
+            or <link linkend='var-MACHINE_FEATURES_BACKFILL_CONSIDERED'><filename>MACHINE_FEATURES_BACKFILL_CONSIDERED</filename></link>
+            variables for distro features and machine features respectively.
+        </para>
+
+        <para>
+            Here are two examples to help illustrate feature backfilling:
+            <itemizedlist>
+                <listitem><para><emphasis>The "pulseaudio" distro feature option</emphasis>:
+                    Previously, PulseAudio support was enabled within the Qt and
+                    GStreamer frameworks.
+                    Because of this, the feature is backfilled and thus
+                    enabled for all distros through the
+                    <filename>DISTRO_FEATURES_BACKFILL</filename>
+                    variable in the <filename>meta/conf/bitbake.conf</filename> file.
+                    However, your distro needs to disable the feature.
+                    You can disable the feature without affecting
+                    other existing distro configurations that need PulseAudio support
+                    by adding "pulseaudio" to
+                    <filename>DISTRO_FEATURES_BACKFILL_CONSIDERED</filename>
+                    in your distro's <filename>.conf</filename> file.
+                    Adding the feature to this variable when it also
+                    exists in the <filename>DISTRO_FEATURES_BACKFILL</filename>
+                    variable prevents the build system from adding the feature to
+                    your configuration's <filename>DISTRO_FEATURES</filename>, effectively disabling
+                    the feature for that particular distro.</para></listitem>
+                <listitem><para><emphasis>The "rtc" machine feature option</emphasis>:
+                    Previously, real time clock (RTC) support was enabled for all
+                    target devices.
+                    Because of this, the feature is backfilled and thus enabled
+                    for all machines through the <filename>MACHINE_FEATURES_BACKFILL</filename>
+                    variable in the <filename>meta/conf/bitbake.conf</filename> file.
+                    However, your target device does not have this capability.
+                    You can disable RTC support for your device without
+                    affecting other machines that need RTC support
+                    by adding the feature to your machine's
+                    <filename>MACHINE_FEATURES_BACKFILL_CONSIDERED</filename>
+                    list in the machine's <filename>.conf</filename> file.
+                    Adding the feature to this variable when it also
+                    exists in the <filename>MACHINE_FEATURES_BACKFILL</filename>
+                    variable prevents the build system from adding the feature to
+                    your configuration's <filename>MACHINE_FEATURES</filename>, effectively
+                    disabling RTC support for that particular machine.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</chapter>
+
+<!--
+vim: expandtab tw=80 ts=4 spell spelllang=en_gb
+-->
diff --git a/documentation/ref-manual/ref-images.xml b/documentation/ref-manual/ref-images.xml
new file mode 100644
index 0000000000..d15ca5b93a
--- /dev/null
+++ b/documentation/ref-manual/ref-images.xml
@@ -0,0 +1,169 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='ref-images'>
+    <title>Images</title>
+
+    <para>
+        The OpenEmbedded build system provides several example
+        images to satisfy different needs.
+        When you issue the <filename>bitbake</filename> command you provide a “top-level” recipe
+        that essentially begins the build for the type of image you want.
+    </para>
+
+    <note>
+        Building an image without GNU General Public License Version 3 (GPLv3),
+        GNU Lesser General Public License Version 3 (LGPLv3), and the
+        GNU Affero General Public License Version 3 (AGPL-3.0) components
+        is only supported for minimal and base images.
+        Furthermore, if you are going to build an image using non-GPLv3 and
+        similarly licensed components, you must make the following changes in
+        the <filename>local.conf</filename> file before using the BitBake
+        command to build the minimal or base image:
+        <literallayout class='monospaced'>
+     1. Comment out the EXTRA_IMAGE_FEATURES line
+     2. Set INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3.0"
+        </literallayout>
+    </note>
+
+    <para>
+        From within the <filename>poky</filename> Git repository, you can use
+        the following command to display the list of directories within the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+        that containe image recipe files:
+        <literallayout class='monospaced'>
+     $ ls meta*/recipes*/images/*.bb
+        </literallayout>
+    </para>
+
+    <para>
+        Following is a list of supported recipes:
+        <itemizedlist>
+            <listitem><para><filename>build-appliance-image</filename>:
+                An example virtual machine that contains all the pieces required to
+                run builds using the build system as well as the build system itself.
+                You can boot and run the image using either the
+                <ulink url='http://www.vmware.com/products/player/overview.html'>VMware Player</ulink>
+                or <ulink url='http://www.vmware.com/products/workstation/overview.html'>VMware Workstation</ulink>.
+                For more information on this image, see the
+                <ulink url='&YOCTO_HOME_URL;/documentation/build-appliance'>Build Appliance</ulink> page on
+                the Yocto Project website.</para></listitem>
+            <listitem><para><filename>core-image-base</filename>:
+                A console-only image that fully supports the target device hardware.</para></listitem>
+            <listitem><para><filename>core-image-clutter</filename>:
+                An image with support for the Open GL-based toolkit Clutter, which enables development of
+                rich and animated graphical user interfaces.</para></listitem>
+            <listitem><para><filename>core-image-directfb</filename>:
+                An image that uses <filename>directfb</filename> instead of X11.
+                </para></listitem>
+            <listitem><para><filename>core-image-full-cmdline</filename>:
+                A console-only image with more full-featured Linux system
+                functionality installed.</para></listitem>
+                <listitem><para><filename>core-image-lsb</filename>:
+                An image that conforms to the Linux Standard Base (LSB)
+                specification.
+                This image requires a distribution configuration that
+                enables LSB compliance (e.g. <filename>poky-lsb</filename>).
+                If you build <filename>core-image-lsb</filename> without that
+                configuration, the image will not be LSB-compliant.
+                </para></listitem>
+            <listitem><para><filename>core-image-lsb-dev</filename>:
+                A <filename>core-image-lsb</filename> image that is suitable for development work
+                using the host.
+                The image includes headers and libraries you can use in a host development
+                environment.
+                This image requires a distribution configuration that
+                enables LSB compliance (e.g. <filename>poky-lsb</filename>).
+                If you build <filename>core-image-lsb-dev</filename> without that
+                configuration, the image will not be LSB-compliant.
+                </para></listitem>
+            <listitem><para><filename>core-image-lsb-sdk</filename>:
+                A <filename>core-image-lsb</filename> that includes everything in
+                meta-toolchain but also includes development headers and libraries
+                to form a complete standalone SDK.
+                This image requires a distribution configuration that
+                enables LSB compliance (e.g. <filename>poky-lsb</filename>).
+                If you build <filename>core-image-lsb-sdk</filename> without that
+                configuration, the image will not be LSB-compliant.
+                This image is suitable for development using the target.</para></listitem>
+            <listitem><para><filename>core-image-minimal</filename>:
+                A small image just capable of allowing a device to boot.</para></listitem>
+            <listitem><para><filename>core-image-minimal-dev</filename>:
+                A <filename>core-image-minimal</filename> image suitable for development work
+                using the host.
+                The image includes headers and libraries you can use in a host development
+                environment.
+                </para></listitem>
+            <listitem><para id='images-core-image-minimal-initramfs'><filename>core-image-minimal-initramfs</filename>:
+                A <filename>core-image-minimal</filename> image that has the Minimal RAM-based
+                Initial Root Filesystem (initramfs) as part of the kernel,
+                which allows the system to find the first “init” program more efficiently.
+                See the
+                <link linkend='var-PACKAGE_INSTALL'><filename>PACKAGE_INSTALL</filename></link>
+                variable for additional information helpful when working with
+                initramfs images.
+                </para></listitem>
+            <listitem><para><filename>core-image-minimal-mtdutils</filename>:
+                A <filename>core-image-minimal</filename> image that has support
+                for the Minimal MTD Utilities, which let the user interact with the
+                MTD subsystem in the kernel to perform operations on flash devices.
+                </para></listitem>
+            <listitem><para><filename>core-image-rt</filename>:
+                A <filename>core-image-minimal</filename> image plus a real-time test suite and
+                tools appropriate for real-time use.</para></listitem>
+            <listitem><para><filename>core-image-rt-sdk</filename>:
+                A <filename>core-image-rt</filename> image that includes everything in
+                <filename>meta-toolchain</filename>.
+                The image also includes development headers and libraries to form a complete
+                stand-alone SDK and is suitable for development using the target.
+                </para></listitem>
+            <listitem><para><filename>core-image-sato</filename>:
+                An image with Sato support, a mobile environment and visual style that works well
+                with mobile devices.
+                The image supports X11 with a Sato theme and applications such as
+                a terminal, editor, file manager, media player, and so forth.
+                </para></listitem>
+            <listitem><para><filename>core-image-sato-dev</filename>:
+                A <filename>core-image-sato</filename> image suitable for development
+                using the host.
+                The image includes libraries needed to build applications on the device itself,
+                testing and profiling tools, and debug symbols.
+                This image was formerly <filename>core-image-sdk</filename>.
+                </para></listitem>
+            <listitem><para><filename>core-image-sato-sdk</filename>:
+                A <filename>core-image-sato</filename> image that includes everything in meta-toolchain.
+                The image also includes development headers and libraries to form a complete standalone SDK
+                and is suitable for development using the target.</para></listitem>
+            <listitem><para><filename>core-image-testmaster</filename>:
+                A "master" image designed to be used for automated runtime testing.
+                Provides a "known good" image that is deployed to a separate
+                partition so that you can boot into it and use it to deploy a
+                second image to be tested.
+                You can find more information about runtime testing in the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
+                section in the Yocto Project Development Manual.
+                </para></listitem>
+            <listitem><para><filename>core-image-testmaster-initramfs</filename>:
+                A RAM-based Initial Root Filesystem (initramfs) image tailored for
+                use with the <filename>core-image-testmaster</filename> image.
+                </para></listitem>
+            <listitem><para><filename>core-image-weston</filename>:
+                A very basic Wayland image with a terminal.
+                This image provides the Wayland protocol libraries and the
+                reference Weston compositor.
+                For more information, see the
+                "<link linkend='wayland'>Wayland</link>" section.
+                </para></listitem>
+            <listitem><para><filename>core-image-x11</filename>:
+                A very basic X11 image with a terminal.
+                </para></listitem>
+            <listitem><para><filename>qt4e-demo-image</filename>:
+                An image that launches into the demo application for the embedded
+                (not based on X11) version of Qt.</para></listitem>
+        </itemizedlist>
+    </para>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/ref-manual-customization.xsl b/documentation/ref-manual/ref-manual-customization.xsl
new file mode 100644
index 0000000000..1bee3bd5d3
--- /dev/null
+++ b/documentation/ref-manual/ref-manual-customization.xsl
@@ -0,0 +1,21 @@
+<?xml version='1.0'?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
+
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
+
+  <xsl:include href="../template/permalinks.xsl"/>
+  <xsl:include href="../template/section.title.xsl"/>
+  <xsl:include href="../template/component.title.xsl"/>
+  <xsl:include href="../template/division.title.xsl"/>
+  <xsl:include href="../template/formal.object.heading.xsl"/>
+  <xsl:include href="../template/gloss-permalinks.xsl"/>
+  <xsl:include href="../template/qa-code-permalinks.xsl"/>
+
+  <xsl:param name="html.stylesheet" select="'ref-style.css'" />
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="appendix.autolabel" select="A" />
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+  <xsl:param name="generate.id.attributes" select="1" />
+
+</xsl:stylesheet>
diff --git a/documentation/ref-manual/ref-manual-eclipse-customization.xsl b/documentation/ref-manual/ref-manual-eclipse-customization.xsl
new file mode 100644
index 0000000000..4e6b7997b8
--- /dev/null
+++ b/documentation/ref-manual/ref-manual-eclipse-customization.xsl
@@ -0,0 +1,27 @@
+<?xml version='1.0'?>
+<xsl:stylesheet
+        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+        xmlns="http://www.w3.org/1999/xhtml"
+        xmlns:fo="http://www.w3.org/1999/XSL/Format"
+        version="1.0">
+
+  <xsl:import
+          href="http://docbook.sourceforge.net/release/xsl/current/eclipse/eclipse3.xsl" />
+
+  <xsl:param name="chunker.output.indent" select="'yes'"/>
+  <xsl:param name="chunk.quietly" select="1"/>
+  <xsl:param name="chunk.first.sections" select="1"/>
+  <xsl:param name="chunk.section.depth" select="10"/>
+  <xsl:param name="use.id.as.filename" select="1"/>
+  <xsl:param name="ulink.target" select="'_self'" />
+  <xsl:param name="base.dir" select="'html/ref-manual/'"/>
+  <xsl:param name="html.stylesheet" select="'../book.css'"/>
+  <xsl:param name="eclipse.manifest" select="0"/>
+  <xsl:param name="create.plugin.xml" select="0"/>
+  <xsl:param name="suppress.navigation" select="1"/>
+  <xsl:param name="generate.index" select="0"/>
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="appendix.autolabel">A</xsl:param>
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+</xsl:stylesheet>
diff --git a/documentation/ref-manual/ref-manual.xml b/documentation/ref-manual/ref-manual.xml
new file mode 100644
index 0000000000..bf9f65fb5e
--- /dev/null
+++ b/documentation/ref-manual/ref-manual.xml
@@ -0,0 +1,160 @@
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<book id='ref-manual' lang='en'
+      xmlns:xi="http://www.w3.org/2003/XInclude"
+      xmlns="http://docbook.org/ns/docbook"
+      >
+    <bookinfo>
+
+        <mediaobject>
+            <imageobject>
+                <imagedata fileref='figures/poky-title.png'
+                    format='SVG'
+                    align='left' scalefit='1' width='100%'/>
+            </imageobject>
+        </mediaobject>
+
+        <title>
+            Yocto Project Reference Manual
+        </title>
+
+        <authorgroup>
+            <author>
+                <firstname>Richard</firstname> <surname>Purdie</surname>
+                <affiliation>
+                    <orgname>Linux Foundation</orgname>
+                </affiliation>
+                <email>richard.purdie@linuxfoundation.org</email>
+            </author>
+
+        </authorgroup>
+
+        <revhistory>
+            <revision>
+                <revnumber>4.0+git</revnumber>
+                <date>24 November 2010</date>
+                <revremark>Released with the Yocto Project 0.9 Release</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.0</revnumber>
+                <date>6 April 2011</date>
+                <revremark>Released with the Yocto Project 1.0 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.0.1</revnumber>
+                <date>23 May 2011</date>
+                <revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.1</revnumber>
+                <date>6 October 2011</date>
+                <revremark>Released with the Yocto Project 1.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.2</revnumber>
+                <date>April 2012</date>
+                <revremark>Released with the Yocto Project 1.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.3</revnumber>
+                <date>October 2012</date>
+                <revremark>Released with the Yocto Project 1.3 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4</revnumber>
+                <date>April 2013</date>
+                <revremark>Released with the Yocto Project 1.4 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5</revnumber>
+                <date>October 2013</date>
+                <revremark>Released with the Yocto Project 1.5 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.1</revnumber>
+                <date>January 2014</date>
+                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.6</revnumber>
+                <date>April 2014</date>
+                <revremark>Released with the Yocto Project 1.6 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7</revnumber>
+                <date>October 2014</date>
+                <revremark>Released with the Yocto Project 1.7 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.1</revnumber>
+                <date>January 2015</date>
+                <revremark>Released with the Yocto Project 1.7.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.2</revnumber>
+                <date>June 2015</date>
+                <revremark>Released with the Yocto Project 1.7.2 Release.</revremark>
+            </revision>
+        </revhistory>
+
+    <copyright>
+      <year>&COPYRIGHT_YEAR;</year>
+      <holder>Linux Foundation</holder>
+    </copyright>
+
+    <legalnotice>
+      <para>
+        Permission is granted to copy, distribute and/or modify this document under
+        the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
+      </para>
+      <note>
+          For the latest version of this manual associated with this
+          Yocto Project release, see the
+          <ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink>
+          from the Yocto Project website.
+      </note>
+    </legalnotice>
+
+    </bookinfo>
+
+    <xi:include href="introduction.xml"/>
+
+    <xi:include href="usingpoky.xml"/>
+
+    <xi:include href="closer-look.xml"/>
+
+    <xi:include href="technical-details.xml"/>
+
+    <xi:include href="migration.xml"/>
+
+    <xi:include href="ref-structure.xml"/>
+
+    <xi:include href="ref-classes.xml"/>
+
+    <xi:include href="ref-tasks.xml"/>
+
+    <xi:include href="ref-qa-checks.xml"/>
+
+    <xi:include href="ref-images.xml"/>
+
+    <xi:include href="ref-features.xml"/>
+
+    <xi:include href="ref-variables.xml"/>
+
+    <xi:include href="ref-varlocality.xml"/>
+
+    <xi:include href="faq.xml"/>
+
+    <xi:include href="resources.xml"/>
+
+<!--    <index id='index'>
+      <title>Index</title>
+    </index>
+-->
+
+</book>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/ref-qa-checks.xml b/documentation/ref-manual/ref-qa-checks.xml
new file mode 100644
index 0000000000..871cd294f6
--- /dev/null
+++ b/documentation/ref-manual/ref-qa-checks.xml
@@ -0,0 +1,1217 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='ref-qa-checks'>
+<title>QA Error and Warning Messages</title>
+
+<section id='qa-introduction'>
+    <title>Introduction</title>
+
+    <para>
+        When building a recipe, the OpenEmbedded build system performs
+        various QA checks on the output to ensure that common issues are
+        detected and reported.
+        Sometimes when you create a new recipe to build new software,
+        it will build with no problems.
+        When this is not the case, or when you have QA issues building any
+        software, it could take a little time to resolve them.
+    </para>
+
+    <para>
+        While it is tempting to ignore a QA message or even to
+        disable QA checks, it is best to try and resolve any
+        reported QA issues.
+        This chapter provides a list of the QA messages and brief explanations
+        of the issues you could encounter so that you can properly resolve
+        problems.
+    </para>
+
+    <para>
+        The next section provides a list of all QA error and warning
+        messages based on a default configuration.
+        Each entry provides the message or error form along with an
+        explanation.
+        <note>
+            <title>Notes</title>
+            <itemizedlist>
+                <listitem><para>
+                    At the end of each message, the name of the associated
+                    QA test (as listed in the
+                    "<link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>"
+                    section) appears within square brackets.
+                    </para></listitem>
+                <listitem><para>
+                    As mentioned, this list of error and warning messages is for
+                    QA checks only.
+                    The list does not cover all possible build errors or
+                    warnings you could encounter.
+                    </para></listitem>
+                <listitem><para>
+                    Because some QA checks are disabled by default, this list
+                    does not include all possible QA check errors and warnings.
+                    </para></listitem>
+            </itemizedlist>
+        </note>
+    </para>
+</section>
+
+<section id='qa-errors-and-warnings'>
+    <title>Errors and Warnings</title>
+
+<!--
+This section uses the <para><code> construct to enable permalinks for the
+various QA issue and warning messages.  The file templates/qa-code-permalinks.xsl
+is used to locate the construct and generate the permalink.  This solution
+leverages the fact that right now this section in the ref-manual is the only
+place is all the YP docs that uses the <para><code> construct.  If, in the
+future, that construct were to appear in the ref-manual, a generic permalink
+would be generated for the text between <code></code>.  If a better solution
+can be found then it should be implemented.  I can't find one at the moment.
+-->
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-libexec'>
+                    <code>
+     &lt;packagename&gt;: &lt;path&gt; is using libexec please relocate to &lt;libexecdir&gt; [libexec]
+                    </code>
+                </para>
+
+                <para>
+                    The specified package contains files in
+                    <filename>/usr/libexec</filename>.
+                    By default, <filename>libexecdir</filename> is set to
+                    "${libdir}/${BPN}" rather than to "/usr/libexec".
+                    Thus, installing to <filename>/usr/libexec</filename>
+                    is likely not desirable.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-rpaths'>
+                    <code>
+     package &lt;packagename&gt; contains bad RPATH &lt;rpath&gt; in file &lt;file&gt; [rpaths]
+                    </code>
+                </para>
+
+                <para>
+                    The specified binary produced by the recipe contains dynamic
+                    library load paths (rpaths) that contain build system paths
+                    such as
+                    <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>,
+                    which are incorrect for the target and could potentially
+                    be a security issue.
+                    Check for bad <filename>-rpath</filename> options being
+                    passed to the linker in your
+                    <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
+                    log.
+                    Depending on the build system used by the software being
+                    built, there might be a configure option to disable rpath
+                    usage completely within the build of the software.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-useless-rpaths'>
+                    <code>
+     &lt;packagename&gt;: &lt;file&gt; contains probably-redundant RPATH &lt;rpath&gt; [useless-rpaths]
+                    </code>
+                </para>
+
+                <para>
+                    The specified binary produced by the recipe contains dynamic
+                    library load paths (rpaths) that on a standard system are
+                    searched by default by the linker (e.g.
+                    <filename>/lib</filename> and <filename>/usr/lib</filename>).
+                    While these paths will not cause any breakage, they do waste
+                    space and are unnecessary.
+                    Depending on the build system used by the software being
+                    built, there might be a configure option to disable rpath
+                    usage completely within the build of the software.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-file-rdeps'>
+                    <code>
+     &lt;packagename&gt; requires &lt;files&gt;, but no providers in its RDEPENDS [file-rdeps]
+                    </code>
+                </para>
+
+                <para>
+                    A file-level dependency has been identified from the
+                    specified package on the specified files, but there is
+                    no explicit corresponding entry in
+                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>.
+                    If particular files are required at runtime then
+                    <filename>RDEPENDS</filename> should be declared in the
+                    recipe to ensure the packages providing them are built.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-build-deps'>
+                    <code>
+     &lt;packagename1&gt; rdepends on &lt;packagename2&gt;, but it isn't a build dependency? [build-deps]
+                    </code>
+                </para>
+
+                <para>
+                    A runtime dependency exists between the two specified
+                    packages, but there is nothing explicit within the recipe
+                    to enable the OpenEmbedded build system to ensure that
+                    dependency is satisfied.
+                    This condition is usually triggered by an
+                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
+                    value being added at the packaging stage rather than up
+                    front, which is usually automatic based on the contents of
+                    the package.
+                    In most cases, you should change the recipe to add an
+                    explicit <filename>RDEPENDS</filename> for the dependency.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-dev-so'>
+                    <code>
+     non -dev/-dbg/-nativesdk package contains symlink .so: &lt;packagename&gt; path '&lt;path&gt;' [dev-so]
+                    </code>
+                </para>
+
+                <para>
+                    Symlink <filename>.so</filename> files are for development
+                    only, and should therefore go into the
+                    <filename>-dev</filename> package.
+                    This situation might occur if you add
+                    <filename>*.so*</filename> rather than
+                    <filename>*.so.*</filename> to a non-dev package.
+                    Change
+                    <link linkend='var-FILES'><filename>FILES</filename></link>
+                    (and possibly
+                    <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>)
+                    such that the specified <filename>.so</filename> file goes
+                    into an appropriate <filename>-dev</filename> package.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-staticdev'>
+                    <code>
+     non -staticdev package contains static .a library: &lt;packagename&gt; path '&lt;path&gt;' [staticdev]
+                    </code>
+                </para>
+
+                <para>
+                    Static <filename>.a</filename> library files should go into
+                    a <filename>-staticdev</filename> package.
+                    Change
+                    <link linkend='var-FILES'><filename>FILES</filename></link>
+                    (and possibly
+                    <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>)
+                    such that the specified <filename>.a</filename> file goes
+                    into an appropriate <filename>-staticdev</filename> package.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-libdir'>
+                    <code>
+     &lt;packagename&gt;: found library in wrong location [libdir]
+                    </code>
+                </para>
+
+                <para>
+                    The specified file may have been installed into an incorrect
+                    (possibly hardcoded) installation path.
+                    For example, this test will catch recipes that install
+                    <filename>/lib/bar.so</filename> when
+                    <filename>${base_libdir}</filename> is "lib32".
+                    Another example is when recipes install
+                    <filename>/usr/lib64/foo.so</filename> when
+                    <filename>${libdir}</filename> is "/usr/lib".
+                    False positives occasionally exist.
+                    For these cases add "libdir" to
+                    <link linkend='var-INSANE_SKIP'><filename>INSANE_SKIP</filename></link>
+                    for the package.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-debug-files'>
+                    <code>
+     non debug package contains .debug directory: &lt;packagename&gt; path &lt;path&gt; [debug-files]
+                    </code>
+                </para>
+
+                <para>
+                    The specified package contains a
+                    <filename>.debug</filename> directory, which should not
+                    appear in anything but the <filename>-dbg</filename>
+                    package.
+                    This situation might occur if you add a path which contains
+                    a <filename>.debug</filename> directory and do not
+                    explicitly add the <filename>.debug</filename> directory
+                    to the <filename>-dbg</filename> package.
+                    If this is the case, add the <filename>.debug</filename>
+                    directory explicitly to
+                    <filename>FILES_${PN}-dbg</filename>.
+                    See
+                    <link linkend='var-FILES'><filename>FILES</filename></link>
+                    for additional information on <filename>FILES</filename>.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-arch'>
+                    <code>
+     Architecture did not match (&lt;machine_arch&gt; to &lt;file_arch&gt;) on &lt;file&gt; [arch]
+                    </code>
+                </para>
+
+                <para>
+                    By default, the OpenEmbedded build system checks the
+                    Executable and Linkable Format (ELF) type, bit size, and
+                    endianness of any binaries to ensure they match the
+                    target architecture.
+                    This test fails if any binaries do not match the type since
+                    there would be an incompatibility.
+                    The test could indicate that the wrong compiler or compiler
+                    options have been used.
+                    Sometimes software, like bootloaders, might need to
+                    bypass this check.
+                    If the file you receive the error for is firmware
+                    that is not intended to be executed within the target
+                    operating system or is intended to run on a separate
+                    processor within the device, you can add "arch" to
+                    <link linkend='var-INSANE_SKIP'><filename>INSANE_SKIP</filename></link>
+                    for the package.
+                    Another option is to check the
+                    <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
+                    log and verify that the compiler options being used
+                    are correct.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-arch-bit-size-no-match'>
+                    <code>
+     Bit size did not match (&lt;machine_bits&gt; to &lt;file_bits&gt;) &lt;recipe&gt; on &lt;file&gt; [arch]
+                    </code>
+                </para>
+
+                <para>
+                    By default, the OpenEmbedded build system checks
+                    the Executable and Linkable Format (ELF) type,
+                    bit size, and endianness of any binaries to ensure
+                    they match the target architecture.
+                    This test fails if any binaries do not match the type since
+                    there would be an incompatibility.
+                    The test could indicate that the wrong compiler or compiler
+                    options have been used.
+                    Sometimes software, like bootloaders, might need to
+                    bypass this check.
+                    If the file you receive the error for is firmware that
+                    is not intended to be executed within the target
+                    operating system or is intended to run on a separate
+                    processor within the device, you can add "arch" to
+                    <link linkend='var-INSANE_SKIP'><filename>INSANE_SKIP</filename></link>
+                    for the package.
+                    Another option is to check the
+                    <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
+                    log and verify that the compiler options being used are
+                    correct.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-arch-endianness-no-match'>
+                    <code>
+     Endianness did not match (&lt;machine_endianness&gt; to &lt;file_endianness&gt;) on &lt;file&gt; [arch]
+                    </code>
+                </para>
+
+                <para>
+                    By default, the OpenEmbedded build system checks
+                    the Executable and Linkable Format (ELF) type, bit
+                    size, and endianness of any binaries to ensure they
+                    match the target architecture.
+                    This test fails if any binaries do not match the type since
+                    there would be an incompatibility.
+                    The test could indicate that the wrong compiler or compiler
+                    options have been used.
+                    Sometimes software, like bootloaders, might need to
+                    bypass this check.
+                    If the file you receive the error for is firmware
+                    that is not intended to be executed within the target
+                    operating system or is intended to run on a separate
+                    processor within the device, you can add "arch" to
+                    <link linkend='var-INSANE_SKIP'><filename>INSANE_SKIP</filename></link>
+                    for the package.
+                    Another option is to check the
+                    <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
+                    log and verify that the compiler options being used
+                    are correct.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-textrel'>
+                    <code>
+     ELF binary '&lt;file&gt;' has relocations in .text [textrel]
+                    </code>
+                </para>
+
+                <para>
+                    The specified ELF binary contains relocations in its
+                    <filename>.text</filename> sections.
+                    This situation can result in a performance impact
+                    at runtime.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-ldflags'>
+                    <code>
+     No GNU_HASH in the elf binary: '&lt;file&gt;' [ldflags]
+                    </code>
+                </para>
+
+                <para>
+                    This indicates that binaries produced when building the
+                    recipe have not been linked with the
+                    <link linkend='var-LDFLAGS'><filename>LDFLAGS</filename></link>
+                    options provided by the build system.
+                    Check to be sure that the <filename>LDFLAGS</filename>
+                    variable is being passed to the linker command.
+                    A common workaround for this situation is to pass in
+                    <filename>LDFLAGS</filename> using
+                    <link linkend='var-TARGET_CC_ARCH'><filename>TARGET_CC_ARCH</filename></link>
+                    within the recipe as follows:
+                    <literallayout class='monospaced'>
+     TARGET_CC_ARCH += "${LDFLAGS}"
+                    </literallayout>
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-xorg-driver-abi'>
+                    <code>
+     Package &lt;packagename&gt; contains Xorg driver (&lt;driver&gt;) but no xorg-abi- dependencies [xorg-driver-abi]
+                    </code>
+                </para>
+
+                <para>
+                    The specified package contains an Xorg driver, but does not
+                    have a corresponding ABI package dependency.
+                    The xserver-xorg recipe provides driver ABI names.
+                    All drivers should depend on the ABI versions that they have
+                    been built against.
+                    Driver recipes that include
+                    <filename>xorg-driver-input.inc</filename> or
+                    <filename>xorg-driver-video.inc</filename> will
+                    automatically get these versions.
+                    Consequently, you should only need to explicitly add
+                    dependencies to binary driver recipes.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-infodir'>
+                    <code>
+     The /usr/share/info/dir file is not meant to be shipped in a particular package. [infodir]
+                    </code>
+                </para>
+
+                <para>
+                    The <filename>/usr/share/info/dir</filename> should not be
+                    packaged.
+                    Add the following line to your
+                    <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+                    task or to your <filename>do_install_append</filename>
+                    within the recipe as follows:
+                    <literallayout class='monospaced'>
+     rm ${D}${infodir}/dir
+                    </literallayout>
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-symlink-to-sysroot'>
+                    <code>
+     Symlink &lt;path&gt; in &lt;packagename&gt; points to TMPDIR [symlink-to-sysroot]
+                    </code>
+                </para>
+
+                <para>
+                    The specified symlink points into
+                    <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
+                    on the host.
+                    Such symlinks will work on the host.
+                    However, they are clearly invalid when running on
+                    the target.
+                    You should either correct the symlink to use a relative
+                    path or remove the symlink.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-la'>
+                    <code>
+     &lt;file&gt; failed sanity test (workdir) in path &lt;path&gt; [la]
+                    </code>
+                </para>
+
+                <para>
+                    The specified <filename>.la</filename> file contains
+                    <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
+                    paths.
+                    Any <filename>.la</filename> file containing these paths
+                    is incorrect since <filename>libtool</filename> adds the
+                    correct sysroot prefix when using the files automatically
+                    itself.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-pkgconfig'>
+                    <code>
+     &lt;file&gt; failed sanity test (tmpdir) in path &lt;path&gt; [pkgconfig]
+                    </code>
+                </para>
+
+                <para>
+                    The specified <filename>.pc</filename> file contains
+                    <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link><filename>/</filename><link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
+                    paths.
+                    Any <filename>.pc</filename> file containing these paths is
+                    incorrect since <filename>pkg-config</filename> itself adds
+                    the correct sysroot prefix when the files are accessed.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-debug-deps'>
+                    <code>
+     &lt;packagename&gt; rdepends on &lt;debug_packagename&gt; [debug-deps]
+                    </code>
+                </para>
+
+                <para>
+                    A dependency exists between the specified non-dbg package
+                    (i.e. a package whose name does not end in
+                    <filename>-dbg</filename>) and a package that is a
+                    <filename>dbg</filename> package.
+                    The <filename>dbg</filename> packages contain
+                    debug symbols and are brought in using several
+                    different methods:
+                    <itemizedlist>
+                        <listitem><para>
+                            Using the <filename>dbg-pkgs</filename>
+                            <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
+                            value.
+                            </para></listitem>
+                        <listitem><para>
+                            Using
+                            <link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>.
+                            </para></listitem>
+                        <listitem><para>
+                            As a dependency of another
+                            <filename>dbg</filename> package that was brought
+                            in using one of the above methods.
+                            </para></listitem>
+                    </itemizedlist>
+                    The dependency might have been automatically added
+                    because the <filename>dbg</filename> package erroneously
+                    contains files that it should not contain (e.g. a
+                    non-symlink <filename>.so</filename> file) or it might
+                    have been added manually (e.g. by adding to
+                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>).
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-dev-deps'>
+                    <code>
+     &lt;packagename&gt; rdepends on &lt;dev_packagename&gt; [dev-deps]
+                    </code>
+                </para>
+
+                <para>
+                    A dependency exists between the specified non-dev package
+                    (a package whose name does not end in
+                    <filename>-dev</filename>) and a package that is a
+                    <filename>dev</filename> package.
+                    The <filename>dev</filename> packages contain development
+                    headers and are usually brought in using several different
+                    methods:
+                    <itemizedlist>
+                        <listitem><para>
+                            Using the <filename>dev-pkgs</filename>
+                            <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
+                            value.
+                            </para></listitem>
+                        <listitem><para>
+                            Using
+                            <link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>.
+                            </para></listitem>
+                        <listitem><para>
+                            As a dependency of another
+                            <filename>dev</filename> package that was brought
+                            in using one of the above methods.
+                            </para></listitem>
+                    </itemizedlist>
+                    The dependency might have been automatically added (because
+                    the <filename>dev</filename> package erroneously contains
+                    files that it should not have (e.g. a non-symlink
+                    <filename>.so</filename> file) or it might have been added
+                    manually (e.g. by adding to
+                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>).
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-dep-cmp'>
+                    <code>
+     &lt;var&gt;_&lt;packagename&gt; is invalid: &lt;comparison&gt; (&lt;value&gt;)   only comparisons &lt;, =, &gt;, &lt;=, and &gt;= are allowed [dep-cmp]
+                    </code>
+                </para>
+
+                <para>
+                    If you are adding a versioned dependency relationship to one
+                    of the dependency variables
+                    (<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>,
+                    <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
+                    <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>,
+                    <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
+                    <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>,
+                    or
+                    <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>),
+                    you must only use the named comparison operators.
+                    Change the versioned dependency values you are adding
+                    to match those listed in the message.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-compile-host-path'>
+                    <code>
+     &lt;recipename&gt;: The compile log indicates that host include and/or library paths were used. Please check the log '&lt;logfile&gt;' for more information. [compile-host-path]
+                    </code>
+                </para>
+
+                <para>
+                    The log for the
+                    <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
+                    task indicates that paths on the host were searched
+                    for files, which is not appropriate when cross-compiling.
+                    Look for "is unsafe for cross-compilation" or "CROSS COMPILE
+                    Badness" in the specified log file.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-install-host-path'>
+                    <code>
+     &lt;recipename&gt;: The install log indicates that host include and/or library paths were used. Please check the log '&lt;logfile&gt;' for more information. [install-host-path]
+                    </code>
+                </para>
+
+                <para>
+                    The log for the
+                    <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+                    task indicates that paths on the host were searched
+                    for files, which is not appropriate when cross-compiling.
+                    Look for "is unsafe for cross-compilation"
+                    or "CROSS COMPILE Badness" in the specified log file.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-autoconf-log'>
+                    <code>
+     This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Rerun configure task after fixing this. The path was '&lt;path&gt;'
+                    </code>
+                </para>
+
+                <para>
+                    The log for the
+                    <link linkend='ref-tasks-configure'><filename>do_configure</filename></link>
+                    task indicates that paths on the host were searched
+                    for files, which is not appropriate when cross-compiling.
+                    Look for "is unsafe for cross-compilation" or
+                    "CROSS COMPILE Badness" in the specified log file.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-pkgname'>
+                    <code>
+     &lt;packagename&gt; doesn't match the [a-z0-9.+-]+ regex [pkgname]
+                    </code>
+                </para>
+
+                <para>
+                    The convention within the OpenEmbedded build system
+                    (sometimes enforced by the package manager itself) is to
+                    require that package names are all lower case
+                    and to allow a restricted set of characters.
+                    If your recipe name does not match this, or you add
+                    packages to
+                    <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>
+                    that do not conform to the convention, then you
+                    will receive this error.
+                    Rename your recipe.
+                    Or, if you have added a non-conforming package name to
+                    <filename>PACKAGES</filename>, change the package name
+                    appropriately.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-unknown-configure-option'>
+                    <code>
+     &lt;recipe&gt;: configure was passed unrecognized options: &lt;options&gt; [unknown-configure-option]
+                    </code>
+                </para>
+
+                <para>
+                    The configure script is reporting that the specified
+                    options are unrecognized.
+                    This situation could be because the options
+                    were previously valid but have been removed from the
+                    configure script.
+                    Or, there was a mistake when the options were added
+                    and there is another option that should be used instead.
+                    If you are unsure, consult the upstream build
+                    documentation, the
+                    <filename>./configure &dash;&dash;help</filename> output,
+                    and the upstream change log or release notes.
+                    Once you have worked out what the appropriate
+                    change is, you can update
+                    <link linkend='var-EXTRA_OECONF'><filename>EXTRA_OECONF</filename></link>
+                    or the individual
+                    <link linkend='var-PACKAGECONFIG'><filename>PACKAGECONFIG</filename></link>
+                    option values accordingly.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-pn-overrides'>
+                    <code>
+     Recipe &lt;recipefile&gt; has PN of "&lt;recipename&gt;" which is in OVERRIDES, this can result in unexpected behavior. [pn-overrides]
+                    </code>
+                </para>
+
+                <para>
+                    The specified recipe has a name
+                    (<link linkend='var-PN'><filename>PN</filename></link>)
+                    value that appears in
+                    <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>.
+                    If a recipe is named such that its <filename>PN</filename>
+                    value matches something already in
+                    <filename>OVERRIDES</filename> (e.g. <filename>PN</filename>
+                    happens to be the same as
+                    <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+                    or
+                    <link linkend='var-DISTRO'><filename>DISTRO</filename></link>),
+                    it can have unexpected consequences.
+                    For example, assignments such as
+                    <filename>FILES_${PN} = "xyz"</filename> effectively
+                    turn into <filename>FILES = "xyz"</filename>.
+                    Rename your recipe (or if <filename>PN</filename> is being
+                    set explicitly, change the <filename>PN</filename> value) so
+                    that the conflict does not occur.
+                    See
+                    <link linkend='var-FILES'><filename>FILES</filename></link>
+                    for additional information.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-pkgvarcheck'>
+                    <code>
+     &lt;recipefile&gt;: Variable &lt;variable&gt; is set as not being package specific, please fix this. [pkgvarcheck]
+                    </code>
+                </para>
+
+                <para>
+                    Certain variables
+                    (<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>,
+                    <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
+                    <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>,
+                    <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>,
+                    <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
+                    <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>,
+                    <link linkend='var-FILES'><filename>FILES</filename></link>,
+                    <filename>pkg_preinst</filename>,
+                    <filename>pkg_postinst</filename>,
+                    <filename>pkg_prerm</filename>,
+                    <filename>pkg_postrm</filename>, and
+                    <link linkend='var-ALLOW_EMPTY'><filename>ALLOW_EMPTY</filename></link>)
+                    should always be set specific to a package (i.e. they
+                    should be set with a package name override such as
+                    <filename>RDEPENDS_${PN} = "value"</filename> rather than
+                    <filename>RDEPENDS = "value"</filename>).
+                    If you receive this error, correct any assignments to these
+                    variables within your recipe.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-already-stripped'>
+                    <code>
+     File '&lt;file&gt;' from &lt;recipename&gt; was already stripped, this will prevent future debugging! [already-stripped]
+                    </code>
+                </para>
+
+                <para>
+                    Produced binaries have already been stripped prior to the
+                    build system extracting debug symbols.
+                    It is common for upstream software projects to default to
+                    stripping debug symbols for output binaries.
+                    In order for debugging to work on the target using
+                    <filename>-dbg</filename> packages, this stripping must be
+                    disabled.
+                </para>
+
+                <para>
+                    Depending on the build system used by the software being
+                    built, disabling this stripping could be as easy as
+                    specifying an additional configure option.
+                    If not, disabling stripping might involve patching
+                    the build scripts.
+                    In the latter case, look for references to "strip" or
+                    "STRIP", or the "-s" or "-S" command-line options being
+                    specified on the linker command line (possibly
+                    through the compiler command line if preceded with "-Wl,").
+                    <note>
+                        Disabling stripping here does not mean that the final
+                        packaged binaries will be unstripped.
+                        Once the OpenEmbedded build system splits out debug
+                        symbols to the <filename>-dbg</filename> package,
+                        it will then strip the symbols from the binaries.
+                    </note>
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-packages-list'>
+                    <code>
+     &lt;packagename&gt; is listed in PACKAGES multiple times, this leads to packaging errors. [packages-list]
+                    </code>
+                </para>
+
+                <para>
+                    Package names must appear only once in the
+                    <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>
+                    variable.
+                    You might receive this error if you are attempting to add a
+                    package to <filename>PACKAGES</filename> that is
+                    already in the variable's value.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-files-invalid'>
+                    <code>
+     FILES variable for package &lt;packagename&gt; contains '//' which is invalid. Attempting to fix this but you should correct the metadata. [files-invalid]
+                    </code>
+                </para>
+
+                <para>
+                    The string "//" is invalid in a Unix path.
+                    Correct all occurrences where this string appears in a
+                    <link linkend='var-FILES'><filename>FILES</filename></link>
+                    variable so that there is only a single "/".
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-installed-vs-shipped'>
+                    <code>
+      &lt;recipename&gt;: Files/directories were installed but not shipped [installed-vs-shipped]
+                    </code>
+                </para>
+
+                <para>
+                    Files have been installed within the
+                    <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+                    task but have not been included in any package by way of the
+                    <link linkend='var-FILES'><filename>FILES</filename></link>
+                    variable.
+                    Files that do not appear in any package cannot be present in
+                    an image later on in the build process.
+                    You need to do one of the following:
+                    <itemizedlist>
+                        <listitem><para>
+                            Add the files to <filename>FILES</filename> for the
+                            package you want them to appear in (e.g.
+                            <filename>FILES_${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename> for the main
+                            package).
+                            </para></listitem>
+                        <listitem><para>
+                            Delete the files at the end of the
+                            <filename>do_install</filename> task if the files
+                            are not needed in any package.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-old-and-new-package-and-version-names'>
+                    <code>
+     &lt;oldpackage&gt;-&lt;oldpkgversion&gt; was registered as shlib provider for &lt;library&gt;, changing it to &lt;newpackage&gt;-&lt;newpkgversion&gt; because it was built later
+                    </code>
+                </para>
+
+                <para>
+                    This message means that both
+                    <filename>&lt;oldpackage&gt;</filename> and
+                    <filename>&lt;newpackage&gt;</filename> provide the specified
+                    shared library.
+                    You can expect this message when a recipe has been renamed.
+                    However, if that is not the case, the message might indicate
+                    that a private version of a library is being erroneously
+                    picked up as the provider for a common library.
+                    If that is the case, you should add the library's
+                    <filename>.so</filename> file name to
+                    <link linkend='var-PRIVATE_LIBS'><filename>PRIVATE_LIBS</filename></link>
+                    in the recipe that provides
+                    the private version of the library.
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+<!--
+Here are some messages that might be documented in the future.
+Right now we are not documenting them because the QA checks are not
+enabled by default:
+
+    <para>
+        <itemizedlist>
+            <listitem><para>
+                <literallayout class='monospaced'>
+     Desktop file issue: &lt;error&gt; [desktop]
+                </literallayout>
+                NEED A DESCRIPTION AND SOLUTION
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem><para>
+                <literallayout class='monospaced'>
+     &lt;packagename&gt;: &lt;file&gt;, installed in the base_prefix, requires a shared library under exec_prefix (&lt;exec_prefix&t;g) [unsafe-references-in-binaries]
+                </literallayout>
+                NEED A DESCRIPTION AND SOLUTION
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem><para>
+                <literallayout class='monospaced'>
+     &lt;packagename&gt;: Found a reference to &lt;exec_prefix&gt;/ in &lt;path&gt; - Shell scripts in base_bindir and base_sbindir should not reference anything in exec_prefix [unsafe-references-in-scripts]
+                </literallayout>
+                NEED A DESCRIPTION AND SOLUTION
+                </para></listitem>
+        </itemizedlist>
+    </para>
+-->
+</section>
+
+<section id='configuring-and-disabling-qa-checks'>
+    <title>Configuring and Disabling QA Checks</title>
+
+    <para>
+        You can configure the QA checks globally so that specific check
+        failures either raise a warning or an error message, using the
+        <link linkend='var-WARN_QA'><filename>WARN_QA</filename></link> and
+        <link linkend='var-ERROR_QA'><filename>ERROR_QA</filename></link>
+        variables, respectively.
+        You can also disable checks within a particular recipe using
+        <link linkend='var-INSANE_SKIP'><filename>INSANE_SKIP</filename></link>.
+        For information on how to work with the QA checks, see the
+        "<link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>"
+        section.
+        <note><title>Tip</title>
+            Please keep in mind that the QA checks exist in order to
+            detect real or potential problems in the packaged output.
+            So exercise caution when disabling these checks.
+        </note>
+    </para>
+</section>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/ref-structure.xml b/documentation/ref-manual/ref-structure.xml
new file mode 100644
index 0000000000..e7ca7b334b
--- /dev/null
+++ b/documentation/ref-manual/ref-structure.xml
@@ -0,0 +1,1129 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='ref-structure'>
+
+<title>Source Directory Structure</title>
+
+<para>
+    The <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> consists of several components.
+    Understanding them and knowing where they are located is key to using the Yocto Project well.
+    This chapter describes the Source Directory and gives information about the various
+    files and directories.
+</para>
+
+<para>
+    For information on how to establish a local Source Directory on your development system, see the
+    "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Set Up</ulink>"
+    section in the Yocto Project Development Manual.
+</para>
+
+<note>
+    The OpenEmbedded build system does not support file or directory names that
+    contain spaces.
+    Be sure that the Source Directory you use does not contain these types
+    of names.
+</note>
+
+<section id='structure-core'>
+    <title>Top-Level Core Components</title>
+
+    <para>
+        This section describes the top-level components of the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+    </para>
+
+    <section id='structure-core-bitbake'>
+        <title><filename>bitbake/</filename></title>
+
+        <para>
+            This directory includes a copy of BitBake for ease of use.
+            The copy usually matches the current stable BitBake release from
+            the BitBake project.
+            BitBake, a
+            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+            interpreter, reads the Yocto Project Metadata and runs the tasks
+            defined by that data.
+            Failures are usually from the Metadata and not from BitBake itself.
+            Consequently, most users do not need to worry about BitBake.
+        </para>
+
+        <para>
+            When you run the <filename>bitbake</filename> command, the
+            main BitBake executable, which resides in the
+            <filename>bitbake/bin/</filename> directory, starts.
+            Sourcing an environment setup script (e.g.
+            <link linkend="structure-core-script"><filename>&OE_INIT_FILE;</filename></link>
+            or
+            <link linkend="structure-memres-core-script"><filename>oe-init-build-env-memres</filename></link>)
+            places the <filename>scripts</filename> and
+            <filename>bitbake/bin</filename> directories (in that order) into
+            the shell's <filename>PATH</filename> environment variable.
+        </para>
+
+        <para>
+            For more information on BitBake, see the
+            <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
+        </para>
+    </section>
+
+    <section id='structure-core-build'>
+        <title><filename>build/</filename></title>
+
+        <para>
+            This directory contains user configuration files and the output
+            generated by the OpenEmbedded build system in its standard configuration where
+            the source tree is combined with the output.
+            The <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            is created initially when you <filename>source</filename>
+            the OpenEmbedded build environment setup script
+            (i.e.
+            <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+            or
+            <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
+        </para>
+
+        <para>
+            It is also possible to place output and configuration
+            files in a directory separate from the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            by providing a directory name when you <filename>source</filename>
+            the setup script.
+            For information on separating output from your local
+            Source Directory files, see the
+            "<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+            and
+            "<link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>"
+            sections.
+        </para>
+    </section>
+
+    <section id='handbook'>
+        <title><filename>documentation/</filename></title>
+
+        <para>
+            This directory holds the source for the Yocto Project documentation
+            as well as templates and tools that allow you to generate PDF and HTML
+            versions of the manuals.
+            Each manual is contained in a sub-folder.
+            For example, the files for this manual reside in
+            the <filename>ref-manual/</filename> directory.
+        </para>
+    </section>
+
+    <section id='structure-core-meta'>
+        <title><filename>meta/</filename></title>
+
+        <para>
+            This directory contains the OpenEmbedded Core metadata.
+            The directory holds recipes, common classes, and machine
+            configuration for emulated targets (<filename>qemux86</filename>,
+            <filename>qemuarm</filename>, and so forth.)
+        </para>
+    </section>
+
+    <section id='structure-core-meta-yocto'>
+        <title><filename>meta-yocto/</filename></title>
+
+        <para>
+            This directory contains the configuration for the Poky
+            reference distribution.
+        </para>
+    </section>
+
+    <section id='structure-core-meta-yocto-bsp'>
+        <title><filename>meta-yocto-bsp/</filename></title>
+
+        <para>
+            This directory contains the Yocto Project reference
+            hardware Board Support Packages (BSPs).
+            For more information on BSPs, see the
+            <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support
+            Package (BSP) Developer's Guide</ulink>.
+        </para>
+    </section>
+
+    <section id='structure-meta-selftest'>
+        <title><filename>meta-selftest/</filename></title>
+
+        <para>
+            This directory adds additional recipes and append files
+            used by the OpenEmbedded selftests to verify the behavior
+            of the build system.
+        </para>
+
+        <para>
+            You do not have to add this layer to your
+            <filename>bblayers.conf</filename> file unless you want to run the
+            selftests.
+        </para>
+    </section>
+
+    <section id='structure-meta-skeleton'>
+        <title><filename>meta-skeleton/</filename></title>
+
+        <para>
+            This directory contains template recipes for BSP and kernel development.
+        </para>
+    </section>
+
+    <section id='structure-core-scripts'>
+        <title><filename>scripts/</filename></title>
+
+        <para>
+            This directory contains various integration scripts that implement
+            extra functionality in the Yocto Project environment (e.g. QEMU scripts).
+            The <link linkend="structure-core-script"><filename>&OE_INIT_FILE;</filename></link>
+            and
+            <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>
+            scripts append this directory to the shell's
+            <filename>PATH</filename> environment variable.
+        </para>
+
+        <para>
+            The <filename>scripts</filename> directory has useful scripts that assist in contributing
+            back to the Yocto Project, such as <filename>create-pull-request</filename> and
+            <filename>send-pull-request</filename>.
+        </para>
+    </section>
+
+    <section id='structure-core-script'>
+        <title><filename>&OE_INIT_FILE;</filename></title>
+
+        <para>
+            This script is one of two scripts that set up the OpenEmbedded build
+            environment.
+            For information on the other script, see the
+            "<link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>"
+            section.
+        </para>
+
+        <para>
+            Running this script with the <filename>source</filename> command in
+            a shell makes changes to <filename>PATH</filename> and sets other
+            core BitBake variables based on the current working directory.
+            You need to run an environment setup script before running BitBake
+            commands.
+            The script uses other scripts within the
+            <filename>scripts</filename> directory to do the bulk of the work.
+        </para>
+
+        <para>
+            When you run this script, your Yocto Project environment is set
+            up, a
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            is created, your working directory becomes the Build Directory,
+            and you are presented with a list of common BitBake targets.
+            Here is an example:
+            <literallayout class='monospaced'>
+     $ source oe-init-build-env
+
+     ### Shell environment set up for builds. ###
+
+     You can now run 'bitbake &lt;target&gt;'
+
+     Common targets are:
+         core-image-minimal
+         core-image-sato
+         meta-toolchain
+         adt-installer
+         meta-ide-support
+
+     You can also run generated qemu images with a command like 'runqemu qemux86'
+            </literallayout>
+            The script gets its default list of common targets from the
+            <filename>conf-notes.txt</filename> file, which is found in the
+            <filename>meta-yocto</filename> directory within the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            Should you have custom distributions, it is very easy to modify
+            this configuration file to include your targets for your
+            distribution.
+            See the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-custom-template-configuration-directory'>Creating a Custom Template Configuration Directory</ulink>"
+            section in the Yocto Project Development Manual for more
+            information.
+        </para>
+
+        <para>
+            By default, running this script without a
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            argument creates the <filename>build</filename> directory
+            in your current working directory.
+            If you provide a Build Directory argument when you
+            <filename>source</filename> the script, you direct the OpenEmbedded
+            build system to create a Build Directory of your choice.
+            For example, the following command creates a Build Directory named
+            <filename>mybuilds</filename> that is outside of the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
+            <literallayout class='monospaced'>
+     $ source &OE_INIT_FILE; ~/mybuilds
+            </literallayout>
+            The OpenEmbedded build system uses the template configuration
+            files, which are found by default in the
+            <filename>meta-yocto/conf</filename> directory in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            See the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-custom-template-configuration-directory'>Creating a Custom Template Configuration Directory</ulink>"
+            section in the Yocto Project Development Manual for more
+            information.
+            <note>
+                The OpenEmbedded build system does not support file or directory names that
+                contain spaces.
+                If you attempt to run the <filename>&OE_INIT_FILE;</filename> script
+                from a Source Directory that contains spaces in either the filenames
+                or directory names, the script returns an error indicating no such
+                file or directory.
+                Be sure to use a Source Directory free of names containing spaces.
+            </note>
+        </para>
+    </section>
+
+    <section id='structure-memres-core-script'>
+        <title><filename>oe-init-build-env-memres</filename></title>
+
+        <para>
+            This script is one of two scripts that set up the OpenEmbedded
+            build environment.
+            Aside from setting up the environment, this script starts a
+            memory-resident BitBake server.
+            For information on the other setup script, see the
+            "<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>"
+            section.
+        </para>
+
+        <para>
+            Memory-resident BitBake resides in memory until you specifically
+            remove it using the following BitBake command:
+            <literallayout class='monospaced'>
+     $ bitbake -m
+            </literallayout>
+        </para>
+
+        <para>
+            Running this script with the <filename>source</filename> command in
+            a shell makes changes to <filename>PATH</filename> and sets other
+            core BitBake variables based on the current working directory.
+            One of these variables is the
+            <link linkend='var-BBSERVER'><filename>BBSERVER</filename></link>
+            variable, which allows the OpenEmbedded build system to locate
+            the server that is running BitBake.
+        </para>
+
+        <para>
+            You need to run an environment setup script before using BitBake
+            commands.
+            Following is the script syntax:
+            <literallayout class='monospaced'>
+     $ source oe-init-build-env-memres <replaceable>port_number</replaceable> <replaceable>build_dir</replaceable>
+            </literallayout>
+            The script uses other scripts within the
+            <filename>scripts</filename> directory to do the bulk of the work.
+        </para>
+
+        <para>
+            If you do not provide a port number with the script, the
+            BitBake server at port "12345" is started.
+        </para>
+
+        <para>
+            When you run this script, your Yocto Project environment is set
+            up, a
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            is created, your working directory becomes the Build Directory,
+            and you are presented with a list of common BitBake targets.
+            Here is an example:
+            <literallayout class='monospaced'>
+     $ source oe-init-build-env-memres
+     No port specified, using dynamically selected port
+
+     ### Shell environment set up for builds. ###
+
+     You can now run 'bitbake &lt;target&gt;'
+
+     Common targets are:
+         core-image-minimal
+         core-image-sato
+         meta-toolchain
+         adt-installer
+         meta-ide-support
+
+     You can also run generated qemu images with a command like 'runqemu qemux86'
+     Bitbake server started on demand as needed, use bitbake -m to shut it down
+            </literallayout>
+            The script gets its default list of common targets from the
+            <filename>conf-notes.txt</filename> file, which is found in the
+            <filename>meta-yocto</filename> directory within the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            Should you have custom distributions, it is very easy to modify
+            this configuration file to include your targets for your
+            distribution.
+            See the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-custom-template-configuration-directory'>Creating a Custom Template Configuration Directory</ulink>"
+            section in the Yocto Project Development Manual for more
+            information.
+        </para>
+
+        <para>
+            By default, running this script without a
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            argument creates a build directory named
+            <filename>build</filename>.
+            If you provide a Build Directory argument when you
+            <filename>source</filename> the script, the Build Directory is
+            created using that name.
+            For example, the following command starts the BitBake server using
+            the default port "12345" and creates a Build Directory named
+            <filename>mybuilds</filename> that is outside of the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
+            <literallayout class='monospaced'>
+     $ source oe-init-build-env-memres ~/mybuilds
+            </literallayout>
+            The OpenEmbedded build system uses the template configuration
+            files, which are found by default in the
+            <filename>meta-yocto/conf</filename> directory in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            See the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-custom-template-configuration-directory'>Creating a Custom Template Configuration Directory</ulink>"
+            section in the Yocto Project Development Manual for more
+            information.
+            <note>
+                The OpenEmbedded build system does not support file or
+                directory names that contain spaces.
+                If you attempt to run the
+                <filename>oe-init-build-env-memres</filename> script
+                from a Source Directory that contains spaces in either the
+                filenames or directory names, the script returns an error
+                indicating no such file or directory.
+                Be sure to use a Source Directory free of names containing
+                spaces.
+            </note>
+        </para>
+    </section>
+
+    <section id='structure-basic-top-level'>
+        <title><filename>LICENSE, README, and README.hardware</filename></title>
+
+        <para>
+            These files are standard top-level files.
+        </para>
+    </section>
+</section>
+
+<section id='structure-build'>
+    <title>The Build Directory - <filename>build/</filename></title>
+
+    <para>
+        The OpenEmbedded build system creates the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+        when you run one of the build environment setup scripts (i.e.
+        <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+        or
+        <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
+    </para>
+
+    <para>
+        If you do not give the Build Directory a specific name when you run
+        a setup script, the name defaults to <filename>build</filename>.
+    </para>
+
+    <para>
+        The
+        <link linkend='var-TOPDIR'><filename>TOPDIR</filename></link> variable
+        points to the Build Directory.
+    </para>
+
+    <section id='structure-build-buildhistory'>
+        <title><filename>build/buildhistory</filename></title>
+
+        <para>
+            The OpenEmbedded build system creates this directory when you
+            enable the build history feature.
+            The directory tracks build information into image, packages, and
+            SDK subdirectories.
+            For information on the build history feature, see the
+            "<link linkend='maintaining-build-output-quality'>Maintaining Build Output Quality</link>"
+            section.
+        </para>
+    </section>
+
+    <section id='structure-build-conf-local.conf'>
+        <title><filename>build/conf/local.conf</filename></title>
+
+        <para>
+            This configuration file contains all the local user configurations
+            for your build environment.
+            The <filename>local.conf</filename> file contains documentation on
+            the various configuration options.
+            Any variable set here overrides any variable set elsewhere within
+            the environment unless that variable is hard-coded within a file
+            (e.g. by using '=' instead of '?=').
+            Some variables are hard-coded for various reasons but these
+            variables are relatively rare.
+        </para>
+
+        <para>
+            Edit this file to set the
+            <filename><link linkend='var-MACHINE'>MACHINE</link></filename>
+            for which you want to build, which package types you wish to use
+            (<link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>),
+            the location from which you want to access downloaded files
+            (<filename><link linkend='var-DL_DIR'>DL_DIR</link></filename>),
+            and how you want your host machine to use resources
+            (<link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
+            and
+            <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>).
+        </para>
+
+        <para>
+            If <filename>local.conf</filename> is not present when you
+            start the build, the OpenEmbedded build system creates it from
+            <filename>local.conf.sample</filename> when
+            you <filename>source</filename> the top-level build environment
+            setup script (i.e.
+            <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+            or
+            <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
+        </para>
+
+        <para>
+            The source <filename>local.conf.sample</filename> file used
+            depends on the <filename>$TEMPLATECONF</filename> script variable,
+            which defaults to <filename>meta-yocto/conf</filename>
+            when you are building from the Yocto Project development
+            environment and defaults to <filename>meta/conf</filename> when
+            you are building from the OpenEmbedded Core environment.
+            Because the script variable points to the source of the
+            <filename>local.conf.sample</filename> file, this implies that
+            you can configure your build environment from any layer by setting
+            the variable in the top-level build environment setup script as
+            follows:
+            <literallayout class='monospaced'>
+     TEMPLATECONF=<replaceable>your_layer</replaceable>/conf
+            </literallayout>
+            Once the build process gets the sample file, it uses
+            <filename>sed</filename> to substitute final
+            <filename>${</filename><link linkend='var-OEROOT'><filename>OEROOT</filename></link><filename>}</filename>
+            values for all <filename>##OEROOT##</filename> values.
+            <note>
+                You can see how the <filename>TEMPLATECONF</filename> variable
+                is used by looking at the
+                <filename>scripts/oe-setup-builddir</filename> script in the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                You can find the Yocto Project version of the
+                <filename>local.conf.sample</filename> file in the
+                <filename>meta-yocto/conf</filename> directory.
+            </note>
+        </para>
+    </section>
+
+    <section id='structure-build-conf-bblayers.conf'>
+        <title><filename>build/conf/bblayers.conf</filename></title>
+
+        <para>
+            This configuration file defines
+            <ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>layers</ulink>,
+            which are directory trees, traversed (or walked) by BitBake.
+            The <filename>bblayers.conf</filename> file uses the
+            <link linkend='var-BBLAYERS'><filename>BBLAYERS</filename></link>
+            variable to list the layers BitBake tries to find, and uses the
+            <link linkend='var-BBLAYERS_NON_REMOVABLE'><filename>BBLAYERS_NON_REMOVABLE</filename></link>
+            variable to list layers that must not be removed.
+        </para>
+
+        <para>
+            If <filename>bblayers.conf</filename> is not present when you
+            start the build, the OpenEmbedded build system creates it from
+            <filename>bblayers.conf.sample</filename> when
+            you <filename>source</filename> the top-level build environment
+            setup script (i.e.
+            <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+            or
+            <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
+        </para>
+
+        <para>
+            The source <filename>bblayers.conf.sample</filename> file used
+            depends on the <filename>$TEMPLATECONF</filename> script variable,
+            which defaults to <filename>meta-yocto/conf</filename>
+            when you are building from the Yocto Project development
+            environment and defaults to <filename>meta/conf</filename> when
+            you are building from the OpenEmbedded Core environment.
+            Because the script variable points to the source of the
+            <filename>bblayers.conf.sample</filename> file, this implies that
+            you can base your build from any layer by setting the variable in
+            the top-level build environment setup script as follows:
+            <literallayout class='monospaced'>
+     TEMPLATECONF=<replaceable>your_layer</replaceable>/conf
+            </literallayout>
+            Once the build process gets the sample file, it uses
+            <filename>sed</filename> to substitute final
+            <filename>${</filename><link linkend='var-OEROOT'><filename>OEROOT</filename></link><filename>}</filename>
+            values for all <filename>##OEROOT##</filename> values.
+            <note>
+                You can see how the <filename>TEMPLATECONF</filename> variable
+                <filename>scripts/oe-setup-builddir</filename> script in the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                You can find the Yocto Project version of the
+                <filename>bblayers.conf.sample</filename> file in the
+                <filename>meta-yocto/conf</filename> directory.
+            </note>
+        </para>
+    </section>
+
+    <section id='structure-build-conf-sanity_info'>
+        <title><filename>build/conf/sanity_info</filename></title>
+
+        <para>
+            This file indicates the state of the sanity checks and is created
+            during the build.
+        </para>
+    </section>
+
+    <section id='structure-build-downloads'>
+        <title><filename>build/downloads/</filename></title>
+
+        <para>
+            This directory contains downloaded upstream source tarballs.
+            You can reuse the directory for multiple builds or move
+            the directory to another location.
+            You can control the location of this directory through the
+            <filename><link linkend='var-DL_DIR'>DL_DIR</link></filename> variable.
+        </para>
+    </section>
+
+    <section id='structure-build-sstate-cache'>
+        <title><filename>build/sstate-cache/</filename></title>
+
+        <para>
+            This directory contains the shared state cache.
+            You can reuse the directory for multiple builds or move
+            the directory to another location.
+            You can control the location of this directory through the
+            <filename><link linkend='var-SSTATE_DIR'>SSTATE_DIR</link></filename> variable.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp'>
+        <title><filename>build/tmp/</filename></title>
+
+        <para>
+            The OpenEmbedded build system creates and uses this directory
+            for all the build system's output.
+            The
+            <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
+            variable points to this directory.
+        </para>
+
+        <para>
+            BitBake creates this directory if it does not exist.
+            As a last resort, to clean up a build and start it from scratch
+            (other than the downloads), you can remove everything in the
+            <filename>tmp</filename> directory or get rid of the
+            directory completely.
+            If you do, you should also completely remove the
+            <filename>build/sstate-cache</filename> directory.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-buildstats'>
+        <title><filename>build/tmp/buildstats/</filename></title>
+
+        <para>
+            This directory stores the build statistics.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-cache'>
+        <title><filename>build/tmp/cache/</filename></title>
+
+        <para>
+            When BitBake parses the metadata, it creates a cache file of the result that can
+            be used when subsequently running commands.
+            BitBake stores these results here on a per-machine basis.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-deploy'>
+        <title><filename>build/tmp/deploy/</filename></title>
+
+        <para>
+            This directory contains any "end result" output from the
+            OpenEmbedded build process.
+            The <link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>
+            variable points to this directory.
+            For more detail on the contents of the <filename>deploy</filename>
+            directory, see the
+            "<link linkend='images-dev-environment'>Images</link>" and
+            "<link linkend='sdk-dev-environment'>Application Development SDK</link>"
+            sections.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-deploy-deb'>
+        <title><filename>build/tmp/deploy/deb/</filename></title>
+
+        <para>
+            This directory receives any <filename>.deb</filename> packages produced by
+            the build process.
+            The packages are sorted into feeds for different architecture types.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-deploy-rpm'>
+        <title><filename>build/tmp/deploy/rpm/</filename></title>
+
+        <para>
+            This directory receives any <filename>.rpm</filename> packages produced by
+            the build process.
+            The packages are sorted into feeds for different architecture types.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-deploy-ipk'>
+        <title><filename>build/tmp/deploy/ipk/</filename></title>
+
+        <para>
+            This directory receives <filename>.ipk</filename> packages produced by
+            the build process.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-deploy-licenses'>
+        <title><filename>build/tmp/deploy/licenses/</filename></title>
+
+        <para>
+            This directory receives package licensing information.
+            For example, the directory contains sub-directories for <filename>bash</filename>,
+            <filename>busybox</filename>, and <filename>glibc</filename> (among others) that in turn
+            contain appropriate <filename>COPYING</filename> license files with other licensing information.
+            For information on licensing, see the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
+            section.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-deploy-images'>
+        <title><filename>build/tmp/deploy/images/</filename></title>
+
+        <para>
+            This directory receives complete filesystem images.
+            If you want to flash the resulting image from a build onto a device, look here for the image.
+        </para>
+
+        <para>
+            Be careful when deleting files in this directory.
+            You can safely delete old images from this directory (e.g.
+            <filename>core-image-*</filename>, <filename>hob-image-*</filename>,
+            etc.).
+            However, the kernel (<filename>*zImage*</filename>, <filename>*uImage*</filename>, etc.),
+            bootloader and other supplementary files might be deployed here prior to building an
+            image.
+            Because these files are not directly produced from the image, if you
+            delete them they will not be automatically re-created when you build the image again.
+        </para>
+
+        <para>
+            If you do accidentally delete files here, you will need to force them to be
+            re-created.
+            In order to do that, you will need to know the target that produced them.
+            For example, these commands rebuild and re-create the kernel files:
+            <literallayout class='monospaced'>
+     $ bitbake -c clean virtual/kernel
+     $ bitbake virtual/kernel
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-deploy-sdk'>
+        <title><filename>build/tmp/deploy/sdk/</filename></title>
+
+        <para>
+            The OpenEmbedded build system creates this directory to hold
+            toolchain installer scripts, which when executed, install the
+            sysroot that matches your target hardware.
+            You can find out more about these installers in the
+            "<ulink url='&YOCTO_DOCS_ADT_URL;#optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</ulink>"
+            section in the Yocto Project Application Developer's Guide.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-sstate-control'>
+        <title><filename>build/tmp/sstate-control/</filename></title>
+
+        <para>
+            The OpenEmbedded build system uses this directory for the
+            shared state manifest files.
+            The shared state code uses these files to record the files
+            installed by each sstate task so that the files can be removed
+            when cleaning the recipe or when a newer version is about to
+            be installed.
+            The build system also uses the manifests to detect and produce
+            a warning when files from one task are overwriting those from
+            another.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-sysroots'>
+        <title><filename>build/tmp/sysroots/</filename></title>
+
+        <para>
+            This directory contains shared header files and libraries as well as other shared
+            data.
+            Packages that need to share output with other packages do so within this directory.
+            The directory is subdivided by architecture so multiple builds can run within
+            the one Build Directory.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-stamps'>
+        <title><filename>build/tmp/stamps/</filename></title>
+
+        <para>
+            This directory holds information that BitBake uses for accounting purposes
+            to track what tasks have run and when they have run.
+            The directory is sub-divided by architecture, package name, and
+            version.
+            Following is an example:
+            <literallayout class='monospaced'>
+     stamps/all-poky-linux/distcc-config/1.0-r0.do_build-2fdd....2do
+            </literallayout>
+            Although the files in the directory are empty of data,
+            BitBake uses the filenames and timestamps for tracking purposes.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-log'>
+        <title><filename>build/tmp/log/</filename></title>
+
+        <para>
+            This directory contains general logs that are not otherwise placed using the
+            package's <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>.
+            Examples of logs are the output from the
+            <filename>do_check_pkg</filename> or
+            <filename>do_distro_check</filename> tasks.
+            Running a build does not necessarily mean this directory is created.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-work'>
+        <title><filename>build/tmp/work/</filename></title>
+
+        <para>
+            This directory contains architecture-specific work sub-directories
+            for packages built by BitBake.
+            All tasks execute from the appropriate work directory.
+            For example, the source for a particular package is unpacked,
+            patched, configured and compiled all within its own work directory.
+            Within the work directory, organization is based on the package group
+            and version for which the source is being compiled
+            as defined by the
+            <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
+        </para>
+
+        <para>
+            It is worth considering the structure of a typical work directory.
+            As an example, consider <filename>linux-yocto-kernel-3.0</filename>
+            on the machine <filename>qemux86</filename>
+            built within the Yocto Project.
+            For this package, a work directory of
+            <filename>tmp/work/qemux86-poky-linux/linux-yocto/3.0+git1+&lt;.....&gt;</filename>,
+            referred to as the
+            <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>, is created.
+            Within this directory, the source is unpacked to
+            <filename>linux-qemux86-standard-build</filename> and then patched by Quilt.
+            (See the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#using-a-quilt-workflow'>Using a Quilt Flow</ulink>"
+            section in the Yocto Project Development Manual for more information.)
+            Within the <filename>linux-qemux86-standard-build</filename> directory,
+            standard Quilt directories <filename>linux-3.0/patches</filename>
+            and <filename>linux-3.0/.pc</filename> are created,
+            and standard Quilt commands can be used.
+        </para>
+
+        <para>
+            There are other directories generated within <filename>WORKDIR</filename>.
+            The most important directory is <filename>WORKDIR/temp/</filename>,
+            which has log files for each task (<filename>log.do_*.pid</filename>)
+            and contains the scripts BitBake runs for each task
+            (<filename>run.do_*.pid</filename>).
+            The <filename>WORKDIR/image/</filename> directory is where "make
+            install" places its output that is then split into sub-packages
+            within <filename>WORKDIR/packages-split/</filename>.
+        </para>
+    </section>
+
+    <section id='structure-build-work-shared'>
+        <title><filename>build/tmp/work-shared/</filename></title>
+
+        <para>
+            For efficiency, the OpenEmbedded build system creates and uses
+            this directory to hold recipes that share a work directory with
+            other recipes.
+            In practice, this is only used for <filename>gcc</filename>
+            and its variants (e.g. <filename>gcc-cross</filename>,
+            <filename>libgcc</filename>, <filename>gcc-runtime</filename>,
+            and so forth).
+        </para>
+    </section>
+</section>
+
+<section id='structure-meta'>
+    <title>The Metadata - <filename>meta/</filename></title>
+
+    <para>
+        As mentioned previously,
+        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> is the core
+        of the Yocto Project.
+        Metadata has several important subdivisions:
+    </para>
+
+    <section id='structure-meta-classes'>
+        <title><filename>meta/classes/</filename></title>
+
+        <para>
+            This directory contains the <filename>*.bbclass</filename> files.
+            Class files are used to abstract common code so it can be reused by multiple
+            packages.
+            Every package inherits the <filename>base.bbclass</filename> file.
+            Examples of other important classes are <filename>autotools.bbclass</filename>, which
+            in theory allows any Autotool-enabled package to work with the Yocto Project with minimal effort.
+            Another example is <filename>kernel.bbclass</filename> that contains common code and functions
+            for working with the Linux kernel.
+            Functions like image generation or packaging also have their specific class files
+            such as <filename>image.bbclass</filename>, <filename>rootfs_*.bbclass</filename> and
+            <filename>package*.bbclass</filename>.
+        </para>
+
+        <para>
+            For reference information on classes, see the
+            "<link linkend='ref-classes'>Classes</link>" chapter.
+        </para>
+    </section>
+
+    <section id='structure-meta-conf'>
+        <title><filename>meta/conf/</filename></title>
+
+        <para>
+            This directory contains the core set of configuration files that start from
+            <filename>bitbake.conf</filename> and from which all other configuration
+            files are included.
+            See the include statements at the end of the
+            <filename>bitbake.conf</filename> file and you will note that even
+            <filename>local.conf</filename> is loaded from there.
+            While <filename>bitbake.conf</filename> sets up the defaults, you can often override
+            these by using the (<filename>local.conf</filename>) file, machine file or
+            the distribution configuration file.
+        </para>
+    </section>
+
+    <section id='structure-meta-conf-machine'>
+        <title><filename>meta/conf/machine/</filename></title>
+
+        <para>
+            This directory contains all the machine configuration files.
+            If you set <filename>MACHINE = "qemux86"</filename>,
+            the OpenEmbedded build system looks for a <filename>qemux86.conf</filename> file in this
+            directory.
+            The <filename>include</filename> directory contains various data common to multiple machines.
+            If you want to add support for a new machine to the Yocto Project, look in this directory.
+        </para>
+    </section>
+
+    <section id='structure-meta-conf-distro'>
+        <title><filename>meta/conf/distro/</filename></title>
+
+        <para>
+            The contents of this directory controls any distribution-specific
+            configurations.
+            For the Yocto Project, the <filename>defaultsetup.conf</filename> is the main file here.
+            This directory includes the versions and the
+            <filename>SRCDATE</filename> definitions for applications that are configured here.
+            An example of an alternative configuration might be <filename>poky-bleeding.conf</filename>.
+            Although this file mainly inherits its configuration from Poky.
+        </para>
+    </section>
+
+    <section id='structure-meta-conf-machine-sdk'>
+        <title><filename>meta/conf/machine-sdk/</filename></title>
+
+        <para>
+            The OpenEmbedded build system searches this directory for
+            configuration files that correspond to the value of
+            <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>.
+            By default, 32-bit and 64-bit x86 files ship with the Yocto
+            Project that support some SDK hosts.
+            However, it is possible to extend that support to other SDK hosts
+            by adding additional configuration files in this subdirectory
+            within another layer.
+        </para>
+    </section>
+
+    <section id='structure-meta-files'>
+        <title><filename>meta/files/</filename></title>
+
+        <para>
+            This directory contains common license files and several text files
+            used by the build system.
+            The text files contain minimal device information and
+            lists of files and directories with known permissions.
+        </para>
+    </section>
+
+    <section id='structure-meta-lib'>
+        <title><filename>meta/lib/</filename></title>
+
+        <para>
+            This directory contains OpenEmbedded Python library code
+            used during the build process.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-bsp'>
+        <title><filename>meta/recipes-bsp/</filename></title>
+
+        <para>
+            This directory contains anything linking to specific hardware or hardware
+            configuration information such as "u-boot" and "grub".
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-connectivity'>
+        <title><filename>meta/recipes-connectivity/</filename></title>
+
+        <para>
+            This directory contains libraries and applications related to communication with other devices.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-core'>
+        <title><filename>meta/recipes-core/</filename></title>
+
+        <para>
+            This directory contains what is needed to build a basic working Linux image
+            including commonly used dependencies.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-devtools'>
+        <title><filename>meta/recipes-devtools/</filename></title>
+
+        <para>
+            This directory contains tools that are primarily used by the build system.
+            The tools, however, can also be used on targets.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-extended'>
+        <title><filename>meta/recipes-extended/</filename></title>
+
+        <para>
+            This directory contains non-essential applications that add features compared to the
+            alternatives in core.
+            You might need this directory for full tool functionality or for Linux Standard Base (LSB)
+            compliance.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-gnome'>
+        <title><filename>meta/recipes-gnome/</filename></title>
+
+        <para>
+            This directory contains all things related to the GTK+ application framework.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-graphics'>
+        <title><filename>meta/recipes-graphics/</filename></title>
+
+        <para>
+            This directory contains X and other graphically related system libraries
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-kernel'>
+        <title><filename>meta/recipes-kernel/</filename></title>
+
+        <para>
+            This directory contains the kernel and generic applications and libraries that
+            have strong kernel dependencies.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-lsb4'>
+        <title><filename>meta/recipes-lsb4/</filename></title>
+
+        <para>
+            This directory contains recipes specifically added to support
+            the Linux Standard Base (LSB) version 4.x.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-multimedia'>
+        <title><filename>meta/recipes-multimedia/</filename></title>
+
+        <para>
+            This directory contains codecs and support utilities for audio, images and video.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-qt'>
+        <title><filename>meta/recipes-qt/</filename></title>
+
+        <para>
+            This directory contains all things related to the Qt application framework.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-rt'>
+        <title><filename>meta/recipes-rt/</filename></title>
+
+        <para>
+            This directory contains package and image recipes for using and testing
+            the <filename>PREEMPT_RT</filename> kernel.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-sato'>
+        <title><filename>meta/recipes-sato/</filename></title>
+
+        <para>
+            This directory contains the Sato demo/reference UI/UX and its associated applications
+            and configuration data.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-support'>
+        <title><filename>meta/recipes-support/</filename></title>
+
+        <para>
+            This directory contains recipes used by other recipes, but that are
+            not directly included in images (i.e. dependencies of other
+            recipes).
+        </para>
+    </section>
+
+    <section id='structure-meta-site'>
+        <title><filename>meta/site/</filename></title>
+
+        <para>
+            This directory contains a list of cached results for various architectures.
+            Because certain "autoconf" test results cannot be determined when cross-compiling due to
+            the tests not able to run on a live system, the information in this directory is
+            passed to "autoconf" for the various architectures.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-txt'>
+        <title><filename>meta/recipes.txt</filename></title>
+
+        <para>
+            This file is a description of the contents of <filename>recipes-*</filename>.
+        </para>
+    </section>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/ref-style.css b/documentation/ref-manual/ref-style.css
new file mode 100644
index 0000000000..e04b5006b4
--- /dev/null
+++ b/documentation/ref-manual/ref-style.css
@@ -0,0 +1,985 @@
+/*
+   Generic XHTML / DocBook XHTML CSS Stylesheet.
+
+   Browser wrangling and typographic design by
+      Oyvind Kolas / pippin@gimp.org
+
+   Customised for Poky by
+      Matthew Allum / mallum@o-hand.com
+
+   Thanks to:
+     Liam R. E. Quin
+     William Skaggs
+     Jakub Steiner
+
+   Structure
+   ---------
+
+   The stylesheet is divided into the following sections:
+
+       Positioning
+          Margins, paddings, width, font-size, clearing.
+       Decorations
+          Borders, style
+       Colors
+          Colors
+       Graphics
+          Graphical backgrounds
+       Nasty IE tweaks
+          Workarounds needed to make it work in internet explorer,
+          currently makes the stylesheet non validating, but up until
+          this point it is validating.
+       Mozilla extensions
+          Transparency for footer
+          Rounded corners on boxes
+
+*/
+
+
+  /*************** /
+ /  Positioning   /
+/ ***************/
+
+body {
+  font-family: Verdana, Sans, sans-serif;
+
+  min-width: 640px;
+  width: 80%;
+  margin:  0em auto;
+  padding: 2em 5em 5em 5em;
+  color: #333;
+}
+
+h1,h2,h3,h4,h5,h6,h7 {
+  font-family: Arial, Sans;
+  color: #00557D;
+  clear: both;
+}
+
+h1 {
+  font-size: 2em;
+  text-align: left;
+  padding: 0em 0em 0em 0em;
+  margin: 2em 0em 0em 0em;
+}
+
+h2.subtitle {
+  margin: 0.10em 0em 3.0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 1.8em;
+  padding-left: 20%;
+  font-weight: normal;
+  font-style: italic;
+}
+
+h2 {
+  margin: 2em 0em 0.66em 0em;
+  padding: 0.5em 0em 0em 0em;
+  font-size: 1.5em;
+  font-weight: bold;
+}
+
+h3.subtitle {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 142.14%;
+  text-align: right;
+}
+
+h3 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 140%;
+  font-weight: bold;
+}
+
+h4 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 120%;
+  font-weight: bold;
+}
+
+h5 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+h6 {
+  margin: 1em 0em 0em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+.authorgroup {
+  background-color: transparent;
+  background-repeat: no-repeat;
+  padding-top: 256px;
+  background-image: url("figures/poky-title.png");
+  background-position: left top;
+  margin-top: -256px;
+  padding-right: 50px;
+  margin-left: 0px;
+  text-align: right;
+  width: 740px;
+}
+
+h3.author {
+  margin: 0em 0me 0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-weight: normal;
+  font-size: 100%;
+  color: #333;
+  clear: both;
+}
+
+.author tt.email {
+  font-size: 66%;
+}
+
+.titlepage hr {
+  width: 0em;
+  clear: both;
+}
+
+.revhistory {
+  padding-top: 2em;
+  clear: both;
+}
+
+.toc,
+.list-of-tables,
+.list-of-examples,
+.list-of-figures {
+  padding: 1.33em 0em 2.5em 0em;
+  color: #00557D;
+}
+
+.toc p,
+.list-of-tables p,
+.list-of-figures p,
+.list-of-examples p {
+  padding: 0em 0em 0em 0em;
+  padding: 0em 0em 0.3em;
+  margin: 1.5em 0em 0em 0em;
+}
+
+.toc p b,
+.list-of-tables p b,
+.list-of-figures p b,
+.list-of-examples p b{
+  font-size: 100.0%;
+  font-weight: bold;
+}
+
+.toc dl,
+.list-of-tables dl,
+.list-of-figures dl,
+.list-of-examples dl {
+  margin: 0em 0em 0.5em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dt {
+  margin: 0em 0em 0em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dd {
+  margin: 0em 0em 0em 2.6em;
+  padding: 0em 0em 0em 0em;
+}
+
+div.glossary dl,
+div.variablelist dl {
+}
+
+.glossary dl dt,
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  font-weight: normal;
+  width: 20em;
+  text-align: right;
+}
+
+.variablelist dl dt {
+  margin-top: 0.5em;
+}
+
+.glossary dl dd,
+.variablelist dl dd {
+  margin-top: -1em;
+  margin-left: 25.5em;
+}
+
+.glossary dd p,
+.variablelist dd p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+
+div.calloutlist table td {
+  padding: 0em 0em 0em 0em;
+  margin: 0em 0em 0em 0em;
+}
+
+div.calloutlist table td p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+div p.copyright {
+  text-align: left;
+}
+
+div.legalnotice p.legalnotice-title {
+  margin-bottom: 0em;
+}
+
+p {
+  line-height: 1.5em;
+  margin-top: 0em;
+
+}
+
+dl {
+  padding-top: 0em;
+}
+
+hr {
+  border: solid 1px;
+}
+
+
+.mediaobject,
+.mediaobjectco {
+  text-align: center;
+}
+
+img {
+  border: none;
+}
+
+ul {
+  padding: 0em 0em 0em 1.5em;
+}
+
+ul li {
+  padding: 0em 0em 0em 0em;
+}
+
+ul li p {
+  text-align: left;
+}
+
+table {
+  width :100%;
+}
+
+th {
+  padding: 0.25em;
+  text-align: left;
+  font-weight: normal;
+  vertical-align: top;
+}
+
+td {
+  padding: 0.25em;
+  vertical-align: top;
+}
+
+p a[id] {
+  margin: 0px;
+  padding: 0px;
+  display: inline;
+  background-image: none;
+}
+
+a {
+  text-decoration: underline;
+  color: #444;
+}
+
+pre {
+    overflow: auto;
+}
+
+a:hover {
+  text-decoration: underline;
+  /*font-weight: bold;*/
+}
+
+/* This style defines how the permalink character
+   appears by itself and when hovered over with
+   the mouse. */
+
+[alt='Permalink'] { color: #eee; }
+[alt='Permalink']:hover { color: black; }
+
+
+div.informalfigure,
+div.informalexample,
+div.informaltable,
+div.figure,
+div.table,
+div.example {
+  margin: 1em 0em;
+  padding: 1em;
+  page-break-inside: avoid;
+}
+
+
+div.informalfigure p.title b,
+div.informalexample p.title b,
+div.informaltable p.title b,
+div.figure p.title b,
+div.example p.title b,
+div.table p.title b{
+    padding-top: 0em;
+    margin-top: 0em;
+    font-size: 100%;
+    font-weight: normal;
+}
+
+.mediaobject .caption,
+.mediaobject .caption p  {
+  text-align: center;
+  font-size: 80%;
+  padding-top: 0.5em;
+  padding-bottom: 0.5em;
+}
+
+.epigraph {
+  padding-left: 55%;
+  margin-bottom: 1em;
+}
+
+.epigraph p {
+  text-align: left;
+}
+
+.epigraph .quote {
+  font-style: italic;
+}
+.epigraph .attribution {
+  font-style: normal;
+  text-align: right;
+}
+
+span.application {
+  font-style: italic;
+}
+
+.programlisting {
+  font-family: monospace;
+  font-size: 80%;
+  white-space: pre;
+  margin: 1.33em 0em;
+  padding: 1.33em;
+}
+
+.tip,
+.warning,
+.caution,
+.note {
+  margin-top: 1em;
+  margin-bottom: 1em;
+
+}
+
+/* force full width of table within div */
+.tip table,
+.warning table,
+.caution table,
+.note table {
+  border: none;
+  width: 100%;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  padding: 0.8em 0.0em 0.0em 0.0em;
+  margin : 0em 0em 0em 0em;
+}
+
+.tip p,
+.warning p,
+.caution p,
+.note p {
+  margin-top: 0.5em;
+  margin-bottom: 0.5em;
+  padding-right: 1em;
+  text-align: left;
+}
+
+.acronym {
+  text-transform: uppercase;
+}
+
+b.keycap,
+.keycap {
+  padding: 0.09em 0.3em;
+  margin: 0em;
+}
+
+.itemizedlist li {
+  clear: none;
+}
+
+.filename {
+  font-size: medium;
+  font-family: Courier, monospace;
+}
+
+
+div.navheader, div.heading{
+  position: absolute;
+  left: 0em;
+  top: 0em;
+  width: 100%;
+  background-color: #cdf;
+  width: 100%;
+}
+
+div.navfooter, div.footing{
+  position: fixed;
+  left: 0em;
+  bottom: 0em;
+  background-color: #eee;
+  width: 100%;
+}
+
+
+div.navheader td,
+div.navfooter td {
+  font-size: 66%;
+}
+
+div.navheader table th {
+  /*font-family: Georgia, Times, serif;*/
+  /*font-size: x-large;*/
+  font-size: 80%;
+}
+
+div.navheader table {
+  border-left: 0em;
+  border-right: 0em;
+  border-top: 0em;
+  width: 100%;
+}
+
+div.navfooter table {
+  border-left: 0em;
+  border-right: 0em;
+  border-bottom: 0em;
+  width: 100%;
+}
+
+div.navheader table td a,
+div.navfooter table td a {
+  color: #777;
+  text-decoration: none;
+}
+
+/* normal text in the footer */
+div.navfooter table td {
+  color: black;
+}
+
+div.navheader table td a:visited,
+div.navfooter table td a:visited {
+  color: #444;
+}
+
+
+/* links in header and footer */
+div.navheader table td a:hover,
+div.navfooter table td a:hover {
+  text-decoration: underline;
+  background-color: transparent;
+  color: #33a;
+}
+
+div.navheader hr,
+div.navfooter hr {
+  display: none;
+}
+
+
+.qandaset tr.question td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.qandaset tr.answer td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+.answer td {
+  padding-bottom: 1.5em;
+}
+
+.emphasis {
+  font-weight: bold;
+}
+
+
+  /************* /
+ / decorations  /
+/ *************/
+
+.titlepage {
+}
+
+.part .title {
+}
+
+.subtitle {
+    border: none;
+}
+
+/*
+h1 {
+  border: none;
+}
+
+h2 {
+  border-top: solid 0.2em;
+  border-bottom: solid 0.06em;
+}
+
+h3 {
+  border-top: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h4 {
+  border: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h5 {
+  border: 0em;
+}
+*/
+
+.programlisting {
+  border: solid 1px;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example {
+  border: 1px solid;
+}
+
+
+
+.tip,
+.warning,
+.caution,
+.note {
+  border: 1px solid;
+}
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom: 1px solid;
+}
+
+.question td {
+  border-top: 1px solid black;
+}
+
+.answer {
+}
+
+
+b.keycap,
+.keycap {
+  border: 1px solid;
+}
+
+
+div.navheader, div.heading{
+  border-bottom: 1px solid;
+}
+
+
+div.navfooter, div.footing{
+  border-top: 1px solid;
+}
+
+  /********* /
+ /  colors  /
+/ *********/
+
+body {
+  color: #333;
+  background: white;
+}
+
+a {
+  background: transparent;
+}
+
+a:hover {
+  background-color: #dedede;
+}
+
+
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7,
+h8 {
+  background-color: transparent;
+}
+
+hr {
+  border-color: #aaa;
+}
+
+
+.tip, .warning, .caution, .note {
+  border-color: #fff;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom-color: #fff;
+}
+
+
+.warning {
+  background-color: #f0f0f2;
+}
+
+.caution {
+  background-color: #f0f0f2;
+}
+
+.tip {
+  background-color: #f0f0f2;
+}
+
+.note {
+  background-color: #f0f0f2;
+}
+
+.glossary dl dt,
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  color: #044;
+}
+
+div.figure,
+div.table,
+div.example,
+div.informalfigure,
+div.informaltable,
+div.informalexample {
+  border-color: #aaa;
+}
+
+pre.programlisting {
+  color: black;
+  background-color: #fff;
+  border-color: #aaa;
+  border-width: 2px;
+}
+
+.guimenu,
+.guilabel,
+.guimenuitem {
+  background-color: #eee;
+}
+
+
+b.keycap,
+.keycap {
+  background-color: #eee;
+  border-color: #999;
+}
+
+
+div.navheader {
+  border-color: black;
+}
+
+
+div.navfooter {
+  border-color: black;
+}
+
+
+  /*********** /
+ /  graphics  /
+/ ***********/
+
+/*
+body {
+  background-image: url("images/body_bg.jpg");
+  background-attachment: fixed;
+}
+
+.navheader,
+.note,
+.tip {
+  background-image: url("images/note_bg.jpg");
+  background-attachment: fixed;
+}
+
+.warning,
+.caution {
+  background-image: url("images/warning_bg.jpg");
+  background-attachment: fixed;
+}
+
+.figure,
+.informalfigure,
+.example,
+.informalexample,
+.table,
+.informaltable {
+  background-image: url("images/figure_bg.jpg");
+  background-attachment: fixed;
+}
+
+*/
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7{
+}
+
+/*
+Example of how to stick an image as part of the title.
+
+div.article .titlepage .title
+{
+  background-image: url("figures/white-on-black.png");
+  background-position: center;
+  background-repeat: repeat-x;
+}
+*/
+
+div.preface .titlepage .title,
+div.colophon .title,
+div.chapter .titlepage .title,
+div.article .titlepage .title
+{
+}
+
+div.section div.section .titlepage .title,
+div.sect2 .titlepage .title {
+    background: none;
+}
+
+
+h1.title {
+  background-color: transparent;
+  background-image: url("figures/poky-title.png");
+  background-repeat: no-repeat;
+  height: 256px;
+  text-indent: -9000px;
+  overflow:hidden;
+}
+
+h2.subtitle {
+  background-color: transparent;
+  text-indent: -9000px;
+  overflow:hidden;
+  width: 0px;
+  display: none;
+}
+
+  /*************************************** /
+ /  pippin.gimp.org specific alterations  /
+/ ***************************************/
+
+/*
+div.heading, div.navheader {
+  color: #777;
+  font-size: 80%;
+  padding: 0;
+  margin: 0;
+  text-align: left;
+  position: absolute;
+  top: 0px;
+  left: 0px;
+  width: 100%;
+  height: 50px;
+  background: url('/gfx/heading_bg.png') transparent;
+  background-repeat: repeat-x;
+  background-attachment: fixed;
+  border: none;
+}
+
+div.heading a {
+  color: #444;
+}
+
+div.footing, div.navfooter {
+  border: none;
+  color: #ddd;
+  font-size: 80%;
+  text-align:right;
+
+  width: 100%;
+  padding-top: 10px;
+  position: absolute;
+  bottom: 0px;
+  left: 0px;
+
+  background: url('/gfx/footing_bg.png') transparent;
+}
+*/
+
+
+
+  /****************** /
+ /  nasty ie tweaks  /
+/ ******************/
+
+/*
+div.heading, div.navheader {
+  width:expression(document.body.clientWidth + "px");
+}
+
+div.footing, div.navfooter {
+  width:expression(document.body.clientWidth + "px");
+  margin-left:expression("-5em");
+}
+body {
+  padding:expression("4em 5em 0em 5em");
+}
+*/
+
+  /**************************************** /
+ / mozilla vendor specific css extensions  /
+/ ****************************************/
+/*
+div.navfooter, div.footing{
+  -moz-opacity: 0.8em;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example,
+.tip,
+.warning,
+.caution,
+.note {
+  -moz-border-radius: 0.5em;
+}
+
+b.keycap,
+.keycap {
+  -moz-border-radius: 0.3em;
+}
+*/
+
+table tr td table tr td {
+  display: none;
+}
+
+
+hr {
+  display: none;
+}
+
+table {
+  border: 0em;
+}
+
+ .photo {
+  float: right;
+  margin-left:   1.5em;
+  margin-bottom: 1.5em;
+  margin-top: 0em;
+  max-width:      17em;
+  border:     1px solid gray;
+  padding:    3px;
+  background: white;
+}
+ .seperator {
+   padding-top: 2em;
+   clear: both;
+  }
+
+  #validators {
+      margin-top: 5em;
+      text-align: right;
+      color: #777;
+  }
+  @media print {
+      body {
+          font-size: 8pt;
+      }
+      .noprint {
+          display: none;
+      }
+  }
+
+
+.tip,
+.note {
+   background: #f0f0f2;
+   color: #333;
+   padding: 20px;
+   margin: 20px;
+}
+
+.tip h3,
+.note h3 {
+   padding: 0em;
+   margin: 0em;
+   font-size: 2em;
+   font-weight: bold;
+   color: #333;
+}
+
+.tip a,
+.note a {
+   color: #333;
+   text-decoration: underline;
+}
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
diff --git a/documentation/ref-manual/ref-tasks.xml b/documentation/ref-manual/ref-tasks.xml
new file mode 100644
index 0000000000..f325f0e233
--- /dev/null
+++ b/documentation/ref-manual/ref-tasks.xml
@@ -0,0 +1,695 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='ref-tasks'>
+<title>Tasks</title>
+
+<para>
+    Tasks are units of execution for BitBake.
+    Recipes (<filename>.bb</filename> files) use tasks to complete
+    configuring, compiling, and packaging software.
+    This chapter provides a reference of the tasks defined in the
+    OpenEmbedded build system.
+</para>
+
+<section id='normal-recipe-build-tasks'>
+    <title>Normal Recipe Build Tasks</title>
+
+    <para>
+        The following sections describe normal tasks associated with building
+        a recipe.
+    </para>
+
+    <section id='ref-tasks-build'>
+        <title><filename>do_build</filename></title>
+
+        <para>
+            The default task for all recipes.
+            This task depends on all other normal tasks
+            required to build a recipe.
+        </para>
+    </section>
+
+    <section id='ref-tasks-compile'>
+        <title><filename>do_compile</filename></title>
+
+        <para>
+            Compiles the source in the compilation directory, which is pointed
+            to by the
+            <link linkend='var-B'><filename>B</filename></link> variable.
+        </para>
+    </section>
+
+    <section id='ref-tasks-compile_ptest_base'>
+        <title><filename>do_compile_ptest_base</filename></title>
+
+        <para>
+            Compiles the runtime test suite included in the software being
+            built.
+        </para>
+    </section>
+
+    <section id='ref-tasks-configure'>
+        <title><filename>do_configure</filename></title>
+
+        <para>
+            Configures the source by enabling and disabling any build-time and
+            configuration options for the software being built.
+        </para>
+    </section>
+
+    <section id='ref-tasks-configure_ptest_base'>
+        <title><filename>do_configure_ptest_base</filename></title>
+
+        <para>
+            Configures the runtime test suite included in the software being
+            built.
+        </para>
+    </section>
+
+    <section id='ref-tasks-deploy'>
+        <title><filename>do_deploy</filename></title>
+
+        <para>
+            Writes output files that are to be deployed to the deploy
+            directory, which is defined by the
+            <link linkend='var-DEPLOYDIR'><filename>DEPLOYDIR</filename></link>
+            variable.
+        </para>
+
+        <para>
+            The <filename>do_deploy</filename> task is a
+            shared state (sstate) task, which means that the task can
+            be accelerated through sstate use.
+            Realize also that if the task is re-executed, any previous output
+            is removed (i.e. "cleaned").
+        </para>
+    </section>
+
+    <section id='ref-tasks-fetch'>
+        <title><filename>do_fetch</filename></title>
+
+        <para>
+            Fetches the source code.
+            This task uses the
+            <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+            variable and the argument's prefix to determine the correct
+            fetcher module.
+        </para>
+    </section>
+
+    <section id='ref-tasks-install'>
+        <title><filename>do_install</filename></title>
+
+        <para>
+            Copies files from the compilation directory, which is defined by
+            the
+            <link linkend='var-B'><filename>B</filename></link> variable,
+            to a holding area defined by the
+            <link linkend='var-D'><filename>D</filename></link> variable.
+        </para>
+    </section>
+
+    <section id='ref-tasks-install_ptest_base'>
+        <title><filename>do_install_ptest_base</filename></title>
+
+        <para>
+            Copies the runtime test suite files from the compilation directory
+            to a holding area.
+        </para>
+    </section>
+
+    <section id='ref-tasks-package'>
+        <title><filename>do_package</filename></title>
+
+        <para>
+            Analyzes the content of the holding area and splits it into subsets
+            based on available packages and files.
+        </para>
+    </section>
+
+    <section id='ref-tasks-package_qa'>
+        <title><filename>do_package_qa</filename></title>
+
+        <para>
+            Runs QA checks on packaged files.
+            For more information on these checks, see the
+            <link linkend='ref-classes-insane'><filename>insane</filename></link>
+            class.
+        </para>
+    </section>
+
+    <section id='ref-tasks-package_write_deb'>
+        <title><filename>do_package_write_deb</filename></title>
+
+        <para>
+            Creates the actual DEB packages and places them in the
+            <link linkend='package-feeds-dev-environment'>Package Feeds</link>
+            area.
+        </para>
+    </section>
+
+    <section id='ref-tasks-package_write_ipk'>
+        <title><filename>do_package_write_ipk</filename></title>
+
+        <para>
+            Creates the actual IPK packages and places them in the
+            <link linkend='package-feeds-dev-environment'>Package Feeds</link>
+            area.
+        </para>
+    </section>
+
+    <section id='ref-tasks-package_write_rpm'>
+        <title><filename>do_package_write_rpm</filename></title>
+
+        <para>
+            Creates the actual RPM packages and places them in the
+            <link linkend='package-feeds-dev-environment'>Package Feeds</link>
+            area.
+        </para>
+    </section>
+
+    <section id='ref-tasks-package_write_tar'>
+        <title><filename>do_package_write_tar</filename></title>
+
+        <para>
+            Creates tar archives for packages and places them in the
+            <link linkend='package-feeds-dev-environment'>Package Feeds</link>
+            area.
+        </para>
+    </section>
+
+    <section id='ref-tasks-packagedata'>
+        <title><filename>do_packagedata</filename></title>
+
+        <para>
+            Creates package metadata used by the build system to generate the
+            final packages.
+        </para>
+    </section>
+
+    <section id='ref-tasks-patch'>
+        <title><filename>do_patch</filename></title>
+
+        <para>
+            Locates patch files and applies them to the source code.
+            See the
+            "<link linkend='patching-dev-environment'>Patching</link>"
+            section for more information.
+        </para>
+    </section>
+
+    <section id='ref-tasks-populate_lic'>
+        <title><filename>do_populate_lic</filename></title>
+
+        <para>
+            Writes license information for the recipe that is collected later
+            when the image is constructed.
+        </para>
+    </section>
+
+    <section id='ref-tasks-populate_sdk'>
+        <title><filename>do_populate_sdk</filename></title>
+
+        <para>
+            Creates the file and directory structure for an installable SDK.
+            See the
+            "<link linkend='sdk-generation-dev-environment'>SDK Generation</link>"
+            section for more information.
+        </para>
+    </section>
+
+    <section id='ref-tasks-populate_sysroot'>
+        <title><filename>do_populate_sysroot</filename></title>
+
+        <para>
+            Copies a subset of files installed by the
+            <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+            task into the sysroot in order to make them available to other
+            recipes.
+        </para>
+
+        <para>
+            The <filename>do_populate_sysroot</filename> task is a
+            shared state (sstate) task, which means that the task can
+            be accelerated through sstate use.
+            Realize also that if the task is re-executed, any previous output
+            is removed (i.e. "cleaned").
+        </para>
+    </section>
+
+    <section id='ref-tasks-rm_work'>
+        <title><filename>do_rm_work</filename></title>
+
+        <para>
+            Removes work files after the OpenEmbedded build system has
+            finished with them.
+            You can learn more by looking at the
+            "<link linkend='ref-classes-rm-work'><filename>rm_work.bbclass</filename></link>"
+            section.
+        </para>
+    </section>
+
+    <section id='ref-tasks-rm_work_all'>
+        <title><filename>do_rm_work_all</filename></title>
+
+        <para>
+            Top-level task for removing work files after the build system has
+            finished with them.
+        </para>
+    </section>
+
+    <section id='ref-tasks-unpack'>
+        <title><filename>do_unpack</filename></title>
+
+        <para>
+            Unpacks the source code into a working directory pointed to
+            by
+            <filename>${</filename><link linkend='var-WORKDIR'><filename>WORKDIR</filename></link><filename>}</filename>.
+            The
+            <link linkend='var-S'><filename>S</filename></link> variable also
+            plays a role in where unpacked source files ultimately reside.
+            For more information on how source files are unpacked, see the
+            "<link linkend='source-fetching-dev-environment'>Source Fetching</link>"
+            section and the <filename>WORKDIR</filename> and
+            <filename>S</filename> variable descriptions.
+        </para>
+    </section>
+</section>
+
+<section id='manually-called-tasks'>
+    <title>Manually Called Tasks</title>
+
+    <para>
+        These tasks are typically manually triggered (e.g. by using the
+        <filename>bitbake -c</filename> command-line option):
+    </para>
+
+    <section id='ref-tasks-checkuri'>
+        <title><filename>do_checkuri</filename></title>
+
+        <para>
+            Validates the
+            <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+            value.
+        </para>
+    </section>
+
+    <section id='ref-tasks-checkuriall'>
+        <title><filename>do_checkuriall</filename></title>
+
+        <para>
+            Validates the
+            <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+            value for all recipes required to build a target.
+        </para>
+    </section>
+
+    <section id='ref-tasks-clean'>
+        <title><filename>do_clean</filename></title>
+
+        <para>
+            Removes all output files for a target from the
+            <link linkend='ref-tasks-unpack'><filename>do_unpack</filename></link>
+            task forward (i.e.
+            <link linkend='ref-tasks-patch'><filename>do_unpack</filename></link>,
+            <link linkend='ref-tasks-configure'><filename>do_configure</filename></link>,
+            <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>,
+            <link linkend='ref-tasks-install'><filename>do_install</filename></link>,
+            and
+            <link linkend='ref-tasks-package'><filename>do_package</filename></link>).
+        </para>
+
+        <para>
+            You can run this task using BitBake as follows:
+            <literallayout class='monospaced'>
+     $ bitbake -c clean <replaceable>recipe</replaceable>
+            </literallayout>
+        </para>
+
+        <para>
+            Running this task does not remove the
+            <link linkend='shared-state-cache'>sstate</link>) cache
+            files.
+            Consequently, if no changes have been made and the recipe is
+            rebuilt after cleaning, output files are simply restored from the
+            sstate cache.
+            If you want to remove the sstate cache files for the recipe,
+            you need to use the
+            <link linkend='ref-tasks-cleansstate'><filename>do_cleansstate</filename></link>
+            task instead (i.e. <filename>bitbake -c cleansstate</filename> <replaceable>recipe</replaceable>).
+        </para>
+    </section>
+
+    <section id='ref-tasks-cleanall'>
+        <title><filename>do_cleanall</filename></title>
+
+        <para>
+            Removes all output files, shared state
+            (<link linkend='shared-state-cache'>sstate</link>) cache, and
+            downloaded source files for a target (i.e. the contents of
+            <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>).
+            Essentially, the <filename>do_cleanall</filename> task is
+            identical to the
+            <link linkend='ref-tasks-cleansstate'><filename>do_cleansstate</filename></link>
+            task with the added removal of downloaded source files.
+        </para>
+
+        <para>
+            You can run this task using BitBake as follows:
+            <literallayout class='monospaced'>
+     $ bitbake -c cleanall <replaceable>recipe</replaceable>
+            </literallayout>
+        </para>
+
+        <para>
+            Typically, you would not normally use the
+            <filename>cleanall</filename> task.
+            Do so only if you want to start fresh with the
+            <link linkend='ref-tasks-fetch'><filename>do_fetch</filename></link>
+            task.
+        </para>
+    </section>
+
+    <section id='ref-tasks-cleansstate'>
+        <title><filename>do_cleansstate</filename></title>
+
+        <para>
+            Removes all output files and shared state
+            (<link linkend='shared-state-cache'>sstate</link>)
+            cache for a target.
+            Essentially, the <filename>do_cleansstate</filename> task is
+            identical to the
+            <link linkend='ref-tasks-clean'><filename>do_clean</filename></link>
+            task with the added removal of shared state
+            (<link linkend='shared-state-cache'>sstate</link>) cache.
+        </para>
+
+        <para>
+            You can run this task using BitBake as follows:
+            <literallayout class='monospaced'>
+     $ bitbake -c cleansstate <replaceable>recipe</replaceable>
+            </literallayout>
+        </para>
+
+        <para>
+            When you run the <filename>do_cleansstate</filename> task,
+            the OpenEmbedded build system no longer uses any
+            sstate.
+            Consequently, building the recipe from scratch is guaranteed.
+            <note>
+                The <filename>do_cleansstate</filename> task cannot remove
+                sstate from a remote sstate mirror.
+                If you need to build a target from scratch using remote
+                mirrors, use the "-f" option as follows:
+                <literallayout class='monospaced'>
+     $ bitbake -f -c do_cleansstate <replaceable>target</replaceable>
+                </literallayout>
+            </note>
+        </para>
+     </section>
+
+    <section id='ref-tasks-devshell'>
+        <title><filename>do_devshell</filename></title>
+
+        <para>
+            Starts a shell whose environment is set up for
+            development, debugging, or both.
+            See the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-devshell'>Using a Development Shell</ulink>"
+            section in the Yocto Project Development Manual for more
+            information about using <filename>devshell</filename>.
+        </para>
+    </section>
+
+    <section id='ref-tasks-fetchall'>
+        <title><filename>do_fetchall</filename></title>
+
+        <para>
+            Fetches all remote sources required to build a target.
+        </para>
+    </section>
+
+    <section id='ref-tasks-listtasks'>
+        <title><filename>do_listtasks</filename></title>
+
+        <para>
+            Lists all defined tasks for a target.
+        </para>
+    </section>
+
+    <section id='ref-tasks-package_index'>
+        <title><filename>do_package_index</filename></title>
+
+        <para>
+            Creates or updates the index in the
+            <link linkend='package-feeds-dev-environment'>Package Feeds</link>
+            area.
+            <note>
+                This task is not triggered with the
+                <filename>bitbake -c</filename> command-line option as
+                are the other tasks in this section.
+                Because this task is specifically for the
+                <filename>package-index</filename> recipe,
+                you run it using
+                <filename>bitbake package-index</filename>.
+            </note>
+        </para>
+    </section>
+</section>
+
+<section id='image-related-tasks'>
+    <title>Image-Related Tasks</title>
+
+    <para>
+        The following tasks are applicable to image recipes.
+    </para>
+
+    <section id='ref-tasks-bootimg'>
+        <title><filename>do_bootimg</filename></title>
+
+        <para>
+            Creates a bootable live image.
+            See the
+            <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
+            variable for additional information on live image types.
+        </para>
+    </section>
+
+    <section id='ref-tasks-bundle_initramfs'>
+        <title><filename>do_bundle_initramfs</filename></title>
+
+        <para>
+            Combines an initial RAM disk (initramfs) image and kernel
+            together to form a single image.
+            The
+            <link linkend='var-CONFIG_INITRAMFS_SOURCE'><filename>CONFIG_INITRAMFS_SOURCE</filename></link>
+            variable has some more information about these types of images.
+        </para>
+    </section>
+
+    <section id='ref-tasks-rootfs'>
+        <title><filename>do_rootfs</filename></title>
+
+        <para>
+            Creates the root filesystem (file and directory structure) for an
+            image.
+            See the
+            "<link linkend='image-generation-dev-environment'>Image Generation</link>"
+            section for more information on how the root filesystem is created.
+        </para>
+    </section>
+
+    <section id='ref-tasks-testimage'>
+        <title><filename>do_testimage</filename></title>
+
+        <para>
+            Boots an image and performs runtime tests within the image.
+            For information on automatically testing images, see the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
+            section in the Yocto Project Development Manual.
+        </para>
+    </section>
+
+    <section id='ref-tasks-testimage_auto'>
+        <title><filename>do_testimage_auto</filename></title>
+
+        <para>
+            Boots an image and performs runtime tests within the image
+            immediately after it has been built.
+            This task is enabled when you set
+            <link linkend='var-TEST_IMAGE'><filename>TEST_IMAGE</filename></link>
+            equal to "1".
+        </para>
+
+        <para>
+            For information on automatically testing images, see the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
+            section in the Yocto Project Development Manual.
+        </para>
+    </section>
+
+    <section id='ref-tasks-vmdkimg'>
+        <title><filename>do_vmdkimg</filename></title>
+
+        <para>
+            Creates a <filename>.vmdk</filename> image for use with
+            <ulink url='http://www.vmware.com/'>VMware</ulink>
+            and compatible virtual machine hosts.
+        </para>
+    </section>
+</section>
+
+<section id='kernel-related-tasks'>
+    <title>Kernel-Related Tasks</title>
+
+    <para>
+        The following tasks are applicable to kernel recipes.
+        Some of these tasks (e.g. the
+        <link linkend='ref-tasks-menuconfig'><filename>do_menuconfig</filename></link>
+        task) are also applicable to recipes that use
+        Linux kernel style configuration such as the BusyBox recipe.
+    </para>
+
+    <section id='ref-tasks-compile_kernelmodules'>
+        <title><filename>do_compile_kernelmodules</filename></title>
+
+        <para>
+            Compiles loadable modules for the Linux kernel.
+        </para>
+    </section>
+
+    <section id='ref-tasks-diffconfig'>
+        <title><filename>do_diffconfig</filename></title>
+
+        <para>
+            Compares the old and new config files after running the
+            <link linkend='ref-tasks-menuconfig'><filename>do_menuconfig</filename></link>
+            task for the kernel.
+        </para>
+    </section>
+
+    <section id='ref-tasks-kernel_checkout'>
+        <title><filename>do_kernel_checkout</filename></title>
+
+        <para>
+            Checks out source/meta branches for a linux-yocto style kernel.
+        </para>
+    </section>
+
+    <section id='ref-tasks-kernel_configcheck'>
+        <title><filename>do_kernel_configcheck</filename></title>
+
+        <para>
+            Validates the kernel configuration for a linux-yocto style kernel.
+        </para>
+    </section>
+
+    <section id='ref-tasks-kernel_configme'>
+        <title><filename>do_kernel_configme</filename></title>
+
+        <para>
+            Assembles the kernel configuration for a linux-yocto style kernel.
+        </para>
+    </section>
+
+    <section id='ref-tasks-kernel_link_vmlinux'>
+        <title><filename>do_kernel_link_vmlinux</filename></title>
+
+        <para>
+            Creates a symbolic link in
+            <filename>arch/$arch/boot</filename> for vmlinux kernel
+            images.
+        </para>
+    </section>
+
+    <section id='ref-tasks-menuconfig'>
+        <title><filename>do_menuconfig</filename></title>
+
+        <para>
+            Runs <filename>make menuconfig</filename> for the kernel.
+            For information on <filename>menuconfig</filename>, see the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#using-menuconfig'>Using&nbsp;&nbsp;<filename>menuconfig</filename></ulink>"
+            section in the Yocto Project Development Manual.
+        </para>
+    </section>
+
+    <section id='ref-tasks-savedefconfig'>
+        <title><filename>do_savedefconfig</filename></title>
+
+        <para>
+            Creates a minimal Linux kernel configuration file.
+        </para>
+    </section>
+
+    <section id='ref-tasks-sizecheck'>
+        <title><filename>do_sizecheck</filename></title>
+
+        <para>
+            Checks the size of the kernel image against
+            <filename>KERNEL_IMAGE_MAXSIZE</filename> when set.
+        </para>
+    </section>
+
+    <section id='ref-tasks-strip'>
+        <title><filename>do_strip</filename></title>
+
+        <para>
+            Strips unneeded sections out of the Linux kernel image.
+        </para>
+    </section>
+
+    <section id='ref-tasks-uboot_mkimage'>
+        <title><filename>do_uboot_mkimage</filename></title>
+
+        <para>
+            Creates a uImage file from the kernel for the U-Boot bootloader.
+        </para>
+    </section>
+
+    <section id='ref-tasks-validate_branches'>
+        <title><filename>do_validate_branches</filename></title>
+
+        <para>
+            Ensures that the source, metadata (or both) branches are on the
+            locations specified by their
+            <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
+            values for a linux-yocto style kernel.
+        </para>
+    </section>
+</section>
+
+<section id='miscellaneous-tasks'>
+    <title>Miscellaneous Tasks</title>
+
+    <para>
+        The following sections describe miscellaneous tasks.
+    </para>
+
+    <section id='ref-tasks-generate_qt_config_file'>
+        <title><filename>do_generate_qt_config_file</filename></title>
+
+        <para>
+            Writes a <filename>qt.conf</filename> configuration
+            file used for building a Qt-based application.
+        </para>
+    </section>
+
+    <section id='ref-tasks-spdx'>
+        <title><filename>do_spdx</filename></title>
+
+        <para>
+            A build stage that takes the source code and scans it on a remote
+            FOSSOLOGY server in order to produce an SPDX document.
+            This task applies only to the
+            <link linkend='ref-classes-spdx'><filename>spdx</filename></link>
+            class.
+        </para>
+    </section>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
new file mode 100644
index 0000000000..576c91f29a
--- /dev/null
+++ b/documentation/ref-manual/ref-variables.xml
@@ -0,0 +1,10284 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<!-- Dummy chapter -->
+<chapter id='ref-variables-glos'>
+
+<title>Variables Glossary</title>
+
+<para>
+    This chapter lists common variables used in the OpenEmbedded build system and gives an overview
+    of their function and contents.
+</para>
+
+<glossary id='ref-variables-glossary'>
+
+
+    <para>
+       <link linkend='var-ABIEXTENSION'>A</link>
+       <link linkend='var-B'>B</link>
+       <link linkend='var-CFLAGS'>C</link>
+       <link linkend='var-D'>D</link>
+       <link linkend='var-EFI_PROVIDER'>E</link>
+       <link linkend='var-FEATURE_PACKAGES'>F</link>
+       <link linkend='var-GLIBC_GENERATE_LOCALES'>G</link>
+       <link linkend='var-HOMEPAGE'>H</link>
+       <link linkend='var-ICECC_DISABLED'>I</link>
+<!--               <link linkend='var-glossary-j'>J</link> -->
+       <link linkend='var-KARCH'>K</link>
+       <link linkend='var-LABELS'>L</link>
+       <link linkend='var-MACHINE'>M</link>
+<!--               <link linkend='var-glossary-n'>N</link> -->
+       <link linkend='var-OE_BINCONFIG_EXTRA_MANGLE'>O</link>
+       <link linkend='var-P'>P</link>
+       <link linkend='var-QMAKE_PROFILES'>Q</link>
+       <link linkend='var-RCONFLICTS'>R</link>
+       <link linkend='var-S'>S</link>
+       <link linkend='var-T'>T</link>
+       <link linkend='var-UBOOT_CONFIG'>U</link>
+<!--               <link linkend='var-glossary-v'>V</link> -->
+       <link linkend='var-WARN_QA'>W</link>
+<!--               <link linkend='var-glossary-x'>X</link> -->
+<!--               <link linkend='var-glossary-y'>Y</link> -->
+<!--               <link linkend='var-glossary-z'>Z</link>-->
+    </para>
+
+    <glossdiv id='var-glossary-a'><title>A</title>
+
+        <glossentry id='var-ABIEXTENSION'><glossterm>ABIEXTENSION</glossterm>
+            <glossdef>
+                <para>
+                    Extension to the Application Binary Interface (ABI)
+                    field of the GNU canonical architecture name
+                    (e.g. "eabi").
+                </para>
+
+                <para>
+                   ABI extensions are set in the machine include files.
+                   For example, the
+                   <filename>meta/conf/machine/include/arm/arch-arm.inc</filename>
+                   file sets the following extension:
+                   <literallayout class='monospaced'>
+     ABIEXTENSION = "eabi"
+                   </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+         <glossentry id='var-ALLOW_EMPTY'><glossterm>ALLOW_EMPTY</glossterm>
+            <glossdef>
+                <para>
+                   Specifies if an output package should still be produced if it is empty.
+                   By default, BitBake does not produce empty packages.
+                   This default behavior can cause issues when there is an
+                   <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link> or
+                   some other hard runtime requirement on the existence of the package.
+                </para>
+
+                <para>
+                   Like all package-controlling variables, you must always use them in
+                   conjunction with a package name override, as in:
+                   <literallayout class='monospaced'>
+     ALLOW_EMPTY_${PN} = "1"
+     ALLOW_EMPTY_${PN}-dev = "1"
+     ALLOW_EMPTY_${PN}-staticdev = "1"
+                   </literallayout>
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-ALTERNATIVE'><glossterm>ALTERNATIVE</glossterm>
+            <glossdef>
+                <para>
+                    Lists commands in a package that need an alternative
+                    binary naming scheme.
+                    Sometimes the same command is provided in multiple packages.
+                    When this occurs, the OpenEmbedded build system needs to
+                    use the alternatives system to create a different binary
+                    naming scheme so the commands can co-exist.
+                </para>
+
+                <para>
+                    To use the variable, list out the package's commands
+                    that also exist as part of another package.
+                    For example, if the <filename>busybox</filename> package
+                    has four commands that also exist as part of another
+                    package, you identify them as follows:
+                    <literallayout class='monospaced'>
+     ALTERNATIVE_busybox = "sh sed test bracket"
+                    </literallayout>
+                    For more information on the alternatives system, see the
+                    "<link linkend='ref-classes-update-alternatives'><filename>update-alternatives.bbclass</filename></link>"
+                    section.
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-ALTERNATIVE_LINK_NAME'><glossterm>ALTERNATIVE_LINK_NAME</glossterm>
+            <glossdef>
+                <para>
+                    Used by the alternatives system to map duplicated commands
+                    to actual locations.
+                    For example, if the <filename>bracket</filename> command
+                    provided by the <filename>busybox</filename> package is
+                    duplicated through another package, you must use the
+                    <filename>ALTERNATIVE_LINK_NAME</filename> variable to
+                    specify the actual location:
+                    <literallayout class='monospaced'>
+     ALTERNATIVE_LINK_NAME[bracket] = "/usr/bin/["
+                    </literallayout>
+                    In this example, the binary for the
+                    <filename>bracket</filename> command (i.e.
+                    <filename>[</filename>) from the
+                    <filename>busybox</filename> package resides in
+                    <filename>/usr/bin/</filename>.
+                    <note>
+                        If <filename>ALTERNATIVE_LINK_NAME</filename> is not
+                        defined, it defaults to
+                        <filename>${bindir}/<replaceable>name</replaceable></filename>.
+                    </note>
+                </para>
+
+                <para>
+                    For more information on the alternatives system, see the
+                    "<link linkend='ref-classes-update-alternatives'><filename>update-alternatives.bbclass</filename></link>"
+                    section.
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-ALTERNATIVE_PRIORITY'><glossterm>ALTERNATIVE_PRIORITY</glossterm>
+            <glossdef>
+                <para>
+                    Used by the alternatives system to create default
+                    priorities for duplicated commands.
+                    You can use the variable to create a single default
+                    regardless of the command name or package, a default for
+                    specific duplicated commands regardless of the package, or
+                    a default for specific commands tied to particular packages.
+                    Here are the available syntax forms:
+                    <literallayout class='monospaced'>
+     ALTERNATIVE_PRIORITY = "<replaceable>priority</replaceable>"
+     ALTERNATIVE_PRIORITY[<replaceable>name</replaceable>] = "<replaceable>priority</replaceable>"
+     ALTERNATIVE_PRIORITY_<replaceable>pkg</replaceable>[<replaceable>name</replaceable>] = "<replaceable>priority</replaceable>"
+                    </literallayout>
+                </para>
+
+                <para>
+                    For more information on the alternatives system, see the
+                    "<link linkend='ref-classes-update-alternatives'><filename>update-alternatives.bbclass</filename></link>"
+                    section.
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-ALTERNATIVE_TARGET'><glossterm>ALTERNATIVE_TARGET</glossterm>
+            <glossdef>
+                <para>
+                    Used by the alternatives system to create default link
+                    locations for duplicated commands.
+                    You can use the variable to create a single default
+                    location for all duplicated commands regardless of the
+                    command name or package, a default for
+                    specific duplicated commands regardless of the package, or
+                    a default for specific commands tied to particular packages.
+                    Here are the available syntax forms:
+                    <literallayout class='monospaced'>
+     ALTERNATIVE_TARGET = "<replaceable>target</replaceable>"
+     ALTERNATIVE_TARGET[<replaceable>name</replaceable>] = "<replaceable>target</replaceable>"
+     ALTERNATIVE_TARGET_<replaceable>pkg</replaceable>[<replaceable>name</replaceable>] = "<replaceable>target</replaceable>"
+                    </literallayout>
+                    <note>
+                        <para>
+                            If <filename>ALTERNATIVE_TARGET</filename> is not
+                            defined, it inherits the value from the
+                            <link linkend='var-ALTERNATIVE_LINK_NAME'><filename>ALTERNATIVE_LINK_NAME</filename></link>
+                            variable.
+                        </para>
+
+                        <para>
+                            If <filename>ALTERNATIVE_LINK_NAME</filename> and
+                            <filename>ALTERNATIVE_TARGET</filename> are the
+                            same, the target for
+                            <filename>ALTERNATIVE_TARGET</filename>
+                            has "<filename>.{BPN}</filename>" appended to it.
+                        </para>
+
+                        <para>
+                            Finally, if the file referenced has not been
+                            renamed, the alternatives system will rename it to
+                            avoid the need to rename alternative files in the
+                            <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+                            task while
+                            retaining support for the command if necessary.
+                        </para>
+                    </note>
+                </para>
+
+                <para>
+                    For more information on the alternatives system, see the
+                    "<link linkend='ref-classes-update-alternatives'><filename>update-alternatives.bbclass</filename></link>"
+                    section.
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-APPEND'><glossterm>APPEND</glossterm>
+            <glossdef>
+                <para>
+                    An override list of append strings for each
+                    <link linkend='var-LABELS'><filename>LABEL</filename></link>.
+                </para>
+
+                <para>
+                    See the
+                    <link linkend='ref-classes-grub-efi'><filename>grub-efi</filename></link>
+                    class for more information on how this variable is used.
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-ASSUME_PROVIDED'><glossterm>ASSUME_PROVIDED</glossterm>
+            <glossdef>
+                <para>
+                    Lists recipe names
+                    (<link linkend='var-PN'><filename>PN</filename></link>
+                    values) BitBake does not attempt to build.
+                    Instead, BitBake assumes these recipes have already been
+                    built.
+                </para>
+
+                <para>
+                    In OpenEmbedded Core, <filename>ASSUME_PROVIDED</filename>
+                    mostly specifies native tools that should not be built.
+                    An example is <filename>git-native</filename>, which when
+                    specified, allows for the Git binary from the host to be
+                    used rather than building <filename>git-native</filename>.
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-AUTHOR'><glossterm>AUTHOR</glossterm>
+            <glossdef>
+                <para>The email address used to contact the original author
+                    or authors in order to send patches and forward bugs.</para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-AUTO_SYSLINUXMENU'><glossterm>AUTO_SYSLINUXMENU</glossterm>
+            <glossdef>
+                <para>
+                    Enables creating an automatic menu.
+                    You must set this in your recipe.
+                    The
+                    <link linkend='ref-classes-syslinux'><filename>syslinux</filename></link>
+                    class checks this variable.
+                </para>
+            </glossdef>
+         </glossentry>
+
+        <glossentry id='var-AUTOREV'><glossterm>AUTOREV</glossterm>
+            <glossdef>
+                <para>When <filename><link linkend='var-SRCREV'>SRCREV</link></filename>
+                    is set to the value of this variable, it specifies to use the latest
+                    source revision in the repository.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     SRCREV = "${AUTOREV}"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-AVAILTUNES'><glossterm>AVAILTUNES</glossterm>
+            <glossdef>
+                <para>
+                    The list of defined CPU and Application Binary Interface
+                    (ABI) tunings (i.e.  "tunes") available for use by the
+                    OpenEmbedded build system.
+                </para>
+
+                <para>
+                    The list simply presents the tunes that are available.
+                    Not all tunes may be compatible with a particular
+                    machine configuration, or with each other in a
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#combining-multiple-versions-library-files-into-one-image'>Multilib</ulink>
+                    configuration.
+                </para>
+
+                <para>
+                    To add a tune to the list, be sure to append it with
+                    spaces using the "+=" BitBake operator.
+                    Do not simply replace the list by using the "=" operator.
+                    See the
+                    "<ulink url='&YOCTO_DOCS_BB_URL;#basic-syntax'>Basic Syntax</ulink>"
+                    section in the BitBake User Manual for more information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-b'><title>B</title>
+
+        <glossentry id='var-B'><glossterm>B</glossterm>
+            <glossdef>
+                <para>
+                    The directory within the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                    in which the OpenEmbedded build system places generated
+                    objects during a recipe's build process.
+                    By default, this directory is the same as the <link linkend='var-S'><filename>S</filename></link>
+                    directory, which is defined as:
+                    <literallayout class='monospaced'>
+     S = "${WORKDIR}/${BP}/"
+                    </literallayout>
+                    You can separate the (<filename>S</filename>) directory
+                    and the directory pointed to by the <filename>B</filename>
+                    variable.
+                    Most Autotools-based recipes support separating these
+                    directories.
+                    The build system defaults to using separate directories for
+                    <filename>gcc</filename> and some kernel recipes.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BAD_RECOMMENDATIONS'><glossterm>BAD_RECOMMENDATIONS</glossterm>
+            <glossdef>
+                <para>
+                    Lists "recommended-only" packages to not install.
+                    Recommended-only packages are packages installed only
+                    through the
+                    <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>
+                    variable.
+                    You can prevent any of these "recommended" packages from
+                    being installed by listing them with the
+                    <filename>BAD_RECOMMENDATIONS</filename> variable:
+                    <literallayout class='monospaced'>
+     BAD_RECOMMENDATIONS = "<replaceable>package_name</replaceable> <replaceable>package_name</replaceable> <replaceable>package_name</replaceable> ..."
+                    </literallayout>
+                    You can set this variable globally in your
+                    <filename>local.conf</filename> file or you can attach it to
+                    a specific image recipe by using the recipe name override:
+                    <literallayout class='monospaced'>
+     BAD_RECOMMENDATIONS_pn-<replaceable>target_image</replaceable> = "<replaceable>package_name</replaceable>"
+                    </literallayout>
+                </para>
+
+                <para>
+                    It is important to realize that if you choose to not install
+                    packages using this variable and some other packages are
+                    dependent on them (i.e. listed in a recipe's
+                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
+                    variable), the OpenEmbedded build system ignores your
+                    request and will install the packages to avoid dependency
+                    errors.
+                </para>
+
+                <para>
+                    Support for this variable exists only when using the
+                    IPK and RPM packaging backend.
+                    Support does not exist for DEB.
+                </para>
+
+                <para>
+                    See the
+                    <link linkend='var-NO_RECOMMENDATIONS'><filename>NO_RECOMMENDATIONS</filename></link>
+                    and the
+                    <link linkend='var-PACKAGE_EXCLUDE'><filename>PACKAGE_EXCLUDE</filename></link>
+                    variables for related information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BASE_LIB'><glossterm>BASE_LIB</glossterm>
+            <glossdef>
+                <para>
+                    The library directory name for the CPU or Application
+                    Binary Interface (ABI) tune.
+                    The <filename>BASE_LIB</filename> applies only in the
+                    Multilib context.
+                    See the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#combining-multiple-versions-library-files-into-one-image'>Combining Multiple Versions of Library Files into One Image</ulink>"
+                    section in the Yocto Project Development Manual for
+                    information on Multilib.
+                </para>
+
+                <para>
+                    The <filename>BASE_LIB</filename> variable is defined in
+                    the machine include files in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    If Multilib is not being used, the value defaults to "lib".
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BB_DANGLINGAPPENDS_WARNONLY'><glossterm>BB_DANGLINGAPPENDS_WARNONLY</glossterm>
+            <glossdef>
+                <para>
+                    Defines how BitBake handles situations where an append
+                    file (<filename>.bbappend</filename>) has no
+                    corresponding recipe file (<filename>.bb</filename>).
+                    This condition often occurs when layers get out of sync
+                    (e.g. <filename>oe-core</filename> bumps a
+                    recipe version and the old recipe no longer exists and the
+                    other layer has not been updated to the new version
+                    of the recipe yet).
+                </para>
+
+                <para>
+                    The default fatal behavior is safest because it is
+                    the sane reaction given something is out of sync.
+                    It is important to realize when your changes are no longer
+                    being applied.
+                </para>
+
+                <para>
+                    You can change the default behavior by setting this
+                    variable to "1", "yes", or "true"
+                    in your <filename>local.conf</filename> file, which is
+                    located in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     BB_DANGLINGAPPENDS_WARNONLY = "1"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BB_DISKMON_DIRS'><glossterm>BB_DISKMON_DIRS</glossterm>
+            <glossdef>
+                <para>
+                    Monitors disk space and available inodes during the build
+                    and allows you to control the build based on these
+                    parameters.
+                </para>
+
+                <para>
+                    Disk space monitoring is disabled by default.
+                    To enable monitoring, add the <filename>BB_DISKMON_DIRS</filename>
+                    variable to your <filename>conf/local.conf</filename> file found in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                    Use the following form:
+                    <literallayout class='monospaced'>
+     BB_DISKMON_DIRS = "<replaceable>action</replaceable>,<replaceable>dir</replaceable>,<replaceable>threshold</replaceable> [...]"
+
+     where:
+
+        <replaceable>action</replaceable> is:
+           ABORT:     Immediately abort the build when
+                      a threshold is broken.
+           STOPTASKS: Stop the build after the currently
+                      executing tasks have finished when
+                      a threshold is broken.
+           WARN:      Issue a warning but continue the
+                      build when a threshold is broken.
+                      Subsequent warnings are issued as
+                      defined by the
+                      <link linkend='var-BB_DISKMON_WARNINTERVAL'>BB_DISKMON_WARNINTERVAL</link> variable,
+                      which must be defined in the
+                      conf/local.conf file.
+
+        <replaceable>dir</replaceable> is:
+           Any directory you choose. You can specify one or
+           more directories to monitor by separating the
+           groupings with a space.  If two directories are
+           on the same device, only the first directory
+           is monitored.
+
+        <replaceable>threshold</replaceable> is:
+           Either the minimum available disk space,
+           the minimum number of free inodes, or
+           both.  You must specify at least one.  To
+           omit one or the other, simply omit the value.
+           Specify the threshold using G, M, K for Gbytes,
+           Mbytes, and Kbytes, respectively. If you do
+           not specify G, M, or K, Kbytes is assumed by
+           default.  Do not use GB, MB, or KB.
+                    </literallayout>
+                </para>
+
+                <para>
+                    Here are some examples:
+                    <literallayout class='monospaced'>
+     BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K"
+     BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G"
+     BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K"
+                    </literallayout>
+                    The first example works only if you also provide
+                    the <link linkend='var-BB_DISKMON_WARNINTERVAL'><filename>BB_DISKMON_WARNINTERVAL</filename></link> variable
+                    in the <filename>conf/local.conf</filename>.
+                    This example causes the build system to immediately
+                    abort when either the disk space in <filename>${TMPDIR}</filename> drops
+                    below 1 Gbyte or the available free inodes drops below
+                    100 Kbytes.
+                    Because two directories are provided with the variable, the
+                    build system also issue a
+                    warning when the disk space in the
+                    <filename>${SSTATE_DIR}</filename> directory drops
+                    below 1 Gbyte or the number of free inodes drops
+                    below 100 Kbytes.
+                    Subsequent warnings are issued during intervals as
+                    defined by the <filename>BB_DISKMON_WARNINTERVAL</filename>
+                    variable.
+                </para>
+
+                <para>
+                    The second example stops the build after all currently
+                    executing tasks complete when the minimum disk space
+                    in the <filename>${<link linkend='var-TMPDIR'>TMPDIR</link>}</filename>
+                    directory drops below 1 Gbyte.
+                    No disk monitoring occurs for the free inodes in this case.
+                </para>
+
+                <para>
+                    The final example immediately aborts the build when the
+                    number of free inodes in the <filename>${TMPDIR}</filename> directory
+                    drops below 100 Kbytes.
+                    No disk space monitoring for the directory itself occurs
+                    in this case.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BB_DISKMON_WARNINTERVAL'><glossterm>BB_DISKMON_WARNINTERVAL</glossterm>
+            <glossdef>
+                <para>
+                    Defines the disk space and free inode warning intervals.
+                    To set these intervals, define the variable in your
+                    <filename>conf/local.conf</filename> file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                </para>
+
+                <para>
+                    If you are going to use the
+                    <filename>BB_DISKMON_WARNINTERVAL</filename> variable, you must
+                    also use the
+                    <link linkend='var-BB_DISKMON_DIRS'><filename>BB_DISKMON_DIRS</filename></link> variable
+                    and define its action as "WARN".
+                    During the build, subsequent warnings are issued each time
+                    disk space or number of free inodes further reduces by
+                    the respective interval.
+                </para>
+
+                <para>
+                    If you do not provide a <filename>BB_DISKMON_WARNINTERVAL</filename>
+                    variable and you do use <filename>BB_DISKMON_DIRS</filename> with
+                    the "WARN" action, the disk monitoring interval defaults to
+                    the following:
+                    <literallayout class='monospaced'>
+     BB_DISKMON_WARNINTERVAL = "50M,5K"
+                    </literallayout>
+                </para>
+
+                <para>
+                    When specifying the variable in your configuration file,
+                    use the following form:
+                    <literallayout class='monospaced'>
+     BB_DISKMON_WARNINTERVAL = "<replaceable>disk_space_interval</replaceable>,<replaceable>disk_inode_interval</replaceable>"
+
+     where:
+
+        <replaceable>disk_space_interval</replaceable> is:
+           An interval of memory expressed in either
+           G, M, or K for Gbytes, Mbytes, or Kbytes,
+           respectively. You cannot use GB, MB, or KB.
+
+        <replaceable>disk_inode_interval</replaceable> is:
+           An interval of free inodes expressed in either
+           G, M, or K for Gbytes, Mbytes, or Kbytes,
+           respectively. You cannot use GB, MB, or KB.
+                    </literallayout>
+                </para>
+
+                <para>
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K"
+     BB_DISKMON_WARNINTERVAL = "50M,5K"
+                    </literallayout>
+                    These variables cause the OpenEmbedded build system to
+                    issue subsequent warnings each time the available
+                    disk space further reduces by 50 Mbytes or the number
+                    of free inodes further reduces by 5 Kbytes in the
+                    <filename>${SSTATE_DIR}</filename> directory.
+                    Subsequent warnings based on the interval occur each time
+                    a respective interval is reached beyond the initial warning
+                    (i.e. 1 Gbytes and 100 Kbytes).
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BB_GENERATE_MIRROR_TARBALLS'><glossterm>BB_GENERATE_MIRROR_TARBALLS</glossterm>
+            <glossdef>
+                <para>
+                    Causes tarballs of the Git repositories, including the
+                    Git metadata, to be placed in the
+                    <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
+                    directory.
+                </para>
+
+                <para>
+                    For performance reasons, creating and placing tarballs of
+                    the Git repositories is not the default action by the
+                    OpenEmbedded build system.
+                    <literallayout class='monospaced'>
+     BB_GENERATE_MIRROR_TARBALLS = "1"
+                    </literallayout>
+                    Set this variable in your <filename>local.conf</filename>
+                    file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BB_NUMBER_THREADS'><glossterm>BB_NUMBER_THREADS</glossterm>
+            <glossdef>
+                <para>
+                    The maximum number of tasks BitBake should run in parallel
+                    at any one time.
+                    If your host development system supports multiple cores,
+                    a good rule of thumb is to set this variable to twice the
+                    number of cores.
+                </para>
+
+                <para>
+                    The default value for <filename>BB_NUMBER_THREADS</filename>
+                    is equal to the number of cores your build system has.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBCLASSEXTEND'><glossterm>BBCLASSEXTEND</glossterm>
+            <glossdef>
+                <para>
+                    Allows you to extend a recipe so that it builds variants of the software.
+                    Common variants for recipes exist such as "natives" like <filename>quilt-native</filename>,
+                    which is a copy of Quilt built to run on the build system;
+                    "crosses" such as <filename>gcc-cross</filename>,
+                    which is a compiler built to run on the build machine but produces binaries
+                    that run on the target <link linkend='var-MACHINE'><filename>MACHINE</filename></link>;
+                    "nativesdk", which targets the SDK machine instead of <filename>MACHINE</filename>;
+                    and "mulitlibs" in the form "<filename>multilib:</filename><replaceable>multilib_name</replaceable>".
+                </para>
+
+                <para>
+                    To build a different variant of the recipe with a minimal amount of code, it usually
+                    is as simple as adding the following to your recipe:
+                    <literallayout class='monospaced'>
+     BBCLASSEXTEND =+ "native nativesdk"
+     BBCLASSEXTEND =+ "multilib:<replaceable>multilib_name</replaceable>"
+                    </literallayout>
+                </para>
+             </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBFILE_COLLECTIONS'><glossterm>BBFILE_COLLECTIONS</glossterm>
+            <glossdef>
+                <para>Lists the names of configured layers.
+                    These names are used to find the other <filename>BBFILE_*</filename>
+                    variables.
+                    Typically, each layer will append its name to this variable in its
+                    <filename>conf/layer.conf</filename> file.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBFILE_PATTERN'><glossterm>BBFILE_PATTERN</glossterm>
+            <glossdef>
+                <para>Variable that expands to match files from
+                    <link linkend='var-BBFILES'><filename>BBFILES</filename></link>
+                    in a particular layer.
+                    This variable is used in the <filename>conf/layer.conf</filename> file and must
+                    be suffixed with the name of the specific layer (e.g.
+                    <filename>BBFILE_PATTERN_emenlow</filename>).</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBFILE_PRIORITY'><glossterm>BBFILE_PRIORITY</glossterm>
+            <glossdef>
+                <para>Assigns the priority for recipe files in each layer.</para>
+                <para>This variable is useful in situations where the same recipe appears in
+                    more than one layer.
+                    Setting this variable allows you to prioritize a
+                    layer against other layers that contain the same recipe - effectively
+                    letting you control the precedence for the multiple layers.
+                    The precedence established through this variable stands regardless of a
+                    recipe's version
+                    (<link linkend='var-PV'><filename>PV</filename></link> variable).
+                    For example, a layer that has a recipe with a higher <filename>PV</filename> value but for
+                    which the <filename>BBFILE_PRIORITY</filename> is set to have a lower precedence still has a
+                    lower precedence.</para>
+                <para>A larger value for the <filename>BBFILE_PRIORITY</filename> variable results in a higher
+                    precedence.
+                    For example, the value 6 has a higher precedence than the value 5.
+                    If not specified, the <filename>BBFILE_PRIORITY</filename> variable is set based on layer
+                    dependencies (see the
+                    <filename><link linkend='var-LAYERDEPENDS'>LAYERDEPENDS</link></filename> variable for
+                    more information.
+                    The default priority, if unspecified
+                    for a layer with no dependencies, is the lowest defined priority + 1
+                    (or 1 if no priorities are defined).</para>
+                <tip>
+                    You can use the command <filename>bitbake-layers show-layers</filename> to list
+                    all configured layers along with their priorities.
+                </tip>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBFILES'><glossterm>BBFILES</glossterm>
+            <glossdef>
+                <para>List of recipe files used by BitBake to build software.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBINCLUDELOGS'><glossterm>BBINCLUDELOGS</glossterm>
+            <glossdef>
+                <para>Variable that controls how BitBake displays logs on build failure.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBLAYERS'><glossterm>BBLAYERS</glossterm>
+            <glossdef>
+                <para>Lists the layers to enable during the build.
+                    This variable is defined in the <filename>bblayers.conf</filename> configuration
+                    file in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     BBLAYERS = " \
+       /home/scottrif/poky/meta \
+       /home/scottrif/poky/meta-yocto \
+       /home/scottrif/poky/meta-yocto-bsp \
+       /home/scottrif/poky/meta-mykernel \
+       "
+
+     BBLAYERS_NON_REMOVABLE ?= " \
+       /home/scottrif/poky/meta \
+       /home/scottrif/poky/meta-yocto \
+       "
+                    </literallayout>
+                    This example enables four layers, one of which is a custom, user-defined layer
+                    named <filename>meta-mykernel</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBLAYERS_NON_REMOVABLE'><glossterm>BBLAYERS_NON_REMOVABLE</glossterm>
+            <glossdef>
+                <para>Lists core layers that cannot be removed from the
+                    <filename>bblayers.conf</filename> file during a build
+                    using the
+                    <ulink url='https://www.yoctoproject.org/tools-resources/projects/hob'>Hob</ulink>.
+                    <note>
+                        When building an image outside of Hob, this variable
+                        is ignored.
+                    </note>
+                    In order for BitBake to build your image using Hob, your
+                    <filename>bblayers.conf</filename> file must include the
+                    <filename>meta</filename> and <filename>meta-yocto</filename>
+                    core layers.
+                    Here is an example that shows these two layers listed in
+                    the <filename>BBLAYERS_NON_REMOVABLE</filename> statement:
+                    <literallayout class='monospaced'>
+     BBLAYERS = " \
+       /home/scottrif/poky/meta \
+       /home/scottrif/poky/meta-yocto \
+       /home/scottrif/poky/meta-yocto-bsp \
+       /home/scottrif/poky/meta-mykernel \
+       "
+
+     BBLAYERS_NON_REMOVABLE ?= " \
+       /home/scottrif/poky/meta \
+       /home/scottrif/poky/meta-yocto \
+       "
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBMASK'><glossterm>BBMASK</glossterm>
+            <glossdef>
+                <para>
+                    Prevents BitBake from processing recipes and recipe
+                    append files.
+                    Use the <filename>BBMASK</filename> variable from within the
+                    <filename>conf/local.conf</filename> file found
+                    in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                </para>
+
+                <para>
+                    You can use the <filename>BBMASK</filename> variable
+                    to "hide" these <filename>.bb</filename> and
+                    <filename>.bbappend</filename> files.
+                    BitBake ignores any recipe or recipe append files that
+                    match the expression.
+                    It is as if BitBake does not see them at all.
+                    Consequently, matching files are not parsed or otherwise
+                    used by BitBake.</para>
+                <para>
+                    The value you provide is passed to Python's regular
+                    expression compiler.
+                    The expression is compared against the full paths to
+                    the files.
+                    For complete syntax information, see Python's
+                    documentation at
+                    <ulink url='http://docs.python.org/release/2.3/lib/re-syntax.html'></ulink>.
+                </para>
+
+                <para>
+                    The following example uses a complete regular expression
+                    to tell BitBake to ignore all recipe and recipe append
+                    files in the <filename>meta-ti/recipes-misc/</filename>
+                    directory:
+                    <literallayout class='monospaced'>
+     BBMASK = "meta-ti/recipes-misc/"
+                    </literallayout>
+                    If you want to mask out multiple directories or recipes,
+                    use the vertical bar to separate the regular expression
+                    fragments.
+                    This next example masks out multiple directories and
+                    individual recipes:
+                    <literallayout class='monospaced'>
+     BBMASK = "meta-ti/recipes-misc/|meta-ti/recipes-ti/packagegroup/"
+     BBMASK .= "|.*meta-oe/recipes-support/"
+     BBMASK .= "|.*openldap"
+     BBMASK .= "|.*opencv"
+     BBMASK .= "|.*lzma"
+                    </literallayout>
+                    Notice how the vertical bar is used to append the fragments.
+                    <note>
+                        When specifying a directory name, use the trailing
+                        slash character to ensure you match just that directory
+                        name.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBPATH'><glossterm>BBPATH</glossterm>
+            <glossdef>
+                <para>
+                    Used by BitBake to locate
+                    <filename>.bbclass</filename> and configuration files.
+                    This variable is analogous to the
+                    <filename>PATH</filename> variable.
+                    <note>
+                        If you run BitBake from a directory outside of the
+                        <ulink url='&YOCTO_DOCS_DEV_URL;build-directory'>Build Directory</ulink>,
+                        you must be sure to set
+                        <filename>BBPATH</filename> to point to the
+                        Build Directory.
+                        Set the variable as you would any environment variable
+                        and then run BitBake:
+                        <literallayout class='monospaced'>
+     $ BBPATH = "<replaceable>build_directory</replaceable>"
+     $ export BBPATH
+     $ bitbake <replaceable>target</replaceable>
+                        </literallayout>
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBSERVER'><glossterm>BBSERVER</glossterm>
+            <glossdef>
+                <para>
+                    Points to the server that runs memory-resident BitBake.
+                    This variable is set by the
+                    <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>
+                    setup script and should not be hand-edited.
+                    The variable is only used when you employ memory-resident
+                    BitBake.
+                    The setup script exports the value as follows:
+                    <literallayout class='monospaced'>
+     export BBSERVER=localhost:$port
+                    </literallayout>
+                    For more information on how the
+                    <filename>BBSERVER</filename> is used, see the
+                    <filename>oe-init-build-env-memres</filename> script, which
+                    is located in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BINCONFIG'><glossterm>BINCONFIG</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-binconfig-disabled'><filename>binconfig-disabled</filename></link>
+                    class, this variable specifies binary configuration
+                    scripts to disable in favor of using
+                    <filename>pkg-config</filename> to query the information.
+                    The <filename>binconfig-disabled</filename> class will
+                    modify the specified scripts to return an error so that
+                    calls to them can be easily found and replaced.
+                </para>
+
+                <para>
+                    To add multiple scripts, separate them by spaces.
+                    Here is an example from the <filename>libpng</filename>
+                    recipe:
+                    <literallayout class='monospaced'>
+     BINCONFIG = "${bindir}/libpng-config ${bindir}/libpng16-config"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BINCONFIG_GLOB'><glossterm>BINCONFIG_GLOB</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-binconfig'><filename>binconfig</filename></link>
+                    class, this variable specifies a wildcard for
+                    configuration scripts that need editing.
+                    The scripts are edited to correct any paths that have been
+                    set up during compilation so that they are correct for
+                    use when installed into the sysroot and called by the
+                    build processes of other recipes.
+                </para>
+
+                <para>
+                    For more information on how this variable works, see
+                    <filename>meta/classes/binconfig.bbclass</filename> in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    You can also find general information on the class in the
+                    "<link linkend='ref-classes-binconfig'><filename>binconfig.bbclass</filename></link>"
+                    section.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BP'><glossterm>BP</glossterm>
+            <glossdef>
+                <para>The base recipe name and version but without any special
+                    recipe name suffix (i.e. <filename>-native</filename>, <filename>lib64-</filename>,
+                    and so forth).
+                    <filename>BP</filename> is comprised of the following:
+                    <literallayout class="monospaced">
+     ${BPN}-${PV}
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BPN'><glossterm>BPN</glossterm>
+            <glossdef>
+                <para>The bare name of the recipe.
+                    This variable is a version of the <link linkend='var-PN'><filename>PN</filename></link> variable
+                    but removes common suffixes such as "-native" and "-cross" as well
+                    as removes common prefixes such as multilib's "lib64-" and "lib32-".
+                    The exact list of suffixes removed is specified by the
+                    <link linkend='var-SPECIAL_PKGSUFFIX'><filename>SPECIAL_PKGSUFFIX</filename></link> variable.
+                    The exact list of prefixes removed is specified by the
+                    <link linkend='var-MLPREFIX'><filename>MLPREFIX</filename></link> variable.
+                    Prefixes are removed for <filename>multilib</filename>
+                    and <filename>nativesdk</filename> cases.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUGTRACKER'><glossterm>BUGTRACKER</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a URL for an upstream bug tracking website for
+                    a recipe.
+                    The OpenEmbedded build system does not use this variable.
+                    Rather, the variable is a useful pointer in case a bug
+                    in the software being built needs to be manually reported.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUILD_CFLAGS'><glossterm>BUILD_CFLAGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the flags to pass to the C compiler when building
+                    for the build host.
+                    When building in the <filename>-native</filename> context,
+                    <link linkend='var-CFLAGS'><filename>CFLAGS</filename></link>
+                    is set to the value of this variable by default.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUILD_CPPFLAGS'><glossterm>BUILD_CPPFLAGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the flags to pass to the C pre-processor
+                    (i.e. to both the C and the C++ compilers) when building
+                    for the build host.
+                    When building in the <filename>native</filename> context,
+                    <link linkend='var-CPPFLAGS'><filename>CPPFLAGS</filename></link>
+                    is set to the value of this variable by default.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUILD_CXXFLAGS'><glossterm>BUILD_CXXFLAGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the flags to pass to the C++ compiler when
+                    building for the build host.
+                    When building in the <filename>native</filename> context,
+                    <link linkend='var-CXXFLAGS'><filename>CXXFLAGS</filename></link>
+                    is set to the value of this variable by default.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUILD_LDFLAGS'><glossterm>BUILD_LDFLAGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the flags to pass to the linker when building
+                    for the build host.
+                    When building in the <filename>-native</filename> context,
+                    <link linkend='var-LDFLAGS'><filename>LDFLAGS</filename></link>
+                    is set to the value of this variable by default.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUILD_OPTIMIZATION'><glossterm>BUILD_OPTIMIZATION</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the optimization flags passed to the C compiler
+                    when building for the build host or the SDK.
+                    The flags are passed through the
+                    <link linkend='var-BUILD_CFLAGS'><filename>BUILD_CFLAGS</filename></link>
+                    and
+                    <link linkend='var-BUILDSDK_CFLAGS'><filename>BUILDSDK_CFLAGS</filename></link>
+                    default values.
+                </para>
+
+                <para>
+                    The default value of the
+                    <filename>BUILD_OPTIMIZATION</filename> variable is
+                    "-O2 -pipe".
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUILDDIR'><glossterm>BUILDDIR</glossterm>
+            <glossdef>
+                <para>
+                    Points to the location of the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                    You can define this directory indirectly through the
+                    <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+                    and
+                    <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>
+                    scripts by passing in a Build Directory path when you run
+                    the scripts.
+                    If you run the scripts and do not provide a Build Directory
+                    path, the <filename>BUILDDIR</filename> defaults to
+                    <filename>build</filename> in the current directory.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUILDHISTORY_COMMIT'><glossterm>BUILDHISTORY_COMMIT</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
+                    class, this variable specifies whether or not to commit the
+                    build history output in a local Git repository.
+                    If set to "1", this local repository will be maintained
+                    automatically by the
+                    <filename>buildhistory</filename>
+                    class and a commit will be created on every
+                    build for changes to each top-level subdirectory of the
+                    build history output (images, packages, and sdk).
+                    If you want to track changes to build history over
+                    time, you should set this value to "1".
+                </para>
+
+                <para>
+                    By default, the <filename>buildhistory</filename> class
+                    does not commit the build history output in a local
+                    Git repository:
+                    <literallayout class='monospaced'>
+     BUILDHISTORY_COMMIT ?= "0"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUILDHISTORY_COMMIT_AUTHOR'><glossterm>BUILDHISTORY_COMMIT_AUTHOR</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
+                    class, this variable specifies the author to use for each
+                    Git commit.
+                    In order for the <filename>BUILDHISTORY_COMMIT_AUTHOR</filename>
+                    variable to work, the
+                    <link linkend='var-BUILDHISTORY_COMMIT'><filename>BUILDHISTORY_COMMIT</filename></link>
+                    variable must be set to "1".
+                </para>
+
+                <para>
+                    Git requires that the value you provide for the
+                    <filename>BUILDHISTORY_COMMIT_AUTHOR</filename> variable
+                    takes the form of "name &lt;email@host&gt;".
+                    Providing an email address or host that is not valid does
+                    not produce an error.
+                </para>
+
+                <para>
+                    By default, the <filename>buildhistory</filename> class
+                    sets the variable as follows:
+                    <literallayout class='monospaced'>
+     BUILDHISTORY_COMMIT_AUTHOR ?= "buildhistory &lt;buildhistory@${DISTRO}&gt;"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUILDHISTORY_DIR'><glossterm>BUILDHISTORY_DIR</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
+                    class, this variable specifies the directory in which
+                    build history information is kept.
+                    For more information on how the variable works, see the
+                    <filename>buildhistory.class</filename>.
+                </para>
+
+                <para>
+                    By default, the <filename>buildhistory</filename> class
+                    sets the directory as follows:
+                    <literallayout class='monospaced'>
+     BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUILDHISTORY_FEATURES'><glossterm>BUILDHISTORY_FEATURES</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
+                    class, this variable specifies the build history features
+                    to be enabled.
+                    For more information on how build history works, see the
+                    "<link linkend='maintaining-build-output-quality'>Maintaining Build Output Quality</link>"
+                    section.
+                </para>
+
+                <para>
+                    You can specify three features in the form of a
+                    space-separated list:
+                    <itemizedlist>
+                        <listitem><para><emphasis>image:</emphasis>
+                            Analysis of the contents of images, which
+                            includes the list of installed packages among other
+                            things.
+                            </para></listitem>
+                        <listitem><para><emphasis>package:</emphasis>
+                            Analysis of the contents of individual packages.
+                            </para></listitem>
+                        <listitem><para><emphasis>sdk:</emphasis>
+                            Analysis of the contents of the software
+                            development kit (SDK).
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    By default, the <filename>buildhistory</filename> class
+                    enables all three features:
+                    <literallayout class='monospaced'>
+     BUILDHISTORY_FEATURES ?= "image package sdk"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUILDHISTORY_IMAGE_FILES'><glossterm>BUILDHISTORY_IMAGE_FILES</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
+                    class, this variable specifies a list of paths to files
+                    copied from the
+                    image contents into the build history directory under
+                    an "image-files" directory in the directory for
+                    the image, so that you can track the contents of each file.
+                    The default is to copy <filename>/etc/passwd</filename>
+                    and <filename>/etc/group</filename>, which allows you to
+                    monitor for changes in user and group entries.
+                    You can modify the list to include any file.
+                    Specifying an invalid path does not produce an error.
+                    Consequently, you can include files that might
+                    not always be present.
+                </para>
+
+                <para>
+                    By default, the <filename>buildhistory</filename> class
+                    provides paths to the following files:
+                    <literallayout class='monospaced'>
+     BUILDHISTORY_IMAGE_FILES ?= "/etc/passwd /etc/group"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUILDHISTORY_PUSH_REPO'><glossterm>BUILDHISTORY_PUSH_REPO</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
+                    class, this variable optionally specifies a remote
+                    repository to which build history pushes Git changes.
+                    In order for <filename>BUILDHISTORY_PUSH_REPO</filename>
+                    to work,
+                    <link linkend='var-BUILDHISTORY_COMMIT'><filename>BUILDHISTORY_COMMIT</filename></link>
+                    must be set to "1".
+                </para>
+
+                <para>
+                    The repository should correspond to a remote
+                    address that specifies a repository as understood by
+                    Git, or alternatively to a remote name that you have
+                    set up manually using <filename>git remote</filename>
+                    within the local repository.
+                </para>
+
+                <para>
+                    By default, the <filename>buildhistory</filename> class
+                    sets the variable as follows:
+                    <literallayout class='monospaced'>
+     BUILDHISTORY_PUSH_REPO ?= ""
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUILDSDK_CFLAGS'><glossterm>BUILDSDK_CFLAGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the flags to pass to the C compiler when building
+                    for the SDK.
+                    When building in the <filename>nativesdk</filename>
+                    context,
+                    <link linkend='var-CFLAGS'><filename>CFLAGS</filename></link>
+                    is set to the value of this variable by default.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUILDSDK_CPPFLAGS'><glossterm>BUILDSDK_CPPFLAGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the flags to pass to the C pre-processor
+                    (i.e. to both the C and the C++ compilers) when building
+                    for the SDK.
+                    When building in the <filename>nativesdk</filename>
+                    context,
+                    <link linkend='var-CPPFLAGS'><filename>CPPFLAGS</filename></link>
+                    is set to the value of this variable by default.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUILDSDK_CXXFLAGS'><glossterm>BUILDSDK_CXXFLAGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the flags to pass to the C++ compiler when
+                    building for the SDK.
+                    When building in the <filename>nativesdk</filename>
+                    context,
+                    <link linkend='var-CXXFLAGS'><filename>CXXFLAGS</filename></link>
+                    is set to the value of this variable by default.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUILDSDK_LDFLAGS'><glossterm>BUILDSDK_LDFLAGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the flags to pass to the linker when building
+                    for the SDK.
+                    When building in the <filename>nativesdk-</filename>
+                    context,
+                    <link linkend='var-LDFLAGS'><filename>LDFLAGS</filename></link>
+                    is set to the value of this variable by default.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUILDSTATS_BASE'><glossterm>BUILDSTATS_BASE</glossterm>
+            <glossdef>
+                <para>
+                    Points to the location of the directory that holds build
+                    statistics when you use and enable the
+                    <link linkend='ref-classes-buildstats'><filename>buildstats</filename></link>
+                    class.
+                    The <filename>BUILDSTATS_BASE</filename> directory defaults
+                    to
+                    <filename>${</filename><link linkend='var-TMPDIR'><filename>TMPDIR</filename></link><filename>}/buildstats/</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUSYBOX_SPLIT_SUID'><glossterm>BUSYBOX_SPLIT_SUID</glossterm>
+            <glossdef>
+                <para>
+                    For the BusyBox recipe, specifies whether to split the
+                    output executable file into two parts: one for features
+                    that require <filename>setuid root</filename>, and one for
+                    the remaining features (i.e. those that do not require
+                    <filename>setuid root</filename>).
+                </para>
+
+                <para>
+                    The <filename>BUSYBOX_SPLIT_SUID</filename> variable
+                    defaults to "1", which results in a single output
+                    executable file.
+                    Set the variable to "0" to split the output file.
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-c'><title>C</title>
+
+        <glossentry id='var-CFLAGS'><glossterm>CFLAGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the flags to pass to the C compiler.
+                    This variable is exported to an environment
+                    variable and thus made visible to the software being
+                    built during the compilation step.
+                </para>
+
+                <para>
+                    Default initialization for <filename>CFLAGS</filename>
+                    varies depending on what is being built:
+                    <itemizedlist>
+                        <listitem><para>
+                            <link linkend='var-TARGET_CFLAGS'><filename>TARGET_CFLAGS</filename></link>
+                            when building for the target
+                            </para></listitem>
+                        <listitem><para>
+                            <link linkend='var-BUILD_CFLAGS'><filename>BUILD_CFLAGS</filename></link>
+                            when building for the build host (i.e.
+                            <filename>-native</filename>)
+                            </para></listitem>
+                        <listitem><para>
+                            <link linkend='var-BUILDSDK_CFLAGS'><filename>BUILDSDK_CFLAGS</filename></link>
+                            when building for an SDK (i.e.
+                            <filename>nativesdk-</filename>)
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-CLASSOVERRIDE'><glossterm>CLASSOVERRIDE</glossterm>
+            <glossdef>
+                <para>
+                    An internal variable specifying the special class override
+                    that should currently apply (e.g. "class-target",
+                    "class-native", and so forth).
+                    The classes that use this variable set it to
+                    appropriate values.
+                </para>
+
+                <para>
+                    You do not normally directly interact with this variable.
+                    The value for the <filename>CLASSOVERRIDE</filename>
+                    variable goes into
+                    <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>
+                    and then can be used as an override.
+                    Here is an example where "python-native" is added to
+                    <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>
+                    only when building for the native case:
+                    <literallayout class='monospaced'>
+     DEPENDS_append_class-native = " python-native"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-COMBINED_FEATURES'><glossterm>COMBINED_FEATURES</glossterm>
+            <glossdef>
+                <para>
+                    Provides a list of hardware features that are enabled in
+                    both
+                    <link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>
+                    and
+                    <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
+                    This select list of features contains features that make
+                    sense to be controlled both at the machine and distribution
+                    configuration level.
+                    For example, the "bluetooth" feature requires hardware
+                    support but should also be optional at the distribution
+                    level, in case the hardware supports Bluetooth but you
+                    do not ever intend to use it.
+                </para>
+
+                <para>
+                    For more information, see the
+                    <link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>
+                    and <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
+                    variables.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-COMMON_LICENSE_DIR'><glossterm>COMMON_LICENSE_DIR</glossterm>
+            <glossdef>
+                <para>
+                    Points to <filename>meta/files/common-licenses</filename>
+                    in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
+                    which is where generic license files reside.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-COMPATIBLE_HOST'><glossterm>COMPATIBLE_HOST</glossterm>
+            <glossdef>
+                <para>A regular expression that resolves to one or more hosts
+                    (when the recipe is native) or one or more targets (when
+                    the recipe is non-native) with which a recipe is compatible.
+                    The regular expression is matched against
+                    <link linkend="var-HOST_SYS"><filename>HOST_SYS</filename></link>.
+                    You can use the variable to stop recipes from being built
+                    for classes of systems with which the recipes are not
+                    compatible.
+                    Stopping these builds is particularly useful with kernels.
+                    The variable also helps to increase parsing speed
+                    since the build system skips parsing recipes not
+                    compatible with the current system.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-COMPATIBLE_MACHINE'><glossterm>COMPATIBLE_MACHINE</glossterm>
+            <glossdef>
+                <para>A regular expression that resolves to one or more
+                    target machines with which a recipe is compatible.
+                    The regular expression is matched against
+                    <link linkend="var-MACHINEOVERRIDES"><filename>MACHINEOVERRIDES</filename></link>.
+                    You can use the variable to stop recipes from being built
+                    for machines with which the recipes are not compatible.
+                    Stopping these builds is particularly useful with kernels.
+                    The variable also helps to increase parsing speed
+                    since the build system skips parsing recipes not
+                    compatible with the current machine.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-COMPLEMENTARY_GLOB'><glossterm>COMPLEMENTARY_GLOB</glossterm>
+            <glossdef>
+                <para>
+                    Defines wildcards to match when installing a list of
+                    complementary packages for all the packages explicitly
+                    (or implicitly) installed in an image.
+                    The resulting list of complementary packages is associated
+                    with an item that can be added to
+                    <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>.
+                    An example usage of this is the "dev-pkgs" item that when
+                    added to <filename>IMAGE_FEATURES</filename> will
+                    install -dev packages (containing headers and other
+                    development files) for every package in the image.
+                </para>
+
+                <para>
+                    To add a new feature item pointing to a wildcard, use a
+                    variable flag to specify the feature item name and
+                    use the value to specify the wildcard.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     COMPLEMENTARY_GLOB[dev-pkgs] = '*-dev'
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-CONFFILES'><glossterm>CONFFILES</glossterm>
+            <glossdef>
+                <para>
+                    Identifies editable or configurable files that are part of a package.
+                    If the Package Management System (PMS) is being used to update
+                    packages on the target system, it is possible that
+                    configuration files you have changed after the original installation
+                    and that you now want to remain unchanged are overwritten.
+                    In other words, editable files might exist in the package that you do not
+                    want reset as part of the package update process.
+                    You can use the <filename>CONFFILES</filename> variable to list the files in the
+                    package that you wish to prevent the PMS from overwriting during this update process.
+                </para>
+
+                <para>
+                    To use the <filename>CONFFILES</filename> variable, provide a package name
+                    override that identifies the resulting package.
+                    Then, provide a space-separated list of files.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     CONFFILES_${PN} += "${sysconfdir}/file1 \
+        ${sysconfdir}/file2 ${sysconfdir}/file3"
+                    </literallayout>
+                </para>
+
+                <para>
+                    A relationship exists between the <filename>CONFFILES</filename> and
+                    <filename><link linkend='var-FILES'>FILES</link></filename> variables.
+                    The files listed within <filename>CONFFILES</filename> must be a subset of
+                    the files listed within <filename>FILES</filename>.
+                    Because the configuration files you provide with <filename>CONFFILES</filename>
+                    are simply being identified so that the PMS will not overwrite them,
+                    it makes sense that
+                    the files must already be included as part of the package through the
+                    <filename>FILES</filename> variable.
+                </para>
+
+                <note>
+                    When specifying paths as part of the <filename>CONFFILES</filename> variable,
+                    it is good practice to use appropriate path variables.
+                    For example, <filename>${sysconfdir}</filename> rather than
+                    <filename>/etc</filename> or <filename>${bindir}</filename> rather
+                    than <filename>/usr/bin</filename>.
+                    You can find a list of these variables at the top of the
+                    <filename>meta/conf/bitbake.conf</filename> file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                </note>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-CONFIG_INITRAMFS_SOURCE'><glossterm>CONFIG_INITRAMFS_SOURCE</glossterm>
+            <glossdef>
+                <para>
+                    Identifies the initial RAM disk (initramfs) source files.
+                    The OpenEmbedded build system receives and uses
+                    this kernel Kconfig variable as an environment variable.
+                    By default, the variable is set to null ("").
+                </para>
+
+                <para>
+                    The <filename>CONFIG_INITRAMFS_SOURCE</filename> can be
+                    either a single cpio archive with a
+                    <filename>.cpio</filename> suffix or a
+                    space-separated list of directories and files for building
+                    the initramfs image.
+                    A cpio archive should contain a filesystem archive
+                    to be used as an initramfs image.
+                    Directories should contain a filesystem layout to be
+                    included in the initramfs image.
+                    Files should contain entries according to the format
+                    described by the
+                    <filename>usr/gen_init_cpio</filename> program in the
+                    kernel tree.
+                </para>
+
+                <para>
+                    If you specify multiple directories and files, the
+                    initramfs image will be the aggregate of all of them.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-CONFIG_SITE'><glossterm>CONFIG_SITE</glossterm>
+            <glossdef>
+                <para>
+                    A list of files that contains <filename>autoconf</filename> test results relevant
+                    to the current build.
+                    This variable is used by the Autotools utilities when running
+                    <filename>configure</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-CONFLICT_DISTRO_FEATURES'><glossterm>CONFLICT_DISTRO_FEATURES</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-distro_features_check'><filename>distro_features_check</filename></link>
+                    class, this
+                    variable identifies distribution features that would
+                    be in conflict should the recipe
+                    be built.
+                    In other words, if the
+                    <filename>CONFLICT_DISTRO_FEATURES</filename> variable
+                    lists a feature that also appears in
+                    <filename>DISTRO_FEATURES</filename> within the
+                    current configuration, an error occurs and the
+                    build stops.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-COPY_LIC_DIRS'><glossterm>COPY_LIC_DIRS</glossterm>
+            <glossdef>
+                <para>
+                    If set to "1" along with the
+                    <link linkend='var-COPY_LIC_MANIFEST'><filename>COPY_LIC_MANIFEST</filename></link>
+                    variable, the OpenEmbedded build system copies
+                    into the image the license files, which are located in
+                    <filename>/usr/share/common-licenses</filename>,
+                    for each package.
+                    The license files are placed
+                    in directories within the image itself.
+                    </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-COPY_LIC_MANIFEST'><glossterm>COPY_LIC_MANIFEST</glossterm>
+            <glossdef>
+                <para>
+                    If set to "1", the OpenEmbedded build system copies
+                    the license manifest for the image to
+                    <filename>/usr/share/common-licenses/license.manifest</filename>
+                    within the image itself.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-CORE_IMAGE_EXTRA_INSTALL'><glossterm>CORE_IMAGE_EXTRA_INSTALL</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the list of packages to be added to the image.
+                    You should only set this variable in the
+                    <filename>local.conf</filename> configuration file found
+                    in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                </para>
+
+                <para>
+                    This variable replaces <filename>POKY_EXTRA_INSTALL</filename>, which is no longer supported.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-COREBASE'><glossterm>COREBASE</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the parent directory of the OpenEmbedded
+                    Core Metadata layer (i.e. <filename>meta</filename>).
+                </para>
+
+                <para>
+                    It is an important distinction that
+                    <filename>COREBASE</filename> points to the parent of this
+                    layer and not the layer itself.
+                    Consider an example where you have cloned the Poky Git
+                    repository and retained the <filename>poky</filename>
+                    name for your local copy of the repository.
+                    In this case, <filename>COREBASE</filename> points to
+                    the <filename>poky</filename> folder because it is the
+                    parent directory of the <filename>poky/meta</filename>
+                    layer.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-CPPFLAGS'><glossterm>CPPFLAGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the flags to pass to the C pre-processor
+                    (i.e. to both the C and the C++ compilers).
+                    This variable is exported to an environment
+                    variable and thus made visible to the software being
+                    built during the compilation step.
+                </para>
+
+                <para>
+                    Default initialization for <filename>CPPFLAGS</filename>
+                    varies depending on what is being built:
+                    <itemizedlist>
+                        <listitem><para>
+                            <link linkend='var-TARGET_CPPFLAGS'><filename>TARGET_CPPFLAGS</filename></link>
+                            when building for the target
+                            </para></listitem>
+                        <listitem><para>
+                            <link linkend='var-BUILD_CPPFLAGS'><filename>BUILD_CPPFLAGS</filename></link>
+                            when building for the build host (i.e.
+                            <filename>-native</filename>)
+                            </para></listitem>
+                        <listitem><para>
+                            <link linkend='var-BUILDSDK_CPPFLAGS'><filename>BUILDSDK_CPPFLAGS</filename></link>
+                            when building for an SDK (i.e.
+                            <filename>nativesdk-</filename>)
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-CXXFLAGS'><glossterm>CXXFLAGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the flags to pass to the C++ compiler.
+                    This variable is exported to an environment
+                    variable and thus made visible to the software being
+                    built during the compilation step.
+                </para>
+
+                <para>
+                    Default initialization for <filename>CXXFLAGS</filename>
+                    varies depending on what is being built:
+                    <itemizedlist>
+                        <listitem><para>
+                            <link linkend='var-TARGET_CXXFLAGS'><filename>TARGET_CXXFLAGS</filename></link>
+                            when building for the target
+                            </para></listitem>
+                        <listitem><para>
+                            <link linkend='var-BUILD_CXXFLAGS'><filename>BUILD_CXXFLAGS</filename></link>
+                            when building for the build host (i.e.
+                            <filename>-native</filename>)
+                            </para></listitem>
+                        <listitem><para>
+                            <link linkend='var-BUILDSDK_CXXFLAGS'><filename>BUILDSDK_CXXFLAGS</filename></link>
+                            when building for an SDK (i.e.
+                            <filename>nativesdk</filename>)
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-d'><title>D</title>
+
+        <glossentry id='var-D'><glossterm>D</glossterm>
+            <glossdef>
+                <para>
+                    The destination directory.
+                    The location in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                    where components are installed by the
+                    <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+                    task.
+                    This location defaults to:
+                    <literallayout class='monospaced'>
+     ${WORKDIR}/image
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DATETIME'><glossterm>DATETIME</glossterm>
+            <glossdef>
+                <para>
+                    The date and time on which the current build started.
+                    The format is suitable for timestamps.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DEBUG_BUILD'><glossterm>DEBUG_BUILD</glossterm>
+            <glossdef>
+                <para>
+                    Specifies to build packages with debugging information.
+                    This influences the value of the
+                    <filename><link linkend='var-SELECTED_OPTIMIZATION'>SELECTED_OPTIMIZATION</link></filename>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DEBUG_OPTIMIZATION'><glossterm>DEBUG_OPTIMIZATION</glossterm>
+            <glossdef>
+                <para>
+                    The options to pass in
+                    <filename><link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link></filename>
+                    and <filename><link linkend='var-CFLAGS'>CFLAGS</link></filename> when compiling
+                    a system for debugging.
+                    This variable defaults to "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe".
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DEFAULT_PREFERENCE'><glossterm>DEFAULT_PREFERENCE</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a weak bias for recipe selection priority.
+                </para>
+                <para>
+                    The most common usage of this is variable is to set
+                    it to "-1" within a recipe for a development version of a
+                    piece of software.
+                    Using the variable in this way causes the stable version
+                    of the recipe to build by default in the absence of
+                    <filename><link linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></filename>
+                    being used to build the development version.
+                </para>
+                <note>
+                    The bias provided by <filename>DEFAULT_PREFERENCE</filename>
+                    is weak and is overridden by
+                    <filename><link linkend='var-BBFILE_PRIORITY'>BBFILE_PRIORITY</link></filename>
+                    if that variable is different between two layers
+                    that contain different versions of the same recipe.
+                </note>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DEFAULTTUNE'><glossterm>DEFAULTTUNE</glossterm>
+            <glossdef>
+                <para>
+                    The default CPU and Application Binary Interface (ABI)
+                    tunings (i.e.  the "tune") used by the OpenEmbedded build
+                    system.
+                    The <filename>DEFAULTTUNE</filename> helps define
+                    <link linkend='var-TUNE_FEATURES'><filename>TUNE_FEATURES</filename></link>.
+                </para>
+
+                <para>
+                    The default tune is either implicitly or explicitly set
+                    by the machine
+                    (<link linkend='var-MACHINE'><filename>MACHINE</filename></link>).
+                    However, you can override the setting using available tunes
+                    as defined with
+                    <link linkend='var-AVAILTUNES'><filename>AVAILTUNES</filename></link>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DEPENDS'><glossterm>DEPENDS</glossterm>
+            <glossdef>
+                <para>
+                    Lists a recipe's build-time dependencies
+                    (i.e. other recipe files).
+                    The system ensures that all the dependencies listed
+                    have been built and have their contents in the appropriate
+                    sysroots before the recipe's configure task is executed.
+                </para>
+
+                <para>
+                    Consider this simple example for two recipes named "a" and
+                    "b" that produce similarly named packages.
+                    In this example, the <filename>DEPENDS</filename>
+                    statement appears in the "a" recipe:
+                    <literallayout class='monospaced'>
+     DEPENDS = "b"
+                    </literallayout>
+                    Here, the dependency is such that the
+                    <link linkend='ref-tasks-configure'><filename>do_configure</filename></link>
+                    task for recipe "a" depends on the
+                    <link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link>
+                    task of recipe "b".
+                    This means anything that recipe "b" puts into sysroot
+                    is available when recipe "a" is configuring itself.
+                </para>
+
+                <para>
+                    For information on runtime dependencies, see the
+                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DEPLOY_DIR'><glossterm>DEPLOY_DIR</glossterm>
+            <glossdef>
+                <para>
+                    Points to the general area that the OpenEmbedded build
+                    system uses 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>${TMPDIR}/deploy</filename>.
+                </para>
+
+                <para>
+                    For more information on the structure of the Build
+                    Directory, see
+                    "<link linkend='structure-build'>The Build Directory - <filename>build/</filename></link>"
+                    section.
+                    For more detail on the contents of the
+                    <filename>deploy</filename> directory, see the
+                    "<link linkend='images-dev-environment'>Images</link>" and
+                    "<link linkend='sdk-dev-environment'>Application Development SDK</link>"
+                    sections.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DEPLOY_DIR_IMAGE'><glossterm>DEPLOY_DIR_IMAGE</glossterm>
+            <glossdef>
+                <para>
+                    Points to the area that the OpenEmbedded build system uses
+                    to place images and other associated output files that are
+                    ready to be deployed onto the target machine.
+                    The directory is machine-specific as it contains the
+                    <filename>${MACHINE}</filename> name.
+                    By default, this directory resides within the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                    as <filename>${DEPLOY_DIR}/images/${MACHINE}/</filename>.
+                </para>
+
+                <para>
+                    For more information on the structure of the Build
+                    Directory, see
+                    "<link linkend='structure-build'>The Build Directory - <filename>build/</filename></link>"
+                    section.
+                    For more detail on the contents of the
+                    <filename>deploy</filename> directory, see the
+                    "<link linkend='images-dev-environment'>Images</link>" and
+                    "<link linkend='sdk-dev-environment'>Application Development SDK</link>"
+                    sections.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DEPLOYDIR'><glossterm>DEPLOYDIR</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-deploy'><filename>deploy</filename></link>
+                    class, the <filename>DEPLOYDIR</filename> points to a
+                    temporary work area for deployed files that is set in the
+                    <filename>deploy</filename> class as follows:
+                    <literallayout class='monospaced'>
+     DEPLOYDIR = "${WORKDIR}/deploy-${<link linkend='var-PN'><filename>PN</filename></link>}"
+                    </literallayout>
+                    Recipes inheriting the <filename>deploy</filename> class
+                    should copy files to be deployed into
+                    <filename>DEPLOYDIR</filename>, and the class will take
+                    care of copying them into
+                    <link linkend='var-DEPLOY_DIR_IMAGE'><filename>DEPLOY_DIR_IMAGE</filename></link>
+                    afterwards.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DESCRIPTION'><glossterm>DESCRIPTION</glossterm>
+            <glossdef>
+                <para>The package description used by package managers.
+                      If not set, <filename>DESCRIPTION</filename> takes
+                      the value of the
+                      <link linkend='var-SUMMARY'><filename>SUMMARY</filename></link>
+                      variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISK_SIGNATURE'><glossterm>DISK_SIGNATURE</glossterm>
+            <glossdef>
+                <para>
+                    A 32-bit MBR disk signature used by
+                    <filename>directdisk</filename> images.
+                </para>
+
+                <para>
+                    By default, the signature is set to an automatically
+                    generated random value that allows the OpenEmbedded
+                    build system to create a boot loader.
+                    You can override the signature in the image recipe
+                    by setting <filename>DISK_SIGNATURE</filename> to an
+                    8-digit hex string.
+                    You might want to override
+                    <filename>DISK_SIGNATURE</filename> if you want the disk
+                    signature to remain constant between image builds.
+                </para>
+
+                <para>
+                    When using Linux 3.8 or later, you can use
+                    <filename>DISK_SIGNATURE</filename> to specify the root
+                    by UUID to allow the kernel to locate the root device
+                    even if the device name changes due to differences in
+                    hardware configuration.
+                    By default, <filename>SYSLINUX_ROOT</filename> is set
+                    as follows:
+                    <literallayout class='monospaced'>
+     SYSLINUX_ROOT = "root=/dev/sda2"
+                    </literallayout>
+                    However, you can change this to locate the root device
+                    using the disk signature instead:
+                    <literallayout class='monospaced'>
+     SYSLINUX_ROOT = "root=PARTUUID=${DISK_SIGNATURE}-02"
+                    </literallayout>
+                </para>
+
+                <para>
+                    As previously mentioned, it is possible to set the
+                    <filename>DISK_SIGNATURE</filename> variable in your
+                    <filename>local.conf</filename> file to a fixed
+                    value if you do not want <filename>syslinux.cfg</filename>
+                    changing for each build.
+                    You might find this useful when you want to upgrade the
+                    root filesystem on a device without having to recreate or
+                    modify the master boot record.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO'><glossterm>DISTRO</glossterm>
+            <glossdef>
+                <para>
+                    The short name of the distribution.
+                    This variable corresponds to a distribution
+                    configuration file whose root name is the same as the
+                    variable's argument and whose filename extension is
+                    <filename>.conf</filename>.
+                    For example, the distribution configuration file for the
+                    Poky distribution is named <filename>poky.conf</filename>
+                    and resides in the
+                    <filename>meta-yocto/conf/distro</filename> directory of
+                    the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                </para>
+
+                <para>
+                    Within that <filename>poky.conf</filename> file, the
+                    <filename>DISTRO</filename> variable is set as follows:
+                    <literallayout class='monospaced'>
+     DISTRO = "poky"
+                    </literallayout>
+                </para>
+
+                <para>
+                    Distribution configuration files are located in a
+                    <filename>conf/distro</filename> directory within the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                    that contains the distribution configuration.
+                    The value for <filename>DISTRO</filename> must not contain
+                    spaces, and is typically all lower-case.
+                    <note>
+                        If the <filename>DISTRO</filename> variable is blank, a set
+                        of default configurations are used, which are specified
+                        within
+                        <filename>meta/conf/distro/defaultsetup.conf</filename>
+                        also in the Source Directory.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO_EXTRA_RDEPENDS'><glossterm>DISTRO_EXTRA_RDEPENDS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a list of distro-specific packages to add to all images.
+                    This variable takes affect through
+                    <filename>packagegroup-base</filename> so the
+                    variable only really applies to the more full-featured
+                    images that include <filename>packagegroup-base</filename>.
+                    You can use this variable to keep distro policy out of
+                    generic images.
+                    As with all other distro variables, you set this variable
+                    in the distro <filename>.conf</filename> file.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO_EXTRA_RRECOMMENDS'><glossterm>DISTRO_EXTRA_RRECOMMENDS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a list of distro-specific packages to add to all images
+                    if the packages exist.
+                    The packages might not exist or be empty (e.g. kernel modules).
+                    The list of packages are automatically installed but you can
+                    remove them.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO_FEATURES'><glossterm>DISTRO_FEATURES</glossterm>
+            <glossdef>
+                <para>
+                    The software support you want in your distribution for
+                    various features.
+                    You define your distribution features in the distribution
+                    configuration file.
+                </para>
+
+                <para>
+                    In most cases, the presence or absence of a feature in
+                    <filename>DISTRO_FEATURES</filename> is translated to the
+                    appropriate option supplied to the configure script
+                    during the
+                    <link linkend='ref-tasks-configure'><filename>do_configure</filename></link>
+                    task for recipes that optionally support the feature.
+                    For example, specifying "x11" in
+                    <filename>DISTRO_FEATURES</filename>, causes
+                    every piece of software built for the target that can
+                    optionally support X11 to have its X11 support enabled.
+                </para>
+
+                <para>
+                    Two more examples are Bluetooth and NFS support.
+                    For a more complete list of features that ships with the
+                    Yocto Project and that you can provide with this variable,
+                    see the
+                    "<link linkend='ref-features-distro'>Distro Features</link>"
+                    section.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO_FEATURES_BACKFILL'><glossterm>DISTRO_FEATURES_BACKFILL</glossterm>
+            <glossdef>
+                <para>Features to be added to
+                    <filename><link linkend='var-DISTRO_FEATURES'>DISTRO_FEATURES</link></filename>
+                    if not also present in
+                    <filename><link linkend='var-DISTRO_FEATURES_BACKFILL_CONSIDERED'>DISTRO_FEATURES_BACKFILL_CONSIDERED</link></filename>.
+                </para>
+
+                <para>
+                    This variable is set in the <filename>meta/conf/bitbake.conf</filename> file.
+                    It is not intended to be user-configurable.
+                    It is best to just reference the variable to see which distro features are
+                    being backfilled for all distro configurations.
+                    See the <link linkend='ref-features-backfill'>Feature backfilling</link> section for
+                    more information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO_FEATURES_BACKFILL_CONSIDERED'><glossterm>DISTRO_FEATURES_BACKFILL_CONSIDERED</glossterm>
+            <glossdef>
+                <para>Features from
+                    <filename><link linkend='var-DISTRO_FEATURES_BACKFILL'>DISTRO_FEATURES_BACKFILL</link></filename>
+                    that should not be backfilled (i.e. added to
+                    <filename><link linkend='var-DISTRO_FEATURES'>DISTRO_FEATURES</link></filename>)
+                    during the build.
+                    See the "<link linkend='ref-features-backfill'>Feature Backfilling</link>" section for
+                    more information.
+                    </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO_NAME'><glossterm>DISTRO_NAME</glossterm>
+            <glossdef>
+                <para>The long name of the distribution.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO_PN_ALIAS'><glossterm>DISTRO_PN_ALIAS</glossterm>
+            <glossdef>
+                <para>Alias names used for the recipe in various Linux distributions.</para>
+                <para>See the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-configuring-DISTRO_PN_ALIAS'>Handling
+                    a Package Name Alias</ulink>" section in the Yocto Project Development
+                    Manual for more information.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO_VERSION'><glossterm>DISTRO_VERSION</glossterm>
+            <glossdef>
+                <para>The version of the distribution.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTROOVERRIDES'><glossterm>DISTROOVERRIDES</glossterm>
+            <glossdef>
+                <para>
+                    This variable lists overrides specific to the current
+                    distribution.
+                    By default, the variable list includes the value of the
+                    <filename><link linkend='var-DISTRO'>DISTRO</link></filename>
+                    variable.
+                    You can extend the variable to apply any variable overrides
+                    you want as part of the distribution and are not
+                    already in <filename>OVERRIDES</filename> through
+                    some other means.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DL_DIR'><glossterm>DL_DIR</glossterm>
+            <glossdef>
+                <para>
+                    The central download directory used by the build process to
+                    store downloads.
+                    By default, <filename>DL_DIR</filename> gets files
+                    suitable for mirroring for everything except Git
+                    repositories.
+                    If you want tarballs of Git repositories, use the
+                    <link linkend='var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link>
+                    variable.
+                </para>
+
+                <para>
+                    You can set this directory by defining the
+                    <filename>DL_DIR</filename> variable in the
+                    <filename>conf/local.conf</filename> file.
+                    This directory is self-maintaining and you should not have
+                    to touch it.
+                    By default, the directory is <filename>downloads</filename>
+                    in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                    <literallayout class='monospaced'>
+     #DL_DIR ?= "${TOPDIR}/downloads"
+                    </literallayout>
+                    To specify a different download directory, simply remove
+                    the comment from the line and provide your directory.
+                </para>
+
+                <para>
+                    During a first build, the system downloads many different
+                    source code tarballs from various upstream projects.
+                    Downloading can take a while, particularly if your network
+                    connection is slow.
+                    Tarballs are all stored in the directory defined by
+                    <filename>DL_DIR</filename> and the build system looks there
+                    first to find source tarballs.
+                    <note>
+                        When wiping and rebuilding, you can preserve this
+                        directory to speed up this part of subsequent
+                        builds.
+                    </note>
+                </para>
+
+                <para>
+                    You can safely share this directory between multiple builds
+                    on the same development machine.
+                    For additional information on how the build process gets
+                    source files when working behind a firewall or proxy server,
+                    see this specific question in the
+                    "<link linkend='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>FAQ</link>"
+                    chapter.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DOC_COMPRESS'><glossterm>DOC_COMPRESS</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-compress_doc'><filename>compress_doc</filename></link>
+                    class, this variable sets the compression policy used when
+                    the OpenEmbedded build system compresses man pages and info
+                    pages.
+                    By default, the compression method used is gz (gzip).
+                    Other policies available are xz and bz2.
+                </para>
+
+                <para>
+                    For information on policies and on how to use this
+                    variable, see the comments in the
+                    <filename>meta/classes/compress_doc.bbclass</filename> file.
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-e'><title>E</title>
+
+        <glossentry id='var-EFI_PROVIDER'><glossterm>EFI_PROVIDER</glossterm>
+            <glossdef>
+                <para>
+                    When building bootable images (i.e. where
+                    <filename>hddimg</filename> or <filename>vmdk</filename>
+                    is in
+                    <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>),
+                    The <filename>EFI_PROVIDER</filename> variable specifies
+                    the EFI bootloader to use.
+                    The default is "grub-efi", but "gummiboot" can be used
+                    instead.
+                </para>
+
+                <para>
+                    See the
+                    <link linkend='ref-classes-gummiboot'><filename>gummiboot</filename></link>
+                    class for more information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-ENABLE_BINARY_LOCALE_GENERATION'><glossterm>ENABLE_BINARY_LOCALE_GENERATION</glossterm>
+            <glossdef>
+                <para>Variable that controls which locales for
+                    <filename>glibc</filename> are generated during the
+                    build (useful if the target device has 64Mbytes
+                    of RAM or less).</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-ERROR_QA'><glossterm>ERROR_QA</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the quality assurance checks whose failures are
+                    reported as errors by the OpenEmbedded build system.
+                    You set this variable in your distribution configuration
+                    file.
+                    For a list of the checks you can control with this variable,
+                    see the
+                    "<link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>"
+                    section.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-ERR_REPORT_DIR'><glossterm>ERR_REPORT_DIR</glossterm>
+            <glossdef>
+                <para>
+                    When used with the
+                    <link linkend='ref-classes-report-error'><filename>report-error</filename></link>
+                    class, specifies the path used for storing the debug files
+                    created by the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#using-the-error-reporting-tool'>error reporting tool</ulink>,
+                    which allows you to submit build errors you encounter to a
+                    central database.
+                    By default, the value of this variable is
+                    <filename>${</filename><link linkend='var-LOG_DIR'><filename>LOG_DIR</filename></link><filename>}/error-report</filename>.
+                </para>
+
+                <para>
+                    You can set <filename>ERR_REPORT_DIR</filename> to the path
+                    you want the error reporting tool to store the debug files
+                    as follows in your <filename>local.conf</filename> file:
+                    <literallayout class='monospaced'>
+     ERR_REPORT_DIR = "<replaceable>path</replaceable>"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXCLUDE_FROM_WORLD'><glossterm>EXCLUDE_FROM_WORLD</glossterm>
+            <glossdef>
+                <para>
+                    Directs BitBake to exclude a recipe from world builds (i.e.
+                    <filename>bitbake world</filename>).
+                    During world builds, BitBake locates, parses and builds all
+                    recipes found in every layer exposed in the
+                    <filename>bblayers.conf</filename> configuration file.
+                </para>
+
+                <para>
+                    To exclude a recipe from a world build using this variable,
+                    set the variable to "1" in the recipe.
+                </para>
+
+                <note>
+                    Recipes added to <filename>EXCLUDE_FROM_WORLD</filename>
+                    may still be built during a world build in order to satisfy
+                    dependencies of other recipes.
+                    Adding a recipe to <filename>EXCLUDE_FROM_WORLD</filename>
+                    only ensures that the recipe is not explicitly added
+                    to the list of build targets in a world build.
+                </note>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTENDPE'><glossterm>EXTENDPE</glossterm>
+            <glossdef>
+                <para>
+                    Used with file and pathnames to create a prefix for a recipe's
+                    version based on the recipe's
+                    <link linkend='var-PE'><filename>PE</filename></link> value.
+                    If <filename>PE</filename> is set and greater than zero for a recipe,
+                    <filename>EXTENDPE</filename> becomes that value (e.g if
+                    <filename>PE</filename> is equal to "1" then <filename>EXTENDPE</filename>
+                    becomes "1_").
+                    If a recipe's <filename>PE</filename> is not set (the default) or is equal to
+                    zero, <filename>EXTENDPE</filename> becomes "".</para>
+                    <para>See the <link linkend='var-STAMP'><filename>STAMP</filename></link>
+                    variable for an example.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTENDPKGV'><glossterm>EXTENDPKGV</glossterm>
+            <glossdef>
+                <para>
+                    The full package version specification as it appears on the
+                    final packages produced by a recipe.
+                    The variable's value is normally used to fix a runtime
+                    dependency to the exact same version of another package
+                    in the same recipe:
+                    <literallayout class='monospaced'>
+     RDEPENDS_${PN}-additional-module = "${PN} (= ${EXTENDPKGV})"
+                    </literallayout>
+                </para>
+
+                <para>
+                    The dependency relationships are intended to force the
+                    package manager to upgrade these types of packages in
+                    lock-step.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTERNALSRC'><glossterm>EXTERNALSRC</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-externalsrc'><filename>externalsrc</filename></link>
+                    class, this variable points to the source tree, which is
+                    outside of the OpenEmbedded build system.
+                    When set, this variable sets the
+                    <link linkend='var-S'><filename>S</filename></link>
+                    variable, which is what the OpenEmbedded build system uses
+                    to locate unpacked recipe source code.
+                </para>
+
+                <para>
+                    For more information on
+                    <filename>externalsrc.bbclass</filename>, see the
+                    "<link linkend='ref-classes-externalsrc'><filename>externalsrc.bbclass</filename></link>"
+                    section.
+                    You can also find information on how to use this variable
+                    in the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source'>Building Software from an External Source</ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTERNALSRC_BUILD'><glossterm>EXTERNALSRC_BUILD</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-externalsrc'><filename>externalsrc</filename></link>
+                    class, this variable points to the directory in which the
+                    recipe's source code is built, which is outside of the
+                    OpenEmbedded build system.
+                    When set, this variable sets the
+                    <link linkend='var-B'><filename>B</filename></link>
+                    variable, which is what the OpenEmbedded build system uses
+                    to locate the Build Directory.
+                </para>
+
+                <para>
+                    For more information on
+                    <filename>externalsrc.bbclass</filename>, see the
+                    "<link linkend='ref-classes-externalsrc'><filename>externalsrc.bbclass</filename></link>"
+                    section.
+                    You can also find information on how to use this variable
+                    in the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source'>Building Software from an External Source</ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTRA_IMAGE_FEATURES'><glossterm>EXTRA_IMAGE_FEATURES</glossterm>
+            <glossdef>
+                <para>
+                    The list of additional features to include in an image.
+                    Typically, you configure this variable in your
+                    <filename>local.conf</filename> file, which is found in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                    Although you can use this variable from within a recipe,
+                    best practices dictate that you do not.
+                    <note>
+                        To enable primary features from within the image
+                        recipe, use the
+                        <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
+                        variable.
+                    </note>
+                </para>
+
+                <para>
+                    Here are some examples of features you can add:
+                    <literallayout class='monospaced'>
+"dbg-pkgs" - Adds -dbg packages for all installed packages
+             including symbol information for debugging and
+             profiling.
+
+"debug-tweaks" - Makes an image suitable for development.
+                 For example, ssh root access has a blank
+                 password.  You should remove this feature
+                 before you produce a production image.
+
+"dev-pkgs" - Adds -dev packages for all installed packages.
+             This is useful if you want to develop against
+             the libraries in the image.
+
+"read-only-rootfs" - Creates an image whose root
+                     filesystem is read-only. See the
+                     "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem'>Creating a Read-Only Root Filesystem</ulink>"
+                     section in the Yocto Project
+                     Development Manual for more
+                     information
+
+"tools-debug" - Adds debugging tools such as gdb and
+                strace.
+
+"tools-profile" - Adds profiling tools such as oprofile,
+                  exmap, lttng and valgrind (x86 only).
+
+"tools-sdk" - Adds development tools such as gcc, make,
+              pkgconfig and so forth.
+
+"tools-testapps" - Adds useful testing tools such as
+                   ts_print, aplay, arecord and so
+                   forth.
+
+                    </literallayout>
+                </para>
+
+                <para>
+                    For a complete list of image features that ships with the
+                    Yocto Project, see the
+                    "<link linkend="ref-features-image">Image Features</link>"
+                    section.
+                </para>
+
+                <para>
+                    For an example that shows how to customize your image by
+                    using this variable, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-imagefeatures'>Customizing Images Using Custom <filename>IMAGE_FEATURES</filename> and <filename>EXTRA_IMAGE_FEATURES</filename></ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTRA_IMAGECMD'><glossterm>EXTRA_IMAGECMD</glossterm>
+            <glossdef>
+                <para>
+                    Specifies additional options for the image
+                    creation command that has been specified in
+                    <link linkend='var-IMAGE_CMD'><filename>IMAGE_CMD</filename></link>.
+                    When setting this variable, you should
+                    use an override for the associated type.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     EXTRA_IMAGECMD_ext3 ?= "-i 4096"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTRA_IMAGEDEPENDS'><glossterm>EXTRA_IMAGEDEPENDS</glossterm>
+            <glossdef>
+                <para>A list of recipes to build that do not provide packages
+                    for installing into the root filesystem.
+                </para>
+                <para>Sometimes a recipe is required to build the final image but is not
+                    needed in the root filesystem.
+                    You can use the <filename>EXTRA_IMAGEDEPENDS</filename> variable to
+                    list these recipes and thus specify the dependencies.
+                    A typical example is a required bootloader in a machine configuration.
+                </para>
+                <note>
+                    To add packages to the root filesystem, see the various
+                    <filename>*<link linkend='var-RDEPENDS'>RDEPENDS</link></filename>
+                    and <filename>*<link linkend='var-RRECOMMENDS'>RRECOMMENDS</link></filename>
+                    variables.
+                </note>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTRA_OECMAKE'><glossterm>EXTRA_OECMAKE</glossterm>
+            <glossdef>
+                <para>Additional <filename>cmake</filename> options.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTRA_OECONF'><glossterm>EXTRA_OECONF</glossterm>
+            <glossdef>
+                <para>Additional <filename>configure</filename> script options.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTRA_OEMAKE'><glossterm>EXTRA_OEMAKE</glossterm>
+            <glossdef>
+                <para>Additional GNU <filename>make</filename> options.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTRA_OESCONS'><glossterm>EXTRA_OESCONS</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-scons'><filename>scons</filename></link>
+                    class, this variable specifies additional configuration
+                    options you want to pass to the
+                    <filename>scons</filename> command line.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTRA_QMAKEVARS_POST'><glossterm>EXTRA_QMAKEVARS_POST</glossterm>
+            <glossdef>
+                <para>
+                    Configuration variables or options you want to pass to
+                    <filename>qmake</filename>.
+                    Use this variable when the arguments need to be after the
+                    <filename>.pro</filename> file list on the command line.
+                </para>
+
+                <para>
+                    This variable is used with recipes that inherit the
+                    <link linkend='ref-classes-qmake*'><filename>qmake_base</filename></link>
+                    class or other classes that inherit
+                    <filename>qmake_base</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+       <glossentry id='var-EXTRA_QMAKEVARS_PRE'><glossterm>EXTRA_QMAKEVARS_PRE</glossterm>
+            <glossdef>
+                <para>
+                    Configuration variables or options you want to pass to
+                    <filename>qmake</filename>.
+                    Use this variable when the arguments need to be before the
+                    <filename>.pro</filename> file list on the command line.
+                </para>
+
+                <para>
+                    This variable is used with recipes that inherit the
+                    <link linkend='ref-classes-qmake*'><filename>qmake_base</filename></link>
+                    class or other classes that inherit
+                    <filename>qmake_base</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTRA_USERS_PARAMS'><glossterm>EXTRA_USERS_PARAMS</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-extrausers'><filename>extrausers</filename></link>
+                    class, this variable provides image level user and group
+                    operations.
+                    This is a more global method of providing user and group
+                    configuration as compared to using the
+                    <link linkend='ref-classes-useradd'><filename>useradd</filename></link>
+                    class, which ties user and group configurations to a
+                    specific recipe.
+                </para>
+
+                <para>
+                    The set list of commands you can configure using the
+                    <filename>EXTRA_USERS_PARAMS</filename> is shown in the
+                    <filename>extrausers</filename> class.
+                    These commands map to the normal Unix commands of the same
+                    names:
+                    <literallayout class='monospaced'>
+     # EXTRA_USERS_PARAMS = "\
+     # useradd -p '' tester; \
+     # groupadd developers; \
+     # userdel nobody; \
+     # groupdel -g video; \
+     # groupmod -g 1020 developers; \
+     # usermod -s /bin/sh tester; \
+     # "
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-f'><title>F</title>
+
+        <glossentry id='var-FEATURE_PACKAGES'><glossterm>FEATURE_PACKAGES</glossterm>
+            <glossdef>
+                <para>
+                    Defines one or more packages to include in an image when
+                    a specific item is included in
+                    <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>.
+                    When setting the value, <filename>FEATURE_PACKAGES</filename>
+                    should have the name of the feature item as an override.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     FEATURE_PACKAGES_widget = "<replaceable>package1</replaceable> <replaceable>package2</replaceable>"
+                    </literallayout>
+                    In this example, if "widget" were added to
+                    <filename>IMAGE_FEATURES</filename>, <replaceable>package1</replaceable> and
+                    <replaceable>package2</replaceable> would be included in the image.
+                    <note>
+                        Packages installed by features defined through
+                        <filename>FEATURE_PACKAGES</filename> are often package
+                        groups.
+                        While similarly named, you should not confuse the
+                        <filename>FEATURE_PACKAGES</filename> variable with
+                        package groups, which are discussed elsewhere in the
+                        documentation.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-FEED_DEPLOYDIR_BASE_URI'><glossterm>FEED_DEPLOYDIR_BASE_URI</glossterm>
+            <glossdef>
+                <para>
+                    Points to the base URL of the server and location within
+                    the document-root that provides the metadata and
+                    packages required by OPKG to support runtime package
+                    management of IPK packages.
+                    You set this variable in your
+                    <filename>local.conf</filename> file.
+                </para>
+
+                <para>
+                    Consider the following example:
+                    <literallayout class='monospaced'>
+     FEED_DEPLOYDIR_BASE_URI = "http://192.168.7.1/BOARD-dir"
+                    </literallayout>
+                    This example assumes you are serving your packages over
+                    HTTP and your databases are located in a directory
+                    named <filename>BOARD-dir</filename>, which is underneath
+                    your HTTP server's document-root.
+                    In this case, the OpenEmbedded build system generates a set
+                    of configuration files for you in your target that work
+                    with the feed.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-FILES'><glossterm>FILES</glossterm>
+            <glossdef>
+                <para>
+                    The list of directories or files that are placed in packages.
+                </para>
+
+                <para>
+                    To use the <filename>FILES</filename> variable, provide a
+                    package name override that identifies the resulting package.
+                    Then, provide a space-separated list of files or paths
+                    that identify the files you want included as part of the
+                    resulting package.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     FILES_${PN} += "${bindir}/mydir1/ ${bindir}/mydir2/myfile"
+                    </literallayout>
+                </para>
+
+                <note>
+                    When specifying paths as part of the
+                    <filename>FILES</filename> variable, it is good practice
+                    to use appropriate path variables.
+                    For example, use <filename>${sysconfdir}</filename> rather
+                    than <filename>/etc</filename>, or
+                    <filename>${bindir}</filename> rather than
+                    <filename>/usr/bin</filename>.
+                    You can find a list of these variables at the top of the
+                    <filename>meta/conf/bitbake.conf</filename> file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                </note>
+
+                <para>
+                    If some of the files you provide with the
+                    <filename>FILES</filename> variable are editable and you
+                    know they should not be overwritten during the package
+                    update process by the Package Management System (PMS), you
+                    can identify these files so that the PMS will not
+                    overwrite them.
+                    See the
+                    <link linkend='var-CONFFILES'><filename>CONFFILES</filename></link>
+                    variable for information on how to identify these files to
+                    the PMS.
+                </para>
+
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-FILESEXTRAPATHS'><glossterm>FILESEXTRAPATHS</glossterm>
+            <glossdef>
+                <para>
+                    Extends the search path the OpenEmbedded build system uses
+                    when looking for files and patches as it processes recipes
+                    and append files.
+                    The default directories BitBake uses when it processes
+                    recipes are initially defined by the
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
+                    variable.
+                    You can extend <filename>FILESPATH</filename> variable
+                    by using <filename>FILESEXTRAPATHS</filename>.
+                </para>
+
+                <para>
+                    Best practices dictate that you accomplish this by using
+                    <filename>FILESEXTRAPATHS</filename> from within a
+                    <filename>.bbappend</filename> file and that you prepend
+                    paths as follows:
+                    <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+                    </literallayout>
+                    In the above example, the build system first looks for files
+                    in a directory that has the same name as the corresponding
+                    append file.
+                    <note>
+                        <para>When extending <filename>FILESEXTRAPATHS</filename>,
+                        be sure to use the immediate expansion
+                        (<filename>:=</filename>) operator.
+                        Immediate expansion makes sure that BitBake evaluates
+                        <link linkend='var-THISDIR'><filename>THISDIR</filename></link>
+                        at the time the directive is encountered rather than at
+                        some later time when expansion might result in a
+                        directory that does not contain the files you need.
+                        </para>
+                        <para>Also, include the trailing separating colon
+                        character if you are prepending.
+                        The trailing colon character is necessary because you
+                        are directing BitBake to extend the path by prepending
+                        directories to the search path.</para>
+                    </note>
+                    Here is another common use:
+                    <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+                    </literallayout>
+                    In this example, the build system extends the
+                    <filename>FILESPATH</filename> variable to include a
+                    directory named <filename>files</filename> that is in the
+                    same directory as the corresponding append file.
+                </para>
+
+                <para>
+                    Here is a final example that specifically adds three paths:
+                    <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:"
+                    </literallayout>
+                </para>
+
+                <para>
+                    By prepending paths in <filename>.bbappend</filename>
+                    files, you allow multiple append files that reside in
+                    different layers but are used for the same recipe to
+                    correctly extend the path.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-FILESOVERRIDES'><glossterm>FILESOVERRIDES</glossterm>
+            <glossdef>
+                <para>
+                    A subset of <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>
+                    used by the OpenEmbedded build system for creating
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>.
+                    You can find more information on how overrides are handled
+                    in the
+                    <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake Manual</ulink>.
+                </para>
+
+                <para>
+                    By default, the <filename>FILESOVERRIDES</filename>
+                    variable is defined as:
+                    <literallayout class='monospaced'>
+     FILESOVERRIDES = "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}"
+                    </literallayout>
+
+                    <note>
+                        Do not hand-edit the <filename>FILESOVERRIDES</filename>
+                        variable.
+                        The values match up with expected overrides and are
+                        used in an expected manner by the build system.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-FILESPATH'><glossterm>FILESPATH</glossterm>
+            <glossdef>
+                <para>
+                    The default set of directories the OpenEmbedded build system
+                    uses when searching for patches and files.
+                    During the build process, BitBake searches each directory in
+                    <filename>FILESPATH</filename> in the specified order when
+                    looking for files and patches specified by each
+                    <filename>file://</filename> URI in a recipe.
+                </para>
+
+                <para>
+                    The default value for the <filename>FILESPATH</filename>
+                    variable is defined in the <filename>base.bbclass</filename>
+                    class found in <filename>meta/classes</filename> in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
+                    <literallayout class='monospaced'>
+     FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \
+        "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
+                    </literallayout>
+                    <note>
+                        Do not hand-edit the <filename>FILESPATH</filename>
+                        variable.
+                        If you want the build system to look in directories
+                        other than the defaults, extend the
+                        <filename>FILESPATH</filename> variable by using the
+                        <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link>
+                        variable.
+                    </note>
+                    Be aware that the default <filename>FILESPATH</filename>
+                    directories do not map to directories in custom layers
+                    where append files (<filename>.bbappend</filename>)
+                    are used.
+                    If you want the build system to find patches or files
+                    that reside with your append files, you need to extend
+                    the <filename>FILESPATH</filename> variable by using
+                    the
+                    <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-FILESYSTEM_PERMS_TABLES'><glossterm>FILESYSTEM_PERMS_TABLES</glossterm>
+            <glossdef>
+                <para>Allows you to define your own file permissions settings table as part of
+                    your configuration for the packaging process.
+                    For example, suppose you need a consistent set of custom permissions for
+                    a set of groups and users across an entire work project.
+                    It is best to do this in the packages themselves but this is not always
+                    possible.
+                </para>
+                <para>
+                    By default, the OpenEmbedded build system uses the <filename>fs-perms.txt</filename>, which
+                    is located in the <filename>meta/files</filename> folder in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    If you create your own file permissions setting table, you should place it in your
+                    layer or the distro's layer.
+                </para>
+                <para>
+                    You define the <filename>FILESYSTEM_PERMS_TABLES</filename> variable in the
+                    <filename>conf/local.conf</filename> file, which is found in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>, to
+                    point to your custom <filename>fs-perms.txt</filename>.
+                    You can specify more than a single file permissions setting table.
+                    The paths you specify to these files must be defined within the
+                    <link linkend='var-BBPATH'><filename>BBPATH</filename></link> variable.
+                </para>
+                <para>
+                    For guidance on how to create your own file permissions settings table file,
+                    examine the existing <filename>fs-perms.txt</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-FONT_PACKAGES'><glossterm>FONT_PACKAGES</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-fontcache'><filename>fontcache</filename></link>
+                    class, this variable identifies packages containing font
+                    files that need to be cached by Fontconfig.
+                    By default, the <filename>fontcache</filename> class assumes
+                    that fonts are in the recipe's main package
+                    (i.e. <filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename>).
+                    Use this variable if fonts you need are in a package
+                    other than that main package.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-FULL_OPTIMIZATION'><glossterm>FULL_OPTIMIZATION</glossterm>
+            <glossdef>
+                <para>
+                    The options to pass in
+                    <filename><link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link></filename>
+                    and <filename><link linkend='var-CFLAGS'>CFLAGS</link></filename>
+                    when compiling an optimized system.
+                    This variable defaults to
+                    "-O2 -pipe ${DEBUG_FLAGS}".
+                </para>
+            </glossdef>
+        </glossentry>
+    </glossdiv>
+
+    <glossdiv id='var-glossary-g'><title>G</title>
+
+        <glossentry id='var-GLIBC_GENERATE_LOCALES'><glossterm>GLIBC_GENERATE_LOCALES</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the list of GLIBC locales to generate should you
+                    not wish generate all LIBC locals, which can be time
+                    consuming.
+                    <note>
+                        If you specifically remove the locale
+                        <filename>en_US.UTF-8</filename>, you must set
+                        <link linkend='var-IMAGE_LINGUAS'><filename>IMAGE_LINGUAS</filename></link>
+                        appropriately.
+                    </note>
+                    You can set <filename>GLIBC_GENERATE_LOCALES</filename>
+                    in your <filename>local.conf</filename> file.
+                    By default, all locales are generated.
+                    <literallayout class='monospaced'>
+      GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 en_US.UTF-8"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-GROUPADD_PARAM'><glossterm>GROUPADD_PARAM</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-useradd'><filename>useradd</filename></link>
+                    class, this variable
+                    specifies for a package what parameters should be passed
+                    to the <filename>groupadd</filename> command
+                    if you wish to add a group to the system when the package
+                    is installed.
+                </para>
+
+                <para>
+                    Here is an example from the <filename>dbus</filename>
+                    recipe:
+                    <literallayout class='monospaced'>
+     GROUPADD_PARAM_${PN} = "-r netdev"
+                    </literallayout>
+                    For information on the standard Linux shell command
+                    <filename>groupadd</filename>, see
+                    <ulink url='http://linux.die.net/man/8/groupadd'></ulink>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-GROUPMEMS_PARAM'><glossterm>GROUPMEMS_PARAM</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-useradd'><filename>useradd</filename></link>
+                    class, this variable
+                    specifies for a package what parameters should be passed
+                    to the <filename>groupmems</filename> command
+                    if you wish to modify the members of a group when the
+                    package is installed.
+                </para>
+
+                <para>
+                    For information on the standard Linux shell command
+                    <filename>groupmems</filename>, see
+                    <ulink url='http://linux.die.net/man/8/groupmems'></ulink>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-GRUB_GFXSERIAL'><glossterm>GRUB_GFXSERIAL</glossterm>
+            <glossdef>
+                <para>
+                    Configures the GNU GRand Unified Bootloader (GRUB) to have
+                    graphics and serial in the boot menu.
+                    Set this variable to "1" in your
+                    <filename>local.conf</filename> or distribution
+                    configuration file to enable graphics and serial
+                    in the menu.
+                </para>
+
+                <para>
+                    See the
+                    <link linkend='ref-classes-grub-efi'><filename>grub-efi</filename></link>
+                    class for more information on how this variable is used.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-GRUB_OPTS'><glossterm>GRUB_OPTS</glossterm>
+            <glossdef>
+                <para>
+                    Additional options to add to the GNU GRand Unified
+                    Bootloader (GRUB) configuration.
+                    Use a semi-colon character (<filename>;</filename>) to
+                    separate multiple options.
+                </para>
+
+                <para>
+                    The <filename>GRUB_OPTS</filename> variable is optional.
+                    See the
+                    <link linkend='ref-classes-grub-efi'><filename>grub-efi</filename></link>
+                    class for more information on how this variable is used.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-GRUB_TIMEOUT'><glossterm>GRUB_TIMEOUT</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the timeout before executing the default
+                    <filename>LABEL</filename> in the GNU GRand Unified
+                    Bootloader (GRUB).
+                </para>
+
+                <para>
+                    The <filename>GRUB_TIMEOUT</filename> variable is optional.
+                    See the
+                    <link linkend='ref-classes-grub-efi'><filename>grub-efi</filename></link>
+                    class for more information on how this variable is used.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-GTKIMMODULES_PACKAGES'><glossterm>GTKIMMODULES_PACKAGES</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-gtk-immodules-cache'><filename>gtk-immodules-cache</filename></link>
+                    class, this variable specifies the packages that contain the
+                    GTK+ input method modules being installed when the modules
+                    are in packages other than the main package.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-GUMMIBOOT_CFG'><glossterm>GUMMIBOOT_CFG</glossterm>
+            <glossdef>
+                <para>
+                    When
+                    <link linkend='var-EFI_PROVIDER'><filename>EFI_PROVIDER</filename></link>
+                    is set to "gummiboot", the
+                    <filename>GUMMIBOOT_CFG</filename> variable specifies the
+                    configuration file that should be used.
+                    By default, the
+                    <link linkend='ref-classes-gummiboot'><filename>gummiboot</filename></link>
+                    class sets the <filename>GUMMIBOOT_CFG</filename> as
+                    follows:
+                    <literallayout class='monospaced'>
+     GUMMIBOOT_CFG ?= "${<link linkend='var-S'>S</link>}/loader.conf"
+                    </literallayout>
+                </para>
+
+                <para>
+                    For information on Gummiboot, see the
+                    <ulink url='http://freedesktop.org/wiki/Software/gummiboot/'>Gummiboot documentation</ulink>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-GUMMIBOOT_ENTRIES'><glossterm>GUMMIBOOT_ENTRIES</glossterm>
+            <glossdef>
+                <para>
+                    When
+                    <link linkend='var-EFI_PROVIDER'><filename>EFI_PROVIDER</filename></link>
+                    is set to "gummiboot", the
+                    <filename>GUMMIBOOT_ENTRIES</filename> variable specifies
+                    a list of entry files
+                    (<filename>*.conf</filename>) to be installed
+                    containing one boot entry per file.
+                    By default, the
+                    <link linkend='ref-classes-gummiboot'><filename>gummiboot</filename></link>
+                    class sets the <filename>GUMMIBOOT_ENTRIES</filename> as
+                    follows:
+                    <literallayout class='monospaced'>
+     GUMMIBOOT_ENTRIES ?= ""
+                    </literallayout>
+                </para>
+
+                <para>
+                    For information on Gummiboot, see the
+                    <ulink url='http://freedesktop.org/wiki/Software/gummiboot/'>Gummiboot documentation</ulink>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-GUMMIBOOT_TIMEOUT'><glossterm>GUMMIBOOT_TIMEOUT</glossterm>
+            <glossdef>
+                <para>
+                    When
+                    <link linkend='var-EFI_PROVIDER'><filename>EFI_PROVIDER</filename></link>
+                    is set to "gummiboot", the
+                    <filename>GUMMIBOOT_TIMEOUT</filename> variable specifies
+                    the boot menu timeout in seconds.
+                    By default, the
+                    <link linkend='ref-classes-gummiboot'><filename>gummiboot</filename></link>
+                    class sets the <filename>GUMMIBOOT_TIMEOUT</filename> as
+                    follows:
+                    <literallayout class='monospaced'>
+     GUMMIBOOT_TIMEOUT ?= "10"
+                    </literallayout>
+                </para>
+
+                <para>
+                    For information on Gummiboot, see the
+                    <ulink url='http://freedesktop.org/wiki/Software/gummiboot/'>Gummiboot documentation</ulink>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-h'><title>H</title>
+
+        <glossentry id='var-HOMEPAGE'><glossterm>HOMEPAGE</glossterm>
+            <glossdef>
+                <para>Website where more information about the software the recipe is building
+                    can be found.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-HOST_CC_ARCH'><glossterm>HOST_CC_ARCH</glossterm>
+            <glossdef>
+                <para>
+                    Specifies architecture-specific compiler flags that are
+                    passed to the C compiler.
+                </para>
+
+                <para>
+                    Default initialization for <filename>HOST_CC_ARCH</filename>
+                    varies depending on what is being built:
+                    <itemizedlist>
+                        <listitem><para>
+                            <link linkend='var-TARGET_CC_ARCH'><filename>TARGET_CC_ARCH</filename></link>
+                            when building for the target
+                            </para></listitem>
+                        <listitem><para>
+                            <filename>BUILD_CC_ARCH</filename>
+                            when building for the build host (i.e.
+                            <filename>native</filename>)
+                            </para></listitem>
+                        <listitem><para>
+                            <filename>BUILDSDK_CC_ARCH</filename>
+                            when building for an SDK (i.e.
+                            <filename>nativesdk</filename>)
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-HOST_SYS'><glossterm>HOST_SYS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the system, including the architecture and the
+                    operating system, for with the build is occurring
+                    in the context of the current
+                    recipe.
+                    The OpenEmbedded build system automatically sets this
+                    variable.
+                    You do not need to set the variable yourself.
+                </para>
+
+                <para>
+                    Here are two examples:
+                    <itemizedlist>
+                        <listitem><para>Given a native recipe on a 32-bit
+                            x86 machine running Linux, the value is
+                            "i686-linux".
+                            </para></listitem>
+                        <listitem><para>Given a recipe being built for a
+                            little-endian MIPS target running Linux,
+                            the value might be "mipsel-linux".
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-i'><title>I</title>
+
+        <glossentry id='var-ICECC_DISABLED'><glossterm>ICECC_DISABLED</glossterm>
+            <glossdef>
+                <para>
+                    Disables or enables the <filename>icecc</filename>
+                    (Icecream) function.
+                    For more information on this function and best practices
+                    for using this variable, see the
+                    "<link linkend='ref-classes-icecc'><filename>icecc.bbclass</filename></link>"
+                    section.
+                </para>
+
+                <para>
+                    Setting this variable to "1" in your
+                    <filename>local.conf</filename> disables the function:
+                    <literallayout class='monospaced'>
+     ICECC_DISABLED ??= "1"
+                    </literallayout>
+                    To enable the function, set the variable as follows:
+                    <literallayout class='monospaced'>
+     ICECC_DISABLED = ""
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-ICECC_ENV_EXEC'><glossterm>ICECC_ENV_EXEC</glossterm>
+            <glossdef>
+                <para>
+                    Points to the <filename>icecc-create-env</filename> script
+                    that you provide.
+                    This variable is used by the
+                    <link linkend='ref-classes-icecc'><filename>icecc</filename></link>
+                    class.
+                    You set this variable in your
+                    <filename>local.conf</filename> file.
+                </para>
+
+                <para>
+                    If you do not point to a script that you provide, the
+                    OpenEmbedded build system uses the default script provided
+                    by the <filename>icecc-create-env.bb</filename> recipe,
+                    which is a modified version and not the one that comes with
+                    <filename>icecc</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-ICECC_PARALLEL_MAKE'><glossterm>ICECC_PARALLEL_MAKE</glossterm>
+            <glossdef>
+                <para>
+                    Extra options passed to the <filename>make</filename>
+                    command during the
+                    <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
+                    task that specify parallel compilation.
+                    This variable usually takes the form of
+                    <filename>-j 4</filename>, where the number
+                    represents the maximum number of parallel threads
+                    <filename>make</filename> can run.
+                    <note>
+                        The options passed affect builds on all enabled
+                        machines on the network, which are machines running the
+                        <filename>iceccd</filename> daemon.
+                    </note>
+                </para>
+
+                <para>
+                    If your enabled machines support multiple cores,
+                    coming up with the maximum number of parallel threads
+                    that gives you the best performance could take some
+                    experimentation since machine speed, network lag,
+                    available memory, and existing machine loads can all
+                    affect build time.
+                    Consequently, unlike the
+                    <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>
+                    variable, there is no rule-of-thumb for setting
+                    <filename>ICECC_PARALLEL_MAKE</filename> to achieve
+                    optimal performance.
+                </para>
+
+                <para>
+                    If you do not set <filename>ICECC_PARALLEL_MAKE</filename>,
+                    the build system does not use it (i.e. the system does
+                    not detect and assign the number of cores as is done with
+                    <filename>PARALLEL_MAKE</filename>).
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-ICECC_PATH'><glossterm>ICECC_PATH</glossterm>
+            <glossdef>
+                <para>
+                    The location of the <filename>icecc</filename> binary.
+                    You can set this variable in your
+                    <filename>local.conf</filename> file.
+                    If your <filename>local.conf</filename> file does not define
+                    this variable, the
+                    <link linkend='ref-classes-icecc'><filename>icecc</filename></link>
+                    class attempts to define it by locating
+                    <filename>icecc</filename> using <filename>which</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-ICECC_USER_CLASS_BL'><glossterm>ICECC_USER_CLASS_BL</glossterm>
+            <glossdef>
+                <para>
+                    Identifies user classes that you do not want the
+                    Icecream distributed compile support to consider.
+                    This variable is used by the
+                    <link linkend='ref-classes-icecc'><filename>icecc</filename></link>
+                    class.
+                    You set this variable in your
+                    <filename>local.conf</filename> file.
+                </para>
+
+                <para>
+                    When you list classes using this variable, you are
+                    "blacklisting" them from distributed compilation across
+                    remote hosts.
+                    Any classes you list will be distributed and compiled
+                    locally.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-ICECC_USER_PACKAGE_BL'><glossterm>ICECC_USER_PACKAGE_BL</glossterm>
+            <glossdef>
+                <para>
+                    Identifies user recipes that you do not want the
+                    Icecream distributed compile support to consider.
+                    This variable is used by the
+                    <link linkend='ref-classes-icecc'><filename>icecc</filename></link>
+                    class.
+                    You set this variable in your
+                    <filename>local.conf</filename> file.
+                </para>
+
+                <para>
+                    When you list packages using this variable, you are
+                    "blacklisting" them from distributed compilation across
+                    remote hosts.
+                    Any packages you list will be distributed and compiled
+                    locally.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-ICECC_USER_PACKAGE_WL'><glossterm>ICECC_USER_PACKAGE_WL</glossterm>
+            <glossdef>
+                <para>
+                    Identifies user recipes that use an empty
+                    <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>
+                    variable that you want to force remote distributed
+                    compilation on using the Icecream distributed compile
+                    support.
+                    This variable is used by the
+                    <link linkend='ref-classes-icecc'><filename>icecc</filename></link>
+                    class.
+                    You set this variable in your
+                    <filename>local.conf</filename> file.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_BASENAME'><glossterm>IMAGE_BASENAME</glossterm>
+            <glossdef>
+                <para>
+                    The base name of image output files.
+                    This variable defaults to the recipe name
+                    (<filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename>).
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_BOOT_FILES'><glossterm>IMAGE_BOOT_FILES</glossterm>
+            <glossdef>
+                <para>
+                    A space-separated list of files installed into the
+                    boot partition when preparing an image.
+                    By default, the files are installed under the same name as
+                    the source files.
+                    To change the installed name, separate it from the
+                    original name with a semi-colon (;).
+                    Source files need to be located in
+                    <link linkend='var-DEPLOY_DIR_IMAGE'><filename>DEPLOY_DIR_IMAGE</filename></link>.
+                    Here are two examples:
+
+                    <literallayout class="monospaced">
+     IMAGE_BOOT_FILES = "u-boot.img uImage;kernel"
+     IMAGE_BOOT_FILES = "u-boot.${UBOOT_SUFFIX} ${KERNEL_IMAGETYPE}"
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_CLASSES'><glossterm>IMAGE_CLASSES</glossterm>
+            <glossdef>
+                <para>
+                    A list of classes that all images should inherit.
+                    You typically use this variable to specify the list of
+                    classes that register the different types of images
+                    the OpenEmbedded build system creates.
+                </para>
+
+                <para>
+                    The default value for <filename>IMAGE_CLASSES</filename> is
+                    <filename>image_types</filename>.
+                    You can set this variable in your
+                    <filename>local.conf</filename> or in a distribution
+                    configuration file.
+                </para>
+
+                <para>
+                    For more information, see
+                    <filename>meta/classes/image_types.bbclass</filename> in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_CMD'><glossterm>IMAGE_CMD</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the command to create the image file for a
+                    specific image type, which corresponds to the value set
+                    set in
+                    <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>,
+                    (e.g. <filename>ext3</filename>,
+                    <filename>btrfs</filename>, and so forth).
+                    When setting this variable, you should use
+                    an override for the associated type.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} \
+        --faketime --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 \
+        ${EXTRA_IMAGECMD}"
+                    </literallayout>
+                    You typically do not need to set this variable unless
+                    you are adding support for a new image type.
+                    For more examples on how to set this variable, see the
+                    <link linkend='ref-classes-image_types'><filename>image_types</filename></link>
+                    class file, which is
+                    <filename>meta/classes/image_types.bbclass</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_DEVICE_TABLES'><glossterm>IMAGE_DEVICE_TABLES</glossterm>
+            <glossdef>
+                <para>
+                    Specifies one or more files that contain custom device
+                    tables that are passed to the
+                    <filename>makedevs</filename> command as part of creating
+                    an image.
+                    These files list basic device nodes that should be
+                    created under <filename>/dev</filename> within the image.
+                    If <filename>IMAGE_DEVICE_TABLES</filename> is not set,
+                    <filename>files/device_table-minimal.txt</filename> is
+                    used, which is located by
+                    <link linkend='var-BBPATH'><filename>BBPATH</filename></link>.
+                    For details on how you should write device table files,
+                    see <filename>meta/files/device_table-minimal.txt</filename>
+                    as an example.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_FEATURES'><glossterm>IMAGE_FEATURES</glossterm>
+            <glossdef>
+                <para>
+                    The primary list of features to include in an image.
+                    Typically, you configure this variable in an image recipe.
+                    Although you can use this variable from your
+                    <filename>local.conf</filename> file, which is found in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
+                    best practices dictate that you do not.
+                    <note>
+                        To enable extra features from outside the image recipe,
+                        use the
+                        <filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></filename> variable.
+                    </note>
+                    For a list of image features that ships with the Yocto
+                    Project, see the
+                    "<link linkend="ref-features-image">Image Features</link>"
+                    section.
+                </para>
+
+                <para>
+                    For an example that shows how to customize your image by
+                    using this variable, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-imagefeatures'>Customizing Images Using Custom <filename>IMAGE_FEATURES</filename> and <filename>EXTRA_IMAGE_FEATURES</filename></ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_FSTYPES'><glossterm>IMAGE_FSTYPES</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the formats the OpenEmbedded build system uses
+                    during the build when creating the root filesystem.
+                    For example, setting <filename>IMAGE_FSTYPES</filename>
+                    as follows causes the build system to create root
+                    filesystems using two formats: <filename>.ext3</filename>
+                    and <filename>.tar.bz2</filename>:
+                    <literallayout class='monospaced'>
+     IMAGE_FSTYPES = "ext3 tar.bz2"
+                    </literallayout>
+                    For the complete list of supported image formats from which
+                    you can choose, see
+                    <link linkend='var-IMAGE_TYPES'><filename>IMAGE_TYPES</filename></link>.
+                </para>
+
+                <note>
+                    If you add "live" to <filename>IMAGE_FSTYPES</filename>
+                    inside an image recipe, be sure that you do so prior to the
+                    "inherit image" line of the recipe or the live image will
+                    not build.
+                </note>
+
+                <note>
+                    Due to the way this variable is processed, it is not
+                    possible to update its contents using
+                    <filename>_append</filename> or
+                    <filename>_prepend</filename>. To add one or more
+                    additional options to this variable the
+                    <filename>+=</filename> operator must be used.
+                </note>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_INSTALL'><glossterm>IMAGE_INSTALL</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the packages to install into an image.
+                    The <filename>IMAGE_INSTALL</filename> variable is a
+                    mechanism for an image recipe and you should use it
+                    with care to avoid ordering issues.
+                    <note>
+                        When working with an
+                        <link linkend='images-core-image-minimal-initramfs'><filename>core-image-minimal-initramfs</filename></link>
+                        image, do not use the <filename>IMAGE_INSTALL</filename>
+                        variable to specify packages for installation.
+                        Instead, use the
+                        <link linkend='var-PACKAGE_INSTALL'><filename>PACKAGE_INSTALL</filename></link>
+                        variable, which allows the initial RAM disk (initramfs)
+                        recipe to use a fixed set of packages and not be
+                        affected by <filename>IMAGE_INSTALL</filename>.
+                    </note>
+                </para>
+
+                <para>
+                    Image recipes set <filename>IMAGE_INSTALL</filename>
+                    to specify the packages to install into an image through
+                    <filename>image.bbclass</filename>.
+                    Additionally, "helper" classes exist, such as
+                    <filename>core-image.bbclass</filename>, that can take
+                    <filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename>
+                    lists and turn these into auto-generated entries in
+                    <filename>IMAGE_INSTALL</filename> in addition to its
+                    default contents.
+                </para>
+
+                <para>
+                    Using <filename>IMAGE_INSTALL</filename> with the
+                    <filename>+=</filename> operator from the
+                    <filename>/conf/local.conf</filename> file or from within
+                    an image recipe is not recommended as it can cause ordering
+                    issues.
+                    Since <filename>core-image.bbclass</filename> sets
+                    <filename>IMAGE_INSTALL</filename> to a default value using
+                    the <filename>?=</filename> operator, using a
+                    <filename>+=</filename> operation against
+                    <filename>IMAGE_INSTALL</filename> will result in
+                    unexpected behavior when used in
+                    <filename>conf/local.conf</filename>.
+                    Furthermore, the same operation from within an image
+                    recipe may or may not succeed depending on the specific
+                    situation.
+                    In both these cases, the behavior is contrary to how most
+                    users expect the <filename>+=</filename> operator to work.
+                </para>
+
+                <para>
+                    When you use this variable, it is best to use it as follows:
+                    <literallayout class='monospaced'>
+     IMAGE_INSTALL_append = " <replaceable>package-name</replaceable>"
+                    </literallayout>
+                    Be sure to include the space between the quotation character
+                    and the start of the package name or names.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_LINGUAS'><glossterm>IMAGE_LINGUAS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the list of locales to install into the image
+                    during the root filesystem construction process.
+                    The OpenEmbedded build system automatically splits locale
+                    files, which are used for localization, into separate
+                    packages.
+                    Setting the <filename>IMAGE_LINGUAS</filename> variable
+                    ensures that any locale packages that correspond to packages
+                    already selected for installation into the image are also
+                    installed.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     IMAGE_LINGUAS = "pt-br de-de"
+                    </literallayout>
+                    In this example, the build system ensures any Brazilian
+                    Portuguese and German locale files that correspond to
+                    packages in the image are installed (i.e.
+                    <filename>*-locale-pt-br</filename>
+                    and <filename>*-locale-de-de</filename> as well as
+                    <filename>*-locale-pt</filename>
+                    and <filename>*-locale-de</filename>, since some software
+                    packages only provide locale files by language and not by
+                    country-specific language).
+                </para>
+
+                <para>
+                    See the
+                    <link linkend='var-GLIBC_GENERATE_LOCALES'><filename>GLIBC_GENERATE_LOCALES</filename></link>
+                    variable for information on generating GLIBC locales.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_MANIFEST'><glossterm>IMAGE_MANIFEST</glossterm>
+            <glossdef>
+                <para>
+                    The manifest file for the image.
+                    This file lists all the installed packages that make up
+                    the image.
+                    The file contains package information on a line-per-package
+                    basis as follows:
+                    <literallayout class='monospaced'>
+     <replaceable>packagename</replaceable> <replaceable>packagearch</replaceable> <replaceable>version</replaceable>
+                    </literallayout>
+                </para>
+
+                <para>
+                    The
+                    <link linkend='ref-classes-image'><filename>image</filename></link>
+                    class defines the manifest file as follows:
+                    <literallayout class='monospaced'>
+     IMAGE_MANIFEST = "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest"
+                    </literallayout>
+                    The location is derived using the
+                    <link linkend='var-DEPLOY_DIR_IMAGE'><filename>DEPLOY_DIR_IMAGE</filename></link>
+                    and
+                    <link linkend='var-IMAGE_NAME'><filename>IMAGE_NAME</filename></link>
+                    variables.
+                    You can find information on how the image
+                    is created in the
+                    "<link linkend='image-generation-dev-environment'>Image Generation</link>"
+                    section.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_NAME'><glossterm>IMAGE_NAME</glossterm>
+            <glossdef>
+                <para>
+                    The name of the output image files minus the extension.
+                    This variable is derived using the
+                    <link linkend='var-IMAGE_BASENAME'><filename>IMAGE_BASENAME</filename></link>,
+                    <link linkend='var-MACHINE'><filename>MACHINE</filename></link>,
+                    and
+                    <link linkend='var-DATETIME'><filename>DATETIME</filename></link>
+                    variables:
+                    <literallayout class='monospaced'>
+     IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_OVERHEAD_FACTOR'><glossterm>IMAGE_OVERHEAD_FACTOR</glossterm>
+            <glossdef>
+                <para>
+                    Defines a multiplier that the build system applies to the initial image
+                    size for cases when the multiplier times the returned disk usage value
+                    for the image is greater than the sum of
+                    <filename><link linkend='var-IMAGE_ROOTFS_SIZE'>IMAGE_ROOTFS_SIZE</link></filename>
+                    and
+                    <filename><link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'>IMAGE_ROOTFS_EXTRA_SPACE</link></filename>.
+                    The result of the multiplier applied to the initial image size creates
+                    free disk space in the image as overhead.
+                    By default, the build process uses a multiplier of 1.3 for this variable.
+                    This default value results in 30% free disk space added to the image when this
+                    method is used to determine the final generated image size.
+                    You should be aware that post install scripts and the package management
+                    system uses disk space inside this overhead area.
+                    Consequently, the multiplier does not produce an image with
+                    all the theoretical free disk space.
+                    See <filename><link linkend='var-IMAGE_ROOTFS_SIZE'>IMAGE_ROOTFS_SIZE</link></filename>
+                    for information on how the build system determines the overall image size.
+                </para>
+
+                <para>
+                    The default 30% free disk space typically gives the image enough room to boot
+                    and allows for basic post installs while still leaving a small amount of
+                    free disk space.
+                    If 30% free space is inadequate, you can increase the default value.
+                    For example, the following setting gives you 50% free space added to the image:
+                    <literallayout class='monospaced'>
+     IMAGE_OVERHEAD_FACTOR = "1.5"
+                    </literallayout>
+                </para>
+
+                <para>
+                    Alternatively, you can ensure a specific amount of free disk space is added
+                    to the image by using the
+                    <filename><link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'>IMAGE_ROOTFS_EXTRA_SPACE</link></filename>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_PKGTYPE'><glossterm>IMAGE_PKGTYPE</glossterm>
+            <glossdef>
+                <para>
+                    Defines the package type (DEB, RPM, IPK, or TAR) used
+                    by the OpenEmbedded build system.
+                    The variable is defined appropriately by the
+                    <link linkend='ref-classes-package_deb'><filename>package_deb</filename></link>,
+                    <link linkend='ref-classes-package_rpm'><filename>package_rpm</filename></link>,
+                    <link linkend='ref-classes-package_ipk'><filename>package_ipk</filename></link>,
+                    or
+                    <link linkend='ref-classes-package_tar'><filename>package_tar</filename></link>
+                    class.
+                </para>
+
+                <para>
+                    The
+                    <link linkend='ref-classes-populate-sdk-*'><filename>package_sdk_base</filename></link>
+                    and
+                    <link linkend='ref-classes-image'><filename>image</filename></link>
+                    classes use the <filename>IMAGE_PKGTYPE</filename> for
+                    packaging up images and SDKs.
+                </para>
+
+                <para>
+                    You should not set the <filename>IMAGE_PKGTYPE</filename>
+                    manually.
+                    Rather, the variable is set indirectly through the
+                    appropriate
+                    <link linkend='ref-classes-package'><filename>package_*</filename></link>
+                    class using the
+                    <link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>
+                    variable.
+                    The OpenEmbedded build system uses the first package type
+                    (e.g. DEB, RPM, or IPK) that appears with the variable
+                    <note>
+                        Files using the <filename>.tar</filename> format are
+                        never used as a substitute packaging format for DEB,
+                        RPM, and IPK formatted files for your image or SDK.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_POSTPROCESS_COMMAND'><glossterm>IMAGE_POSTPROCESS_COMMAND</glossterm>
+            <glossdef>
+                <para>
+                    Added by classes to run post processing commands once the
+                    OpenEmbedded build system has created the image.
+                    You can specify shell commands separated by semicolons:
+                    <literallayout class='monospaced'>
+     IMAGE_POSTPROCESS_COMMAND += "<replaceable>shell_command</replaceable>; ... "
+                    </literallayout>
+                    If you need to pass the path to the root filesystem within
+                    the command, you can use
+                    <filename>${IMAGE_ROOTFS}</filename>, which points to
+                    the root filesystem image.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_ROOTFS'><glossterm>IMAGE_ROOTFS</glossterm>
+            <glossdef>
+                <para>
+                    The location of the root filesystem while it is under
+                    construction (i.e. during the
+                    <link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>
+                    task).
+                    This variable is not configurable.
+                    Do not change it.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_ROOTFS_ALIGNMENT'><glossterm>IMAGE_ROOTFS_ALIGNMENT</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the alignment for the output image file in
+                    Kbytes.
+                    If the size of the image is not a multiple of
+                    this value, then the size is rounded up to the nearest
+                    multiple of the value.
+                    The default value is "1".
+                    See
+                    <link linkend='var-IMAGE_ROOTFS_SIZE'><filename>IMAGE_ROOTFS_SIZE</filename></link>
+                    for additional information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_ROOTFS_EXTRA_SPACE'><glossterm>IMAGE_ROOTFS_EXTRA_SPACE</glossterm>
+            <glossdef>
+                <para>
+                    Defines additional free disk space created in the image in Kbytes.
+                    By default, this variable is set to "0".
+                    This free disk space is added to the image after the build system determines
+                    the image size as described in
+                    <filename><link linkend='var-IMAGE_ROOTFS_SIZE'>IMAGE_ROOTFS_SIZE</link></filename>.
+                </para>
+
+                <para>
+                    This variable is particularly useful when you want to ensure that a
+                    specific amount of free disk space is available on a device after an image
+                    is installed and running.
+                    For example, to be sure 5 Gbytes of free disk space is available, set the
+                    variable as follows:
+                    <literallayout class='monospaced'>
+     IMAGE_ROOTFS_EXTRA_SPACE = "5242880"
+                    </literallayout>
+                </para>
+
+                <para>
+                    For example, the Yocto Project Build Appliance specifically requests 40 Gbytes
+                    of extra space with the line:
+                    <literallayout class='monospaced'>
+     IMAGE_ROOTFS_EXTRA_SPACE = "41943040"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_ROOTFS_SIZE'><glossterm>IMAGE_ROOTFS_SIZE</glossterm>
+            <glossdef>
+                <para>
+                    Defines the size in Kbytes for the generated image.
+                    The OpenEmbedded build system determines the final size for the generated
+                    image using an algorithm that takes into account the initial disk space used
+                    for the generated image, a requested size for the image, and requested
+                    additional free disk space to be added to the image.
+                    Programatically, the build system determines the final size of the
+                    generated image as follows:
+                    <literallayout class='monospaced'>
+    if (image-du * overhead) &lt; rootfs-size:
+        internal-rootfs-size = rootfs-size + xspace
+    else:
+        internal-rootfs-size = (image-du * overhead) + xspace
+
+    where:
+
+      image-du = Returned value of the du command on
+                 the image.
+
+      overhead = IMAGE_OVERHEAD_FACTOR
+
+      rootfs-size = IMAGE_ROOTFS_SIZE
+
+      internal-rootfs-size = Initial root filesystem
+                             size before any modifications.
+
+      xspace = IMAGE_ROOTFS_EXTRA_SPACE
+                    </literallayout>
+                    See the <link linkend='var-IMAGE_OVERHEAD_FACTOR'><filename>IMAGE_OVERHEAD_FACTOR</filename></link>
+                    and <link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'><filename>IMAGE_ROOTFS_EXTRA_SPACE</filename></link>
+                    variables for related information.
+<!--                    In the above example, <filename>overhead</filename> is defined by the
+                    <filename><link linkend='var-IMAGE_OVERHEAD_FACTOR'>IMAGE_OVERHEAD_FACTOR</link></filename>
+                    variable, <filename>xspace</filename> is defined by the
+                    <filename><link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'>IMAGE_ROOTFS_EXTRA_SPACE</link></filename>
+                    variable, and <filename>du</filename> is the results of the disk usage command
+                    on the initially generated image. -->
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_TYPEDEP'><glossterm>IMAGE_TYPEDEP</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a dependency from one image type on another.
+                    Here is an example from the
+                    <link linkend='ref-classes-image-live'><filename>image-live</filename></link>
+                    class:
+                    <literallayout class='monospaced'>
+     IMAGE_TYPEDEP_live = "ext3"
+                    </literallayout>
+                    In the previous example, the variable ensures that when
+                    "live" is listed with the
+                    <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
+                    variable, the OpenEmbedded build system produces an
+                    <filename>ext3</filename> image first since one of the
+                    components of the live
+                    image is an <filename>ext3</filename>
+                    formatted partition containing the root
+                    filesystem.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_TYPES'><glossterm>IMAGE_TYPES</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the complete list of supported image types
+                    by default:
+                    <literallayout class='monospaced'>
+     jffs2
+     jffs2.sum
+     cramfs
+     ext2
+     ext2.gz
+     ext2.bz2
+     ext3
+     ext3.gz
+     ext2.lzma
+     btrfs
+     live
+     squashfs
+     squashfs-xz
+     ubi
+     ubifs
+     tar
+     tar.gz
+     tar.bz2
+     tar.xz
+     cpio
+     cpio.gz
+     cpio.xz
+     cpio.lzma
+     vmdk
+     elf
+                    </literallayout>
+                    For more information about these types of images, see
+                    <filename>meta/classes/image_types*.bbclass</filename>
+                    in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INC_PR'><glossterm>INC_PR</glossterm>
+            <glossdef>
+                <para>Helps define the recipe revision for recipes that share
+                    a common <filename>include</filename> file.
+                    You can think of this variable as part of the recipe revision
+                    as set from within an include file.</para>
+                <para>Suppose, for example, you have a set of recipes that
+                    are used across several projects.
+                    And, within each of those recipes the revision
+                    (its <link linkend='var-PR'><filename>PR</filename></link>
+                    value) is set accordingly.
+                    In this case, when the revision of those recipes changes,
+                    the burden is on you to find all those recipes and
+                    be sure that they get changed to reflect the updated
+                    version of the recipe.
+                    In this scenario, it can get complicated when recipes
+                    that are used in many places and provide common functionality
+                    are upgraded to a new revision.</para>
+                <para>A more efficient way of dealing with this situation is
+                    to set the <filename>INC_PR</filename> variable inside
+                    the <filename>include</filename> files that the recipes
+                    share and then expand the <filename>INC_PR</filename>
+                    variable within the recipes to help
+                    define the recipe revision.
+                    </para>
+                <para>
+                    The following provides an example that shows how to use
+                    the <filename>INC_PR</filename> variable
+                    given a common <filename>include</filename> file that
+                    defines the variable.
+                    Once the variable is defined in the
+                    <filename>include</filename> file, you can use the
+                    variable to set the <filename>PR</filename> values in
+                    each recipe.
+                    You will notice that when you set a recipe's
+                    <filename>PR</filename> you can provide more granular
+                    revisioning by appending values to the
+                    <filename>INC_PR</filename> variable:
+                    <literallayout class='monospaced'>
+recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
+recipes-graphics/xorg-font/encodings_1.0.4.bb:PR = "${INC_PR}.1"
+recipes-graphics/xorg-font/font-util_1.3.0.bb:PR = "${INC_PR}.0"
+recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
+                    </literallayout>
+                    The first line of the example establishes the baseline
+                    revision to be used for all recipes that use the
+                    <filename>include</filename> file.
+                    The remaining lines in the example are from individual
+                    recipes and show how the <filename>PR</filename> value
+                    is set.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INCOMPATIBLE_LICENSE'><glossterm>INCOMPATIBLE_LICENSE</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a space-separated list of license names
+                    (as they would appear in
+                    <link linkend='var-LICENSE'><filename>LICENSE</filename></link>)
+                    that should be excluded from the build.
+                    Recipes that provide no alternatives to listed incompatible
+                    licenses are not built.
+                    Packages that are individually licensed with the specified
+                    incompatible licenses will be deleted.
+                </para>
+
+                <note>
+                    This functionality is only regularly tested using
+                    the following setting:
+                    <literallayout class='monospaced'>
+     INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3.0"
+                    </literallayout>
+                    Although you can use other settings, you might be required
+                    to remove dependencies on or provide alternatives to
+                    components that are required to produce a functional system
+                    image.
+                </note>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INHIBIT_DEFAULT_DEPS'><glossterm>INHIBIT_DEFAULT_DEPS</glossterm>
+            <glossdef>
+                <para>
+                    Prevents the default dependencies, namely the C compiler
+                    and standard C library (libc), from being added to
+                    <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>.
+                    This variable is usually used within recipes that do not
+                    require any compilation using the C compiler.
+                </para>
+
+                <para>
+                    Set the variable to "1" to prevent the default dependencies
+                    from being added.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INHIBIT_PACKAGE_DEBUG_SPLIT'><glossterm>INHIBIT_PACKAGE_DEBUG_SPLIT</glossterm>
+            <glossdef>
+
+                <para>
+                    Prevents the OpenEmbedded build system from splitting
+                    out debug information during packaging.
+                    By default, the build system splits out debugging
+                    information during the
+                    <link linkend='ref-tasks-package'><filename>do_package</filename></link>
+                    task.
+                    For more information on how debug information is split out,
+                    see the
+                    <link linkend='var-PACKAGE_DEBUG_SPLIT_STYLE'><filename>PACKAGE_DEBUG_SPLIT_STYLE</filename></link>
+                    variable.
+                </para>
+
+                <para>
+                    To prevent the build system from splitting out
+                    debug information during packaging, set the
+                    <filename>INHIBIT_PACKAGE_DEBUG_SPLIT</filename> variable
+                    as follows:
+                    <literallayout class='monospaced'>
+     INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INHIBIT_PACKAGE_STRIP'><glossterm>INHIBIT_PACKAGE_STRIP</glossterm>
+            <glossdef>
+                <para>
+                    If set to "1", causes the build to not strip binaries in resulting packages.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INHERIT'><glossterm>INHERIT</glossterm>
+            <glossdef>
+                <para>
+                    Causes the named class to be inherited at
+                    this point during parsing.
+                    The variable is only valid in configuration files.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INHERIT_DISTRO'><glossterm>INHERIT_DISTRO</glossterm>
+            <glossdef>
+                <para>
+                    Lists classes that will be inherited at the
+                    distribution level.
+                    It is unlikely that you want to edit this variable.
+                </para>
+
+                <para>
+                    The default value of the variable is set as follows in the
+                    <filename>meta/conf/distro/defaultsetup.conf</filename>
+                    file:
+                    <literallayout class='monospaced'>
+     INHERIT_DISTRO ?= "debian devshell sstate license"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INITRAMFS_FSTYPES'><glossterm>INITRAMFS_FSTYPES</glossterm>
+            <glossdef>
+                <para>
+                    Defines the format for the output image of an initial
+                    RAM disk (initramfs), which is used during boot.
+                    Supported formats are the same as those supported by the
+                    <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INITRAMFS_IMAGE'><glossterm>INITRAMFS_IMAGE</glossterm>
+            <glossdef>
+                <para>
+                    Causes the OpenEmbedded build system to build an additional
+                    recipe as a dependency to your root filesystem recipe
+                    (e.g. <filename>core-image-sato</filename>).
+                    The additional recipe is used to create an initial RAM disk
+                    (initramfs) that might be needed during the initial boot of
+                    the target system to accomplish such things as loading
+                    kernel modules prior to mounting the root file system.
+                </para>
+
+                <para>
+                    When you set the variable, specify the name of the
+                    initramfs you want created.
+                    The following example, which is set in the
+                    <filename>local.conf</filename> configuration file, causes
+                    a separate recipe to be created that results in an
+                    initramfs image named
+                    <filename>core-image-sato-initramfs.bb</filename> to be
+                    created:
+                    <literallayout class='monospaced'>
+     INITRAMFS_IMAGE = "core-image-minimal-initramfs"
+                    </literallayout>
+                    By default, the
+                    <link linkend='ref-classes-kernel'><filename>kernel</filename></link>
+                    class sets this variable to a null string as follows:
+                    <literallayout class='monospaced'>
+     INITRAMFS_IMAGE = ""
+                    </literallayout>
+                </para>
+
+                <para>
+                    See the
+                    <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-yocto/conf/local.conf.sample.extended'><filename>local.conf.sample.extended</filename></ulink>
+                    file for additional information.
+                    You can also reference the
+                    <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass'><filename>kernel.bbclass</filename></ulink>
+                    file to see how the variable is used.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INITRAMFS_IMAGE_BUNDLE'><glossterm>INITRAMFS_IMAGE_BUNDLE</glossterm>
+            <glossdef>
+                <para>
+                    Controls whether or not the image recipe specified by
+                    <link linkend='var-INITRAMFS_IMAGE'><filename>INITRAMFS_IMAGE</filename></link>
+                    is run through an extra pass during kernel compilation
+                    in order to build a single binary that contains both the
+                    kernel image and the initial RAM disk (initramfs).
+                    Using an extra compilation pass ensures that when a kernel
+                    attempts to use an initramfs, it does not encounter
+                    circular dependencies should the initramfs include kernel
+                    modules.
+                </para>
+
+                <para>
+                    The combined binary is deposited into the
+                    <filename>tmp/deploy</filename> directory, which is part
+                    of the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                </para>
+
+                <para>
+                    Setting the variable to "1" in a configuration file causes
+                    the OpenEmbedded build system to make the extra pass during
+                    kernel compilation:
+                    <literallayout class='monospaced'>
+     INITRAMFS_IMAGE_BUNDLE = "1"
+                    </literallayout>
+                    By default, the
+                    <link linkend='ref-classes-kernel'><filename>kernel</filename></link>
+                    class sets this variable to a null string as follows:
+                    <literallayout class='monospaced'>
+     INITRAMFS_IMAGE_BUNDLE = ""
+                    </literallayout>
+                    <note>
+                        You must set the
+                        <filename>INITRAMFS_IMAGE_BUNDLE</filename> variable in
+                        a configuration file.
+                        You cannot set the variable in a recipe file.
+                    </note>
+                    See the
+                    <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-yocto/conf/local.conf.sample.extended'><filename>local.conf.sample.extended</filename></ulink>
+                    file for additional information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INITRD'><glossterm>INITRD</glossterm>
+            <glossdef>
+                <para>
+                    Indicates list of filesystem images to concatenate and use
+                    as an initial RAM disk (<filename>initrd</filename>).
+                </para>
+
+                <para>
+                    The <filename>INITRD</filename> variable is an optional
+                    variable used with the
+                    <link linkend='ref-classes-bootimg'><filename>bootimg</filename></link>
+                    class.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INITRD_IMAGE'><glossterm>INITRD_IMAGE</glossterm>
+            <glossdef>
+                <para>
+                    When building a "live" bootable image (i.e. when
+                    <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
+                    contains "live"), <filename>INITRD_IMAGE</filename>
+                    specifies the image recipe that should be built
+                    to provide the initial RAM disk image.
+                    The default value is "core-image-minimal-initramfs".
+                </para>
+
+                <para>
+                    See the
+                    <link linkend='ref-classes-image-live'><filename>image-live</filename></link>
+                    class for more information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INITSCRIPT_NAME'><glossterm>INITSCRIPT_NAME</glossterm>
+            <glossdef>
+                <para>
+                    The filename of the initialization script as installed to
+                    <filename>${sysconfdir}/init.d</filename>.
+                </para>
+                <para>
+                    This variable is used in recipes when using <filename>update-rc.d.bbclass</filename>.
+                    The variable is mandatory.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INITSCRIPT_PACKAGES'><glossterm>INITSCRIPT_PACKAGES</glossterm>
+            <glossdef>
+                <para>
+                    A list of the packages that contain initscripts.
+                    If multiple packages are specified, you need to append the package name
+                    to the other <filename>INITSCRIPT_*</filename> as an override.</para>
+                 <para>
+                    This variable is used in recipes when using <filename>update-rc.d.bbclass</filename>.
+                    The variable is optional and defaults to the
+                    <link linkend='var-PN'><filename>PN</filename></link> variable.
+                </para>
+           </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INITSCRIPT_PARAMS'><glossterm>INITSCRIPT_PARAMS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the options to pass to <filename>update-rc.d</filename>.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     INITSCRIPT_PARAMS = "start 99 5 2 . stop 20 0 1 6 ."
+                    </literallayout>
+                    In this example, the script has a runlevel of 99,
+                    starts the script in initlevels 2 and 5, and
+                    stops the script in levels 0, 1 and 6.
+                </para>
+                <para>
+                    The variable's default value is "defaults", which is
+                    set in the
+                    <link linkend='ref-classes-update-rc.d'><filename>update-rc.d</filename></link>
+                    class.
+                </para>
+                <para>
+                    The value in
+                    <filename>INITSCRIPT_PARAMS</filename> is passed through
+                    to the <filename>update-rc.d</filename> command.
+                    For more information on valid parameters, please see the
+                    <filename>update-rc.d</filename> manual page at
+                    <ulink url='http://www.tin.org/bin/man.cgi?section=8&amp;topic=update-rc.d'></ulink>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INSANE_SKIP'><glossterm>INSANE_SKIP</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the QA checks to skip for a specific package
+                    within a recipe.
+                    For example, to skip the check for symbolic link
+                    <filename>.so</filename> files in the main package of a
+                    recipe, add the following to the recipe.
+                    The package name override must be used, which in this
+                    example is <filename>${PN}</filename>:
+                    <literallayout class='monospaced'>
+     INSANE_SKIP_${PN} += "dev-so"
+                    </literallayout>
+                </para>
+                <para>
+                    See the "<link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>"
+                    section for a list of the valid QA checks you can
+                    specify using this variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IPK_FEED_URIS'><glossterm>IPK_FEED_URIS</glossterm>
+            <glossdef>
+                <para>
+                    When the IPK backend is in use and package management
+                    is enabled on the target, you can use this variable to
+                    set up <filename>opkg</filename> in the target image
+                    to point to package feeds on a nominated server.
+                    Once the feed is established, you can perform
+                    installations or upgrades using the package manager
+                    at runtime.
+                </para>
+            </glossdef>
+        </glossentry>
+
+<!--
+        <glossentry id='var-INTERCEPT_DIR'><glossterm>INTERCEPT_DIR</glossterm>
+            <glossdef>
+                <para>
+                    An environment variable that defines the directory where
+                    post installation hooks are installed for the
+                    post install environment.
+                    This variable is fixed as follows:
+                    <literallayout class='monospaced'>
+     ${WORKDIR}/intercept_scripts
+                    </literallayout>
+                </para>
+
+                <para>
+                    After installation of a target's root filesystem,
+                    post installation scripts, which are essentially bash scripts,
+                    are all executed just a single time.
+                    Limiting execution of these scripts minimizes installation
+                    time that would be lengthened due to  certain packages
+                    triggering redundant operations.
+                    For example, consider the installation of font packages
+                    as a common example.
+                    Without limiting the execution of post installation scripts,
+                    all font directories would be rescanned to create the
+                    cache after each individual font package was installed.
+                </para>
+
+                <para>
+                    Do not edit the <filename>INTERCEPT_DIR</filename>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+-->
+
+    </glossdiv>
+
+<!--            <glossdiv id='var-glossary-j'><title>J</title>-->
+<!--            </glossdiv>-->
+
+   <glossdiv id='var-glossary-k'><title>K</title>
+
+        <glossentry id='var-KARCH'><glossterm>KARCH</glossterm>
+            <glossdef>
+                <para>
+                    Defines the kernel architecture used when assembling
+                    the configuration.
+                    Architectures supported for this release are:
+                    <literallayout class='monospaced'>
+     powerpc
+     i386
+     x86_64
+     arm
+     qemu
+     mips
+                    </literallayout>
+                </para>
+
+                <para>
+                    You define the <filename>KARCH</filename> variable in the
+                    <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#bsp-descriptions'>BSP Descriptions</ulink>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KBRANCH'><glossterm>KBRANCH</glossterm>
+            <glossdef>
+                <para>
+                    A regular expression used by the build process to explicitly
+                    identify the kernel branch that is validated, patched
+                    and configured during a build.
+                    The <filename>KBRANCH</filename> variable is optional.
+                    You can use it to trigger checks to ensure the exact kernel
+                    branch you want is being used by the build process.
+                </para>
+
+                <para>
+                    Values for this variable are set in the kernel's recipe
+                    file and the kernel's append file.
+                    For example, if you are using the Yocto Project kernel that
+                    is based on the Linux 3.10 kernel, the kernel recipe file
+                    is the
+                    <filename>meta/recipes-kernel/linux/linux-yocto_3.10.bb</filename>
+                    file.
+                    Following is the default value for <filename>KBRANCH</filename>
+                    and the default override for the architectures the Yocto
+                    Project supports:
+                    <literallayout class='monospaced'>
+     KBRANCH_DEFAULT = "standard/base"
+     KBRANCH = "${KBRANCH_DEFAULT}"
+                    </literallayout>
+                    This branch exists in the <filename>linux-yocto-3.10</filename>
+                    kernel Git repository
+                    <ulink url='&YOCTO_GIT_URL;/cgit.cgi/linux-yocto-3.10/refs/heads'></ulink>.
+                </para>
+
+                <para>
+                    This variable is also used from the kernel's append file
+                    to identify the kernel branch specific to a particular
+                    machine or target hardware.
+                    The kernel's append file is located in the BSP layer for
+                    a given machine.
+                    For example, the kernel append file for the Crown Bay BSP is in the
+                    <filename>meta-intel</filename> Git repository and is named
+                    <filename>meta-crownbay/recipes-kernel/linux/linux-yocto_3.10.bbappend</filename>.
+                    Here are the related statements from the append file:
+                    <literallayout class='monospaced'>
+     COMPATIBLE_MACHINE_crownbay = "crownbay"
+     KMACHINE_crownbay = "crownbay"
+     KBRANCH_crownbay = "standard/crownbay"
+     KERNEL_FEATURES_append_crownbay = " features/drm-emgd/drm-emgd-1.18 cfg/vesafb"
+
+     COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
+     KMACHINE_crownbay-noemgd = "crownbay"
+     KBRANCH_crownbay-noemgd = "standard/crownbay"
+     KERNEL_FEATURES_append_crownbay-noemgd = " cfg/vesafb"
+                    </literallayout>
+                        The <filename>KBRANCH_*</filename> statements identify
+                        the kernel branch to use when building for the Crown
+                        Bay BSP.
+                        In this case there are two identical statements: one
+                        for each type of Crown Bay machine.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KBRANCH_DEFAULT'><glossterm>KBRANCH_DEFAULT</glossterm>
+            <glossdef>
+                <para>
+                    Defines the Linux kernel source repository's default
+                    branch used to build the Linux kernel.
+                    The <filename>KBRANCH_DEFAULT</filename> value is
+                    the default value for
+                    <link linkend='var-KBRANCH'><filename>KBRANCH</filename></link>.
+                    Unless you specify otherwise,
+                    <filename>KBRANCH_DEFAULT</filename> initializes to
+                    "master".
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KERNEL_EXTRA_ARGS'><glossterm>KERNEL_EXTRA_ARGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies additional <filename>make</filename>
+                    command-line arguments the OpenEmbedded build system
+                    passes on when compiling the kernel.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KERNEL_FEATURES'><glossterm>KERNEL_FEATURES</glossterm>
+            <glossdef>
+                <para>Includes additional metadata from the Yocto Project kernel Git repository.
+                    In the OpenEmbedded build system, the default Board Support Packages (BSPs)
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                    is provided through
+                    the <link linkend='var-KMACHINE'><filename>KMACHINE</filename></link>
+                    and <link linkend='var-KBRANCH'><filename>KBRANCH</filename></link> variables.
+                    You can use the <filename>KERNEL_FEATURES</filename> variable to further
+                    add metadata for all BSPs.</para>
+                <para>The metadata you add through this variable includes config fragments and
+                    features descriptions,
+                    which usually includes patches as well as config fragments.
+                    You typically override the <filename>KERNEL_FEATURES</filename> variable
+                    for a specific machine.
+                    In this way, you can provide validated, but optional, sets of kernel
+                    configurations and features.</para>
+                <para>For example, the following adds <filename>netfilter</filename> to all
+                    the Yocto Project kernels and adds sound support to the <filename>qemux86</filename>
+                    machine:
+                    <literallayout class='monospaced'>
+     # Add netfilter to all linux-yocto kernels
+     KERNEL_FEATURES="features/netfilter"
+
+     # Add sound support to the qemux86 machine
+     KERNEL_FEATURES_append_qemux86=" cfg/sound"
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KERNEL_IMAGE_BASE_NAME'><glossterm>KERNEL_IMAGE_BASE_NAME</glossterm>
+            <glossdef>
+                <para>
+                    The base name of the kernel image.
+                    This variable is set in the
+                    <link linkend='ref-classes-kernel'>kernel</link> class
+                    as follows:
+                    <literallayout class='monospaced'>
+     KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
+                    </literallayout>
+                    See the
+                    <link linkend='var-KERNEL_IMAGETYPE'><filename>KERNEL_IMAGETYPE</filename></link>,
+                    <link linkend='var-PKGE'><filename>PKGE</filename></link>,
+                    <link linkend='var-PKGV'><filename>PKGV</filename></link>,
+                    <link linkend='var-PKGR'><filename>PKGR</filename></link>,
+                    <link linkend='var-MACHINE'><filename>MACHINE</filename></link>,
+                    and
+                    <link linkend='var-DATETIME'><filename>DATETIME</filename></link>
+                    variables for additional information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KERNEL_IMAGETYPE'><glossterm>KERNEL_IMAGETYPE</glossterm>
+            <glossdef>
+                <para>The type of kernel to build for a device, usually set by the
+                    machine configuration files and defaults to "zImage".
+                    This variable is used
+                    when building the kernel and is passed to <filename>make</filename> as the target to
+                    build.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KERNEL_MODULE_AUTOLOAD'><glossterm>KERNEL_MODULE_AUTOLOAD</glossterm>
+            <glossdef>
+                <para>
+                    Lists kernel modules that need to be auto-loaded during
+                    boot.
+                    <note>
+                        This variable replaces the deprecated
+                        <link linkend='var-module_autoload'><filename>module_autoload</filename></link>
+                        variable.
+                    </note>
+                </para>
+
+                <para>
+                    You can use the <filename>KERNEL_MODULE_AUTOLOAD</filename>
+                    variable anywhere that it can be
+                    recognized by the kernel recipe or by an out-of-tree kernel
+                    module recipe (e.g. a machine configuration file, a
+                    distribution configuration file, an append file for the
+                    recipe, or the recipe itself).
+                </para>
+
+                <para>
+                    Specify it as follows:
+                    <literallayout class='monospaced'>
+     KERNEL_MODULE_AUTOLOAD += "<replaceable>module_name1</replaceable> <replaceable>module_name2</replaceable> <replaceable>module_name3</replaceable>"
+                    </literallayout>
+                </para>
+
+                <para>
+                    Including <filename>KERNEL_MODULE_AUTOLOAD</filename> causes
+                    the OpenEmbedded build system to populate the
+                    <filename>/etc/modules-load.d/modname.conf</filename>
+                    file with the list of modules to be auto-loaded on boot.
+                    The modules appear one-per-line in the file.
+                    Here is an example of the most common use case:
+                    <literallayout class='monospaced'>
+     KERNEL_MODULE_AUTOLOAD += "<replaceable>module_name</replaceable>"
+                    </literallayout>
+                </para>
+
+                <para>
+                    For information on how to populate the
+                    <filename>modname.conf</filename> file with
+                    <filename>modprobe.d</filename> syntax lines, see the
+                    <link linkend='var-KERNEL_MODULE_PROBECONF'><filename>KERNEL_MODULE_PROBECONF</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KERNEL_MODULE_PROBECONF'><glossterm>KERNEL_MODULE_PROBECONF</glossterm>
+            <glossdef>
+                <para>
+                    Provides a list of modules for which the OpenEmbedded
+                    build system expects to find
+                    <filename>module_conf_</filename><replaceable>modname</replaceable>
+                    values that specify configuration for each of the modules.
+                    For information on how to provide those module
+                    configurations, see the
+                    <link linkend='var-module_conf'><filename>module_conf_*</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KERNEL_PATH'><glossterm>KERNEL_PATH</glossterm>
+            <glossdef>
+                <para>
+                    The location of the kernel sources.
+                    This variable is set to the value of the
+                    <link linkend='var-STAGING_KERNEL_DIR'><filename>STAGING_KERNEL_DIR</filename></link>
+                    within the
+                    <link linkend='ref-classes-module'><filename>module</filename></link>
+                    class.
+                    For information on how this variable is used, see the
+                    "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules'>Incorporating Out-of-Tree Modules</ulink>"
+                    section.
+                </para>
+
+                <para>
+                    To help maximize compatibility with out-of-tree drivers
+                    used to build modules, the OpenEmbedded build system also
+                    recognizes and uses the
+                    <link linkend='var-KERNEL_SRC'><filename>KERNEL_SRC</filename></link>
+                    variable, which is identical to the
+                    <filename>KERNEL_PATH</filename> variable.
+                    Both variables are common variables used by external
+                    Makefiles to point to the kernel source directory.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KERNEL_SRC'><glossterm>KERNEL_SRC</glossterm>
+            <glossdef>
+                <para>
+                    The location of the kernel sources.
+                    This variable is set to the value of the
+                    <link linkend='var-STAGING_KERNEL_DIR'><filename>STAGING_KERNEL_DIR</filename></link>
+                    within the
+                    <link linkend='ref-classes-module'><filename>module</filename></link>
+                    class.
+                    For information on how this variable is used, see the
+                    "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules'>Incorporating Out-of-Tree Modules</ulink>"
+                    section.
+                </para>
+
+                <para>
+                    To help maximize compatibility with out-of-tree drivers
+                    used to build modules, the OpenEmbedded build system also
+                    recognizes and uses the
+                    <link linkend='var-KERNEL_PATH'><filename>KERNEL_PATH</filename></link>
+                    variable, which is identical to the
+                    <filename>KERNEL_SRC</filename> variable.
+                    Both variables are common variables used by external
+                    Makefiles to point to the kernel source directory.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KFEATURE_DESCRIPTION'><glossterm>KFEATURE_DESCRIPTION</glossterm>
+            <glossdef>
+                <para>
+                    Provides a short description of a configuration fragment.
+                    You use this variable in the <filename>.scc</filename>
+                    file that describes a configuration fragment file.
+                    Here is the variable used in a file named
+                    <filename>smp.scc</filename> to describe SMP being
+                    enabled:
+                    <literallayout class='monospaced'>
+     define KFEATURE_DESCRIPTION "Enable SMP"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KMACHINE'><glossterm>KMACHINE</glossterm>
+            <glossdef>
+                <para>
+                    The machine as known by the kernel.
+                    Sometimes the machine name used by the kernel does not match the machine name
+                    used by the OpenEmbedded build system.
+                    For example, the machine name that the OpenEmbedded build system understands as
+                    <filename>qemuarm</filename> goes by a different name in the Linux Yocto kernel.
+                    The kernel understands that machine as <filename>arm_versatile926ejs</filename>.
+                    For cases like these, the <filename>KMACHINE</filename> variable maps the
+                    kernel machine name to the OpenEmbedded build system machine name.
+                </para>
+
+                <para>
+                    Kernel machine names are initially defined in the
+                    Yocto Linux Kernel's <filename>meta</filename> branch.
+                    From the <filename>meta</filename> branch, look in
+                    the <filename>meta/cfg/kernel-cache/bsp/&lt;bsp_name&gt;/&lt;bsp-name&gt;-&lt;kernel-type&gt;.scc</filename> file.
+                    For example, from the <filename>meta</filename> branch in the
+                    <filename>linux-yocto-3.0</filename> kernel, the
+                    <filename>meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc</filename> file
+                    has the following:
+                    <literallayout class='monospaced'>
+     define KMACHINE cedartrail
+     define KTYPE standard
+     define KARCH i386
+
+     include ktypes/standard
+     branch cedartrail
+
+     include cedartrail.scc
+                    </literallayout>
+                    You can see that the kernel understands the machine name for
+                    the Cedar Trail Board Support Package (BSP) as
+                    <filename>cedartrail</filename>.
+                </para>
+
+                <para>
+                    If you look in the Cedar Trail BSP layer in the
+                    <filename>meta-intel</filename>
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-repositories'>Source Repositories</ulink>
+                    at <filename>meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>,
+                    you will find the following statements among others:
+                    <literallayout class='monospaced'>
+     COMPATIBLE_MACHINE_cedartrail = "cedartrail"
+     KMACHINE_cedartrail  = "cedartrail"
+     KBRANCH_cedartrail  = "yocto/standard/cedartrail"
+     KERNEL_FEATURES_append_cedartrail += "bsp/cedartrail/cedartrail-pvr-merge.scc"
+     KERNEL_FEATURES_append_cedartrail += "cfg/efi-ext.scc"
+
+     COMPATIBLE_MACHINE_cedartrail-nopvr = "cedartrail"
+     KMACHINE_cedartrail-nopvr  = "cedartrail"
+     KBRANCH_cedartrail-nopvr  = "yocto/standard/cedartrail"
+     KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc"
+                    </literallayout>
+                    The <filename>KMACHINE</filename> statements in the kernel's append file make sure that
+                    the OpenEmbedded build system and the Yocto Linux kernel understand the same machine
+                    names.
+                </para>
+
+                <para>
+                    This append file uses two <filename>KMACHINE</filename> statements.
+                    The first is not really necessary but does ensure that the machine known to the
+                    OpenEmbedded build system as <filename>cedartrail</filename> maps to the machine
+                    in the kernel also known as <filename>cedartrail</filename>:
+                    <literallayout class='monospaced'>
+     KMACHINE_cedartrail  = "cedartrail"
+                    </literallayout>
+                </para>
+
+                <para>
+                    The second statement is a good example of why the <filename>KMACHINE</filename> variable
+                    is needed.
+                    In this example, the OpenEmbedded build system uses the <filename>cedartrail-nopvr</filename>
+                    machine name to refer to the Cedar Trail BSP that does not support the proprietary
+                    PowerVR driver.
+                    The kernel, however, uses the machine name <filename>cedartrail</filename>.
+                    Thus, the append file must map the <filename>cedartrail-nopvr</filename> machine name to
+                    the kernel's <filename>cedartrail</filename> name:
+                    <literallayout class='monospaced'>
+     KMACHINE_cedartrail-nopvr  = "cedartrail"
+                    </literallayout>
+                </para>
+
+                <para>
+                    BSPs that ship with the Yocto Project release provide all mappings between the Yocto
+                    Project kernel machine names and the OpenEmbedded machine names.
+                    Be sure to use the <filename>KMACHINE</filename> if you create a BSP and the machine
+                    name you use is different than that used in the kernel.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KTYPE'><glossterm>KTYPE</glossterm>
+            <glossdef>
+                <para>
+                    Defines the kernel type to be used in assembling the
+                    configuration.
+                    The linux-yocto recipes define "standard", "tiny",
+                    and "preempt-rt" kernel types.
+                    See the
+                    "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#kernel-types'>Kernel Types</ulink>"
+                    section in the Yocto Project Linux Kernel Development
+                    Manual for more information on kernel types.
+                </para>
+
+                <para>
+                    You define the <filename>KTYPE</filename> variable in the
+                    <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#bsp-descriptions'>BSP Descriptions</ulink>.
+                    The value you use must match the value used for the
+                    <link linkend='var-LINUX_KERNEL_TYPE'><filename>LINUX_KERNEL_TYPE</filename></link>
+                    value used by the kernel recipe.
+                </para>
+            </glossdef>
+        </glossentry>
+   </glossdiv>
+
+    <glossdiv id='var-glossary-l'><title>L</title>
+
+        <glossentry id='var-LABELS'><glossterm>LABELS</glossterm>
+            <glossdef>
+                <para>
+                    Provides a list of targets for automatic configuration.
+                </para>
+
+                <para>
+                    See the
+                    <link linkend='ref-classes-grub-efi'><filename>grub-efi</filename></link>
+                    class for more information on how this variable is used.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LAYERDEPENDS'><glossterm>LAYERDEPENDS</glossterm>
+            <glossdef>
+                <para>Lists the layers that this recipe depends upon, separated by spaces.
+                    Optionally, you can specify a specific layer version for a dependency
+                    by adding it to the end of the layer name with a colon, (e.g. "anotherlayer:3"
+                    to be compared against
+                    <link linkend='var-LAYERVERSION'><filename>LAYERVERSION</filename></link><filename>_anotherlayer</filename>
+                    in this case).
+                    An error will be produced if any dependency is missing or
+                    the version numbers do not match exactly (if specified).
+                    This variable is used in the <filename>conf/layer.conf</filename> file
+                    and must be suffixed with the name of the specific layer (e.g.
+                    <filename>LAYERDEPENDS_mylayer</filename>).</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LAYERDIR'><glossterm>LAYERDIR</glossterm>
+            <glossdef>
+                <para>When used inside the <filename>layer.conf</filename> configuration
+                    file, this variable provides the path of the current layer.
+                    This variable is not available outside of <filename>layer.conf</filename>
+                    and references are expanded immediately when parsing of the file completes.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LAYERVERSION'><glossterm>LAYERVERSION</glossterm>
+            <glossdef>
+                <para>Optionally specifies the version of a layer as a single number.
+                    You can use this within
+                    <link linkend='var-LAYERDEPENDS'><filename>LAYERDEPENDS</filename></link>
+                    for another layer in order to depend on a specific version
+                    of the layer.
+                    This variable is used in the <filename>conf/layer.conf</filename> file
+                    and must be suffixed with the name of the specific layer (e.g.
+                    <filename>LAYERVERSION_mylayer</filename>).</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LDFLAGS'><glossterm>LDFLAGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the flags to pass to the linker.
+                    This variable is exported to an environment
+                    variable and thus made visible to the software being
+                    built during the compilation step.
+                </para>
+
+                <para>
+                    Default initialization for <filename>LDFLAGS</filename>
+                    varies depending on what is being built:
+                    <itemizedlist>
+                        <listitem><para>
+                            <link linkend='var-TARGET_LDFLAGS'><filename>TARGET_LDFLAGS</filename></link>
+                            when building for the target
+                            </para></listitem>
+                        <listitem><para>
+                            <link linkend='var-BUILD_LDFLAGS'><filename>BUILD_LDFLAGS</filename></link>
+                            when building for the build host (i.e.
+                            <filename>-native</filename>)
+                            </para></listitem>
+                        <listitem><para>
+                            <link linkend='var-BUILDSDK_LDFLAGS'><filename>BUILDSDK_LDFLAGS</filename></link>
+                            when building for an SDK (i.e.
+                            <filename>nativesdk-</filename>)
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LEAD_SONAME'><glossterm>LEAD_SONAME</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the lead (or primary) compiled library file
+                    (<filename>.so</filename>) that the
+                    <link linkend='ref-classes-debian'><filename>debian</filename></link>
+                    class applies its naming policy to given a recipe that
+                    packages multiple libraries.
+                </para>
+
+                <para>
+                    This variable works in conjunction with the
+                    <filename>debian</filename> class.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LIC_FILES_CHKSUM'><glossterm>LIC_FILES_CHKSUM</glossterm>
+            <glossdef>
+                <para>Checksums of the license text in the recipe source code.</para>
+                <para>This variable tracks changes in license text of the source
+                    code files.
+                    If the license text is changed, it will trigger a build
+                    failure, which gives the developer an opportunity to review any
+                    license change.</para>
+                <para>
+                    This variable must be defined for all recipes (unless
+                    <link linkend='var-LICENSE'><filename>LICENSE</filename></link>
+                    is set to "CLOSED").</para>
+                <para>For more information, see the
+                    "<link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>
+                    Tracking License Changes</link>" section.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LICENSE'><glossterm>LICENSE</glossterm>
+            <glossdef>
+                <para>
+                    The list of source licenses for the recipe.
+                    Follow these rules:
+                    <itemizedlist>
+                        <listitem><para>Do not use spaces within individual
+                            license names.</para></listitem>
+                        <listitem><para>Separate license names using
+                            | (pipe) when there is a choice between licenses.
+                            </para></listitem>
+                        <listitem><para>Separate license names using
+                            &amp; (ampersand) when multiple licenses exist
+                            that cover different parts of the source.
+                            </para></listitem>
+                        <listitem><para>You can use spaces between license
+                            names.</para></listitem>
+                        <listitem><para>For standard licenses, use the names
+                            of the files in
+                            <filename>meta/files/common-licenses/</filename>
+                            or the
+                            <link linkend='var-SPDXLICENSEMAP'><filename>SPDXLICENSEMAP</filename></link>
+                            flag names defined in
+                            <filename>meta/conf/licenses.conf</filename>.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    Here are some examples:
+                    <literallayout class='monospaced'>
+     LICENSE = "LGPLv2.1 | GPLv3"
+     LICENSE = "MPL-1 &amp; LGPLv2.1"
+     LICENSE = "GPLv2+"
+                    </literallayout>
+                    The first example is from the recipes for Qt, which the user
+                    may choose to distribute under either the LGPL version
+                    2.1 or GPL version 3.
+                    The second example is from Cairo where two licenses cover
+                    different parts of the source code.
+                    The final example is from <filename>sysstat</filename>,
+                    which presents a single license.
+                </para>
+
+                <para>
+                    You can also specify licenses on a per-package basis to
+                    handle situations where components of the output have
+                    different licenses.
+                    For example, a piece of software whose code is
+                    licensed under GPLv2 but has accompanying documentation
+                    licensed under the GNU Free Documentation License 1.2 could
+                    be specified as follows:
+                    <literallayout class='monospaced'>
+     LICENSE = "GFDL-1.2 &amp; GPLv2"
+     LICENSE_${PN} = "GPLv2"
+     LICENSE_${PN}-doc = "GFDL-1.2"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LICENSE_FLAGS'><glossterm>LICENSE_FLAGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies additional flags for a recipe you must
+                    whitelist through
+                    <link linkend='var-LICENSE_FLAGS_WHITELIST'><filename>LICENSE_FLAGS_WHITELIST</filename></link>
+                    in order to allow the recipe to be built.
+                    When providing multiple flags, separate them with
+                    spaces.
+                </para>
+
+                <para>
+                    This value is independent of
+                    <link linkend='var-LICENSE'><filename>LICENSE</filename></link>
+                    and is typically used to mark recipes that might
+                    require additional licenses in order to be used in a
+                    commercial product.
+                    For more information, see the
+                    "<link linkend='enabling-commercially-licensed-recipes'>Enabling Commercially Licensed Recipes</link>"
+                    section.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LICENSE_FLAGS_WHITELIST'><glossterm>LICENSE_FLAGS_WHITELIST</glossterm>
+            <glossdef>
+                <para>
+                    Lists license flags that when specified in
+                    <link linkend='var-LICENSE_FLAGS'><filename>LICENSE_FLAGS</filename></link>
+                    within a recipe should not prevent that recipe from being
+                    built.
+                    This practice is otherwise known as "whitelisting"
+                    license flags.
+                    For more information, see the
+                    <link linkend='enabling-commercially-licensed-recipes'>Enabling Commercially Licensed Recipes</link>"
+                    section.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LICENSE_PATH'><glossterm>LICENSE_PATH</glossterm>
+            <glossdef>
+                <para>Path to additional licenses used during the build.
+                    By default, the OpenEmbedded build system uses <filename>COMMON_LICENSE_DIR</filename>
+                    to define the directory that holds common license text used during the build.
+                    The <filename>LICENSE_PATH</filename> variable allows you to extend that
+                    location to other areas that have additional licenses:
+                    <literallayout class='monospaced'>
+     LICENSE_PATH += "<replaceable>path-to-additional-common-licenses</replaceable>"
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LINUX_KERNEL_TYPE'><glossterm>LINUX_KERNEL_TYPE</glossterm>
+            <glossdef>
+                <para>
+                    Defines the kernel type to be used in assembling the
+                    configuration.
+                    The linux-yocto recipes define "standard", "tiny", and
+                    "preempt-rt" kernel types.
+                    See the
+                    "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#kernel-types'>Kernel Types</ulink>"
+                    section in the Yocto Project Linux Kernel Development
+                    Manual for more information on kernel types.
+                </para>
+
+                <para>
+                    If you do not specify a
+                    <filename>LINUX_KERNEL_TYPE</filename>, it defaults to
+                    "standard".
+                    Together with
+                    <link linkend='var-KMACHINE'><filename>KMACHINE</filename></link>,
+                    the <filename>LINUX_KERNEL_TYPE</filename> variable
+                    defines the search
+                    arguments used by the kernel tools to find the appropriate
+                    description within the kernel
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                    with which to build out the sources and configuration.
+                    </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LINUX_VERSION'><glossterm>LINUX_VERSION</glossterm>
+            <glossdef>
+                <para>The Linux version from <filename>kernel.org</filename>
+                    on which the Linux kernel image being built using the
+                    OpenEmbedded build system is based.
+                    You define this variable in the kernel recipe.
+                    For example, the <filename>linux-yocto-3.4.bb</filename>
+                    kernel recipe found in
+                    <filename>meta/recipes-kernel/linux</filename>
+                    defines the variables as follows:
+                    <literallayout class='monospaced'>
+     LINUX_VERSION ?= "3.4.24"
+                    </literallayout>
+                    The <filename>LINUX_VERSION</filename> variable is used to
+                    define <link linkend='var-PV'><filename>PV</filename></link>
+                    for the recipe:
+                    <literallayout class='monospaced'>
+     PV = "${LINUX_VERSION}+git${SRCPV}"
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LINUX_VERSION_EXTENSION'><glossterm>LINUX_VERSION_EXTENSION</glossterm>
+            <glossdef>
+                <para>A string extension compiled into the version
+                    string of the Linux kernel built with the OpenEmbedded
+                    build system.
+                    You define this variable in the kernel recipe.
+                    For example, the linux-yocto kernel recipes all define
+                    the variable as follows:
+                    <literallayout class='monospaced'>
+     LINUX_VERSION_EXTENSION ?= "-yocto-${<link linkend='var-LINUX_KERNEL_TYPE'>LINUX_KERNEL_TYPE</link>}"
+                    </literallayout>
+                    Defining this variable essentially sets the
+                    Linux kernel configuration item
+                    <filename>CONFIG_LOCALVERSION</filename>, which is visible
+                    through the <filename>uname</filename> command.
+                    Here is an example that shows the extension assuming it
+                    was set as previously shown:
+                    <literallayout class='monospaced'>
+     $ uname -r
+     3.7.0-rc8-custom
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LOG_DIR'><glossterm>LOG_DIR</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the directory to which the OpenEmbedded build
+                    system writes overall log files.
+                    The default directory is <filename>${TMPDIR}/log</filename>.
+                </para>
+                <para>
+                    For the directory containing logs specific to each task,
+                    see the <link linkend='var-T'><filename>T</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-m'><title>M</title>
+
+         <glossentry id='var-MACHINE'><glossterm>MACHINE</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the target device for which the image is built.
+                    You define <filename>MACHINE</filename> in the
+                    <filename>local.conf</filename> file found in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                    By default, <filename>MACHINE</filename> is set to
+                    "qemux86", which is an x86-based architecture machine to
+                    be emulated using QEMU:
+                    <literallayout class='monospaced'>
+     MACHINE ?= "qemux86"
+                    </literallayout>
+                    The variable corresponds to a machine configuration file of the
+                    same name, through which machine-specific configurations are set.
+                    Thus, when <filename>MACHINE</filename> is set to "qemux86" there
+                    exists the corresponding <filename>qemux86.conf</filename> machine
+                    configuration file, which can be found in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    in <filename>meta/conf/machine</filename>.
+                </para>
+
+                <para>
+                    The list of machines supported by the Yocto Project as
+                    shipped include the following:
+                    <literallayout class='monospaced'>
+     MACHINE ?= "qemuarm"
+     MACHINE ?= "qemumips"
+     MACHINE ?= "qemuppc"
+     MACHINE ?= "qemux86"
+     MACHINE ?= "qemux86-64"
+     MACHINE ?= "genericx86"
+     MACHINE ?= "genericx86-64"
+     MACHINE ?= "beaglebone"
+     MACHINE ?= "mpc8315e-rdb"
+     MACHINE ?= "edgerouter"
+                    </literallayout>
+                    The last five are Yocto Project reference hardware boards, which
+                    are provided in the <filename>meta-yocto-bsp</filename> layer.
+                    <note>Adding additional Board Support Package (BSP) layers
+                        to your configuration adds new possible settings for
+                        <filename>MACHINE</filename>.
+                    </note>
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-MACHINE_ARCH'><glossterm>MACHINE_ARCH</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the name of the machine-specific architecture.
+                    This variable is set automatically from
+                    <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+                    or
+                    <link linkend='var-TUNE_PKGARCH'><filename>TUNE_PKGARCH</filename></link>.
+                    You should not hand-edit the
+                    <filename>MACHINE_ARCH</filename> variable.
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</glossterm>
+            <glossdef>
+                <para>
+                    A list of required machine-specific packages to install as part of
+                    the image being built.
+                    The build process depends on these packages being present.
+                    Furthermore, because this is a "machine essential" variable, the list of
+                    packages are essential for the machine to boot.
+                    The impact of this variable affects images based on
+                    <filename>packagegroup-core-boot</filename>,
+                    including the <filename>core-image-minimal</filename> image.
+                </para>
+                <para>
+                    This variable is similar to the
+                    <filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</link></filename>
+                    variable with the exception that the image being built has a build
+                    dependency on the variable's list of packages.
+                    In other words, the image will not build if a file in this list is not found.
+                </para>
+                <para>
+                    As an example, suppose the machine for which you are building requires
+                    <filename>example-init</filename> to be run during boot to initialize the hardware.
+                    In this case, you would use the following in the machine's
+                    <filename>.conf</filename> configuration file:
+                    <literallayout class='monospaced'>
+     MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "example-init"
+                    </literallayout>
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</glossterm>
+            <glossdef>
+                <para>
+                    A list of recommended machine-specific packages to install as part of
+                    the image being built.
+                    The build process does not depend on these packages being present.
+                    However, because this is a "machine essential" variable, the list of
+                    packages are essential for the machine to boot.
+                    The impact of this variable affects images based on
+                    <filename>packagegroup-core-boot</filename>,
+                    including the <filename>core-image-minimal</filename> image.
+                </para>
+                <para>
+                    This variable is similar to the
+                    <filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</link></filename>
+                    variable with the exception that the image being built does not have a build
+                    dependency on the variable's list of packages.
+                    In other words, the image will still build if a package in this list is not found.
+                    Typically, this variable is used to handle essential kernel modules, whose
+                    functionality may be selected to be built into the kernel rather than as a module,
+                    in which case a package will not be produced.
+                </para>
+                <para>
+                    Consider an example where you have a custom kernel where a specific touchscreen
+                    driver is required for the machine to be usable.
+                    However, the driver can be built as a module or
+                    into the kernel depending on the kernel configuration.
+                    If the driver is built as a module, you want it to be installed.
+                    But, when the driver is built into the kernel, you still want the
+                    build to succeed.
+                    This variable sets up a "recommends" relationship so that in the latter case,
+                    the build will not fail due to the missing package.
+                    To accomplish this, assuming the package for the module was called
+                    <filename>kernel-module-ab123</filename>, you would use the
+                    following in the machine's <filename>.conf</filename> configuration
+                    file:
+                    <literallayout class='monospaced'>
+     MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-ab123"
+                    </literallayout>
+                </para>
+                <para>
+                    Some examples of these machine essentials are flash, screen, keyboard, mouse,
+                    or touchscreen drivers (depending on the machine).
+                </para>
+            </glossdef>
+        </glossentry>
+
+         <glossentry id='var-MACHINE_EXTRA_RDEPENDS'><glossterm>MACHINE_EXTRA_RDEPENDS</glossterm>
+            <glossdef>
+                <para>
+                    A list of machine-specific packages to install as part of the
+                    image being built that are not essential for the machine to boot.
+                    However, the build process for more fully-featured images
+                    depends on the packages being present.
+                </para>
+                <para>
+                    This variable affects all images based on
+                    <filename>packagegroup-base</filename>, which does not include the
+                    <filename>core-image-minimal</filename> or <filename>core-image-full-cmdline</filename>
+                    images.
+                </para>
+                <para>
+                    The variable is similar to the
+                    <filename><link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS</link></filename>
+                    variable with the exception that the image being built has a build
+                    dependency on the variable's list of packages.
+                    In other words, the image will not build if a file in this list is not found.
+                </para>
+                <para>
+                    An example is a machine that has WiFi capability but is not
+                    essential for the machine to boot the image.
+                    However, if you are building a more fully-featured image, you want to enable
+                    the WiFi.
+                    The package containing the firmware for the WiFi hardware is always
+                    expected to exist, so it is acceptable for the build process to depend upon
+                    finding the package.
+                    In this case, assuming the package for the firmware was called
+                    <filename>wifidriver-firmware</filename>, you would use the following in the
+                    <filename>.conf</filename> file for the machine:
+                    <literallayout class='monospaced'>
+     MACHINE_EXTRA_RDEPENDS += "wifidriver-firmware"
+                    </literallayout>
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-MACHINE_EXTRA_RRECOMMENDS'><glossterm>MACHINE_EXTRA_RRECOMMENDS</glossterm>
+            <glossdef>
+                <para>
+                    A list of machine-specific packages to install as part of the
+                    image being built that are not essential for booting the machine.
+                    The image being built has no build dependency on this list of packages.
+                </para>
+                <para>
+                    This variable affects only images based on
+                    <filename>packagegroup-base</filename>, which does not include the
+                    <filename>core-image-minimal</filename> or <filename>core-image-full-cmdline</filename>
+                    images.
+                </para>
+                <para>
+                    This variable is similar to the
+                    <filename><link linkend='var-MACHINE_EXTRA_RDEPENDS'>MACHINE_EXTRA_RDEPENDS</link></filename>
+                    variable with the exception that the image being built does not have a build
+                    dependency on the variable's list of packages.
+                    In other words, the image will build if a file in this list is not found.
+                </para>
+                <para>
+                    An example is a machine that has WiFi capability but is not essential
+                    For the machine to boot the image.
+                    However, if you are building a more fully-featured image, you want to enable
+                    WiFi.
+                    In this case, the package containing the WiFi kernel module will not be produced
+                    if the WiFi driver is built into the kernel, in which case you still want the
+                    build to succeed instead of failing as a result of the package not being found.
+                    To accomplish this, assuming the package for the module was called
+                    <filename>kernel-module-examplewifi</filename>, you would use the
+                    following in the <filename>.conf</filename> file for the machine:
+                    <literallayout class='monospaced'>
+     MACHINE_EXTRA_RRECOMMENDS += "kernel-module-examplewifi"
+                    </literallayout>
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-MACHINE_FEATURES'><glossterm>MACHINE_FEATURES</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the list of hardware features the
+                    <link linkend='var-MACHINE'><filename>MACHINE</filename></link> is capable
+                    of supporting.
+                    For related information on enabling features, see the
+                    <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>,
+                    <link linkend='var-COMBINED_FEATURES'><filename>COMBINED_FEATURES</filename></link>,
+                    and
+                    <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
+                    variables.
+                </para>
+
+                <para>
+                    For a list of hardware features supported by the Yocto
+                    Project as shipped, see the
+                    "<link linkend='ref-features-machine'>Machine Features</link>"
+                    section.
+                </para>
+            </glossdef>
+         </glossentry>
+
+        <glossentry id='var-MACHINE_FEATURES_BACKFILL'><glossterm>MACHINE_FEATURES_BACKFILL</glossterm>
+            <glossdef>
+                <para>Features to be added to
+                    <filename><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link></filename>
+                    if not also present in
+                    <filename><link linkend='var-MACHINE_FEATURES_BACKFILL_CONSIDERED'>MACHINE_FEATURES_BACKFILL_CONSIDERED</link></filename>.
+                </para>
+
+                <para>
+                    This variable is set in the <filename>meta/conf/bitbake.conf</filename> file.
+                    It is not intended to be user-configurable.
+                    It is best to just reference the variable to see which machine features are
+                    being backfilled for all machine configurations.
+                    See the "<link linkend='ref-features-backfill'>Feature backfilling</link>" section for
+                    more information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-MACHINE_FEATURES_BACKFILL_CONSIDERED'><glossterm>MACHINE_FEATURES_BACKFILL_CONSIDERED</glossterm>
+            <glossdef>
+                <para>Features from
+                    <filename><link linkend='var-MACHINE_FEATURES_BACKFILL'>MACHINE_FEATURES_BACKFILL</link></filename>
+                    that should not be backfilled (i.e. added to
+                    <filename><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link></filename>)
+                    during the build.
+                    See the "<link linkend='ref-features-backfill'>Feature backfilling</link>" section for
+                    more information.
+                    </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-MACHINEOVERRIDES'><glossterm>MACHINEOVERRIDES</glossterm>
+            <glossdef>
+                <para>
+                    Lists overrides specific to the current machine.
+                    By default, this list includes the value
+                    of <filename><link linkend='var-MACHINE'>MACHINE</link></filename>.
+                    You can extend the list to apply variable overrides for
+                    classes of machines.
+                    For example, all QEMU emulated machines (e.g. qemuarm,
+                    qemux86, and so forth) include a common file named
+                    <filename>meta/conf/machine/include/qemu.inc</filename>
+                    that prepends <filename>MACHINEOVERRIDES</filename> with
+                    the following variable override:
+                    <literallayout class='monospaced'>
+    MACHINEOVERRIDES =. "qemuall:"
+                    </literallayout>
+                    Applying an override like <filename>qemuall</filename>
+                    affects all QEMU emulated machines elsewhere.
+                    Here is an example from the
+                    <filename>connman-conf</filename> recipe:
+                    <literallayout class='monospaced'>
+    SRC_URI_append_qemuall = "file://wired.config \
+                              file://wired-setup \
+                             "
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-MAINTAINER'><glossterm>MAINTAINER</glossterm>
+            <glossdef>
+                <para>The email address of the distribution maintainer.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-MIRRORS'><glossterm>MIRRORS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies additional paths from which the OpenEmbedded
+                    build system gets source code.
+                    When the build system searches for source code, it first
+                    tries the local download directory.
+                    If that location fails, the build system tries locations
+                    defined by
+                    <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>,
+                    the upstream source, and then locations specified by
+                    <filename>MIRRORS</filename> in that order.
+                </para>
+
+                <para>
+                    Assuming your distribution
+                    (<link linkend='var-DISTRO'><filename>DISTRO</filename></link>)
+                    is "poky", the default value for
+                    <filename>MIRRORS</filename> is defined in the
+                    <filename>conf/distro/poky.conf</filename> file in the
+                    <filename>meta-yocto</filename> Git repository.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-MLPREFIX'><glossterm>MLPREFIX</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a prefix has been added to
+                    <link linkend='var-PN'><filename>PN</filename></link> to create a special version
+                    of a recipe or package, such as a Multilib version.
+                    The variable is used in places where the prefix needs to be
+                    added to or removed from a the name (e.g. the
+                    <link linkend='var-BPN'><filename>BPN</filename></link> variable).
+                    <filename>MLPREFIX</filename> gets set when a prefix has been
+                    added to <filename>PN</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-module_autoload'><glossterm>module_autoload</glossterm>
+            <glossdef>
+                <para>
+                    This variable has been replaced by the
+                    <filename>KERNEL_MODULE_AUTOLOAD</filename> variable.
+                    You should replace all occurrences of
+                    <filename>module_autoload</filename> with additions to
+                    <filename>KERNEL_MODULE_AUTOLOAD</filename>, for example:
+                    <literallayout class='monospaced'>
+     module_autoload_rfcomm = "rfcomm"
+                    </literallayout>
+                    should now be replaced with:
+                    <literallayout class='monospaced'>
+     KERNEL_MODULE_AUTOLOAD += "rfcomm"
+                    </literallayout>
+                    See the
+                    <link linkend='var-KERNEL_MODULE_AUTOLOAD'><filename>KERNEL_MODULE_AUTOLOAD</filename></link>
+                    variable for more information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-module_conf'><glossterm>module_conf</glossterm>
+            <glossdef>
+                <para>
+                    Specifies
+                    <ulink url='http://linux.die.net/man/5/modprobe.d'><filename>modprobe.d</filename></ulink>
+                    syntax lines for inclusion in the
+                    <filename>/etc/modprobe.d/modname.conf</filename> file.
+                </para>
+
+                <para>
+                    You can use this variable anywhere that it can be
+                    recognized by the kernel recipe or out-of-tree kernel
+                    module recipe (e.g. a machine configuration file, a
+                    distribution configuration file, an append file for the
+                    recipe, or the recipe itself).
+                    If you use this variable, you must also be sure to list
+                    the module name in the
+                    <link linkend='var-KERNEL_MODULE_AUTOLOAD'><filename>KERNEL_MODULE_AUTOLOAD</filename></link>
+                    variable.
+                </para>
+
+                <para>
+                    Here is the general syntax:
+                    <literallayout class='monospaced'>
+     module_conf_<replaceable>module_name</replaceable> = "<replaceable>modprobe.d-syntax</replaceable>"
+                    </literallayout>
+                    You must use the kernel module name override.
+                </para>
+
+                <para>
+                    Run <filename>man modprobe.d</filename> in the shell to
+                    find out more information on the exact syntax
+                    you want to provide with <filename>module_conf</filename>.
+                </para>
+
+                <para>
+                    Including <filename>module_conf</filename> causes the
+                    OpenEmbedded build system to populate the
+                    <filename>/etc/modprobe.d/modname.conf</filename>
+                    file with <filename>modprobe.d</filename> syntax lines.
+                    Here is an example that adds the options
+                    <filename>arg1</filename> and <filename>arg2</filename>
+                    to a module named <filename>mymodule</filename>:
+                    <literallayout class='monospaced'>
+     module_conf_mymodule = "options mymodule arg1=val1 arg2=val2"
+                    </literallayout>
+                </para>
+
+                <para>
+                    For information on how to specify kernel modules to
+                    auto-load on boot, see the
+                    <link linkend='var-KERNEL_MODULE_AUTOLOAD'><filename>KERNEL_MODULE_AUTOLOAD</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-MODULE_IMAGE_BASE_NAME'><glossterm>MODULE_IMAGE_BASE_NAME</glossterm>
+            <glossdef>
+                <para>
+                    The base name of the kernel modules tarball.
+                    This variable is set in the
+                    <link linkend='ref-classes-kernel'>kernel</link> class
+                    as follows:
+                    <literallayout class='monospaced'>
+     MODULE_IMAGE_BASE_NAME ?= "modules-${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
+                    </literallayout>
+                    See the
+                    <link linkend='var-PKGE'><filename>PKGE</filename></link>,
+                    <link linkend='var-PKGV'><filename>PKGV</filename></link>,
+                    <link linkend='var-PKGR'><filename>PKGR</filename></link>,
+                    <link linkend='var-MACHINE'><filename>MACHINE</filename></link>,
+                    and
+                    <link linkend='var-DATETIME'><filename>DATETIME</filename></link>
+                    variables for additional information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-MODULE_TARBALL_DEPLOY'><glossterm>MODULE_TARBALL_DEPLOY</glossterm>
+            <glossdef>
+                <para>
+                    Controls creation of the <filename>modules-*.tgz</filename>
+                    file.
+                    Set this variable to "0" to disable creation of this
+                    file, which contains all of the kernel modules resulting
+                    from a kernel build.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-MULTIMACH_TARGET_SYS'><glossterm>MULTIMACH_TARGET_SYS</glossterm>
+            <glossdef>
+                <para>
+                    Separates files for different machines such that you can build
+                    for multiple target machines using the same output directories.
+                    See the <link linkend='var-STAMP'><filename>STAMP</filename></link> variable
+                    for an example.
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-n'><title>N</title>
+
+        <glossentry id='var-NATIVELSBSTRING'><glossterm>NATIVELSBSTRING</glossterm>
+            <glossdef>
+                <para>
+                    A string identifying the host distribution.
+                    Strings consist of the host distributor ID
+                    followed by the release, as reported by the
+                    <filename>lsb_release</filename> tool
+                    or as read from <filename>/etc/lsb-release</filename>.
+                    For example, when running a build on Ubuntu 12.10, the value
+                    is "Ubuntu-12.10".
+                    If this information is unable to be determined, the value
+                    resolves to "Unknown".
+                </para>
+                <para>
+                    This variable is used by default to isolate native shared
+                    state packages for different distributions (e.g. to avoid
+                    problems with <filename>glibc</filename> version
+                    incompatibilities).
+                    Additionally, the variable is checked against
+                    <link linkend='var-SANITY_TESTED_DISTROS'><filename>SANITY_TESTED_DISTROS</filename></link>
+                    if that variable is set.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-NO_RECOMMENDATIONS'><glossterm>NO_RECOMMENDATIONS</glossterm>
+            <glossdef>
+                <para>
+                    Prevents installation of all "recommended-only" packages.
+                    Recommended-only packages are packages installed only
+                    through the
+                    <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>
+                    variable).
+                    Setting the <filename>NO_RECOMMENDATIONS</filename> variable
+                    to "1" turns this feature on:
+                    <literallayout class='monospaced'>
+     NO_RECOMMENDATIONS = "1"
+                    </literallayout>
+                    You can set this variable globally in your
+                    <filename>local.conf</filename> file or you can attach it to
+                    a specific image recipe by using the recipe name override:
+                    <literallayout class='monospaced'>
+     NO_RECOMMENDATIONS_pn-<replaceable>target_image</replaceable> = "<replaceable>package_name</replaceable>"
+                    </literallayout>
+                </para>
+
+                <para>
+                    It is important to realize that if you choose to not install
+                    packages using this variable and some other packages are
+                    dependent on them (i.e. listed in a recipe's
+                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
+                    variable), the OpenEmbedded build system ignores your
+                    request and will install the packages to avoid dependency
+                    errors.
+                    <note>
+                        Some recommended packages might be required for certain
+                        system functionality, such as kernel modules.
+                        It is up to you to add packages with the
+                        <link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>
+                        variable.
+                    </note>
+                </para>
+
+                <para>
+                    Support for this variable exists only when using the
+                    IPK and RPM packaging backend.
+                    Support does not exist for DEB.
+                </para>
+
+                <para>
+                    See the
+                    <link linkend='var-BAD_RECOMMENDATIONS'><filename>BAD_RECOMMENDATIONS</filename></link>
+                    and the
+                    <link linkend='var-PACKAGE_EXCLUDE'><filename>PACKAGE_EXCLUDE</filename></link>
+                    variables for related information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-NOHDD'><glossterm>NOHDD</glossterm>
+            <glossdef>
+                <para>
+                    Causes the OpenEmbedded build system to skip building the
+                    <filename>.hddimg</filename> image.
+                    The <filename>NOHDD</filename> variable is used with the
+                    <link linkend='ref-classes-bootimg'><filename>bootimg</filename></link>
+                    class.
+                    Set the variable to "1" to prevent the
+                    <filename>.hddimg</filename> image from being built.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-NOISO'><glossterm>NOISO</glossterm>
+            <glossdef>
+                <para>
+                    Causes the OpenEmbedded build system to skip building the
+                    ISO image.
+                    The <filename>NOISO</filename> variable is used with the
+                    <link linkend='ref-classes-bootimg'><filename>bootimg</filename></link>
+                    class.
+                    Set the variable to "1" to prevent the ISO image from
+                    being built.
+                    To enable building an ISO image, set the variable to "0".
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-o'><title>O</title>
+
+        <glossentry id='var-OE_BINCONFIG_EXTRA_MANGLE'><glossterm>OE_BINCONFIG_EXTRA_MANGLE</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-binconfig'><filename>binconfig</filename></link>
+                    class, this variable
+                    specifies additional arguments passed to the "sed" command.
+                    The sed command alters any paths in configuration scripts
+                    that have been set up during compilation.
+                    Inheriting this class results in all paths in these scripts
+                    being changed to point into the
+                    <filename>sysroots/</filename> directory so that all builds
+                    that use the script will use the correct directories
+                    for the cross compiling layout.
+                </para>
+
+                <para>
+                    See the <filename>meta/classes/binconfig.bbclass</filename>
+                    in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    for details on how this class applies these additional
+                    sed command arguments.
+                    For general information on the
+                    <filename>binconfig.bbclass</filename> class, see the
+                    "<link linkend='ref-classes-binconfig'>Binary Configuration Scripts - <filename>binconfig.bbclass</filename></link>"
+                    section.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-OE_IMPORTS'><glossterm>OE_IMPORTS</glossterm>
+            <glossdef>
+                <para>
+                    An internal variable used to tell the OpenEmbedded build
+                    system what Python modules to import for every Python
+                    function run by the system.
+                </para>
+
+                <note>
+                    Do not set this variable.
+                    It is for internal use only.
+                </note>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-OE_TERMINAL'><glossterm>OE_TERMINAL</glossterm>
+            <glossdef>
+                <para>
+                    Controls how the OpenEmbedded build system spawns
+                    interactive terminals on the host development system
+                    (e.g. using the BitBake command with the
+                    <filename>-c devshell</filename> command-line option).
+                    For more information, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-devshell'>Using a Development Shell</ulink>" section
+                    in the Yocto Project Development Manual.
+                 </para>
+
+                 <para>
+                    You can use the following values for the
+                    <filename>OE_TERMINAL</filename> variable:
+                    <literallayout class='monospaced'>
+     auto
+     gnome
+     xfce
+     rxvt
+     screen
+     konsole
+     none
+                    </literallayout>
+                    <note>Konsole support only works for KDE 3.x.
+                        Also, "auto" is the default behavior for
+                        <filename>OE_TERMINAL</filename></note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-OEROOT'><glossterm>OEROOT</glossterm>
+            <glossdef>
+                <para>
+                    The directory from which the top-level build environment
+                    setup script is sourced.
+                    The Yocto Project makes two top-level build environment
+                    setup scripts available:
+                    <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+                    and
+                    <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>.
+                    When you run one of these scripts, the
+                    <filename>OEROOT</filename> variable resolves to the
+                    directory that contains the script.
+                </para>
+
+                <para>
+                    For additional information on how this variable is used,
+                    see the initialization scripts.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-OLDEST_KERNEL'><glossterm>OLDEST_KERNEL</glossterm>
+            <glossdef>
+                <para>
+                    Declares the oldest version of the Linux kernel that the
+                    produced binaries must support.
+                    This variable is passed into the build of the Embedded
+                    GNU C Library (<filename>glibc</filename>).
+                </para>
+
+                <para>
+                    The default for this variable comes from the
+                    <filename>meta/conf/bitbake.conf</filename> configuration
+                    file.
+                    You can override this default by setting the variable
+                    in a custom distribution configuration file.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-OVERRIDES'><glossterm>OVERRIDES</glossterm>
+            <glossdef>
+                <para>
+                    BitBake uses <filename>OVERRIDES</filename> to control
+                    what variables are overridden after BitBake parses
+                    recipes and configuration files.
+                    You can find more information on how overrides are handled
+                    in the
+                    "<ulink url='&YOCTO_DOCS_BB_URL;#conditional-syntax-overrides'>Conditional Syntax (Overrides)</ulink>"
+                    section of the BitBake User Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+    </glossdiv>
+
+    <glossdiv id='var-glossary-p'><title>P</title>
+
+        <glossentry id='var-P'><glossterm>P</glossterm>
+            <glossdef>
+                <para>The recipe name and version.
+                    <filename>P</filename> is comprised of the following:
+                    <literallayout class='monospaced'>
+     ${PN}-${PV}
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGE_ARCH'><glossterm>PACKAGE_ARCH</glossterm>
+            <glossdef>
+                <para>
+                    The architecture of the resulting package or packages.
+                </para>
+
+                <para>
+                    By default, the value of this variable is set to
+                    <link linkend='var-TUNE_PKGARCH'><filename>TUNE_PKGARCH</filename></link>
+                    when building for the target,
+                    <filename>BUILD_ARCH</filename> when building for the
+                    build host and "${SDK_ARCH}-${SDKPKGSUFFIX}" when building
+                    for the SDK.
+                    However, if your recipe's output packages are built
+                    specific to the target machine rather than general for
+                    the architecture of the machine, you should set
+                    <filename>PACKAGE_ARCH</filename> to the value of
+                    <link linkend='var-MACHINE_ARCH'><filename>MACHINE_ARCH</filename></link>
+                    in the recipe as follows:
+                    <literallayout class='monospaced'>
+     PACKAGE_ARCH = "${MACHINE_ARCH}"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGE_ARCHS'><glossterm>PACKAGE_ARCHS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a list of architectures compatible with
+                    the target machine.
+                    This variable is set automatically and should not
+                    normally be hand-edited.
+                    Entries are separated using spaces and listed in order
+                    of priority.
+                    The default value for
+                    <filename>PACKAGE_ARCHS</filename> is "all any noarch
+                    ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}".
+                </para>
+            </glossdef>
+        </glossentry>
+
+
+
+        <glossentry id='var-PACKAGE_BEFORE_PN'><glossterm>PACKAGE_BEFORE_PN</glossterm>
+            <glossdef>
+                <para>Enables easily adding packages to
+                <filename><link linkend='var-PACKAGES'>PACKAGES</link></filename>
+                before <filename>${<link linkend='var-PN'>PN</link>}</filename>
+                so that those added packages can pick up files that would normally be
+                included in the default package.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGE_CLASSES'><glossterm>PACKAGE_CLASSES</glossterm>
+            <glossdef>
+                <para>
+                    This variable, which is set in the
+                    <filename>local.conf</filename> configuration file found in
+                    the <filename>conf</filename> folder of the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
+                    specifies the package manager the OpenEmbedded build system
+                    uses when packaging data.
+                </para>
+
+                <para>
+                    You can provide one or more of the following arguments for
+                    the variable:
+                    <literallayout class='monospaced'>
+     PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk package_tar"
+                    </literallayout>
+                    The build system uses only the first argument in the list
+                    as the package manager when creating your image or SDK.
+                    However, packages will be created using any additional
+                    packaging classes you specify.
+                    For example, if you use the following in your
+                    <filename>local.conf</filename> file:
+                    <literallayout class='monospaced'>
+     PACKAGE_CLASSES ?= "package_ipk package_tar"
+                    </literallayout>
+                    The OpenEmbedded build system uses the IPK package manager
+                    to create your image or SDK as well as generating
+                    TAR packages.
+                </para>
+
+                <para>
+                    You cannot specify the
+                    <link linkend='ref-classes-package_tar'><filename>package_tar</filename></link>
+                    class first in the list.
+                    Files using the <filename>.tar</filename> format cannot
+                    be used as a substitute packaging format
+                    for DEB, RPM, and IPK formatted files for your image or SDK.
+                </para>
+
+                <para>
+                    For information on packaging and build performance effects
+                    as a result of the package manager in use, see the
+                    "<link linkend='ref-classes-package'><filename>package.bbclass</filename></link>"
+                    section.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGE_DEBUG_SPLIT_STYLE'><glossterm>PACKAGE_DEBUG_SPLIT_STYLE</glossterm>
+            <glossdef>
+
+                <para>
+                    Determines how to split up the binary and debug information
+                    when creating <filename>*-dbg</filename> packages to be
+                    used with the GNU Project Debugger (GDB).
+                </para>
+
+                <para>
+                    With the
+                    <filename>PACKAGE_DEBUG_SPLIT_STYLE</filename> variable,
+                    you can control where debug information, which can include
+                    or exclude source files, is stored:
+                    <itemizedlist>
+                        <listitem><para>
+                            ".debug": Debug symbol files are placed next
+                            to the binary in a <filename>.debug</filename>
+                            directory on the target.
+                            For example, if a binary is installed into
+                            <filename>/bin</filename>, the corresponding debug
+                            symbol files are installed in
+                            <filename>/bin/.debug</filename>.
+                            Source files are placed in
+                            <filename>/usr/src/debug</filename>.
+                            This is the default behavior.
+                            </para></listitem>
+                        <listitem><para>
+                            "debug-file-directory": Debug symbol files are
+                            placed under <filename>/usr/lib/debug</filename>
+                            on the target, and separated by the path from where
+                            the binary is installed.
+                            For example, if a binary is installed in
+                            <filename>/bin</filename>, the corresponding debug
+                            symbols are installed in
+                            <filename>/usr/lib/debug/bin</filename>.
+                            Source files are placed in
+                            <filename>/usr/src/debug</filename>.
+                            </para></listitem>
+                        <listitem><para>
+                            "debug-without-src": The same behavior as
+                            ".debug" previously described with the exception
+                            that no source files are installed.
+                            </para></listitem>.
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    You can find out more about debugging using GDB by reading
+                    the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug'>Debugging With the GNU Project Debugger (GDB) Remotely</ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGE_EXCLUDE'><glossterm>PACKAGE_EXCLUDE</glossterm>
+            <glossdef>
+                <para>
+                    Lists packages that should not be installed into an image.
+                    For example:
+                    <literallayout class='monospaced'>
+     PACKAGE_EXCLUDE = "<replaceable>package_name</replaceable> <replaceable>package_name</replaceable> <replaceable>package_name</replaceable> ..."
+                    </literallayout>
+                    You can set this variable globally in your
+                    <filename>local.conf</filename> file or you can attach it to
+                    a specific image recipe by using the recipe name override:
+                    <literallayout class='monospaced'>
+     PACKAGE_EXCLUDE_pn-<replaceable>target_image</replaceable> = "<replaceable>package_name</replaceable>"
+                    </literallayout>
+                </para>
+
+                <para>
+                    If you choose to not install
+                    a package using this variable and some other package is
+                    dependent on it (i.e. listed in a recipe's
+                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
+                    variable), the OpenEmbedded build system generates a fatal
+                    installation error.
+                    Because the build system halts the process with a fatal
+                    error, you can use the variable with an iterative
+                    development process to remove specific components from a
+                    system.
+                </para>
+
+                <para>
+                    Support for this variable exists only when using the
+                    IPK and RPM packaging backend.
+                    Support does not exist for DEB.
+                </para>
+
+                <para>
+                    See the
+                    <link linkend='var-NO_RECOMMENDATIONS'><filename>NO_RECOMMENDATIONS</filename></link>
+                    and the
+                    <link linkend='var-BAD_RECOMMENDATIONS'><filename>BAD_RECOMMENDATIONS</filename></link>
+                    variables for related information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGE_EXTRA_ARCHS'><glossterm>PACKAGE_EXTRA_ARCHS</glossterm>
+            <glossdef>
+                <para>Specifies the list of architectures compatible with the device CPU.
+                    This variable is useful when you build for several different devices that use
+                    miscellaneous processors such as XScale and ARM926-EJS).</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGE_GROUP'><glossterm>PACKAGE_GROUP</glossterm>
+            <glossdef>
+
+                <para>
+                    The <filename>PACKAGE_GROUP</filename> variable has been
+                    renamed to
+                    <link linkend='var-FEATURE_PACKAGES'><filename>FEATURE_PACKAGES</filename></link>.
+                    See the variable description for
+                    <filename>FEATURE_PACKAGES</filename> for information.
+                </para>
+
+                <para>
+                    If if you use the <filename>PACKAGE_GROUP</filename>
+                    variable, the OpenEmbedded build system issues a warning
+                    message.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGE_INSTALL'><glossterm>PACKAGE_INSTALL</glossterm>
+            <glossdef>
+                <para>
+                    The final list of packages passed to the package manager
+                    for installation into the image.
+                </para>
+
+                <para>
+                    Because the package manager controls actual installation
+                    of all packages, the list of packages passed using
+                    <filename>PACKAGE_INSTALL</filename> is not the final list
+                    of packages that are actually installed.
+                    This variable is internal to the image construction
+                    code.
+                    Consequently, in general, you should use the
+                    <link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>
+                    variable to specify packages for installation.
+                    The exception to this is when working with
+                    the
+                    <link linkend='images-core-image-minimal-initramfs'><filename>core-image-minimal-initramfs</filename></link>
+                    image.
+                    When working with an initial RAM disk (initramfs)
+                    image, use the <filename>PACKAGE_INSTALL</filename>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGE_PREPROCESS_FUNCS'><glossterm>PACKAGE_PREPROCESS_FUNCS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a list of functions run to pre-process the
+                    <link linkend='var-PKGD'><filename>PKGD</filename></link>
+                    directory prior to splitting the files out to individual
+                    packages.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGECONFIG'><glossterm>PACKAGECONFIG</glossterm>
+            <glossdef>
+                <para>
+                    This variable provides a means of enabling or disabling
+                    features of a recipe on a per-recipe basis.
+                    <filename>PACKAGECONFIG</filename> blocks are defined
+                    in recipes when you specify features and then arguments
+                    that define feature behaviors.
+                    Here is the basic block structure:
+                    <literallayout class='monospaced'>
+     PACKAGECONFIG ??= "f1 f2 f3 ..."
+     PACKAGECONFIG[f1] = "--with-f1,--without-f1,build-deps-f1,rt-deps-f1"
+     PACKAGECONFIG[f2] = "--with-f2,--without-f2,build-deps-f2,rt-deps-f2"
+     PACKAGECONFIG[f3] = "--with-f3,--without-f3,build-deps-f3,rt-deps-f3"
+                    </literallayout>
+                    The <filename>PACKAGECONFIG</filename>
+                    variable itself specifies a space-separated list of the
+                    features to enable.
+                    Following the features, you can determine the behavior of
+                    each feature by providing up to four order-dependent
+                    arguments, which are separated by commas.
+                    You can omit any argument you like but must retain the
+                    separating commas.
+                    The order is important and specifies the following:
+                    <orderedlist>
+                        <listitem><para>Extra arguments
+                            that should be added to the configure script
+                            argument list
+                            (<link linkend='var-EXTRA_OECONF'><filename>EXTRA_OECONF</filename></link>)
+                            if the feature is enabled.</para></listitem>
+                        <listitem><para>Extra arguments
+                            that should be added to <filename>EXTRA_OECONF</filename>
+                            if the feature is disabled.
+                            </para></listitem>
+                        <listitem><para>Additional build dependencies
+                            (<link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>)
+                            that should be added if the feature is enabled.
+                            </para></listitem>
+                        <listitem><para>Additional runtime dependencies
+                            (<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>)
+                            that should be added if the feature is enabled.
+                            </para></listitem>
+                    </orderedlist>
+                </para>
+
+                <para>
+                    Consider the following
+                    <filename>PACKAGECONFIG</filename> block taken from the
+                    <filename>librsvg</filename> recipe.
+                    In this example the feature is <filename>croco</filename>,
+                    which has three arguments that determine the feature's
+                    behavior.
+                    <literallayout class='monospaced'>
+     PACKAGECONFIG ??= "croco"
+     PACKAGECONFIG[croco] = "--with-croco,--without-croco,libcroco"
+                    </literallayout>
+                    The <filename>--with-croco</filename> and
+                    <filename>libcroco</filename> arguments apply only if
+                    the feature is enabled.
+                    In this case, <filename>--with-croco</filename> is
+                    added to the configure script argument list and
+                    <filename>libcroco</filename> is added to
+                    <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>.
+                    On the other hand, if the feature is disabled say through
+                    a <filename>.bbappend</filename> file in another layer, then
+                    the second argument <filename>--without-croco</filename> is
+                    added to the configure script rather than
+                    <filename>--with-croco</filename>.
+                </para>
+
+                <para>
+                    The basic <filename>PACKAGECONFIG</filename> structure
+                    previously described holds true regardless of whether you
+                    are creating a block or changing a block.
+                    When creating a block, use the structure inside your
+                    recipe.
+                </para>
+
+                <para>
+                    If you want to change an existing
+                    <filename>PACKAGECONFIG</filename> block, you can do so
+                    one of two ways:
+                    <itemizedlist>
+                        <listitem><para><emphasis>Append file:</emphasis>
+                            Create an append file named
+                            <replaceable>recipename</replaceable><filename>.bbappend</filename>
+                            in your layer and override the value of
+                            <filename>PACKAGECONFIG</filename>.
+                            You can either completely override the variable:
+                            <literallayout class='monospaced'>
+     PACKAGECONFIG="f4 f5"
+                            </literallayout>
+                            Or, you can just append the variable:
+                            <literallayout class='monospaced'>
+     PACKAGECONFIG_append = " f4"
+                            </literallayout></para></listitem>
+                        <listitem><para><emphasis>Configuration file:</emphasis>
+                            This method is identical to changing the block
+                            through an append file except you edit your
+                            <filename>local.conf</filename> or
+                            <filename><replaceable>mydistro</replaceable>.conf</filename> file.
+                            As with append files previously described,
+                            you can either completely override the variable:
+                            <literallayout class='monospaced'>
+     PACKAGECONFIG_pn-<replaceable>recipename</replaceable>="f4 f5"
+                            </literallayout>
+                            Or, you can just amend the variable:
+                            <literallayout class='monospaced'>
+     PACKAGECONFIG_append_pn-<replaceable>recipename</replaceable> = " f4"
+                            </literallayout></para></listitem>
+                    </itemizedlist>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGES'><glossterm>PACKAGES</glossterm>
+            <glossdef>
+                <para>The list of packages to be created from the recipe.
+                    The default value is the following:
+                    <literallayout class='monospaced'>
+     ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGESPLITFUNCS'><glossterm>PACKAGESPLITFUNCS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a list of functions run to perform additional
+                    splitting of files into individual packages.
+                    Recipes can either prepend to this variable or prepend
+                    to the <filename>populate_packages</filename> function
+                    in order to perform additional package splitting.
+                    In either case, the function should set
+                    <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>,
+                    <link linkend='var-FILES'><filename>FILES</filename></link>,
+                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
+                    and other packaging variables appropriately in order to
+                    perform the desired splitting.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGES_DYNAMIC'><glossterm>PACKAGES_DYNAMIC</glossterm>
+            <glossdef>
+                <para>
+                    A promise that your recipe satisfies runtime dependencies
+                    for optional modules that are found in other recipes.
+                    <filename>PACKAGES_DYNAMIC</filename>
+                    does not actually satisfy the dependencies, it only states that
+                    they should be satisfied.
+                    For example, if a hard, runtime dependency
+                    (<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>)
+                    of another package is satisfied
+                    at build time through the <filename>PACKAGES_DYNAMIC</filename>
+                    variable, but a package with the module name is never actually
+                    produced, then the other package will be broken.
+                    Thus, if you attempt to include that package in an image,
+                    you will get a dependency failure from the packaging system
+                    during the
+                    <link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>
+                    task.
+                </para>
+                <para>
+                    Typically, if there is a chance that such a situation can
+                    occur and the package that is not created is valid
+                    without the dependency being satisfied, then you should use
+                    <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>
+                    (a soft runtime dependency) instead of
+                    <filename>RDEPENDS</filename>.
+                </para>
+
+                <para>
+                    For an example of how to use the <filename>PACKAGES_DYNAMIC</filename>
+                    variable when you are splitting packages, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#handling-optional-module-packaging'>Handling Optional Module Packaging</ulink>" section
+                    in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PARALLEL_MAKE'><glossterm>PARALLEL_MAKE</glossterm>
+            <glossdef>
+                <para>
+                    Extra options passed to the <filename>make</filename>
+                    command during the
+                    <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
+                    task in order to specify parallel compilation on the local
+                    build host.
+                    This variable is usually in the form "-j &lt;x&gt;",
+                    where x represents the maximum number of parallel threads
+                    <filename>make</filename> can run.
+                </para>
+
+                <para>
+                    If your development host supports multiple cores, a good
+                    rule of thumb is to set this variable to twice the number
+                    of cores on the host.
+                    If you do not set <filename>PARALLEL_MAKE</filename>, it
+                    defaults to the number of cores your build system has.
+                    <note>
+                        Individual recipes might clear out this variable if
+                        the software being built has problems running its
+                        <filename>make</filename> process in parallel.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PARALLEL_MAKEINST'><glossterm>PARALLEL_MAKEINST</glossterm>
+            <glossdef>
+                <para>
+                    Extra options passed to the
+                    <filename>make install</filename> command during the
+                    <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+                    task in order to specify parallel installation.
+                    This variable defaults to the value of
+                    <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>.
+                    <note>
+                        Individual recipes might clear out this variable if
+                        the software being built has problems running its
+                        <filename>make install</filename> process in parallel.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PATCHRESOLVE'><glossterm>PATCHRESOLVE</glossterm>
+            <glossdef>
+                <para>
+                    Determines the action to take when a patch fails.
+                    You can set this variable to one of two values: "noop" and
+                    "user".
+                </para>
+
+                <para>
+                    The default value of "noop" causes the build to simply fail
+                    when the OpenEmbedded build system cannot successfully
+                    apply a patch.
+                    Setting the value to "user" causes the build system to
+                    launch a shell and places you in the right location so that
+                    you can manually resolve the conflicts.
+                </para>
+
+                <para>
+                    Set this variable in your
+                    <filename>local.conf</filename> file.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PATCHTOOL'><glossterm>PATCHTOOL</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the utility used to apply patches for a recipe
+                    during the
+                    <link linkend='ref-tasks-patch'><filename>do_patch</filename></link>
+                    task.
+                    You can specify one of three utilities: "patch", "quilt", or
+                    "git".
+                    The default utility used is "quilt" except for the
+                    quilt-native recipe itself.
+                    Because the quilt tool is not available at the
+                    time quilt-native is being patched, it uses "patch".
+                </para>
+
+                <para>
+                    If you wish to use an alternative patching tool, set the
+                    variable in the recipe using one of the following:
+                    <literallayout class='monospaced'>
+     PATCHTOOL = "patch"
+     PATCHTOOL = "quilt"
+     PATCHTOOL = "git"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PE'><glossterm>PE</glossterm>
+            <glossdef>
+                <para>
+                    The epoch of the recipe.
+                    By default, this variable is unset.
+                    The variable is used to make upgrades possible when the
+                    versioning scheme changes in some backwards incompatible
+                    way.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PF'><glossterm>PF</glossterm>
+            <glossdef>
+                <para>Specifies the recipe or package name and includes all version and revision
+                    numbers (i.e. <filename>glibc-2.13-r20+svnr15508/</filename> and
+                    <filename>bash-4.2-r1/</filename>).
+                    This variable is comprised of the following:
+                    <literallayout class='monospaced'>
+     ${<link linkend='var-PN'>PN</link>}-${<link linkend='var-EXTENDPE'>EXTENDPE</link>}${<link linkend='var-PV'>PV</link>}-${<link linkend='var-PR'>PR</link>}
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PIXBUF_PACKAGES'><glossterm>PIXBUF_PACKAGES</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-pixbufcache'><filename>pixbufcache</filename></link>
+                    class, this variable identifies packages that contain
+                    the pixbuf loaders used with
+                    <filename>gdk-pixbuf</filename>.
+                    By default, the <filename>pixbufcache</filename> class
+                    assumes that the loaders are in the recipe's main package
+                    (i.e. <filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename>).
+                    Use this variable if the loaders you need are in a package
+                    other than that main package.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PKG'><glossterm>PKG</glossterm>
+            <glossdef>
+                <para>
+                    The name of the resulting package created by the
+                    OpenEmbedded build system.
+                    <note>
+                        When using the <filename>PKG</filename> variable, you
+                        must use a package name override.
+                    </note>
+                    For example, when the
+                    <link linkend='ref-classes-debian'><filename>debian</filename></link>
+                    class renames the output package, it does so by setting
+                    <filename>PKG_<replaceable>packagename</replaceable></filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PKGD'><glossterm>PKGD</glossterm>
+            <glossdef>
+                <para>
+                    Points to the destination directory for files to be
+                    packaged before they are split into individual packages.
+                    This directory defaults to the following:
+                    <literallayout class='monospaced'>
+     ${WORKDIR}/package
+                    </literallayout>
+                    Do not change this default.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PKGDATA_DIR'><glossterm>PKGDATA_DIR</glossterm>
+            <glossdef>
+                <para>
+                    Points to a shared, global-state directory that holds data
+                    generated during the packaging process.
+                    During the packaging process, the
+                    <link linkend='ref-tasks-packagedata'><filename>do_packagedata</filename></link>
+                    task packages data for each recipe and installs it into
+                    this temporary, shared area.
+                    This directory defaults to the following:
+                    <literallayout class='monospaced'>
+     ${STAGING_DIR_HOST}/pkgdata
+                    </literallayout>
+                    Do not change this default.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PKGDEST'><glossterm>PKGDEST</glossterm>
+            <glossdef>
+                <para>
+                    Points to the parent directory for files to be packaged
+                    after they have been split into individual packages.
+                    This directory defaults to the following:
+                    <literallayout class='monospaced'>
+     ${WORKDIR}/packages-split
+                    </literallayout>
+                    Under this directory, the build system creates
+                    directories for each package specified in
+                    <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>.
+                    Do not change this default.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PKGDESTWORK'><glossterm>PKGDESTWORK</glossterm>
+            <glossdef>
+                <para>
+                    Points to a temporary work area used by the
+                    <link linkend='ref-tasks-package'><filename>do_package</filename></link>
+                    task to write output from the
+                    <link linkend='ref-tasks-packagedata'><filename>do_packagedata</filename></link>
+                    task.
+                    The <filename>PKGDESTWORK</filename> location defaults to
+                    the following:
+                    <literallayout class='monospaced'>
+     ${WORKDIR}/pkgdata
+                    </literallayout>
+                    The <filename>do_packagedata</filename> task then packages
+                    the data in the temporary work area and installs it into a
+                    shared directory pointed to by
+                    <link linkend='var-PKGDATA_DIR'><filename>PKGDATA_DIR</filename></link>.
+                </para>
+
+                <para>
+                    Do not change this default.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PKGE'><glossterm>PKGE</glossterm>
+            <glossdef>
+                <para>
+                    The epoch of the output package built by the
+                    OpenEmbedded build system.
+                    By default, <filename>PKGE</filename> is set to
+                    <link linkend='var-PE'><filename>PE</filename></link>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PKGR'><glossterm>PKGR</glossterm>
+            <glossdef>
+                <para>
+                    The revision of the output package built by the
+                    OpenEmbedded build system.
+                    By default, <filename>PKGR</filename> is set to
+                    <link linkend='var-PR'><filename>PR</filename></link>.
+                    </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PKGV'><glossterm>PKGV</glossterm>
+            <glossdef>
+                <para>
+                    The version of the output package built by the
+                    OpenEmbedded build system.
+                    By default, <filename>PKGV</filename> is set to
+                    <link linkend='var-PV'><filename>PV</filename></link>.
+                 </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PN'><glossterm>PN</glossterm>
+            <glossdef>
+                <para>This variable can have two separate functions depending on the context: a recipe
+                    name or a resulting package name.</para>
+                <para><filename>PN</filename> refers to a recipe name in the context of a file used
+                    by the OpenEmbedded build system as input to create a package.
+                    The name is normally extracted from the recipe file name.
+                    For example, if the recipe is named
+                    <filename>expat_2.0.1.bb</filename>, then the default value of <filename>PN</filename>
+                    will be "expat".</para>
+                <para>
+                    The variable refers to a package name in the context of a file created or produced by the
+                    OpenEmbedded build system.</para>
+                <para>If applicable, the <filename>PN</filename> variable also contains any special
+                    suffix or prefix.
+                    For example, using <filename>bash</filename> to build packages for the native
+                    machine, <filename>PN</filename> is <filename>bash-native</filename>.
+                    Using <filename>bash</filename> to build packages for the target and for Multilib,
+                    <filename>PN</filename> would be <filename>bash</filename> and
+                    <filename>lib64-bash</filename>, respectively.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PNBLACKLIST'><glossterm>PNBLACKLIST</glossterm>
+            <glossdef>
+                <para>
+                    Lists recipes you do not want the OpenEmbedded build system
+                    to build.
+                    This variable works in conjunction with the
+                    <link linkend='ref-classes-blacklist'><filename>blacklist</filename></link>
+                    class, which the recipe must inherit globally.
+                </para>
+
+                <para>
+                    To prevent a recipe from being built, inherit the class
+                    globally and use the variable in your
+                    <filename>local.conf</filename> file.
+                    Here is an example that prevents
+                    <filename>myrecipe</filename> from being built:
+                    <literallayout class='monospaced'>
+     INHERIT += "blacklist"
+     PNBLACKLIST[myrecipe] = "Not supported by our organization."
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PR'><glossterm>PR</glossterm>
+            <glossdef>
+                <para>
+                    The revision of the recipe.
+                    The default value for this variable is "r0".
+                    </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PREFERRED_PROVIDER'><glossterm>PREFERRED_PROVIDER</glossterm>
+            <glossdef>
+                <para>
+                    If multiple recipes provide an item, this variable
+                    determines which recipe should be given preference.
+                    You should always suffix the variable with the name of the
+                    provided item, and you should set it to the
+                    <link linkend='var-PN'><filename>PN</filename></link>
+                    of the recipe to which you want to give precedence.
+                    Some examples:
+                    <literallayout class='monospaced'>
+     PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+     PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
+     PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PREFERRED_VERSION'><glossterm>PREFERRED_VERSION</glossterm>
+            <glossdef>
+                <para>
+                    If there are multiple versions of recipes available, this
+                    variable determines which recipe should be given preference.
+                    You must always suffix the variable with the
+                    <link linkend='var-PN'><filename>PN</filename></link>
+                    you want to select, and you should set the
+                    <link linkend='var-PV'><filename>PV</filename></link>
+                    accordingly for precedence.
+                    You can use the "<filename>%</filename>" character as a
+                    wildcard to match any number of characters, which can be
+                    useful when specifying versions that contain long revision
+                    numbers that could potentially change.
+                    Here are two examples:
+                    <literallayout class='monospaced'>
+     PREFERRED_VERSION_python = "2.7.3"
+     PREFERRED_VERSION_linux-yocto = "3.10%"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PREMIRRORS'><glossterm>PREMIRRORS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies additional paths from which the OpenEmbedded
+                    build system gets source code.
+                    When the build system searches for source code, it first
+                    tries the local download directory.
+                    If that location fails, the build system tries locations
+                    defined by <filename>PREMIRRORS</filename>, the upstream
+                    source, and then locations specified by
+                    <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
+                    in that order.
+                </para>
+
+                <para>
+                    Assuming your distribution
+                    (<link linkend='var-DISTRO'><filename>DISTRO</filename></link>)
+                    is "poky", the default value for
+                    <filename>PREMIRRORS</filename> is defined in the
+                    <filename>conf/distro/poky.conf</filename> file in the
+                    <filename>meta-yocto</filename> Git repository.
+                </para>
+
+                <para>
+                    Typically, you could add a specific server for the
+                    build system to attempt before any others by adding
+                    something like the following to the
+                    <filename>local.conf</filename> configuration file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
+                    <literallayout class='monospaced'>
+     PREMIRRORS_prepend = "\
+     git://.*/.* http://www.yoctoproject.org/sources/ \n \
+     ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
+     http://.*/.* http://www.yoctoproject.org/sources/ \n \
+     https://.*/.* http://www.yoctoproject.org/sources/ \n"
+                    </literallayout>
+                    These changes cause the build system to intercept
+                    Git, FTP, HTTP, and HTTPS requests and direct them to
+                    the <filename>http://</filename> sources mirror.
+                    You can use <filename>file://</filename> URLs to point
+                    to local directories or network shares as well.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PRINC'><glossterm>PRINC</glossterm>
+            <glossdef>
+
+                <para>
+                    The <filename>PRINC</filename> variable has been deprecated
+                    and triggers a warning if detected during a build.
+                    For
+                    <link linkend='var-PR'><filename>PR</filename></link>
+                    increments on changes, use the PR service instead.
+                    You can find out more about this service in the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service'>Working With a PR Service</ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+<!--
+
+                <para>
+                    Causes the
+                    <link linkend='var-PR'><filename>PR</filename></link>
+                    variable of <filename>.bbappend</filename> files to
+                    dynamically increment.
+                    This increment minimizes the impact of layer ordering.
+                </para>
+
+                <para>
+                    In order to ensure multiple <filename>.bbappend</filename>
+                    files can co-exist,
+                    <filename>PRINC</filename> should be self-referencing.
+                    This variable defaults to 0.
+                </para>
+
+                <para>
+                    Following is an example that increments
+                    <filename>PR</filename> by two:
+                    <literallayout class='monospaced'>
+     PRINC := "${@int(PRINC) + 2}"
+                    </literallayout>
+                    It is advisable not to use strings such as ".= '.1'" with the variable because
+                    this usage is very sensitive to layer ordering.
+                    You should avoid explicit assignments as they cannot
+                    adequately represent multiple
+                    <filename>.bbappend</filename> files.
+                </para>
+-->
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PRIVATE_LIBS'><glossterm>PRIVATE_LIBS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies libraries installed within a recipe that
+                    should be ignored by the OpenEmbedded build system's
+                    shared library resolver.
+                    This variable is typically used when software being
+                    built by a recipe has its own private versions of a
+                    library normally provided by another recipe.
+                    In this case, you would not want the package containing
+                    the private libraries to be set as a dependency on other
+                    unrelated packages that should instead depend on the
+                    package providing the standard version of the library.
+                </para>
+
+                <para>
+                    Libraries specified in this variable should be specified
+                    by their file name.
+                    For example, from the Firefox recipe in meta-browser:
+                    <literallayout class='monospaced'>
+     PRIVATE_LIBS = "libmozjs.so \
+                     libxpcom.so \
+                     libnspr4.so \
+                     libxul.so \
+                     libmozalloc.so \
+                     libplc4.so \
+                     libplds4.so"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PROVIDES'><glossterm>PROVIDES</glossterm>
+            <glossdef>
+                <para>
+                    A list of aliases by which a particular recipe can be
+                    known.
+                    By default, a recipe's own
+                    <filename><link linkend='var-PN'>PN</link></filename>
+                    is implicitly already in its <filename>PROVIDES</filename>
+                    list.
+                    If a recipe uses <filename>PROVIDES</filename>, the
+                    additional aliases are synonyms for the recipe and can
+                    be useful satisfying dependencies of other recipes during
+                    the build as specified by
+                    <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>.
+                </para>
+
+                <para>
+                    Consider the following example
+                    <filename>PROVIDES</filename> statement from a recipe
+                    file <filename>libav_0.8.11.bb</filename>:
+                    <literallayout class='monospaced'>
+     PROVIDES += "libpostproc"
+                    </literallayout>
+                    The <filename>PROVIDES</filename> statement results in
+                    the "libav" recipe also being known as "libpostproc".
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PRSERV_HOST'><glossterm>PRSERV_HOST</glossterm>
+            <glossdef>
+                <para>
+                    The network based
+                    <link linkend='var-PR'><filename>PR</filename></link>
+                    service host and port.
+                </para>
+
+                <para>
+                    The <filename>conf/local.conf.sample.extended</filename>
+                    configuration file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    shows how the <filename>PRSERV_HOST</filename> variable is
+                    set:
+                    <literallayout class='monospaced'>
+     PRSERV_HOST = "localhost:0"
+                    </literallayout>
+                    You must set the variable if you want to automatically
+                    start a local
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service'>PR service</ulink>.
+                    You can set <filename>PRSERV_HOST</filename> to other
+                    values to use a remote PR service.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PTEST_ENABLED'><glossterm>PTEST_ENABLED</glossterm>
+            <glossdef>
+                <para>
+                    Specifies whether or not
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest'>Package Test</ulink>
+                    (ptest) functionality is enabled when building a recipe.
+                    You should not set this variable directly.
+                    Enabling and disabling building Package Tests
+                    at build time should be done by adding "ptest" to (or
+                    removing it from)
+                    <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
+                 </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PV'><glossterm>PV</glossterm>
+            <glossdef>
+                <para>
+                    The version of the recipe.
+                    The version is normally extracted from the recipe filename.
+                    For example, if the recipe is named
+                    <filename>expat_2.0.1.bb</filename>, then the default value of <filename>PV</filename>
+                    will be "2.0.1".
+                    <filename>PV</filename> is generally not overridden within
+                    a recipe unless it is building an unstable (i.e. development) version from a source code repository
+                    (e.g. Git or Subversion).
+                 </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PYTHON_ABI'><glossterm>PYTHON_ABI</glossterm>
+            <glossdef>
+                <para>
+                    When used by recipes that inherit the
+                    <link linkend='ref-classes-distutils3'><filename>distutils3</filename></link>,
+                    <link linkend='ref-classes-setuptools3'><filename>setuptools3</filename></link>,
+                    <link linkend='ref-classes-distutils'><filename>distutils</filename></link>,
+                    or
+                    <link linkend='ref-classes-setuptools'><filename>setuptools</filename></link>
+                    classes, denotes the Application Binary Interface (ABI)
+                    currently in use for Python.
+                    By default, the ABI is "m".
+                    You do not have to set this variable as the OpenEmbedded
+                    build system sets it for you.
+                </para>
+
+                <para>
+                    The OpenEmbedded build system uses the ABI to construct
+                    directory names used when installing the Python headers
+                    and libraries in sysroot
+                    (e.g. <filename>.../python3.3m/...</filename>).
+                </para>
+
+                <para>
+                    Recipes that inherit the
+                    <link linkend='ref-classes-distutils'><filename>distutils</filename></link>
+                    class during cross-builds also use this variable to
+                    locate the headers and libraries of the appropriate Python
+                    that the extension is targeting.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PYTHON_PN'><glossterm>PYTHON_PN</glossterm>
+            <glossdef>
+                <para>
+                    When used by recipes that inherit the
+                    <link linkend='ref-classes-distutils3'><filename>distutils3</filename></link>,
+                    <link linkend='ref-classes-setuptools3'><filename>setuptools3</filename></link>,
+                    <link linkend='ref-classes-distutils'><filename>distutils</filename></link>,
+                    or
+                    <link linkend='ref-classes-setuptools'><filename>setuptools</filename></link>
+                    classes, specifies the major Python version being built.
+                    For Python 2.x, <filename>PYTHON_PN</filename> would
+                    be "python2".  For Python 3.x, the variable would be
+                    "python3".
+                    You do not have to set this variable as the
+                    OpenEmbedded build system automatically sets it for you.
+                </para>
+
+                <para>
+                    The variable allows recipes to use common infrastructure
+                    such as the following:
+                    <literallayout class='monospaced'>
+     DEPENDS += "${PYTHON_PN}-native"
+                    </literallayout>
+                    In the previous example, the version of the dependency
+                    is <filename>PYTHON_PN</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-q'><title>Q</title>
+
+        <glossentry id='var-QMAKE_PROFILES'><glossterm>QMAKE_PROFILES</glossterm>
+            <glossdef>
+                <para>
+                    Specifies your own subset of <filename>.pro</filename>
+                    files to be built for use with
+                    <filename>qmake</filename>.
+                    If you do not set this variable, all
+                    <filename>.pro</filename> files in the directory pointed to
+                    by <link linkend='var-S'><filename>S</filename></link>
+                    will be built by default.
+                </para>
+
+                <para>
+                    This variable is used with recipes that inherit the
+                    <link linkend='ref-classes-qmake*'><filename>qmake_base</filename></link>
+                    class or other classes that inherit
+                    <filename>qmake_base</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-r'><title>R</title>
+
+        <glossentry id='var-RCONFLICTS'><glossterm>RCONFLICTS</glossterm>
+            <glossdef>
+                <para>
+                    The list of packages that conflict with packages.
+                    Note that packages will not be installed if conflicting
+                    packages are not first removed.
+                </para>
+
+                <para>
+                   Like all package-controlling variables, you must always use
+                   them in conjunction with a package name override.
+                   Here is an example:
+                   <literallayout class='monospaced'>
+     RCONFLICTS_${PN} = "<replaceable>another-conflicting-package-name</replaceable>"
+                   </literallayout>
+                </para>
+
+                <para>
+                    BitBake, which the OpenEmbedded build system uses, supports
+                    specifying versioned dependencies.
+                    Although the syntax varies depending on the packaging
+                    format, BitBake hides these differences from you.
+                    Here is the general syntax to specify versions with
+                    the <filename>RCONFLICTS</filename> variable:
+                    <literallayout class='monospaced'>
+     RCONFLICTS_${PN} = "<replaceable>package</replaceable> (<replaceable>operator</replaceable> <replaceable>version</replaceable>)"
+                    </literallayout>
+                    For <filename>operator</filename>, you can specify the
+                    following:
+                    <literallayout class='monospaced'>
+     =
+     &lt;
+     &gt;
+     &lt;=
+     &gt;=
+                    </literallayout>
+                    For example, the following sets up a dependency on version
+                    1.2 or greater of the package <filename>foo</filename>:
+                    <literallayout class='monospaced'>
+     RCONFLICTS_${PN} = "foo (>= 1.2)"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-RDEPENDS'><glossterm>RDEPENDS</glossterm>
+            <glossdef>
+                <para>
+                    Lists a package's runtime dependencies (i.e. other packages)
+                    that must be installed in order for the built package to run
+                    correctly.
+                    If a package in this list cannot be found during the build,
+                    you will get a build error.
+                </para>
+
+                <para>
+                    When you use the <filename>RDEPENDS</filename> variable
+                    in a recipe, you are essentially stating that the recipe's
+                    <link linkend='ref-tasks-build'><filename>do_build</filename></link>
+                    task depends on the existence of a specific package.
+                    Consider this simple example for two recipes named "a" and
+                    "b" that produce similarly named IPK packages.
+                    In this example, the <filename>RDEPENDS</filename>
+                    statement appears in the "a" recipe:
+                    <literallayout class='monospaced'>
+     RDEPENDS_${PN} = "b"
+                    </literallayout>
+                    Here, the dependency is such that the
+                    <filename>do_build</filename> task for recipe "a" depends
+                    on the
+                    <link linkend='ref-tasks-package_write_ipk'><filename>do_package_write_ipk</filename></link>
+                    task of recipe "b".
+                    This means the package file for "b" must be available when
+                    the output for recipe "a" has been completely built.
+                    More importantly, package "a" will be marked as depending
+                    on package "b" in a manner that is understood by the
+                    package manager.
+                </para>
+
+                <para>
+                    The names of the packages you list within
+                    <filename>RDEPENDS</filename> must be the names of other
+                    packages - they cannot be recipe names.
+                    Although package names and recipe names usually match,
+                    the important point here is that you are
+                    providing package names within the
+                    <filename>RDEPENDS</filename> variable.
+                    For an example of the default list of packages created from
+                    a recipe, see the
+                    <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>
+                    variable.
+                </para>
+
+                <para>
+                    Because the <filename>RDEPENDS</filename> variable applies
+                    to packages being built, you should always use the variable
+                    in a form with an attached package name.
+                    For example, suppose you are building a development package
+                    that depends on the <filename>perl</filename> package.
+                    In this case, you would use the following
+                    <filename>RDEPENDS</filename> statement:
+                    <literallayout class='monospaced'>
+     RDEPENDS_${PN}-dev += "perl"
+                    </literallayout>
+                    In the example, the development package depends on
+                    the <filename>perl</filename> package.
+                    Thus, the <filename>RDEPENDS</filename> variable has the
+                    <filename>${PN}-dev</filename> package name as part of the
+                    variable.
+                </para>
+
+                <para>
+                    The package name you attach to the
+                    <filename>RDEPENDS</filename> variable must appear
+                    as it would in the <filename>PACKAGES</filename>
+                    namespace before any renaming of the output package by
+                    classes like
+                    <link linkend='ref-classes-debian'><filename>debian</filename></link>.
+                </para>
+
+                <para>
+                    In many cases you do not need to explicitly add
+                    runtime dependencies using
+                    <filename>RDEPENDS</filename> since some automatic
+                    handling occurs:
+                    <itemizedlist>
+                        <listitem><para><emphasis><filename>shlibdeps</filename></emphasis>:  If
+                            a runtime package contains a shared library
+                            (<filename>.so</filename>), the build
+                            processes the library in order to determine other
+                            libraries to which it is dynamically linked.
+                            The build process adds these libraries to
+                            <filename>RDEPENDS</filename> when creating the runtime
+                            package.</para></listitem>
+                        <listitem><para><emphasis><filename>pcdeps</filename></emphasis>:  If
+                            the package ships a <filename>pkg-config</filename>
+                            information file, the build process uses this file
+                            to add items to the <filename>RDEPENDS</filename>
+                            variable to create the runtime packages.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    BitBake, which the OpenEmbedded build system uses, supports
+                    specifying versioned dependencies.
+                    Although the syntax varies depending on the packaging
+                    format, BitBake hides these differences from you.
+                    Here is the general syntax to specify versions with
+                    the <filename>RDEPENDS</filename> variable:
+                    <literallayout class='monospaced'>
+     RDEPENDS_${PN} = "<replaceable>package</replaceable> (<replaceable>operator</replaceable> <replaceable>version</replaceable>)"
+                    </literallayout>
+                    For <filename>operator</filename>, you can specify the
+                    following:
+                    <literallayout class='monospaced'>
+     =
+     &lt;
+     &gt;
+     &lt;=
+     &gt;=
+                    </literallayout>
+                    For example, the following sets up a dependency on version
+                    1.2 or greater of the package <filename>foo</filename>:
+                    <literallayout class='monospaced'>
+     RDEPENDS_${PN} = "foo (>= 1.2)"
+                    </literallayout>
+                </para>
+
+                <para>
+                    For information on build-time dependencies, see the
+                    <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-REQUIRED_DISTRO_FEATURES'><glossterm>REQUIRED_DISTRO_FEATURES</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-distro_features_check'><filename>distro_features_check</filename></link>
+                    class, this
+                    variable identifies distribution features that must
+                    exist in the current configuration in order for the
+                    OpenEmbedded build system to build the recipe.
+                    In other words, if the
+                    <filename>REQUIRED_DISTRO_FEATURES</filename> variable
+                    lists a feature that does not appear in
+                    <filename>DISTRO_FEATURES</filename> within the
+                    current configuration, an error occurs and the
+                    build stops.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-RM_OLD_IMAGE'><glossterm>RM_OLD_IMAGE</glossterm>
+            <glossdef>
+                <para>
+                    Reclaims disk space by removing previously built
+                    versions of the same image from the
+                    <filename>images</filename> directory pointed to by the
+                    <link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>
+                    variable.
+                </para>
+
+                <para>
+                    Set this variable to "1" in your
+                    <filename>local.conf</filename> file to remove these
+                    images.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-RM_WORK_EXCLUDE'><glossterm>RM_WORK_EXCLUDE</glossterm>
+            <glossdef>
+                <para>
+                    With <filename>rm_work</filename> enabled, this
+                    variable specifies a list of recipes whose work directories
+                    should not be removed.
+                    See the "<link linkend='ref-classes-rm-work'><filename>rm_work.bbclass</filename></link>"
+                    section for more details.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-ROOT_HOME'><glossterm>ROOT_HOME</glossterm>
+            <glossdef>
+                <para>
+                    Defines the root home directory.
+                    By default, this directory is set as follows in the
+                    BitBake configuration file:
+                    <literallayout class='monospaced'>
+     ROOT_HOME ??= "/home/root"
+                    </literallayout>
+                    <note>
+                        This default value is likely used because some
+                        embedded solutions prefer to have a read-only root
+                        filesystem and prefer to keep writeable data in one
+                        place.
+                    </note>
+                </para>
+
+                <para>
+                    You can override the default by setting the variable
+                    in any layer or in the <filename>local.conf</filename> file.
+                    Because the default is set using a "weak" assignment
+                    (i.e. "??="), you can use either of the following forms
+                    to define your override:
+                    <literallayout class='monospaced'>
+     ROOT_HOME = "/root"
+     ROOT_HOME ?= "/root"
+                    </literallayout>
+                    These override examples use <filename>/root</filename>,
+                    which is probably the most commonly used override.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-ROOTFS'><glossterm>ROOTFS</glossterm>
+            <glossdef>
+                <para>
+                    Indicates a filesystem image to include as the root
+                    filesystem.
+                </para>
+
+                <para>
+                    The <filename>ROOTFS</filename> variable is an optional
+                    variable used with the
+                    <link linkend='ref-classes-bootimg'><filename>bootimg</filename></link>
+                    class.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-ROOTFS_POSTPROCESS_COMMAND'><glossterm>ROOTFS_POSTPROCESS_COMMAND</glossterm>
+            <glossdef>
+                <para>
+                    Added by classes to run post processing commands once the
+                    OpenEmbedded build system has created the root filesystem.
+                    You can specify shell commands separated by semicolons:
+                    <literallayout class='monospaced'>
+     ROOTFS_POSTPROCESS_COMMAND += "<replaceable>shell_command</replaceable>; ... "
+                    </literallayout>
+                    If you need to pass the path to the root filesystem within
+                    the command, you can use
+                    <filename>${IMAGE_ROOTFS}</filename>, which points to
+                    the root filesystem image.
+                    See the
+                    <link linkend='var-IMAGE_ROOTFS'><filename>IMAGE_ROOTFS</filename></link>
+                    variable for more information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-RPROVIDES'><glossterm>RPROVIDES</glossterm>
+            <glossdef>
+                <para>
+                    A list of package name aliases that a package also provides.
+                    These aliases are useful for satisfying runtime dependencies
+                    of other packages both during the build and on the target
+                    (as specified by
+                    <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>).
+                    <note>
+                        A package's own name is implicitly already in its
+                        <filename>RPROVIDES</filename> list.
+                    </note>
+                </para>
+                <para>
+                   As with all package-controlling variables, you must always
+                   use the variable in conjunction with a package name override.
+                   Here is an example:
+                   <literallayout class='monospaced'>
+     RPROVIDES_${PN} = "widget-abi-2"
+                   </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm>
+            <glossdef>
+                <para>
+                    A list of packages that extends the usability of a package
+                    being built.
+                    The package being built does not depend on this list of
+                    packages in order to successfully build, but rather
+                    uses them for extended usability.
+                    To specify runtime dependencies for packages, see the
+                    <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>
+                    variable.
+                </para>
+
+                <para>
+                    The package manager will automatically install the
+                    <filename>RRECOMMENDS</filename> list of packages when
+                    installing the built package.
+                    However, you can prevent listed packages from being
+                    installed by using the
+                    <link linkend='var-BAD_RECOMMENDATIONS'><filename>BAD_RECOMMENDATIONS</filename></link>,
+                    <link linkend='var-NO_RECOMMENDATIONS'><filename>NO_RECOMMENDATIONS</filename></link>,
+                    and
+                    <link linkend='var-PACKAGE_EXCLUDE'><filename>PACKAGE_EXCLUDE</filename></link>
+                    variables.
+                </para>
+
+                <para>
+                    Packages specified in
+                    <filename>RRECOMMENDS</filename> need not actually be
+                    produced.
+                    However, a recipe must exist that provides each package,
+                    either through the
+                    <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>
+                    or
+                    <link linkend='var-PACKAGES_DYNAMIC'><filename>PACKAGES_DYNAMIC</filename></link>
+                    variables or the
+                    <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>
+                    variable, or an error will occur during the build.
+                    If such a recipe does exist and the package is not produced,
+                    the build continues without error.
+                </para>
+
+                <para>
+                    Because the <filename>RRECOMMENDS</filename> variable
+                    applies to packages being built, you should always attach
+                    an override to the variable to specify the particular
+                    package whose usability is being extended.
+                    For example, suppose you are building a development package
+                    that is extended to support wireless functionality.
+                    In this case, you would use the following:
+                    <literallayout class='monospaced'>
+     RRECOMMENDS_${PN}-dev += "<replaceable>wireless_package_name</replaceable>"
+                    </literallayout>
+                    In the example, the package name
+                    (<filename>${<link linkend='var-PN'>PN</link>}-dev</filename>)
+                    must appear as it would in the
+                    <filename><link linkend='var-PACKAGES'>PACKAGES</link></filename>
+                    namespace before any renaming of the output package by
+                    classes such as <filename>debian.bbclass</filename>.
+                </para>
+
+                <para>
+                    BitBake, which the OpenEmbedded build system uses, supports
+                    specifying versioned recommends.
+                    Although the syntax varies depending on the packaging
+                    format, BitBake hides these differences from you.
+                    Here is the general syntax to specify versions with
+                    the <filename>RRECOMMENDS</filename> variable:
+                    <literallayout class='monospaced'>
+     RRECOMMENDS_${PN} = "<replaceable>package</replaceable> (<replaceable>operator</replaceable> <replaceable>version</replaceable>)"
+                    </literallayout>
+                    For <filename>operator</filename>, you can specify the
+                    following:
+                    <literallayout class='monospaced'>
+     =
+     &lt;
+     &gt;
+     &lt;=
+     &gt;=
+                    </literallayout>
+                    For example, the following sets up a recommend on version
+                    1.2 or greater of the package <filename>foo</filename>:
+                    <literallayout class='monospaced'>
+     RRECOMMENDS_${PN} = "foo (>= 1.2)"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-RREPLACES'><glossterm>RREPLACES</glossterm>
+            <glossdef>
+                <para>
+                    A list of packages replaced by a package.
+                    The package manager uses this variable to determine which
+                    package should be installed to replace other package(s)
+                    during an upgrade.
+                    In order to also have the other package(s) removed at the
+                    same time, you must add the name of the other
+                    package to the
+                    <filename><link linkend='var-RCONFLICTS'>RCONFLICTS</link></filename> variable.
+                </para>
+                <para>
+                   As with all package-controlling variables, you must use
+                   this variable in conjunction with a package name
+                   override.
+                   Here is an example:
+                   <literallayout class='monospaced'>
+     RREPLACES_${PN} = "<replaceable>other-package-being-replaced</replaceable>"
+                   </literallayout>
+                </para>
+
+                <para>
+                    BitBake, which the OpenEmbedded build system uses, supports
+                    specifying versioned replacements.
+                    Although the syntax varies depending on the packaging
+                    format, BitBake hides these differences from you.
+                    Here is the general syntax to specify versions with
+                    the <filename>RREPLACES</filename> variable:
+                    <literallayout class='monospaced'>
+     RREPLACES_${PN} = "<replaceable>package</replaceable> (<replaceable>operator</replaceable> <replaceable>version</replaceable>)"
+                    </literallayout>
+                    For <filename>operator</filename>, you can specify the
+                    following:
+                    <literallayout class='monospaced'>
+     =
+     &lt;
+     &gt;
+     &lt;=
+     &gt;=
+                    </literallayout>
+                    For example, the following sets up a replacement using
+                    version 1.2 or greater of the package
+                    <filename>foo</filename>:
+                    <literallayout class='monospaced'>
+     RREPLACES_${PN} = "foo (>= 1.2)"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-RSUGGESTS'><glossterm>RSUGGESTS</glossterm>
+            <glossdef>
+                <para>
+                    A list of additional packages that you can suggest for
+                    installation by the package manager at the time a package
+                    is installed.
+                    Not all package managers support this functionality.
+                </para>
+                <para>
+                   As with all package-controlling variables, you must always
+                   use this variable in conjunction with a package name
+                   override.
+                   Here is an example:
+                   <literallayout class='monospaced'>
+     RSUGGESTS_${PN} = "<replaceable>useful-package</replaceable> <replaceable>another-package</replaceable>"
+                   </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-s'><title>S</title>
+
+        <glossentry id='var-S'><glossterm>S</glossterm>
+            <glossdef>
+                <para>
+                    The location in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                    where unpacked recipe source code resides.
+                    This location is within the work directory
+                    (<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>),
+                    which is not static.
+                    The unpacked source location depends on the recipe name
+                    (<filename><link linkend='var-PN'>PN</link></filename>) and
+                    recipe version
+                    (<filename><link linkend='var-PV'>PV</link></filename>) as
+                    follows:
+                    <literallayout class='monospaced'>
+     ${WORKDIR}/${PN}-${PV}
+                    </literallayout>
+                    As an example, assume a
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    top-level folder named <filename>poky</filename> and a
+                    default Build Directory at <filename>poky/build</filename>.
+                    In this case, the work directory the build system uses
+                    to keep the unpacked recipe for <filename>db</filename>
+                    is the following:
+                    <literallayout class='monospaced'>
+     poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SANITY_REQUIRED_UTILITIES'><glossterm>SANITY_REQUIRED_UTILITIES</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a list of command-line utilities that should be
+                    checked for during the initial sanity checking process when
+                    running BitBake.
+                    If any of the utilities are not installed on the build host,
+                    then BitBake immediately exits with an error.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SANITY_TESTED_DISTROS'><glossterm>SANITY_TESTED_DISTROS</glossterm>
+            <glossdef>
+                <para>
+                    A list of the host distribution identifiers that the
+                    build system has been tested against.
+                    Identifiers consist of the host distributor ID
+                    followed by the release,
+                    as reported by the <filename>lsb_release</filename> tool
+                    or as read from <filename>/etc/lsb-release</filename>.
+                    Separate the list items with explicit newline
+                    characters (<filename>\n</filename>).
+                    If <filename>SANITY_TESTED_DISTROS</filename> is not empty
+                    and the current value of
+                    <link linkend='var-NATIVELSBSTRING'><filename>NATIVELSBSTRING</filename></link>
+                    does not appear in the list, then the build system reports
+                    a warning that indicates the current host distribution has
+                    not been tested as a build host.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDK_ARCH'><glossterm>SDK_ARCH</glossterm>
+            <glossdef>
+                <para>
+                    The target architecture for the SDK.
+                    Typically, you do not directly set this variable.
+                    Instead, use
+                    <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDK_DEPLOY'><glossterm>SDK_DEPLOY</glossterm>
+            <glossdef>
+                <para>
+                    The directory set up and used by the
+                    <link linkend='ref-classes-populate-sdk'><filename>populate_sdk_base</filename></link>
+                    to which the SDK is deployed.
+                    The <filename>populate_sdk_base</filename> class defines
+                    <filename>SDK_DEPLOY</filename> as follows:
+                    <literallayout class='monospaced'>
+     SDK_DEPLOY = "${<link linkend='var-TMPDIR'>TMPDIR</link>}/deploy/sdk"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDK_DIR'><glossterm>SDK_DIR</glossterm>
+            <glossdef>
+                <para>
+                    The parent directory used by the OpenEmbedded build system
+                    when creating SDK output.
+                    The
+                    <link linkend='ref-classes-populate-sdk-*'><filename>populate_sdk_base</filename></link>
+                    class defines the variable as follows:
+                    <literallayout class='monospaced'>
+     SDK_DIR = "${<link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>}/sdk"
+                    </literallayout>
+                    <note>
+                        The <filename>SDK_DIR</filename> directory is a
+                        temporary directory as it is part of
+                        <filename>WORKDIR</filename>.
+                        The final output directory is
+                        <link linkend='var-SDK_DEPLOY'><filename>SDK_DEPLOY</filename></link>.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDK_NAME'><glossterm>SDK_NAME</glossterm>
+            <glossdef>
+                <para>
+                    The base name for SDK output files.
+                    The name is derived from the
+                    <link linkend='var-DISTRO'><filename>DISTRO</filename></link>,
+                    <link linkend='var-TCLIBC'><filename>TCLIBC</filename></link>,
+                    <link linkend='var-SDK_ARCH'><filename>SDK_ARCH</filename></link>,
+                    <link linkend='var-IMAGE_BASENAME'><filename>IMAGE_BASENAME</filename></link>,
+                    and
+                    <link linkend='var-TUNE_PKGARCH'><filename>TUNE_PKGARCH</filename></link>
+                    variables:
+                    <literallayout class='monospaced'>
+     SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDK_OUTPUT'><glossterm>SDK_OUTPUT</glossterm>
+            <glossdef>
+                <para>
+                    The location used by the OpenEmbedded build system when
+                    creating SDK output.
+                    The
+                    <link linkend='ref-classes-populate-sdk-*'><filename>populate_sdk_base</filename></link>
+                    class defines the variable as follows:
+                    <literallayout class='monospaced'>
+     SDK_OUTPUT = "${<link linkend='var-SDK_DIR'>SDK_DIR</link>}/image"
+                    </literallayout>
+                    <note>
+                        The <filename>SDK_OUTPUT</filename> directory is a
+                        temporary directory as it is part of
+                        <filename>WORKDIR</filename> by way of
+                        <filename>SDK_DIR</filename>.
+                        The final output directory is
+                        <link linkend='var-SDK_DEPLOY'><filename>SDK_DEPLOY</filename></link>.
+                    </note>
+
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDK_PACKAGE_ARCHS'><glossterm>SDK_PACKAGE_ARCHS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a list of architectures compatible with
+                    the SDK machine.
+                    This variable is set automatically and should not
+                    normally be hand-edited.
+                    Entries are separated using spaces and listed in order
+                    of priority.
+                    The default value for
+                    <filename>SDK_PACKAGE_ARCHS</filename> is "all any noarch
+                    ${SDK_ARCH}-${SDKPKGSUFFIX}".
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDKIMAGE_FEATURES'><glossterm>SDKIMAGE_FEATURES</glossterm>
+            <glossdef>
+                <para>Equivalent to
+                    <filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename>.
+                    However, this variable applies to the SDK generated from an
+                    image using the following command:
+                    <literallayout class='monospaced'>
+     $ bitbake -c populate_sdk <replaceable>imagename</replaceable>
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDKMACHINE'><glossterm>SDKMACHINE</glossterm>
+            <glossdef>
+                <para>
+                    The machine for which the Application Development Toolkit
+                    (ADT) or SDK is built.
+                    In other words, the SDK or ADT is built such that it
+                    runs on the target you specify with the
+                    <filename>SDKMACHINE</filename> value.
+                    The value points to a corresponding
+                    <filename>.conf</filename> file under
+                    <filename>conf/machine-sdk/</filename>.
+                </para>
+
+                <para>
+                     You can use "i686" and "x86_64" as possible values
+                     for this variable. The variable defaults to "i686"
+                     and is set in the local.conf file in the Build Directory.
+                     <literallayout class='monospaced'>
+     SDKMACHINE ?= "i686"
+                     </literallayout>
+                     <note>
+                         You cannot set the <filename>SDKMACHINE</filename>
+                         variable in your distribution configuration file.
+                         If you do, the configuration will not take affect.
+                     </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDKPATH'><glossterm>SDKPATH</glossterm>
+            <glossdef>
+                <para>
+                    Defines the path offered to the user for installation
+                    of the SDK that is generated by the OpenEmbedded build
+                    system.
+                    The path appears as the default location for installing
+                    the SDK when you run the SDK's installation script.
+                    You can override the offered path when you run the
+                    script.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SECTION'><glossterm>SECTION</glossterm>
+            <glossdef>
+                <para>The section in which packages should be categorized.
+                    Package management utilities can make use of this variable.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SELECTED_OPTIMIZATION'><glossterm>SELECTED_OPTIMIZATION</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the optimization flags passed to the C compiler
+                    when building for the target.
+                    The flags are passed through the default value of the
+                    <link linkend='var-TARGET_CFLAGS'><filename>TARGET_CFLAGS</filename></link>
+                    variable.
+                </para>
+
+                <para>
+                    The <filename>SELECTED_OPTIMIZATION</filename> variable
+                    takes the value of
+                    <filename><link linkend='var-FULL_OPTIMIZATION'>FULL_OPTIMIZATION</link></filename>
+                    unless <filename><link linkend='var-DEBUG_BUILD'>DEBUG_BUILD</link></filename> = "1".
+                    If that is the case, the value of
+                    <filename><link linkend='var-DEBUG_OPTIMIZATION'>DEBUG_OPTIMIZATION</link></filename> is used.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SERIAL_CONSOLE'><glossterm>SERIAL_CONSOLE</glossterm>
+            <glossdef>
+                <para>
+                    Defines a serial console (TTY) to enable using getty.
+                    Provide a value that specifies the baud rate followed by
+                    the TTY device name separated by a space.
+                    You cannot specify more than one TTY device:
+                    <literallayout class='monospaced'>
+     SERIAL_CONSOLE = "115200 ttyS0"
+                    </literallayout>
+                    <note>
+                        The <filename>SERIAL_CONSOLE</filename> variable
+                        is deprecated.
+                        Please use the
+                        <link linkend='var-SERIAL_CONSOLES'><filename>SERIAL_CONSOLES</filename></link>
+                        variable.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SERIAL_CONSOLES'><glossterm>SERIAL_CONSOLES</glossterm>
+            <glossdef>
+                <para>
+                    Defines the serial consoles (TTYs) to enable using getty.
+                    Provide a value that specifies the baud rate followed by
+                    the TTY device name separated by a semicolon.
+                    Use spaces to separate multiple devices:
+                    <literallayout class='monospaced'>
+     SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SERIAL_CONSOLES_CHECK'><glossterm>SERIAL_CONSOLES_CHECK</glossterm>
+            <glossdef>
+                <para>
+                    Similar to
+                    <link linkend='var-SERIAL_CONSOLES'><filename>SERIAL_CONSOLES</filename></link>
+                    except the device is checked for existence before attempting
+                    to enable it.
+                    This variable is currently only supported with SysVinit
+                    (i.e. not with systemd).
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS'><glossterm>SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS</glossterm>
+            <glossdef>
+                <para>
+                    A list of recipe dependencies that should not be used to
+                    determine signatures of tasks from one recipe when they
+                    depend on tasks from another recipe.
+                    For example:
+                    <literallayout class='monospaced'>
+    SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "intone->mplayer2"
+                    </literallayout>
+                    In this example, <filename>intone</filename> depends on
+                    <filename>mplayer2</filename>.
+                </para>
+
+                <para>
+                    Use of this variable is one mechanism to remove dependencies
+                    that affect task signatures and thus force rebuilds when a
+                    recipe changes.
+                    <note><title>Caution</title>
+                        If you add an inappropriate dependency for a recipe
+                        relationship, the software might break during
+                        runtime if the interface of the second recipe was
+                        changed after the first recipe had been built.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SIGGEN_EXCLUDERECIPES_ABISAFE'><glossterm>SIGGEN_EXCLUDERECIPES_ABISAFE</glossterm>
+            <glossdef>
+                <para>
+                    A list of recipes that are completely stable and will
+                    never change.
+                    The ABI for the recipes in the list are presented by
+                    output from the tasks run to build the recipe.
+                    Use of this variable is one way to remove dependencies from
+                    one recipe on another that affect task signatures and
+                    thus force rebuilds when the recipe changes.
+                    <note><title>Caution</title>
+                        If you add an inappropriate variable to this list,
+                        the software might break at runtime if the
+                        interface of the recipe was changed after the other
+                        had been built.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SITEINFO_BITS'><glossterm>SITEINFO_BITS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the number of bits for the target system CPU.
+                    The value should be either "32" or "64".
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SITEINFO_ENDIANNESS'><glossterm>SITEINFO_ENDIANNESS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the endian byte order of the target system.
+                    The value should be either "le" for little-endian or "be" for big-endian.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SOC_FAMILY'><glossterm>SOC_FAMILY</glossterm>
+            <glossdef>
+                <para>
+                    Groups together machines based upon the same family
+                    of SOC (System On Chip).
+                    You typically set this variable in a common
+                    <filename>.inc</filename> file that you include in the
+                    configuration files of all the machines.
+                    <note>
+                        You must include
+                        <filename>conf/machine/include/soc-family.inc</filename>
+                        for this variable to appear in
+                    <link linkend='var-MACHINEOVERRIDES'><filename>MACHINEOVERRIDES</filename></link>.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SOLIBS'><glossterm>SOLIBS</glossterm>
+            <glossdef>
+                <para>
+                    Defines the suffix for shared libraries used on the
+                    target platform.
+                    By default, this suffix is ".so.*" for all Linux-based
+                    systems and is defined in the
+                    <filename>meta/conf/bitbake.conf</filename> configuration
+                    file.
+                </para>
+
+                <para>
+                    You will see this variable referenced in the default values
+                    of <filename>FILES_${PN}</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SOLIBSDEV'><glossterm>SOLIBSDEV</glossterm>
+            <glossdef>
+                <para>
+                    Defines the suffix for the development symbolic link
+                    (symlink) for shared libraries on the target platform.
+                    By default, this suffix is ".so" for Linux-based
+                    systems and is defined in the
+                    <filename>meta/conf/bitbake.conf</filename> configuration
+                    file.
+                </para>
+
+                <para>
+                    You will see this variable referenced in the default values
+                    of <filename>FILES_${PN}-dev</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SOURCE_MIRROR_URL'><glossterm>SOURCE_MIRROR_URL</glossterm>
+            <glossdef>
+                <para>
+                    Defines your own
+                    <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>
+                    from which to first fetch source before attempting to fetch
+                    from the upstream specified in
+                    <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>.
+                </para>
+
+                <para>
+                    To use this variable, you must globally inherit the
+                    <link linkend='ref-classes-own-mirrors'><filename>own-mirrors</filename></link>
+                    class and then provide the URL to your mirrors.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     INHERIT += "own-mirrors"
+     SOURCE_MIRROR_URL = "http://example.com/my-source-mirror"
+                    </literallayout>
+                    <note>
+                        You can specify only a single URL in
+                        <filename>SOURCE_MIRROR_URL</filename>.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SPDXLICENSEMAP'><glossterm>SPDXLICENSEMAP</glossterm>
+            <glossdef>
+                <para>
+                    Maps commonly used license names to their SPDX counterparts
+                    found in <filename>meta/files/common-licenses/</filename>.
+                    For the default <filename>SPDXLICENSEMAP</filename>
+                    mappings, see the
+                    <filename>meta/conf/licenses.conf</filename> file.
+                </para>
+
+                <para>
+                    For additional information, see the
+                    <link linkend='var-LICENSE'><filename>LICENSE</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SPECIAL_PKGSUFFIX'><glossterm>SPECIAL_PKGSUFFIX</glossterm>
+            <glossdef>
+                <para>
+                    A list of prefixes for <link linkend='var-PN'><filename>PN</filename></link> used by the
+                    OpenEmbedded build system to create variants of recipes or packages.
+                    The list specifies the prefixes to strip off during certain circumstances
+                    such as the generation of the <link linkend='var-BPN'><filename>BPN</filename></link> variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SRC_URI'><glossterm>SRC_URI</glossterm>
+            <glossdef>
+                <para>The list of source files - local or remote.
+                    This variable tells the OpenEmbedded build system which bits
+                    to pull in for the build and how to pull them in.
+                    For example, if the recipe or append file only needs to
+                    fetch a tarball from the Internet, the recipe or
+                    append file uses a single <filename>SRC_URI</filename>
+                    entry.
+                    On the other hand, if the recipe or append file needs to
+                    fetch a tarball, apply two patches, and include a custom
+                    file, the recipe or append file would include four
+                    instances of the variable.</para>
+                <para>The following list explains the available URI protocols:
+                    <itemizedlist>
+                        <listitem><para><emphasis><filename>file://</filename> -</emphasis>
+                            Fetches files, which are usually files shipped with
+                            the
+                            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>,
+                            from the local machine.
+                            The path is relative to the
+                            <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
+                            variable.
+                            Thus, the build system searches, in order, from the
+                            following directories, which are assumed to be a
+                            subdirectories of the directory in which the
+                            recipe file (<filename>.bb</filename>) or
+                            append file (<filename>.bbappend</filename>)
+                            resides:
+                            <itemizedlist>
+                                <listitem><para><emphasis><filename>${BPN}</filename> -</emphasis>
+                                    The base recipe name without any special
+                                    suffix or version numbers.
+                                    </para></listitem>
+                                <listitem><para><emphasis><filename>${BP}</filename> -</emphasis>
+                                    <filename>${<link linkend='var-BPN'>BPN</link>}-${PV}</filename>.
+                                    The base recipe name and version but without
+                                    any special package name suffix.
+                                    </para></listitem>
+                                <listitem><para><emphasis>files -</emphasis>
+                                    Files within a directory, which is named
+                                    <filename>files</filename> and is also
+                                    alongside the recipe or append file.
+                                    </para></listitem>
+                            </itemizedlist>
+                            <note>
+                                If you want the build system to pick up files
+                                specified through a
+                                <filename>SRC_URI</filename>
+                                statement from your append file, you need to be
+                                sure to extend the
+                                <filename>FILESPATH</filename>
+                                variable by also using the
+                                <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link>
+                                variable from within your append file.
+                            </note>
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>bzr://</filename> -</emphasis> Fetches files from a
+                            Bazaar revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>git://</filename> -</emphasis> Fetches files from a
+                            Git revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>osc://</filename> -</emphasis> Fetches files from
+                            an OSC (OpenSUSE Build service) revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>repo://</filename> -</emphasis> Fetches files from
+                            a repo (Git) repository.</para></listitem>
+                        <listitem><para><emphasis><filename>ccrc://</filename> -</emphasis>
+                            Fetches files from a ClearCase repository.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>http://</filename> -</emphasis> Fetches files from
+                            the Internet using <filename>http</filename>.</para></listitem>
+                        <listitem><para><emphasis><filename>https://</filename> -</emphasis> Fetches files
+                            from the Internet using <filename>https</filename>.</para></listitem>
+                        <listitem><para><emphasis><filename>ftp://</filename> -</emphasis> Fetches files
+                            from the Internet using <filename>ftp</filename>.</para></listitem>
+                        <listitem><para><emphasis><filename>cvs://</filename> -</emphasis> Fetches files from
+                            a CVS revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>hg://</filename> -</emphasis> Fetches files from
+                            a Mercurial (<filename>hg</filename>) revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>p4://</filename> -</emphasis> Fetches files from
+                            a Perforce (<filename>p4</filename>) revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>ssh://</filename> -</emphasis> Fetches files from
+                            a secure shell.</para></listitem>
+                        <listitem><para><emphasis><filename>svn://</filename> -</emphasis> Fetches files from
+                            a Subversion (<filename>svn</filename>) revision control repository.</para></listitem>
+                    </itemizedlist>
+                </para>
+                <para>Standard and recipe-specific options for <filename>SRC_URI</filename> exist.
+                    Here are standard options:
+                    <itemizedlist>
+                        <listitem><para><emphasis><filename>apply</filename> -</emphasis> Whether to apply
+                            the patch or not.
+                            The default action is to apply the patch.</para></listitem>
+                        <listitem><para><emphasis><filename>striplevel</filename> -</emphasis> Which
+                            striplevel to use when applying the patch.
+                            The default level is 1.</para></listitem>
+                        <listitem><para><emphasis><filename>patchdir</filename> -</emphasis> Specifies
+                            the directory in which the patch should be applied.
+                            The default is <filename>${</filename><link linkend='var-S'><filename>S</filename></link><filename>}</filename>.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+                <para>Here are options specific to recipes building code from a revision control system:
+                    <itemizedlist>
+                        <listitem><para><emphasis><filename>mindate</filename> -</emphasis>
+                            Apply the patch only if
+                            <link linkend='var-SRCDATE'><filename>SRCDATE</filename></link>
+                            is equal to or greater than <filename>mindate</filename>.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>maxdate</filename> -</emphasis>
+                            Apply the patch only if <filename>SRCDATE</filename>
+                            is not later than <filename>mindate</filename>.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>minrev</filename> -</emphasis>
+                            Apply the patch only if <filename>SRCREV</filename>
+                            is equal to or greater than <filename>minrev</filename>.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>maxrev</filename> -</emphasis>
+                            Apply the patch only if <filename>SRCREV</filename>
+                            is not later than <filename>maxrev</filename>.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>rev</filename> -</emphasis>
+                            Apply the patch only if <filename>SRCREV</filename>
+                            is equal to <filename>rev</filename>.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>notrev</filename> -</emphasis>
+                            Apply the patch only if <filename>SRCREV</filename>
+                            is not equal to <filename>rev</filename>.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+                <para>Here are some additional options worth mentioning:
+                    <itemizedlist>
+                        <listitem><para><emphasis><filename>unpack</filename> -</emphasis> Controls
+                            whether or not to unpack the file if it is an archive.
+                            The default action is to unpack the file.</para></listitem>
+                        <listitem><para><emphasis><filename>subdir</filename> -</emphasis> Places the file
+                            (or extracts its contents) into the specified
+                            subdirectory of <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
+                            This option is useful for unusual tarballs or other archives that
+                            do not have their files already in a subdirectory within the archive.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>name</filename> -</emphasis> Specifies a
+                            name to be used for association with <filename>SRC_URI</filename> checksums
+                            when you have more than one file specified in <filename>SRC_URI</filename>.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>downloadfilename</filename> -</emphasis> Specifies
+                            the filename used when storing the downloaded file.</para></listitem>
+                    </itemizedlist>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'><glossterm>SRC_URI_OVERRIDES_PACKAGE_ARCH</glossterm>
+            <glossdef>
+                <para>
+                    By default, the OpenEmbedded build system automatically detects whether
+                    <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename>
+                    contains files that are machine-specific.
+                    If so, the build system automatically changes
+                    <filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename>.
+                    Setting this variable to "0" disables this behavior.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SRCDATE'><glossterm>SRCDATE</glossterm>
+            <glossdef>
+                <para>
+                    The date of the source code used to build the package.
+                    This variable applies only if the source was fetched from a Source Code Manager (SCM).
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SRCPV'><glossterm>SRCPV</glossterm>
+            <glossdef>
+                <para>
+                    Returns the version string of the current package.
+                    This string is used to help define the value of
+                    <link linkend='var-PV'><filename>PV</filename></link>.
+                </para>
+
+                <para>
+                    The <filename>SRCPV</filename> variable is defined in the
+                    <filename>meta/conf/bitbake.conf</filename> configuration
+                    file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    as follows:
+                    <literallayout class='monospaced'>
+     SRCPV = "${@bb.fetch2.get_srcrev(d)}"
+                    </literallayout>
+                </para>
+
+                <para>
+                    Recipes that need to define <filename>PV</filename> do so
+                    with the help of the <filename>SRCPV</filename>.
+                    For example, the <filename>ofono</filename> recipe
+                    (<filename>ofono_git.bb</filename>) located in
+                    <filename>meta/recipes-connectivity</filename> in the
+                    Source Directory defines <filename>PV</filename> as
+                    follows:
+                    <literallayout class='monospaced'>
+     PV = "0.12-git${SRCPV}"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SRCREV'><glossterm>SRCREV</glossterm>
+            <glossdef>
+                <para>
+                    The revision of the source code used to build the package.
+                    This variable applies to Subversion, Git, Mercurial and Bazaar
+                    only.
+                    Note that if you wish to build a fixed revision and you wish
+                    to avoid performing a query on the remote repository every time
+                    BitBake parses your recipe, you should specify a <filename>SRCREV</filename> that is a
+                    full revision identifier and not just a tag.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SSTATE_DIR'><glossterm>SSTATE_DIR</glossterm>
+            <glossdef>
+                <para>The directory for the shared state cache.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SSTATE_MIRROR_ALLOW_NETWORK'><glossterm>SSTATE_MIRROR_ALLOW_NETWORK</glossterm>
+            <glossdef>
+                <para>
+                    If set to "1", allows fetches from
+                    mirrors that are specified in
+                    <link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>
+                    to work even when fetching from the network has been
+                    disabled by setting <filename>BB_NO_NETWORK</filename>
+                    to "1".
+                    Using the
+                    <filename>SSTATE_MIRROR_ALLOW_NETWORK</filename>
+                    variable is useful if you have set
+                    <filename>SSTATE_MIRRORS</filename> to point to an
+                    internal server for your shared state cache, but
+                    you want to disable any other fetching from the network.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SSTATE_MIRRORS'><glossterm>SSTATE_MIRRORS</glossterm>
+            <glossdef>
+                <para>
+                    Configures the OpenEmbedded build system to search other
+                    mirror locations for prebuilt cache data objects before
+                    building out the data.
+                    This variable works like fetcher
+                    <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
+                    and <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>
+                    and points to the cache locations to check for the shared
+                    objects.
+                </para>
+
+                <para>
+                    You can specify a filesystem directory or a remote URL such
+                    as HTTP or FTP.
+                    The locations you specify need to contain the shared state
+                    cache (sstate-cache) results from previous builds.
+                    The sstate-cache you point to can also be from builds on
+                    other machines.
+                </para>
+
+                <para>
+                    If a mirror uses the same structure as
+                    <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>,
+                    you need to add
+                    "PATH" at the end as shown in the examples below.
+                    The build system substitutes the correct path within the
+                    directory structure.
+                    <literallayout class='monospaced'>
+     SSTATE_MIRRORS ?= "\
+     file://.* http://<replaceable>someserver</replaceable>.tld/share/sstate/PATH \n \
+     file://.* file:///<replaceable>some-local-dir</replaceable>/sstate/PATH"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAGING_BASE_LIBDIR_NATIVE'><glossterm>STAGING_BASE_LIBDIR_NATIVE</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the path to the <filename>/lib</filename>
+                    subdirectory of the sysroot directory for the
+                    build host.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAGING_BASELIBDIR'><glossterm>STAGING_BASELIBDIR</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the path to the <filename>/lib</filename>
+                    subdirectory of the sysroot directory for the target
+                    for which the current recipe is being built
+                    (<link linkend='var-STAGING_DIR_HOST'><filename>STAGING_DIR_HOST</filename></link>).
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAGING_BINDIR'><glossterm>STAGING_BINDIR</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the path to the
+                    <filename>/usr/bin</filename> subdirectory of the
+                    sysroot directory for the target for which the current
+                    recipe is being built
+                    (<link linkend='var-STAGING_DIR_HOST'><filename>STAGING_DIR_HOST</filename></link>).
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAGING_BINDIR_CROSS'><glossterm>STAGING_BINDIR_CROSS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the path to the directory containing binary
+                    configuration scripts.
+                    These scripts provide configuration information for
+                    other software that wants to make use of libraries or
+                    include files provided by the software associated with
+                    the script.
+                    <note>
+                        This style of build configuration has been largely
+                        replaced by <filename>pkg-config</filename>.
+                        Consequently, if <filename>pkg-config</filename>
+                        is supported by the library to which you are linking,
+                        it is recommended you use
+                        <filename>pkg-config</filename> instead of a
+                        provided configuration script.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAGING_BINDIR_NATIVE'><glossterm>STAGING_BINDIR_NATIVE</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the path to the
+                    <filename>/usr/bin</filename> subdirectory of the
+                    sysroot directory for the build host.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAGING_DATADIR'><glossterm>STAGING_DATADIR</glossterm>
+            <glossdef>
+                <para>
+                     Specifies the path to the <filename>/usr/share</filename>
+                     subdirectory of the sysroot directory for the target
+                     for which the current recipe is being built
+                     (<link linkend='var-STAGING_DIR_HOST'><filename>STAGING_DIR_HOST</filename></link>).
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAGING_DIR'><glossterm>STAGING_DIR</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the path to the top-level sysroots directory
+                    (i.e.
+                    <filename>${</filename><link linkend='var-TMPDIR'><filename>TMPDIR</filename></link><filename>}/sysroots</filename>).
+                    <note>
+                        Recipes should never write files directly under
+                        this directory because the OpenEmbedded build system
+                        manages the directory automatically.
+                        Instead, files should be installed to
+                        <filename>${</filename><link linkend='var-D'><filename>D</filename></link><filename>}</filename>
+                        within your recipe's
+                        <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+                        task and then the OpenEmbedded build system will
+                        stage a subset of those files into the sysroot.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAGING_DIR_HOST'><glossterm>STAGING_DIR_HOST</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the path to the primary sysroot directory for
+                    which the target is being built.
+                    Depending on the type of recipe and the build target, the
+                    recipe's value is as follows:
+                    <itemizedlist>
+                        <listitem><para>For recipes building for the target
+                           machine, the value is "${STAGING_DIR}/${MACHINE}".
+                           </para></listitem>
+                        <listitem><para>For <filename>native</filename>
+                           recipes building
+                           for the build host, the value is empty given the
+                           assumption that when building for the build host,
+                           the build host's own directories should be used.
+                           </para></listitem>
+                        <listitem><para>For <filename>nativesdk</filename>
+                           recipes that Build for the SDK, the value is
+                           "${STAGING_DIR}/${MULTIMACH_HOST_SYS}".
+                           </para></listitem>
+                    </itemizedlist>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAGING_DATADIR_NATIVE'><glossterm>STAGING_DATADIR_NATIVE</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the path to the <filename>/usr/share</filename>
+                    subdirectory of the sysroot directory for the build host.
+                </para>
+            </glossdef>
+        </glossentry>
+
+
+
+        <glossentry id='var-STAGING_DIR_NATIVE'><glossterm>STAGING_DIR_NATIVE</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the path to the sysroot directory for the
+                    build host.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAGING_DIR_TARGET'><glossterm>STAGING_DIR_TARGET</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the path to the sysroot directory for the
+                    target for which the current recipe is being built.
+                    In most cases, this path is the
+                    <link linkend='var-STAGING_DIR_HOST'><filename>STAGING_DIR_HOST</filename></link>.
+                </para>
+
+                <para>
+                    Some recipes build binaries that can run on the target
+                    system but those binaries in turn generate code for
+                    another different system (e.g. cross-canadian recipes).
+                    Using terminology from GNU, the primary system is referred
+                    to as the "HOST" and the secondary, or different, system is
+                    referred to as the "TARGET".
+                    Thus, the binaries run on the "HOST" system and
+                    and generate binaries for the "TARGET" system.
+                    <filename>STAGING_DIR_TARGET</filename> points to the
+                    sysroot used for the "TARGET" system.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAGING_ETCDIR_NATIVE'><glossterm>STAGING_ETCDIR_NATIVE</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the path to the <filename>/etc</filename>
+                    subdirectory of the sysroot directory for the
+                    build host.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAGING_EXECPREFIXDIR'><glossterm>STAGING_EXECPREFIXDIR</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the path to the <filename>/usr</filename>
+                    subdirectory of the sysroot directory for the target
+                    for which the current recipe is being built
+                    (<link linkend='var-STAGING_DIR_HOST'><filename>STAGING_DIR_HOST</filename></link>).
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAGING_INCDIR'><glossterm>STAGING_INCDIR</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the path to the
+                    <filename>/usr/include</filename> subdirectory of the
+                    sysroot directory for the target for which the current
+                    recipe being built
+                    (<link linkend='var-STAGING_DIR_HOST'><filename>STAGING_DIR_HOST</filename></link>).
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAGING_INCDIR_NATIVE'><glossterm>STAGING_INCDIR_NATIVE</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the path to the <filename>/usr/include</filename>
+                    subdirectory of the sysroot directory for the build host.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAGING_LIBDIR'><glossterm>STAGING_LIBDIR</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the path to the <filename>/usr/lib</filename>
+                    subdirectory of the sysroot directory for the target for
+                    which the current recipe is being built
+                    (<link linkend='var-STAGING_DIR_HOST'><filename>STAGING_DIR_HOST</filename></link>).
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAGING_LIBDIR_NATIVE'><glossterm>STAGING_LIBDIR_NATIVE</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the path to the <filename>/usr/lib</filename>
+                    subdirectory of the sysroot directory for the build host.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAGING_KERNEL_DIR'><glossterm>STAGING_KERNEL_DIR</glossterm>
+            <glossdef>
+                <para>
+                    The directory with kernel headers that are required to build out-of-tree
+                    modules.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAMP'><glossterm>STAMP</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the base path used to create recipe stamp files.
+                    The path to an actual stamp file is constructed by evaluating this
+                    string and then appending additional information.
+                    Currently, the default assignment for <filename>STAMP</filename>
+                    as set in the <filename>meta/conf/bitbake.conf</filename> file
+                    is:
+                    <literallayout class='monospaced'>
+     STAMP = "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
+                    </literallayout>
+                    See <link linkend='var-STAMPS_DIR'><filename>STAMPS_DIR</filename></link>,
+                    <link linkend='var-MULTIMACH_TARGET_SYS'><filename>MULTIMACH_TARGET_SYS</filename></link>,
+                    <link linkend='var-PN'><filename>PN</filename></link>,
+                    <link linkend='var-EXTENDPE'><filename>EXTENDPE</filename></link>,
+                    <link linkend='var-PV'><filename>PV</filename></link>, and
+                    <link linkend='var-PR'><filename>PR</filename></link> for related variable
+                    information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAMPS_DIR'><glossterm>STAMPS_DIR</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the base directory in which the OpenEmbedded
+                    build system places stamps.
+                    The default directory is
+                    <filename>${TMPDIR}/stamps</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SUMMARY'><glossterm>SUMMARY</glossterm>
+            <glossdef>
+                <para>The short (72 characters or less) summary of the binary package for packaging
+                    systems such as <filename>opkg</filename>, <filename>rpm</filename> or
+                    <filename>dpkg</filename>.
+                    By default, <filename>SUMMARY</filename> is used to define
+                    the <link linkend='var-DESCRIPTION'><filename>DESCRIPTION</filename></link>
+                    variable if <filename>DESCRIPTION</filename> is not set
+                    in the recipe.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SYSLINUX_DEFAULT_CONSOLE'><glossterm>SYSLINUX_DEFAULT_CONSOLE</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the kernel boot default console.
+                    If you want to use a console other than the default,
+                    set this variable in your recipe as follows where "X" is
+                    the console number you want to use:
+                    <literallayout class='monospaced'>
+     SYSLINUX_DEFAULT_CONSOLE = "console=ttyX"
+                    </literallayout>
+                </para>
+
+                <para>
+                    The
+                    <link linkend='ref-classes-syslinux'><filename>syslinux</filename></link>
+                    class initially sets this variable to null but then checks
+                    for a value later.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SYSLINUX_OPTS'><glossterm>SYSLINUX_OPTS</glossterm>
+            <glossdef>
+                <para>
+                    Lists additional options to add to the syslinux file.
+                    You need to set this variable in your recipe.
+                    If you want to list multiple options, separate the options
+                    with a semicolon character (<filename>;</filename>).
+                </para>
+
+                <para>
+                    The
+                    <link linkend='ref-classes-syslinux'><filename>syslinux</filename></link>
+                    class uses this variable to create a set of options.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SYSLINUX_SERIAL'><glossterm>SYSLINUX_SERIAL</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the alternate serial port or turns it off.
+                    To turn off serial, set this variable to an empty string
+                    in your recipe.
+                    The variable's default value is set in the
+                    <link linkend='ref-classes-syslinux'><filename>syslinux</filename></link>
+                    as follows:
+                    <literallayout class='monospaced'>
+     SYSLINUX_SERIAL ?= "0 115200"
+                    </literallayout>
+                    The class checks for and uses the variable as needed.                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SYSLINUX_SPLASH'><glossterm>SYSLINUX_SPLASH</glossterm>
+            <glossdef>
+                <para>
+                    An <filename>.LSS</filename> file used as the background
+                    for the VGA boot menu when you are using the boot menu.
+                    You need to set this variable in your recipe.
+                </para>
+
+                <para>
+                    The
+                    <link linkend='ref-classes-syslinux'><filename>syslinux</filename></link>
+                    class checks for this variable and if found, the
+                    OpenEmbedded build system installs the splash screen.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SYSLINUX_SERIAL_TTY'><glossterm>SYSLINUX_SERIAL_TTY</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the alternate console=tty... kernel boot argument.
+                    The variable's default value is set in the
+                    <link linkend='ref-classes-syslinux'><filename>syslinux</filename></link>
+                    as follows:
+                    <literallayout class='monospaced'>
+     SYSLINUX_SERIAL_TTY ?= "console=ttyS0,115200"
+                    </literallayout>
+                    The class checks for and uses the variable as needed.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SYSROOT_PREPROCESS_FUNCS'><glossterm>SYSROOT_PREPROCESS_FUNCS</glossterm>
+            <glossdef>
+                <para>
+                    A list of functions to execute after files are staged into
+                    the sysroot.
+                    These functions are usually used to apply additional
+                    processing on the staged files, or to stage additional
+                    files.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SYSTEMD_AUTO_ENABLE'><glossterm>SYSTEMD_AUTO_ENABLE</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-systemd'><filename>systemd</filename></link>
+                    class, this variable specifies whether the service you have
+                    specified in
+                    <link linkend='var-SYSTEMD_SERVICE'><filename>SYSTEMD_SERVICE</filename></link>
+                    should be started automatically or not.
+                    By default, the service is enabled to automatically start
+                    at boot time.
+                    The default setting is in the
+                    <link linkend='ref-classes-systemd'><filename>systemd</filename></link>
+                    class as follows:
+                    <literallayout class='monospaced'>
+     SYSTEMD_AUTO_ENABLE ??= "enable"
+                    </literallayout>
+                    You can disable the service by setting the variable to
+                    "disable".
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SYSTEMD_PACKAGES'><glossterm>SYSTEMD_PACKAGES</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-systemd'><filename>systemd</filename></link>
+                    class, this variable locates the systemd unit files when
+                    they are not found in the main recipe's package.
+                    By default, the
+                    <filename>SYSTEMD_PACKAGES</filename> variable is set
+                    such that the systemd unit files are assumed to reside in
+                    the recipes main package:
+                    <literallayout class='monospaced'>
+     SYSTEMD_PACKAGES ?= "${PN}"
+                    </literallayout>
+                    If these unit files are not in this recipe's main
+                    package, you need to use
+                    <filename>SYSTEMD_PACKAGES</filename> to list the package
+                    or packages in which the build system can find the systemd
+                    unit files.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SYSTEMD_SERVICE'><glossterm>SYSTEMD_SERVICE</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-systemd'><filename>systemd</filename></link>
+                    class, this variable specifies the systemd service name for
+                    a package.
+                </para>
+
+                <para>
+                    When you specify this file in your recipe, use a package
+                    name override to indicate the package to which the value
+                    applies.
+                    Here is an example from the connman recipe:
+                    <literallayout class='monospaced'>
+     SYSTEMD_SERVICE_${PN} = "connman.service"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SYSVINIT_ENABLED_GETTYS'><glossterm>SYSVINIT_ENABLED_GETTYS</glossterm>
+            <glossdef>
+                <para>
+                    When using
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-enabling-system-services'>SysVinit</ulink>,
+                    specifies a space-separated list of the virtual terminals
+                    that should be running a
+                    <ulink url='http://en.wikipedia.org/wiki/Getty_%28Unix%29'>getty</ulink>
+                    (allowing login), assuming
+                    <link linkend='var-USE_VT'><filename>USE_VT</filename></link>
+                    is not set to "0".
+                </para>
+
+                <para>
+                    The default value for
+                    <filename>SYSVINIT_ENABLED_GETTYS</filename> is "1"
+                    (i.e. only run a getty on the first virtual terminal).
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-t'><title>T</title>
+
+        <glossentry id='var-T'><glossterm>T</glossterm>
+            <glossdef>
+                <para>This variable points to a directory were BitBake places
+                    temporary files, which consist mostly of task logs and
+                    scripts, when building a particular recipe.
+                    The variable is typically set as follows:
+                    <literallayout class='monospaced'>
+     T = "${WORKDIR}/temp"
+                    </literallayout>
+                    The <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
+                    is the directory into which BitBake unpacks and builds the
+                    recipe.
+                    The default <filename>bitbake.conf</filename> file sets this variable.</para>
+                    <para>The <filename>T</filename> variable is not to be confused with
+                    the <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link> variable,
+                    which points to the root of the directory tree where BitBake
+                    places the output of an entire build.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TARGET_ARCH'><glossterm>TARGET_ARCH</glossterm>
+            <glossdef>
+                <para>
+                    The target machine's architecture.
+                    The OpenEmbedded build system supports many
+                    architectures.
+                    Here is an example list of architectures supported.
+                    This list is by no means complete as the architecture
+                    is configurable:
+                    <literallayout class='monospaced'>
+     arm
+     i586
+     x86_64
+     powerpc
+     powerpc64
+     mips
+     mipsel
+                    </literallayout>
+                    For additional information on machine architectures, see
+                    the
+                    <link linkend='var-TUNE_ARCH'><filename>TUNE_ARCH</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TARGET_AS_ARCH'><glossterm>TARGET_AS_ARCH</glossterm>
+            <glossdef>
+                <para>
+                    Specifies architecture-specific assembler flags for the
+                    target system.
+                    <filename>TARGET_AS_ARCH</filename> is initialized from
+                    <link linkend='var-TUNE_ASARGS'><filename>TUNE_ASARGS</filename></link>
+                    by default in the BitBake configuration file
+                    (<filename>meta/conf/bitbake.conf</filename>):
+                    <literallayout class='monospaced'>
+     TARGET_AS_ARCH = "${TUNE_ASARGS}"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TARGET_CC_ARCH'><glossterm>TARGET_CC_ARCH</glossterm>
+            <glossdef>
+                <para>
+                    Specifies architecture-specific C compiler flags for the
+                    target system.
+                    <filename>TARGET_CC_ARCH</filename> is initialized from
+                    <link linkend='var-TUNE_CCARGS'><filename>TUNE_CCARGS</filename></link>
+                    by default.
+                    <note>
+                        It is a common workaround to append
+                        <link linkend='var-LDFLAGS'><filename>LDFLAGS</filename></link>
+                        to <filename>TARGET_CC_ARCH</filename>
+                        in recipes that build software for the target that
+                        would not otherwise respect the exported
+                        <filename>LDFLAGS</filename> variable.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TARGET_CC_KERNEL_ARCH'><glossterm>TARGET_CC_KERNEL_ARCH</glossterm>
+            <glossdef>
+                <para>
+                    This is a specific kernel compiler flag for a CPU or
+                    Application Binary Interface (ABI) tune.
+                    The flag is used rarely and only for cases where a
+                    userspace
+                    <link linkend='var-TUNE_CCARGS'><filename>TUNE_CCARGS</filename></link>
+                    is not compatible with the kernel compilation.
+                    The <filename>TARGET_CC_KERNEL_ARCH</filename> variable
+                    allows the kernel (and associated modules) to use a
+                    different configuration.
+                    See the
+                    <filename>meta/conf/machine/include/arm/feature-arm-thumb.inc</filename>
+                    file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    for an example.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TARGET_CFLAGS'><glossterm>TARGET_CFLAGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the flags to pass to the C compiler when building
+                    for the target.
+                    When building in the target context,
+                    <link linkend='var-CFLAGS'><filename>CFLAGS</filename></link>
+                    is set to the value of this variable by default.
+                </para>
+
+                <para>
+                    Additionally, the SDK's environment setup script sets
+                    the
+                    <link linkend='var-CFLAGS'><filename>CFLAGS</filename></link>
+                    variable in the environment to the
+                    <filename>TARGET_CFLAGS</filename> value so that
+                    executables built using the SDK also have the flags
+                    applied.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TARGET_CPPFLAGS'><glossterm>TARGET_CPPFLAGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the flags to pass to the C pre-processor
+                    (i.e. to both the C and the C++ compilers) when building
+                    for the target.
+                    When building in the target context,
+                    <link linkend='var-CPPFLAGS'><filename>CPPFLAGS</filename></link>
+                    is set to the value of this variable by default.
+                </para>
+
+                <para>
+                    Additionally, the SDK's environment setup script sets
+                    the
+                    <link linkend='var-CPPFLAGS'><filename>CPPFLAGS</filename></link>
+                    variable in the environment to the
+                    <filename>TARGET_CPPFLAGS</filename> value so that
+                    executables built using the SDK also have the flags
+                    applied.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TARGET_CXXFLAGS'><glossterm>TARGET_CXXFLAGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the flags to pass to the C++ compiler when
+                    building for the target.
+                    When building in the target context,
+                    <link linkend='var-CXXFLAGS'><filename>CXXFLAGS</filename></link>
+                    is set to the value of this variable by default.
+                </para>
+
+                <para>
+                    Additionally, the SDK's environment setup script sets
+                    the
+                    <link linkend='var-CXXFLAGS'><filename>CXXFLAGS</filename></link>
+                    variable in the environment to the
+                    <filename>TARGET_CXXFLAGS</filename> value so that
+                    executables built using the SDK also have the flags
+                    applied.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TARGET_FPU'><glossterm>TARGET_FPU</glossterm>
+            <glossdef>
+                <para>Specifies the method for handling FPU code.
+                    For FPU-less targets, which include most ARM CPUs, the variable must be
+                    set to "soft".
+                    If not, the kernel emulation gets used, which results in a performance penalty.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TARGET_LD_ARCH'><glossterm>TARGET_LD_ARCH</glossterm>
+            <glossdef>
+                <para>
+                    Specifies architecture-specific linker flags for the
+                    target system.
+                    <filename>TARGET_LD_ARCH</filename> is initialized from
+                    <link linkend='var-TUNE_LDARGS'><filename>TUNE_LDARGS</filename></link>
+                    by default in the BitBake configuration file
+                    (<filename>meta/conf/bitbake.conf</filename>):
+                    <literallayout class='monospaced'>
+     TARGET_LD_ARCH = "${TUNE_LDARGS}"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TARGET_LDFLAGS'><glossterm>TARGET_LDFLAGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the flags to pass to the linker when building
+                    for the target.
+                    When building in the target context,
+                    <link linkend='var-LDFLAGS'><filename>LDFLAGS</filename></link>
+                    is set to the value of this variable by default.
+                </para>
+
+                <para>
+                    Additionally, the SDK's environment setup script sets
+                    the
+                    <link linkend='var-LDFLAGS'><filename>LDFLAGS</filename></link>
+                    variable in the environment to the
+                    <filename>TARGET_LDFLAGS</filename> value so that
+                    executables built using the SDK also have the flags
+                    applied.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TARGET_OS'><glossterm>TARGET_OS</glossterm>
+            <glossdef>
+                <para>Specifies the target's operating system.
+                    The variable can be set to "linux" for <filename>glibc</filename>-based systems and
+                    to "linux-uclibc" for <filename>uclibc</filename>.
+                    For ARM/EABI targets, there are also "linux-gnueabi" and
+                    "linux-uclibc-gnueabi" values possible.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TCLIBC'><glossterm>TCLIBC</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the GNU standard C library (<filename>libc</filename>)
+                    variant to use during the build process.
+                    This variable replaces <filename>POKYLIBC</filename>, which is no longer
+                    supported.
+                </para>
+                <para>
+                    You can select "glibc" or "uclibc".
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TCMODE'><glossterm>TCMODE</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the toolchain selector.
+                    <filename>TCMODE</filename> controls the characteristics
+                    of the generated packages and images by telling the
+                    OpenEmbedded build system which toolchain profile to use.
+                    By default, the OpenEmbedded build system builds its own
+                    internal toolchain.
+                    The variable's default value is "default", which uses
+                    that internal toolchain.
+                    <note>
+                        If <filename>TCMODE</filename> is set to a value
+                        other than "default", then it is your responsibility
+                        to ensure that the toolchain is compatible with the
+                        default toolchain.
+                        Using older or newer versions of these components
+                        might cause build problems.
+                        See the
+                        <ulink url='&YOCTO_RELEASE_NOTES;'>Release Notes</ulink>
+                        for the specific components with which the toolchain
+                        must be compatible.
+                    </note>
+                </para>
+
+                <para>
+                    With additional layers, it is possible to use a pre-compiled
+                    external toolchain.
+                    One example is the Sourcery G++ Toolchain.
+                    The support for this toolchain resides in the separate
+                    <filename>meta-sourcery</filename> layer at
+                    <ulink url='http://github.com/MentorEmbedded/meta-sourcery/'></ulink>.
+                    You can use <filename>meta-sourcery</filename> as a
+                    template for adding support for other external toolchains.
+                </para>
+
+                <para>
+                    The <filename>TCMODE</filename> variable points the build
+                    system to a file in
+                    <filename>conf/distro/include/tcmode-${TCMODE}.inc</filename>.
+                    Thus, for <filename>meta-sourcery</filename>,
+                    which has <filename>conf/distro/include/tcmode-external-sourcery.inc</filename>,
+                    you would set the variable as follows:
+                    <literallayout class='monospaced'>
+     TCMODE ?= "external-sourcery"
+                    </literallayout>
+                </para>
+
+                <para>
+                    The variable is similar to
+                    <link linkend='var-TCLIBC'><filename>TCLIBC</filename></link>,
+                    which controls the variant of the GNU standard C library
+                    (<filename>libc</filename>) used during the build process:
+                    <filename>glibc</filename> or <filename>uclibc</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TEST_EXPORT_DIR'><glossterm>TEST_EXPORT_DIR</glossterm>
+            <glossdef>
+                <para>
+                    The location the OpenEmbedded build system uses to export
+                    tests when the
+                    <link linkend='var-TEST_EXPORT_ONLY'><filename>TEST_EXPORT_ONLY</filename></link>
+                    variable is set to "1".
+                </para>
+
+                <para>
+                    The <filename>TEST_EXPORT_DIR</filename> variable defaults
+                    to <filename>"${TMPDIR}/testimage/${PN}"</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TEST_EXPORT_ONLY'><glossterm>TEST_EXPORT_ONLY</glossterm>
+            <glossdef>
+                <para>
+                    Specifies to export the tests only.
+                    Set this variable to "1" if you do not want to run the
+                    tests but you want them to be exported in a manner that
+                    you to run them outside of the build system.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TEST_IMAGE'><glossterm>TEST_IMAGE</glossterm>
+            <glossdef>
+                <para>
+                    Automatically runs the series of automated tests for
+                    images when an image is successfully built.
+                </para>
+
+                <para>
+                    These tests are written in Python making use of the
+                    <filename>unittest</filename> module, and the majority of
+                    them run commands on the target system over
+                    <filename>ssh</filename>.
+                    You can set this variable to "1" in your
+                    <filename>local.conf</filename> file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                    to have the OpenEmbedded build system automatically run
+                    these tests after an image successfully builds:
+                    <literallayout class='monospaced'>
+     TEST_IMAGE = "1"
+                    </literallayout>
+                    For more information on enabling, running, and writing
+                    these tests, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
+                    section in the Yocto Project Development Manual and the
+                    "<link linkend='ref-classes-testimage'><filename>testimage.bbclass</filename></link>"
+                    section.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TEST_LOG_DIR'><glossterm>TEST_LOG_DIR</glossterm>
+            <glossdef>
+                <para>
+                    Holds the SSH log and the boot log for QEMU machines.
+                    The <filename>TEST_LOG_DIR</filename> variable defaults
+                    to <filename>"${WORKDIR}/testimage"</filename>.
+                    <note>
+                        Actual test results reside in the task log
+                        (<filename>log.do_testimage</filename>), which is in
+                        the <filename>${WORKDIR}/temp/</filename> directory.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TEST_POWERCONTROL_CMD'><glossterm>TEST_POWERCONTROL_CMD</glossterm>
+            <glossdef>
+                <para>
+                    For automated hardware testing, specifies the command to
+                    use to control the power of the target machine under test.
+                    Typically, this command would point to a script that
+                    performs the appropriate action (e.g. interacting
+                    with a web-enabled power strip).
+                    The specified command should expect to receive as the last
+                    argument "off", "on" or "cycle" specifying to power off,
+                    on, or cycle (power off and then power on) the device,
+                    respectively.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TEST_POWERCONTROL_EXTRA_ARGS'><glossterm>TEST_POWERCONTROL_EXTRA_ARGS</glossterm>
+            <glossdef>
+                <para>
+                    For automated hardware testing, specifies additional
+                    arguments to pass through to the command specified in
+                    <link linkend='var-TEST_POWERCONTROL_CMD'><filename>TEST_POWERCONTROL_CMD</filename></link>.
+                    Setting <filename>TEST_POWERCONTROL_EXTRA_ARGS</filename>
+                    is optional.
+                    You can use it if you wish, for example, to separate the
+                    machine-specific and non-machine-specific parts of the
+                    arguments.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TEST_QEMUBOOT_TIMEOUT'><glossterm>TEST_QEMUBOOT_TIMEOUT</glossterm>
+            <glossdef>
+                <para>
+                    The time in seconds allowed for an image to boot before
+                    automated runtime tests begin to run against an
+                    image.
+                    The default timeout period to allow the boot process to
+                    reach the login prompt is 500 seconds.
+                    You can specify a different value in the
+                    <filename>local.conf</filename> file.
+                </para>
+
+                <para>
+                    For more information on testing images, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TEST_SERIALCONTROL_CMD'><glossterm>TEST_SERIALCONTROL_CMD</glossterm>
+            <glossdef>
+                <para>
+                    For automated hardware testing, specifies the command
+                    to use to connect to the serial console of the target
+                    machine under test.
+                    This command simply needs to connect to the serial console
+                    and forward that connection to standard input and output
+                    as any normal terminal program does.
+                </para>
+
+                <para>
+                    For example, to use the Picocom terminal program on
+                    serial device <filename>/dev/ttyUSB0</filename> at
+                    115200bps, you would set the variable as follows:
+                    <literallayout class='monospaced'>
+     TEST_SERIALCONTROL_CMD = "picocom /dev/ttyUSB0 -b 115200"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TEST_SERIALCONTROL_EXTRA_ARGS'><glossterm>TEST_SERIALCONTROL_EXTRA_ARGS</glossterm>
+            <glossdef>
+                <para>
+                    For automated hardware testing, specifies additional
+                    arguments to pass through to the command specified in
+                    <link linkend='var-TEST_SERIALCONTROL_CMD'><filename>TEST_SERIALCONTROL_CMD</filename></link>.
+                    Setting <filename>TEST_SERIALCONTROL_EXTRA_ARGS</filename>
+                    is optional.
+                    You can use it if you wish, for example, to separate the
+                    machine-specific and non-machine-specific parts of the
+                    command.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TEST_SERVER_IP'><glossterm>TEST_SERVER_IP</glossterm>
+            <glossdef>
+                <para>
+                    The IP address of the build machine (host machine).
+                    This IP address is usually automatically detected.
+                    However, if detection fails, this variable needs to be set
+                    to the IP address of the build machine (i.e. where
+                    the build is taking place).
+                    <note>
+                        The <filename>TEST_SERVER_IP</filename> variable
+                        is only used for a small number of tests such as
+                        the "smart" test suite, which needs to download
+                        packages from <filename>DEPLOY_DIR/rpm</filename>.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TEST_TARGET'><glossterm>TEST_TARGET</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the target controller to use when running tests
+                    against a test image.
+                    The default controller to use is "qemu":
+                    <literallayout class='monospaced'>
+     TEST_TARGET = "qemu"
+                    </literallayout>
+                    A target controller is a class that defines how an
+                    image gets deployed on a target and how a target is started.
+                    A layer can extend the controllers by adding a module
+                    in the layer's <filename>/lib/oeqa/controllers</filename>
+                    directory and by inheriting the
+                    <filename>BaseTarget</filename> class, which is an abstract
+                    class that cannot be used as a value of
+                    <filename>TEST_TARGET</filename>.
+                </para>
+
+                <para>
+                    You can provide the following arguments with
+                    <filename>TEST_TARGET</filename>:
+                    <itemizedlist>
+                        <listitem><para><emphasis>"qemu" and "QemuTarget":</emphasis>
+                            Boots a QEMU image and runs the tests.
+                            See the
+                            "<ulink url='&YOCTO_DOCS_DEV_URL;#qemu-image-enabling-tests'>Enabling Runtime Tests on QEMU</ulink>"
+                            section in the Yocto Project Development Manual for
+                            more information.
+                            </para></listitem>
+                        <listitem><para><emphasis>"simpleremote" and "SimpleRemoteTarget":</emphasis>
+                            Runs the tests on target hardware that is already
+                            up and running.
+                            The hardware can be on the network or it can be
+                            a device running an image on QEMU.
+                            You must also set
+                            <link linkend='var-TEST_TARGET_IP'><filename>TEST_TARGET_IP</filename></link>
+                            when you use "simpleremote" or "SimpleRemoteTarget".
+                            <note>
+                                This argument is defined in
+                                <filename>meta/lib/oeqa/targetcontrol.py</filename>.
+                                The small caps names are kept for compatibility
+                                reasons.
+                            </note>
+                            </para></listitem>
+                        <listitem><para><emphasis>"GummibootTarget":</emphasis>
+                            Automatically deploys and runs tests on an
+                            EFI-enabled machine that has a master image
+                            installed.
+                            <note>
+                                This argument is defined in
+                                <filename>meta/lib/oeqa/controllers/masterimage.py</filename>.
+                            </note>
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    For information on running tests on hardware, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#hardware-image-enabling-tests'>Enabling Runtime Tests on Hardware</ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TEST_TARGET_IP'><glossterm>TEST_TARGET_IP</glossterm>
+            <glossdef>
+                <para>
+                    The IP address of your hardware under test.
+                    The <filename>TEST_TARGET_IP</filename> variable has no
+                    effect when
+                    <link linkend='var-TEST_TARGET'><filename>TEST_TARGET</filename></link>
+                    is set to "qemu".
+                </para>
+
+                <para>
+                    When you specify the IP address, you can also include a
+                    port.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     TEST_TARGET_IP = "192.168.1.4:2201"
+                    </literallayout>
+                    Specifying a port is useful when SSH is started on a
+                    non-standard port or in cases when your hardware under test
+                    is behind a firewall or network that is not directly
+                    accessible from your host and you need to do port address
+                    translation.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TEST_SUITES'><glossterm>TEST_SUITES</glossterm>
+            <glossdef>
+                <para>
+                    An ordered list of tests (modules) to run against
+                    an image when performing automated runtime testing.
+                </para>
+
+                <para>
+                    The OpenEmbedded build system provides a core set of tests
+                    that can be used against images.
+                    <note>
+                        Currently, there is only support for running these tests
+                        under QEMU.
+                    </note>
+                    Tests include <filename>ping</filename>,
+                    <filename>ssh</filename>, <filename>df</filename> among
+                    others.
+                    You can add your own tests to the list of tests by
+                    appending <filename>TEST_SUITES</filename> as follows:
+                    <literallayout class='monospaced'>
+     TEST_SUITES_append = " <replaceable>mytest</replaceable>"
+                    </literallayout>
+                    Alternatively, you can provide the "auto" option to
+                    have all applicable tests run against the image.
+                    <literallayout class='monospaced'>
+     TEST_SUITES_append = " auto"
+                    </literallayout>
+                    Using this option causes the build system to automatically
+                    run tests that are applicable to the image.
+                    Tests that are not applicable are skipped.
+                </para>
+
+                <para>
+                    The order in which tests are run is important.
+                    Tests that depend on another test must appear later in the
+                    list than the test on which they depend.
+                    For example, if you append the list of tests with two
+                    tests (<filename>test_A</filename> and
+                    <filename>test_B</filename>) where
+                    <filename>test_B</filename> is dependent on
+                    <filename>test_A</filename>, then you must order the tests
+                    as follows:
+                    <literallayout class='monospaced'>
+     TEST_SUITES = " test_A test_B"
+                    </literallayout>
+                </para>
+
+                <para>
+                    For more information on testing images, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-THISDIR'><glossterm>THISDIR</glossterm>
+            <glossdef>
+                <para>
+                    The directory in which the file BitBake is currently
+                    parsing is located.
+                    Do not manually set this variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TMPDIR'><glossterm>TMPDIR</glossterm>
+            <glossdef>
+                <para>
+                    This variable is the base directory the OpenEmbedded
+                    build system uses for all build output and intermediate
+                    files (other than the shared state cache).
+                    By default, the <filename>TMPDIR</filename> variable points
+                    to <filename>tmp</filename> within the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                </para>
+
+                <para>
+                    If you want to establish this directory in a location other
+                    than the default, you can uncomment and edit the following
+                    statement in the
+                    <filename>conf/local.conf</filename> file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
+                    <literallayout class='monospaced'>
+     #TMPDIR = "${TOPDIR}/tmp"
+                    </literallayout>
+                    An example use for this scenario is to set
+                    <filename>TMPDIR</filename> to a local disk, which does
+                    not use NFS, while having the Build Directory use NFS.
+                </para>
+
+                <para>
+                    The filesystem used by <filename>TMPDIR</filename> must
+                    have standard filesystem semantics (i.e. mixed-case files
+                    are unique, POSIX file locking, and persistent inodes).
+                    Due to various issues with NFS and bugs in some
+                    implementations, NFS does not meet this minimum
+                    requirement.
+                    Consequently, <filename>TMPDIR</filename> cannot be on
+                    NFS.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TOOLCHAIN_HOST_TASK'><glossterm>TOOLCHAIN_HOST_TASK</glossterm>
+            <glossdef>
+                <para>
+                    This variable lists packages the OpenEmbedded build system
+                    uses when building an SDK, which contains a
+                    cross-development environment.
+                    The packages specified by this variable are part of the
+                    toolchain set that runs on the
+                    <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>,
+                    and each package should usually have the prefix
+                    "nativesdk-".
+                    When building an SDK using
+                    <filename>bitbake -c populate_sdk &lt;imagename&gt;</filename>,
+                    a default list of packages is set in this variable, but
+                    you can add additional packages to the list.
+                </para>
+
+                <para>
+                    For background information on cross-development toolchains
+                    in the Yocto Project development environment, see the
+                    "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
+                    section.
+                    For information on setting up a cross-development
+                    environment, see the
+                    "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
+                    section in the Yocto Project Application Developer's Guide.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TOOLCHAIN_TARGET_TASK'><glossterm>TOOLCHAIN_TARGET_TASK</glossterm>
+            <glossdef>
+                <para>
+                    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>
+                    For background information on cross-development toolchains
+                    in the Yocto Project development environment, see the
+                    "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
+                    section.
+                    For information on setting up a cross-development
+                    environment, see the
+                    "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
+                    section in the Yocto Project Application Developer's Guide.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TOPDIR'><glossterm>TOPDIR</glossterm>
+            <glossdef>
+                <para>
+                    The top-level
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                    BitBake automatically sets this variable when you
+                    initialize your build environment using either
+                    <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+                    or
+                    <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TRANSLATED_TARGET_ARCH'><glossterm>TRANSLATED_TARGET_ARCH</glossterm>
+            <glossdef>
+                <para>
+                    A sanitized version of
+                    <link linkend='var-TARGET_ARCH'><filename>TARGET_ARCH</filename></link>.
+                    This variable is used where the architecture is needed in
+                    a value where underscores are not allowed, for example
+                    within package filenames.
+                    In this case, dash characters replace any underscore
+                    characters used in TARGET_ARCH.
+                </para>
+
+                <para>
+                    Do not edit this variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TUNE_ARCH'><glossterm>TUNE_ARCH</glossterm>
+            <glossdef>
+                <para>
+                    The GNU canonical architecture for a specific architecture
+                    (i.e. <filename>arm</filename>,
+                    <filename>armeb</filename>,
+                    <filename>mips</filename>,
+                    <filename>mips64</filename>, and so forth).
+                    BitBake uses this value to setup configuration.
+                </para>
+
+                <para>
+                    <filename>TUNE_ARCH</filename> definitions are specific to
+                    a given architecture.
+                    The definitions can be a single static definition, or
+                    can be dynamically adjusted.
+                    You can see details for a given CPU family by looking at
+                    the architecture's <filename>README</filename> file.
+                    For example, the
+                    <filename>meta/conf/machine/include/mips/README</filename>
+                    file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    provides information for <filename>TUNE_ARCH</filename>
+                    specific to the <filename>mips</filename> architecture.
+                </para>
+
+                <para>
+                    <filename>TUNE_ARCH</filename> is tied closely to
+                    <link linkend='var-TARGET_ARCH'><filename>TARGET_ARCH</filename></link>,
+                    which defines the target machine's architecture.
+                    The BitBake configuration file
+                    (<filename>meta/conf/bitbake.conf</filename>) sets
+                    <filename>TARGET_ARCH</filename> as follows:
+                    <literallayout class='monospaced'>
+     TARGET_ARCH = "${TUNE_ARCH}"
+                    </literallayout>
+                </para>
+
+                <para>
+                    The following list, which is by no means complete since
+                    architectures are configurable, shows supported machine
+                    architectures:
+                    <literallayout class='monospaced'>
+     arm
+     i586
+     x86_64
+     powerpc
+     powerpc64
+     mips
+     mipsel
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TUNE_ASARGS'><glossterm>TUNE_ASARGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies architecture-specific assembler flags for
+                    the target system.
+                    The set of flags is based on the selected tune features.
+                    <filename>TUNE_ASARGS</filename> is set using
+                    the tune include files, which are typically under
+                    <filename>meta/conf/machine/include/</filename> and are
+                    influenced through <filename>TUNE_FEATURES</filename>.
+                    For example, the
+                    <filename>meta/conf/machine/include/x86/arch-x86.inc</filename>
+                    file defines the flags for the x86 architecture as follows:
+                    <literallayout class='monospaced'>
+     TUNE_ASARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}"
+                    </literallayout>
+                    <note>
+                        Board Support Packages (BSPs) can supply their own
+                        set of flags.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TUNE_CCARGS'><glossterm>TUNE_CCARGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies architecture-specific C compiler flags for
+                    the target system.
+                    The set of flags is based on the selected tune features.
+                    <filename>TUNE_CCARGS</filename> is set using
+                    the tune include files, which are typically under
+                    <filename>meta/conf/machine/include/</filename> and are
+                    influenced through <filename>TUNE_FEATURES</filename>.
+                    <note>
+                        Board Support Packages (BSPs) can supply their own
+                        set of flags.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TUNE_LDARGS'><glossterm>TUNE_LDARGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies architecture-specific linker flags for
+                    the target system.
+                    The set of flags is based on the selected tune features.
+                    <filename>TUNE_LDARGS</filename> is set using
+                    the tune include files, which are typically under
+                    <filename>meta/conf/machine/include/</filename> and are
+                    influenced through <filename>TUNE_FEATURES</filename>.
+                    For example, the
+                    <filename>meta/conf/machine/include/x86/arch-x86.inc</filename>
+                    file defines the flags for the x86 architecture as follows:
+                    <literallayout class='monospaced'>
+     TUNE_LDARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m elf32_x86_64", "", d)}"
+                    </literallayout>
+                    <note>
+                        Board Support Packages (BSPs) can supply their own
+                        set of flags.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TUNE_FEATURES'><glossterm>TUNE_FEATURES</glossterm>
+            <glossdef>
+                <para>
+                    Features used to "tune" a compiler for optimal use
+                    given a specific processor.
+                    The features are defined within the tune files and allow
+                    arguments (i.e. <filename>TUNE_*ARGS</filename>) to be
+                    dynamically generated based on the features.
+                </para>
+
+                <para>
+                    The OpenEmbedded build system verifies the features
+                    to be sure they are not conflicting and that they are
+                    supported.
+                </para>
+
+                <para>
+                    The BitBake configuration file
+                    (<filename>meta/conf/bitbake.conf</filename>) defines
+                    <filename>TUNE_FEATURES</filename> as follows:
+                    <literallayout class='monospaced'>
+     TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}"
+                    </literallayout>
+                    See the
+                    <link linkend='var-DEFAULTTUNE'><filename>DEFAULTTUNE</filename></link>
+                    variable for more information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TUNE_PKGARCH'><glossterm>TUNE_PKGARCH</glossterm>
+            <glossdef>
+                <para>
+                    The package architecture understood by the packaging
+                    system to define the architecture, ABI, and tuning of
+                    output packages.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TUNE_PKGARCH_tune'><glossterm>TUNE_PKGARCH_tune</glossterm>
+            <glossdef>
+                <para>
+                    The CPU or Application Binary Interface (ABI) specific
+                    tuning of the
+                    <link linkend='var-TUNE_PKGARCH'><filename>TUNE_PKGARCH</filename></link>.
+                </para>
+
+                <para>
+                    These tune-specific package architectures are defined in
+                    the machine include files.
+                    Here is an example of the "core2-32" tuning as used
+                    in the
+                    <filename>meta/conf/machine/include/tune-core2.inc</filename>
+                    file:
+                    <literallayout class='monospaced'>
+     TUNE_PKGARCH_tune-core2-32 = "core2-32"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TUNEABI'><glossterm>TUNEABI</glossterm>
+            <glossdef>
+                <para>
+                    An underlying Application Binary Interface (ABI) used by
+                    a particular tuning in a given toolchain layer.
+                    Providers that use prebuilt libraries can use the
+                    <filename>TUNEABI</filename>,
+                    <link linkend='var-TUNEABI_OVERRIDE'><filename>TUNEABI_OVERRIDE</filename></link>,
+                    and
+                    <link linkend='var-TUNEABI_WHITELIST'><filename>TUNEABI_WHITELIST</filename></link>
+                    variables to check compatibility of tunings against their
+                    selection of libraries.
+                </para>
+
+                <para>
+                    If <filename>TUNEABI</filename> is undefined, then every
+                    tuning is allowed.
+                    See the
+                    <link linkend='ref-classes-sanity'><filename>sanity</filename></link>
+                    class to see how the variable is used.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TUNEABI_OVERRIDE'><glossterm>TUNEABI_OVERRIDE</glossterm>
+            <glossdef>
+                <para>
+                    If set, the OpenEmbedded system ignores the
+                    <link linkend='var-TUNEABI_WHITELIST'><filename>TUNEABI_WHITELIST</filename></link>
+                    variable.
+                    Providers that use prebuilt libraries can use the
+                    <filename>TUNEABI_OVERRIDE</filename>,
+                    <filename>TUNEABI_WHITELIST</filename>,
+                    and
+                    <link linkend='var-TUNEABI'><filename>TUNEABI</filename></link>
+                    variables to check compatibility of a tuning against their
+                    selection of libraries.
+                </para>
+
+                <para>
+                    See the
+                    <link linkend='ref-classes-sanity'><filename>sanity</filename></link>
+                    class to see how the variable is used.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TUNEABI_WHITELIST'><glossterm>TUNEABI_WHITELIST</glossterm>
+            <glossdef>
+                <para>
+                    A whitelist of permissible
+                    <link linkend='var-TUNEABI'><filename>TUNEABI</filename></link>
+                    values.
+                    If <filename>TUNEABI_WHITELIST</filename> is not set,
+                    all tunes are allowed.
+                    Providers that use prebuilt libraries can use the
+                    <filename>TUNEABI_WHITELIST</filename>,
+                    <link linkend='var-TUNEABI_OVERRIDE'><filename>TUNEABI_OVERRIDE</filename></link>,
+                    and <filename>TUNEABI</filename> variables to check
+                    compatibility of a tuning against their selection of
+                    libraries.
+                </para>
+
+                <para>
+                    See the
+                    <link linkend='ref-classes-sanity'><filename>sanity</filename></link>
+                    class to see how the variable is used.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TUNECONFLICT'><glossterm>TUNECONFLICT[<replaceable>feature</replaceable>]</glossterm>
+            <glossdef>
+                <para>
+                    Specifies CPU or Application Binary Interface (ABI)
+                    tuning features that conflict with <replaceable>feature</replaceable>.
+                </para>
+
+                <para>
+                    Known tuning conflicts are specified in the machine include
+                    files in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    Here is an example from the
+                    <filename>meta/conf/machine/include/mips/arch-mips.inc</filename>
+                    include file that lists the "o32" and "n64" features as
+                    conflicting with the "n32" feature:
+                    <literallayout class='monospaced'>
+     TUNECONFLICTS[n32] = "o32 n64"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TUNEVALID'><glossterm>TUNEVALID[<replaceable>feature</replaceable>]</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a valid CPU or Application Binary Interface (ABI)
+                    tuning feature.
+                    The specified feature is stored as a flag.
+                    Valid features are specified in the machine include files
+                    (e.g. <filename>meta/conf/machine/include/arm/arch-arm.inc</filename>).
+                    Here is an example from that file:
+                    <literallayout class='monospaced'>
+     TUNEVALID[bigendian] = "Enable big-endian mode."
+                    </literallayout>
+                    See the machine include files in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    for these features.
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-u'><title>U</title>
+
+        <glossentry id='var-UBOOT_CONFIG'><glossterm>UBOOT_CONFIG</glossterm>
+            <glossdef>
+                <para>
+                    Configures the
+                    <link linkend='var-UBOOT_MACHINE'><filename>UBOOT_MACHINE</filename></link>
+                    and can also define
+                    <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
+                    for individual cases.
+                </para>
+
+                <para>
+                    Following is an example from the
+                    <filename>meta-fsl-arm</filename> layer.
+                    <literallayout class='monospaced'>
+     UBOOT_CONFIG ??= "sd"
+     UBOOT_CONFIG[sd] = "mx6qsabreauto_config,sdcard"
+     UBOOT_CONFIG[eimnor] = "mx6qsabreauto_eimnor_config"
+     UBOOT_CONFIG[nand] = "mx6qsabreauto_nand_config,ubifs"
+     UBOOT_CONFIG[spinor] = "mx6qsabreauto_spinor_config"
+                    </literallayout>
+                    In this example, "sd" is selected as the configuration
+                    of the possible four for the
+                    <filename>UBOOT_MACHINE</filename>.
+                    The "sd" configuration defines "mx6qsabreauto_config"
+                    as the value for <filename>UBOOT_MACHINE</filename>, while
+                    the "sdcard" specifies the
+                    <filename>IMAGE_FSTYPES</filename> to use for the U-boot
+                    image.
+                </para>
+
+                <para>
+                    For more information on how the
+                    <filename>UBOOT_CONFIG</filename> is handled, see the
+                    <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/uboot-config.bbclass'><filename>uboot-config</filename></ulink>
+                    class.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-UBOOT_ENTRYPOINT'><glossterm>UBOOT_ENTRYPOINT</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the entry point for the U-Boot image.
+                    During U-Boot image creation, the
+                    <filename>UBOOT_ENTRYPOINT</filename> variable is passed
+                    as a command-line parameter to the
+                    <filename>uboot-mkimage</filename> utility.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-UBOOT_LOADADDRESS'><glossterm>UBOOT_LOADADDRESS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the load address for the U-Boot image.
+                    During U-Boot image creation, the
+                    <filename>UBOOT_LOADADDRESS</filename> variable is passed
+                    as a command-line parameter to the
+                    <filename>uboot-mkimage</filename> utility.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-UBOOT_LOCALVERSION'><glossterm>UBOOT_LOCALVERSION</glossterm>
+            <glossdef>
+                <para>
+                    Appends a string to the name of the local version of the
+                    U-Boot image.
+                    For example, assuming the version of the U-Boot image
+                    built was "2013.10, the full version string reported by
+                    U-Boot would be "2013.10-yocto" given the following
+                    statement:
+                    <literallayout class='monospaced'>
+     UBOOT_LOCALVERSION = "-yocto"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-UBOOT_MACHINE'><glossterm>UBOOT_MACHINE</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the value passed on the
+                    <filename>make</filename> command line when building
+                    a U-Boot image.
+                    The value indicates the target platform configuration.
+                    You typically set this variable from the machine
+                    configuration file (i.e.
+                    <filename>conf/machine/<replaceable>machine_name</replaceable>.conf</filename>).
+                </para>
+
+                <para>
+                    Please see the "Selection of Processor Architecture and
+                    Board Type" section in the U-Boot README for valid values
+                    for this variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-UBOOT_MAKE_TARGET'><glossterm>UBOOT_MAKE_TARGET</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the target called in the
+                    <filename>Makefile</filename>.
+                    The default target is "all".
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-UBOOT_SUFFIX'><glossterm>UBOOT_SUFFIX</glossterm>
+            <glossdef>
+                <para>
+                    Points to the generated U-Boot extension.
+                    For example, <filename>u-boot.sb</filename> has a
+                    <filename>.sb</filename> extension.
+                </para>
+
+                <para>
+                    The default U-Boot extension is
+                    <filename>.bin</filename>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-UBOOT_TARGET'><glossterm>UBOOT_TARGET</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the target used for building U-Boot.
+                    The target is passed directly as part of the "make" command
+                    (e.g. SPL and AIS).
+                    If you do not specifically set this variable, the
+                    OpenEmbedded build process passes and uses "all" for the
+                    target during the U-Boot building process.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-USE_VT'><glossterm>USE_VT</glossterm>
+            <glossdef>
+                <para>
+                    When using
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-enabling-system-services'>SysVinit</ulink>,
+                    determines whether or not to run a
+                    <ulink url='http://en.wikipedia.org/wiki/Getty_%28Unix%29'>getty</ulink>
+                    on any virtual terminals in order to enable logging in
+                    through those terminals.
+                </para>
+
+                <para>
+                    The default value used for <filename>USE_VT</filename>
+                    is "1" when no default value is specifically set.
+                    Typically, you would set <filename>USE_VT</filename>
+                    to "0" in the machine configuration file for machines
+                    that do not have a graphical display attached and
+                    therefore do not need virtual terminal functionality.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-USER_CLASSES'><glossterm>USER_CLASSES</glossterm>
+            <glossdef>
+                <para>
+                    A list of classes to globally inherit.
+                    These classes are used by the OpenEmbedded build system
+                    to enable extra features (e.g.
+                    <filename>buildstats</filename>,
+                    <filename>image-mklibs</filename>, and so forth).
+                </para>
+
+                <para>
+                    The default list is set in your
+                    <filename>local.conf</filename> file:
+                    <literallayout class='monospaced'>
+     USER_CLASSES ?= "buildstats image-mklibs image-prelink"
+                    </literallayout>
+                    For more information, see
+                    <filename>meta-yocto/conf/local.conf.sample</filename> in
+                    the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-USERADD_ERROR_DYNAMIC'><glossterm>USERADD_ERROR_DYNAMIC</glossterm>
+            <glossdef>
+                <para>
+                    Forces the OpenEmbedded build system to produce an error
+                    if the user identification (<filename>uid</filename>) and
+                    group identification (<filename>gid</filename>) values
+                    are not defined in <filename>files/passwd</filename>
+                    and <filename>files/group</filename> files.
+                </para>
+
+                <para>
+                    The default behavior for the build system is to dynamically
+                    apply <filename>uid</filename> and
+                    <filename>gid</filename> values.
+                    Consequently, the <filename>USERADD_ERROR_DYNAMIC</filename>
+                    variable is by default not set.
+                    If you plan on using statically assigned
+                    <filename>gid</filename> and <filename>uid</filename>
+                    values, you should set
+                    the <filename>USERADD_ERROR_DYNAMIC</filename> variable in
+                    your <filename>local.conf</filename> file as
+                    follows:
+                    <literallayout class='monospaced'>
+     USERADD_ERROR_DYNAMIC = "1"
+                    </literallayout>
+                    Overriding the default behavior implies you are going to
+                    also take steps to set static <filename>uid</filename> and
+                    <filename>gid</filename> values through use of the
+                    <link linkend='var-USERADDEXTENSION'><filename>USERADDEXTENSION</filename></link>,
+                    <link linkend='var-USERADD_UID_TABLES'><filename>USERADD_UID_TABLES</filename></link>,
+                    and
+                    <link linkend='var-USERADD_GID_TABLES'><filename>USERADD_GID_TABLES</filename></link>
+                    variables.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-USERADD_GID_TABLES'><glossterm>USERADD_GID_TABLES</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a password file to use for obtaining static
+                    group identification (<filename>gid</filename>) values
+                    when the OpenEmbedded build system adds a group to the
+                    system during package installation.
+                </para>
+
+                <para>
+                    When applying static group identification
+                    (<filename>gid</filename>) values, the OpenEmbedded build
+                    system looks in
+                    <link linkend='var-BBPATH'><filename>BBPATH</filename></link>
+                    for a <filename>files/group</filename> file and then applies
+                    those <filename>uid</filename> values.
+                    Set the variable as follows in your
+                    <filename>local.conf</filename> file:
+                    <literallayout class='monospaced'>
+     USERADD_GID_TABLES = "files/group"
+                    </literallayout>
+                </para>
+
+                <note>
+                    Setting the
+                    <link linkend='var-USERADDEXTENSION'><filename>USERADDEXTENSION</filename></link>
+                    variable to "useradd-staticids" causes the build system
+                    to use static <filename>gid</filename> values.
+                </note>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-USERADD_UID_TABLES'><glossterm>USERADD_UID_TABLES</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a password file to use for obtaining static
+                    user identification (<filename>uid</filename>) values
+                    when the OpenEmbedded build system adds a user to the
+                    system during package installation.
+                </para>
+
+                <para>
+                    When applying static user identification
+                    (<filename>uid</filename>) values, the OpenEmbedded build
+                    system looks in
+                    <link linkend='var-BBPATH'><filename>BBPATH</filename></link>
+                    for a <filename>files/passwd</filename> file and then applies
+                    those <filename>uid</filename> values.
+                    Set the variable as follows in your
+                    <filename>local.conf</filename> file:
+                    <literallayout class='monospaced'>
+     USERADD_UID_TABLES = "files/passwd"
+                    </literallayout>
+                </para>
+
+                <note>
+                    Setting the
+                    <link linkend='var-USERADDEXTENSION'><filename>USERADDEXTENSION</filename></link>
+                    variable to "useradd-staticids" causes the build system
+                    to use static <filename>uid</filename> values.
+                </note>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-USERADD_PACKAGES'><glossterm>USERADD_PACKAGES</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-useradd'><filename>useradd</filename></link>
+                    class, this variable
+                    specifies the individual packages within the recipe that
+                    require users and/or groups to be added.
+                </para>
+
+                <para>
+                    You must set this variable if the recipe inherits the
+                    class.
+                    For example, the following enables adding a user for the
+                    main package in a recipe:
+                    <literallayout class='monospaced'>
+     USERADD_PACKAGES = "${PN}"
+                    </literallayout>
+                    <note>
+                        If follows that if you are going to use the
+                        <filename>USERADD_PACKAGES</filename> variable,
+                        you need to set one or more of the
+                        <link linkend='var-USERADD_PARAM'><filename>USERADD_PARAM</filename></link>,
+                        <link linkend='var-GROUPADD_PARAM'><filename>GROUPADD_PARAM</filename></link>,
+                        or
+                        <link linkend='var-GROUPMEMS_PARAM'><filename>GROUPMEMS_PARAM</filename></link>
+                        variables.
+                    </note>
+                </para>
+
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-USERADD_PARAM'><glossterm>USERADD_PARAM</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting the
+                    <link linkend='ref-classes-useradd'><filename>useradd</filename></link>
+                    class, this variable
+                    specifies for a package what parameters should be passed
+                    to the <filename>useradd</filename> command
+                    if you wish to add a user to the system when the package
+                    is installed.
+                </para>
+
+                <para>
+                    Here is an example from the <filename>dbus</filename>
+                    recipe:
+                    <literallayout class='monospaced'>
+     USERADD_PARAM_${PN} = "--system --home ${localstatedir}/lib/dbus \
+                            --no-create-home --shell /bin/false \
+                            --user-group messagebus"
+                    </literallayout>
+                    For information on the standard Linux shell command
+                    <filename>useradd</filename>, see
+                    <ulink url='http://linux.die.net/man/8/useradd'></ulink>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-USERADDEXTENSION'><glossterm>USERADDEXTENSION</glossterm>
+            <glossdef>
+                <para>
+                    When set to "useradd-staticids", causes the
+                    OpenEmbedded build system to base all user and group
+                    additions on a static
+                    <filename>passwd</filename> and
+                    <filename>group</filename> files found in
+                    <link linkend='var-BBPATH'><filename>BBPATH</filename></link>.
+                </para>
+
+                <para>
+                    To use static user identification (<filename>uid</filename>)
+                    and group identification (<filename>gid</filename>)
+                    values, set the variable
+                    as follows in your <filename>local.conf</filename> file:
+                    <literallayout class='monospaced'>
+     USERADDEXTENSION = "useradd-staticids"
+                    </literallayout>
+                    <note>
+                        Setting this variable to use static
+                        <filename>uid</filename> and <filename>gid</filename>
+                        values causes the OpenEmbedded build system to employ
+                        the
+                        <link linkend='ref-classes-useradd-staticids'><filename>useradd-staticids</filename></link>
+                        class.
+                    </note>
+                </para>
+
+                <para>
+                    If you use static <filename>uid</filename> and
+                    <filename>gid</filename> information, you must also
+                    specify the <filename>files/passwd</filename> and
+                    <filename>files/group</filename> files by setting the
+                    <link linkend='var-USERADD_UID_TABLES'><filename>USERADD_UID_TABLES</filename></link>
+                    and
+                    <link linkend='var-USERADD_GID_TABLES'><filename>USERADD_GID_TABLES</filename></link>
+                    variables.
+                    Additionally, you should also set the
+                    <link linkend='var-USERADD_ERROR_DYNAMIC'><filename>USERADD_ERROR_DYNAMIC</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+<!--            <glossdiv id='var-glossary-v'><title>V</title>-->
+<!--            </glossdiv>-->
+
+    <glossdiv id='var-glossary-w'><title>W</title>
+
+        <glossentry id='var-WARN_QA'><glossterm>WARN_QA</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the quality assurance checks whose failures are
+                    reported as warnings by the OpenEmbedded build system.
+                    You set this variable in your distribution configuration
+                    file.
+                    For a list of the checks you can control with this variable,
+                    see the
+                    "<link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>"
+                    section.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-WORKDIR'><glossterm>WORKDIR</glossterm>
+            <glossdef>
+                <para>
+                    The pathname of the work directory in which the OpenEmbedded
+                    build system builds a recipe.
+                    This directory is located within the
+                    <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
+                    directory structure and is specific to the recipe being
+                    built and the system for which it is being built.
+                </para>
+
+                <para>
+                    The <filename>WORKDIR</filename> directory is defined as
+                    follows:
+                    <literallayout class='monospaced'>
+     ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}
+                    </literallayout>
+                    The actual directory depends on several things:
+                    <itemizedlist>
+                        <listitem><link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>:
+                            The top-level build output directory</listitem>
+                        <listitem><link linkend='var-MULTIMACH_TARGET_SYS'><filename>MULTIMACH_TARGET_SYS</filename></link>:
+                            The target system identifier</listitem>
+                        <listitem><link linkend='var-PN'><filename>PN</filename></link>:
+                            The recipe name</listitem>
+                        <listitem><link linkend='var-EXTENDPE'><filename>EXTENDPE</filename></link>:
+                            The epoch - (if
+                            <link linkend='var-PE'><filename>PE</filename></link>
+                            is not specified, which is usually the case for most
+                            recipes, then <filename>EXTENDPE</filename> is blank)</listitem>
+                        <listitem><link linkend='var-PV'><filename>PV</filename></link>:
+                            The recipe version</listitem>
+                        <listitem><link linkend='var-PR'><filename>PR</filename></link>:
+                            The recipe revision</listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    As an example, assume a Source Directory top-level folder
+                    name <filename>poky</filename>, a default Build Directory at
+                    <filename>poky/build</filename>, and a
+                    <filename>qemux86-poky-linux</filename> machine target
+                    system.
+                    Furthermore, suppose your recipe is named
+                    <filename>foo_1.3.0-r0.bb</filename>.
+                    In this case, the work directory the build system uses to
+                    build the package would be as follows:
+                    <literallayout class='monospaced'>
+     poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+<!--            <glossdiv id='var-glossary-x'><title>X</title>-->
+<!--            </glossdiv>-->
+
+<!--            <glossdiv id='var-glossary-y'><title>Y</title>-->
+<!--            </glossdiv>-->
+
+<!--            <glossdiv id='var-glossary-z'><title>Z</title>-->
+<!--            </glossdiv>-->
+
+</glossary>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/ref-varlocality.xml b/documentation/ref-manual/ref-varlocality.xml
new file mode 100644
index 0000000000..d3f873298d
--- /dev/null
+++ b/documentation/ref-manual/ref-varlocality.xml
@@ -0,0 +1,196 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='ref-varlocality'>
+    <title>Variable Context</title>
+
+    <para>
+        While you can use most variables in almost any context such as
+        <filename>.conf</filename>, <filename>.bbclass</filename>,
+        <filename>.inc</filename>, and <filename>.bb</filename> files,
+        some variables are often associated with a particular locality or context.
+        This chapter describes some common associations.
+    </para>
+
+    <section id='ref-varlocality-configuration'>
+        <title>Configuration</title>
+
+        <para>
+            The following subsections provide lists of variables whose context is
+            configuration: distribution, machine, and local.
+        </para>
+
+        <section id='ref-varlocality-config-distro'>
+            <title>Distribution (Distro)</title>
+
+            <para>
+               This section lists variables whose configuration context is the
+               distribution, or distro.
+               <itemizedlist>
+                   <listitem><para><filename><link linkend='var-DISTRO'>DISTRO</link></filename></para></listitem>
+                   <listitem><para><filename><link linkend='var-DISTRO_NAME'>DISTRO_NAME</link></filename>
+                       </para></listitem>
+                   <listitem><para><filename><link linkend='var-DISTRO_VERSION'>DISTRO_VERSION</link>
+                       </filename></para></listitem>
+                   <listitem><para><filename><link linkend='var-MAINTAINER'>MAINTAINER</link></filename>
+                       </para></listitem>
+                   <listitem><para><filename><link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link>
+                       </filename></para></listitem>
+                   <listitem><para><filename><link linkend='var-TARGET_OS'>TARGET_OS</link></filename>
+                       </para></listitem>
+                   <listitem><para><filename><link linkend='var-TARGET_FPU'>TARGET_FPU</link></filename>
+                       </para></listitem>
+                   <listitem><para><filename><link linkend='var-TCMODE'>TCMODE</link></filename>
+                       </para></listitem>
+                   <listitem><para><filename><link linkend='var-TCLIBC'>TCLIBC</link></filename>
+                       </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='ref-varlocality-config-machine'>
+            <title>Machine</title>
+
+            <para>
+                This section lists variables whose configuration context is the
+                machine.
+                <itemizedlist>
+                    <listitem><para><filename><link linkend='var-TARGET_ARCH'>TARGET_ARCH</link></filename>
+                        </para></listitem>
+                    <listitem><para><filename><link linkend='var-SERIAL_CONSOLES'>SERIAL_CONSOLES</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-PACKAGE_EXTRA_ARCHS'>PACKAGE_EXTRA_ARCHS</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-IMAGE_FSTYPES'>IMAGE_FSTYPES</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-MACHINE_EXTRA_RDEPENDS'>MACHINE_EXTRA_RDEPENDS
+                        </link></filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS
+                        </link></filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'>MACHINE_ESSENTIAL_EXTRA_RDEPENDS
+                        </link></filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'>
+                        MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</link></filename></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='ref-varlocality-config-local'>
+            <title>Local</title>
+
+            <para>
+                This section lists variables whose configuration context is the
+                local configuration through the <filename>local.conf</filename>
+                file.
+                <itemizedlist>
+                    <listitem><para><filename><link linkend='var-DISTRO'>DISTRO</link></filename>
+                        </para></listitem>
+                    <listitem><para><filename><link linkend='var-MACHINE'>MACHINE</link></filename>
+                        </para></listitem>
+                    <listitem><para><filename><link linkend='var-DL_DIR'>DL_DIR</link></filename>
+                        </para></listitem>
+                    <listitem><para><filename><link linkend='var-BBFILES'>BBFILES</link></filename>
+                        </para></listitem>
+                    <listitem><para><filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES
+                        </link></filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-BBINCLUDELOGS'>BBINCLUDELOGS</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>
+                        ENABLE_BINARY_LOCALE_GENERATION</link></filename></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+    </section>
+
+    <section id='ref-varlocality-recipes'>
+        <title>Recipes</title>
+
+        <para>
+            The following subsections provide lists of variables whose context is
+            recipes: required, dependencies, path, and extra build information.
+        </para>
+
+        <section id='ref-varlocality-recipe-required'>
+            <title>Required</title>
+
+            <para>
+                This section lists variables that are required for recipes.
+                <itemizedlist>
+                    <listitem><para><filename><link linkend='var-LICENSE'>LICENSE</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-SRC_URI'>SRC_URI</link></filename> - used
+                        in recipes that fetch local or remote files.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='ref-varlocality-recipe-dependencies'>
+            <title>Dependencies</title>
+
+            <para>
+                This section lists variables that define recipe dependencies.
+                <itemizedlist>
+                    <listitem><para><filename><link linkend='var-DEPENDS'>DEPENDS</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-RDEPENDS'>RDEPENDS</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-RRECOMMENDS'>RRECOMMENDS</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-RCONFLICTS'>RCONFLICTS</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-RREPLACES'>RREPLACES</link>
+                        </filename></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='ref-varlocality-recipe-paths'>
+            <title>Paths</title>
+
+            <para>
+                This section lists variables that define recipe paths.
+                <itemizedlist>
+                    <listitem><para><filename><link linkend='var-WORKDIR'>WORKDIR</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-S'>S</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-FILES'>FILES</link>
+                        </filename></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='ref-varlocality-recipe-build'>
+            <title>Extra Build Information</title>
+
+            <para>
+                This section lists variables that define extra build information for recipes.
+                <itemizedlist>
+                    <listitem><para><filename><link linkend='var-EXTRA_OECMAKE'>EXTRA_OECMAKE</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-EXTRA_OECONF'>EXTRA_OECONF</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-PACKAGES'>PACKAGES</link></filename>
+                        </para></listitem>
+                    <listitem><para><filename><link linkend='var-DEFAULT_PREFERENCE'>DEFAULT_PREFERENCE
+                        </link></filename></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+    </section>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4 spell spelllang=en_gb
+-->
diff --git a/documentation/ref-manual/resources.xml b/documentation/ref-manual/resources.xml
new file mode 100644
index 0000000000..17b8e97145
--- /dev/null
+++ b/documentation/ref-manual/resources.xml
@@ -0,0 +1,130 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='resources'>
+<title>Contributing to the Yocto Project</title>
+
+<section id='resources-intro'>
+    <title>Introduction</title>
+    <para>
+        The Yocto Project team is happy for people to experiment with the Yocto Project.
+        A number of places exist to find help if you run into difficulties or find bugs.
+        To find out how to download source code,
+        see the "<ulink url='&YOCTO_DOCS_DEV_URL;#local-yp-release'>Yocto Project Release</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+</section>
+
+<section id='resources-bugtracker'>
+    <title>Tracking Bugs</title>
+
+    <para>
+        If you find problems with the Yocto Project, you should report them using the
+        Bugzilla application at <ulink url='&YOCTO_BUGZILLA_URL;'></ulink>.
+    </para>
+</section>
+
+<section id='resources-mailinglist'>
+    <title>Mailing lists</title>
+
+    <para>
+        A number of mailing lists maintained by the Yocto Project exist
+        as well as related OpenEmbedded mailing lists for discussion,
+        patch submission and announcements.
+        To subscribe to one of the following mailing lists, click on the
+        appropriate URL in the following list and follow the instructions:
+        <itemizedlist>
+            <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'></ulink> -
+                General Yocto Project discussion mailing list. </para></listitem>
+            <listitem><para><ulink url='&OE_LISTS_URL;/listinfo/openembedded-core'></ulink> -
+                Discussion mailing list about OpenEmbedded-Core (the core metadata).</para></listitem>
+            <listitem><para><ulink url='&OE_LISTS_URL;/listinfo/openembedded-devel'></ulink> -
+                Discussion mailing list about OpenEmbedded.</para></listitem>
+            <listitem><para><ulink url='&OE_LISTS_URL;/listinfo/bitbake-devel'></ulink> -
+                Discussion mailing list about the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>
+                build tool.</para></listitem>
+            <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink> -
+                Discussion mailing list about
+                <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink>.
+                </para></listitem>
+            <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto-announce'></ulink> -
+                Mailing list to receive official Yocto Project release and milestone
+                announcements.</para></listitem>
+        </itemizedlist>
+    </para>
+    For more Yocto Project-related mailing lists, see the Yocto Project community mailing lists page
+    <ulink url='&YOCTO_HOME_URL;/tools-resources/community/mailing-lists'>here</ulink>.
+</section>
+
+<section id='resources-irc'>
+    <title>Internet Relay Chat (IRC)</title>
+
+    <para>
+        Two IRC channels on freenode are available for the Yocto Project and Poky discussions:
+        <itemizedlist>
+            <listitem><para><filename>#yocto</filename></para></listitem>
+            <listitem><para><filename>#poky</filename></para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='resources-links'>
+    <title>Links</title>
+
+    <para>
+        Here is a list of resources you will find helpful:
+        <itemizedlist>
+            <listitem><para><emphasis>
+                <ulink url='&YOCTO_HOME_URL;'>The Yocto Project website</ulink>:
+                </emphasis> The home site for the Yocto
+                Project.</para></listitem>
+            <listitem><para><emphasis>
+                <ulink url='http://www.intel.com/'>Intel Corporation</ulink>:</emphasis>
+                The company that acquired OpenedHand in 2008 and began
+                development on the Yocto Project.</para></listitem>
+            <listitem><para><emphasis>
+                <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:</emphasis>
+                The upstream, generic, embedded distribution used as the basis
+                for the build system in the Yocto Project.
+                Poky derives from and contributes back to the OpenEmbedded
+                project.</para></listitem>
+            <listitem><para><emphasis>
+                <ulink url='http://www.openembedded.org/wiki/BitBake'>
+                BitBake</ulink>:</emphasis> The tool used to process metadata.</para></listitem>
+            <listitem><para><emphasis>
+                <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>:</emphasis>
+                A comprehensive guide to the BitBake tool.
+                In the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
+                you can find the BitBake User Manual in the
+                <filename>bitbake/doc/bitbake-user-manual</filename> directory.
+                </para></listitem>
+            <listitem><para><emphasis>
+                <ulink url='http://wiki.qemu.org/Index.html'>QEMU</ulink>:
+                </emphasis> An open source machine emulator and virtualizer.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='resources-contributions'>
+    <title>Contributions</title>
+
+    <para>
+        The Yocto Project gladly accepts contributions.
+        You can submit changes to the project either by creating and sending
+        pull requests,
+        or by submitting patches through email.
+        For information on how to do both as well as information on how
+        to identify the maintainer for each area of code, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>How to Submit a Change</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml
new file mode 100644
index 0000000000..2df36521c2
--- /dev/null
+++ b/documentation/ref-manual/technical-details.xml
@@ -0,0 +1,1421 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='technical-details'>
+<title>Technical Details</title>
+
+    <para>
+        This chapter provides technical details for various parts of the
+        Yocto Project.
+        Currently, topics include Yocto Project components,
+        cross-toolchain generation, shared state (sstate) cache,
+        x32, Wayland support, and Licenses.
+    </para>
+
+<section id='usingpoky-components'>
+    <title>Yocto Project Components</title>
+
+    <para>
+        The
+        <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>
+        task executor together with various types of configuration files form
+        the OpenEmbedded Core.
+        This section overviews these components by describing their use and
+        how they interact.
+    </para>
+
+    <para>
+        BitBake handles the parsing and execution of the data files.
+        The data itself is of various types:
+        <itemizedlist>
+            <listitem><para><emphasis>Recipes:</emphasis> Provides details
+                about particular pieces of software.
+                </para></listitem>
+            <listitem><para><emphasis>Class Data:</emphasis> Abstracts
+                common build information (e.g. how to build a Linux kernel).
+                </para></listitem>
+            <listitem><para><emphasis>Configuration Data:</emphasis> Defines
+                machine-specific settings, policy decisions, and so forth.
+                Configuration data acts as the glue to bind everything
+                together.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        BitBake knows how to combine multiple data sources together and refers
+        to each data source as a layer.
+        For information on layers, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and
+        Creating Layers</ulink>" section of the Yocto Project Development Manual.
+    </para>
+
+    <para>
+        Following are some brief details on these core components.
+        For additional information on how these components interact during
+        a build, see the
+        "<link linkend='closer-look'>A Closer Look at the Yocto Project Development Environment</link>"
+        Chapter.
+    </para>
+
+    <section id='usingpoky-components-bitbake'>
+        <title>BitBake</title>
+
+        <para>
+            BitBake is the tool at the heart of the OpenEmbedded build system
+            and is responsible for parsing the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>,
+            generating a list of tasks from it, and then executing those tasks.
+        </para>
+
+        <para>
+            This section briefly introduces BitBake.
+            If you want more information on BitBake, see the
+            <ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual'>BitBake User Manual</ulink>.
+        </para>
+
+        <para>
+            To see a list of the options BitBake supports, use either of
+            the following commands:
+            <literallayout class='monospaced'>
+     $ bitbake -h
+     $ bitbake --help
+            </literallayout>
+        </para>
+
+        <para>
+            The most common usage for BitBake is <filename>bitbake <replaceable>packagename</replaceable></filename>, where
+            <filename>packagename</filename> is the name of the package you want to build
+            (referred to as the "target" in this manual).
+            The target often equates to the first part of a recipe's filename
+            (e.g. "foo" for a recipe named
+            <filename>foo_1.3.0-r0.bb</filename>).
+            So, to process the <filename>matchbox-desktop_1.2.3.bb</filename> recipe file, you
+            might type the following:
+            <literallayout class='monospaced'>
+     $ bitbake matchbox-desktop
+            </literallayout>
+            Several different versions of <filename>matchbox-desktop</filename> might exist.
+            BitBake chooses the one selected by the distribution configuration.
+            You can get more details about how BitBake chooses between different
+            target versions and providers in the
+            "<ulink url='&YOCTO_DOCS_BB_URL;#bb-bitbake-preferences'>Preferences</ulink>"
+            section of the BitBake User Manual.
+        </para>
+
+        <para>
+            BitBake also tries to execute any dependent tasks first.
+            So for example, before building <filename>matchbox-desktop</filename>, BitBake
+            would build a cross compiler and <filename>glibc</filename> if they had not already
+            been built.
+        </para>
+
+        <para>
+            A useful BitBake option to consider is the <filename>-k</filename> or
+            <filename>--continue</filename> option.
+            This option instructs BitBake to try and continue processing the job
+            as long as possible even after encountering an error.
+            When an error occurs, the target that
+            failed and those that depend on it cannot be remade.
+            However, when you use this option other dependencies can still be
+            processed.
+        </para>
+    </section>
+
+    <section id='usingpoky-components-metadata'>
+        <title>Metadata (Recipes)</title>
+
+        <para>
+            Files that have the <filename>.bb</filename> suffix are "recipes"
+            files.
+            In general, a recipe contains information about a single piece of
+            software.
+            This information includes the location from which to download the
+            unaltered source, any source patches to be applied to that source
+            (if needed), which special configuration options to apply,
+            how to compile the source files, and how to package the compiled
+            output.
+        </para>
+
+        <para>
+            The term "package" is sometimes used to refer to recipes. However,
+            since the word "package" is used for the packaged output from the OpenEmbedded
+            build system (i.e. <filename>.ipk</filename> or <filename>.deb</filename> files),
+            this document avoids using the term "package" when referring to recipes.
+        </para>
+    </section>
+
+    <section id='usingpoky-components-classes'>
+        <title>Classes</title>
+
+        <para>
+            Class files (<filename>.bbclass</filename>) contain information that
+            is useful to share between
+            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> files.
+            An example is the
+            <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
+            class, which contains common settings for any application that
+            Autotools uses.
+            The "<link linkend='ref-classes'>Classes</link>" chapter provides
+            details about classes and how to use them.
+        </para>
+    </section>
+
+    <section id='usingpoky-components-configuration'>
+        <title>Configuration</title>
+
+        <para>
+            The configuration files (<filename>.conf</filename>) define various configuration variables
+            that govern the OpenEmbedded build process.
+            These files fall into several areas that define machine configuration options,
+            distribution configuration options, compiler tuning options, general common configuration
+            options, and user configuration options in <filename>local.conf</filename>, which is found
+            in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+        </para>
+    </section>
+</section>
+
+<section id="cross-development-toolchain-generation">
+    <title>Cross-Development Toolchain Generation</title>
+
+    <para>
+        The Yocto Project does most of the work for you when it comes to
+        creating
+        <ulink url='&YOCTO_DOCS_DEV_URL;#cross-development-toolchain'>cross-development toolchains</ulink>.
+        This section provides some technical background on how
+        cross-development toolchains are created and used.
+        For more information on toolchains, you can also see the
+        <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>.
+    </para>
+
+    <para>
+        In the Yocto Project development environment, cross-development
+        toolchains are used to build the image and applications that run on the
+        target hardware.
+        With just a few commands, the OpenEmbedded build system creates
+        these necessary toolchains for you.
+    </para>
+
+    <para>
+        The following figure shows a high-level build environment regarding
+        toolchain construction and use.
+    </para>
+
+    <para>
+        <imagedata fileref="figures/cross-development-toolchains.png" width="8in" depth="6in" align="center" />
+    </para>
+
+    <para>
+        Most of the work occurs on the Build Host.
+        This is the machine used to build images and generally work within the
+        the Yocto Project environment.
+        When you run BitBake to create an image, the OpenEmbedded build system
+        uses the host <filename>gcc</filename> compiler to bootstrap a
+        cross-compiler named <filename>gcc-cross</filename>.
+        The <filename>gcc-cross</filename> compiler is what BitBake uses to
+        compile source files when creating the target image.
+        You can think of <filename>gcc-cross</filename> simply as an
+        automatically generated cross-compiler that is used internally within
+        BitBake only.
+    </para>
+
+    <para>
+        The chain of events that occurs when <filename>gcc-cross</filename> is
+        bootstrapped is as follows:
+        <literallayout class='monospaced'>
+     gcc -> binutils-cross -> gcc-cross-initial -> linux-libc-headers -> glibc-initial -> glibc -> gcc-cross -> gcc-runtime
+        </literallayout>
+        <itemizedlist>
+            <listitem><para><filename>gcc</filename>:
+                The build host's GNU Compiler Collection (GCC).
+                </para></listitem>
+            <listitem><para><filename>binutils-cross</filename>:
+                The bare minimum binary utilities needed in order to run
+                the <filename>gcc-cross-initial</filename> phase of the
+                bootstrap operation.
+                </para></listitem>
+            <listitem><para><filename>gcc-cross-initial</filename>:
+                An early stage of the bootstrap process for creating
+                the cross-compiler.
+                This stage builds enough of the <filename>gcc-cross</filename>,
+                the C library, and other pieces needed to finish building the
+                final cross-compiler in later stages.
+                This tool is a "native" package (i.e. it is designed to run on
+                the build host).
+                </para></listitem>
+            <listitem><para><filename>linux-libc-headers</filename>:
+                Headers needed for the cross-compiler.
+                </para></listitem>
+            <listitem><para><filename>glibc-initial</filename>:
+                An initial version of the Embedded GLIBC needed to bootstrap
+                <filename>glibc</filename>.
+                </para></listitem>
+            <listitem><para><filename>gcc-cross</filename>:
+                The final stage of the bootstrap process for the
+                cross-compiler.
+                This stage results in the actual cross-compiler that
+                BitBake uses when it builds an image for a targeted
+                device.
+                <note>
+                    If you are replacing this cross compiler toolchain
+                    with a custom version, you must replace
+                    <filename>gcc-cross</filename>.
+                </note>
+                This tool is also a "native" package (i.e. it is
+                designed to run on the build host).
+                </para></listitem>
+            <listitem><para><filename>gcc-runtime</filename>:
+                Runtime libraries resulting from the toolchain bootstrapping
+                process.
+                This tool produces a binary that consists of the
+                runtime libraries need for the targeted device.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        You can use the OpenEmbedded build system to build an installer for
+        the relocatable SDK used to develop applications.
+        When you run the installer, it installs the toolchain, which contains
+        the development tools (e.g., the
+        <filename>gcc-cross-canadian</filename>),
+        <filename>binutils-cross-canadian</filename>, and other
+        <filename>nativesdk-*</filename> tools you need to cross-compile and
+        test your software.
+        The figure shows the commands you use to easily build out this
+        toolchain.
+        This cross-development toolchain is built to execute on the
+        <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>,
+        which might or might not be the same
+        machine as the Build Host.
+        <note>
+            If your target architecture is supported by the Yocto Project,
+            you can take advantage of pre-built images that ship with the
+            Yocto Project and already contain cross-development toolchain
+            installers.
+        </note>
+    </para>
+
+    <para>
+        Here is the bootstrap process for the relocatable toolchain:
+        <literallayout class='monospaced'>
+     gcc -> binutils-crosssdk -> gcc-crosssdk-initial -> linux-libc-headers ->
+        glibc-initial -> nativesdk-glibc -> gcc-crosssdk -> gcc-cross-canadian
+        </literallayout>
+        <itemizedlist>
+            <listitem><para><filename>gcc</filename>:
+                The build host's GNU Compiler Collection (GCC).
+                </para></listitem>
+            <listitem><para><filename>binutils-crosssdk</filename>:
+                The bare minimum binary utilities needed in order to run
+                the <filename>gcc-crosssdk-initial</filename> phase of the
+                bootstrap operation.
+                </para></listitem>
+            <listitem><para><filename>gcc-crosssdk-initial</filename>:
+                An early stage of the bootstrap process for creating
+                the cross-compiler.
+                This stage builds enough of the
+                <filename>gcc-crosssdk</filename> and supporting pieces so that
+                the final stage of the bootstrap process can produce the
+                finished cross-compiler.
+                This tool is a "native" binary that runs on the build host.
+                </para></listitem>
+            <listitem><para><filename>linux-libc-headers</filename>:
+                Headers needed for the cross-compiler.
+                </para></listitem>
+            <listitem><para><filename>glibc-initial</filename>:
+                An initial version of the Embedded GLIBC needed to bootstrap
+                <filename>nativesdk-glibc</filename>.
+                </para></listitem>
+            <listitem><para><filename>nativesdk-glibc</filename>:
+                The Embedded GLIBC needed to bootstrap the
+                <filename>gcc-crosssdk</filename>.
+                </para></listitem>
+            <listitem><para><filename>gcc-crosssdk</filename>:
+                The final stage of the bootstrap process for the
+                relocatable cross-compiler.
+                The <filename>gcc-crosssdk</filename> is a transitory compiler
+                and never leaves the build host.
+                Its purpose is to help in the bootstrap process to create the
+                eventual relocatable <filename>gcc-cross-canadian</filename>
+                compiler, which is relocatable.
+                This tool is also a "native" package (i.e. it is
+                designed to run on the build host).
+                </para></listitem>
+            <listitem><para><filename>gcc-cross-canadian</filename>:
+                The final relocatable cross-compiler.
+                When run on the
+                <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>,
+                this tool
+                produces executable code that runs on the target device.
+                Only one cross-canadian compiler is produced per architecture
+                since they can be targeted at different processor optimizations
+                using configurations passed to the compiler through the
+                compile commands.
+                This circumvents the need for multiple compilers and thus
+                reduces the size of the toolchains.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <note>
+        For information on advantages gained when building a
+        cross-development toolchain installer, see the
+        "<ulink url='&YOCTO_DOCS_ADT_URL;#optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</ulink>"
+        section in the Yocto Project Application Developer's Guide.
+    </note>
+</section>
+
+<section id="shared-state-cache">
+    <title>Shared State Cache</title>
+
+    <para>
+        By design, the OpenEmbedded build system builds everything from scratch unless
+        BitBake can determine that parts do not need to be rebuilt.
+        Fundamentally, building from scratch is attractive as it means all parts are
+        built fresh and there is no possibility of stale data causing problems.
+        When developers hit problems, they typically default back to building from scratch
+        so they know the state of things from the start.
+    </para>
+
+    <para>
+        Building an image from scratch is both an advantage and a disadvantage to the process.
+        As mentioned in the previous paragraph, building from scratch ensures that
+        everything is current and starts from a known state.
+        However, building from scratch also takes much longer as it generally means
+        rebuilding things that do not necessarily need to be rebuilt.
+    </para>
+
+    <para>
+        The Yocto Project implements shared state code that supports incremental builds.
+        The implementation of the shared state code answers the following questions that
+        were fundamental roadblocks within the OpenEmbedded incremental build support system:
+        <itemizedlist>
+            <listitem><para>What pieces of the system have changed and what pieces have
+                not changed?</para></listitem>
+            <listitem><para>How are changed pieces of software removed and replaced?</para></listitem>
+            <listitem><para>How are pre-built components that do not need to be rebuilt from scratch
+                used when they are available?</para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        For the first question, the build system detects changes in the "inputs" to a given task by
+        creating a checksum (or signature) of the task's inputs.
+        If the checksum changes, the system assumes the inputs have changed and the task needs to be
+        rerun.
+        For the second question, the shared state (sstate) code tracks which tasks add which output
+        to the build process.
+        This means the output from a given task can be removed, upgraded or otherwise manipulated.
+        The third question is partly addressed by the solution for the second question
+        assuming the build system can fetch the sstate objects from remote locations and
+        install them if they are deemed to be valid.
+    </para>
+
+    <note>
+        The OpenEmbedded build system does not maintain
+        <link linkend='var-PR'><filename>PR</filename></link> information
+        as part of the shared state packages.
+        Consequently, considerations exist that affect maintaining shared
+        state feeds.
+        For information on how the OpenEmbedded build system
+        works with packages and can
+        track incrementing <filename>PR</filename> information, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#incrementing-a-package-revision-number'>Incrementing a Package Revision Number</ulink>"
+        section.
+    </note>
+
+    <para>
+        The rest of this section goes into detail about the overall incremental build
+        architecture, the checksums (signatures), shared state, and some tips and tricks.
+    </para>
+
+    <section id='overall-architecture'>
+        <title>Overall Architecture</title>
+
+        <para>
+            When determining what parts of the system need to be built, BitBake
+            works on a per-task basis rather than a per-recipe basis.
+            You might wonder why using a per-task basis is preferred over a per-recipe basis.
+            To help explain, consider having the IPK packaging backend enabled and then switching to DEB.
+            In this case, the
+            <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+            and
+            <link linkend='ref-tasks-package'><filename>do_package</filename></link>
+            task outputs are still valid.
+            However, with a per-recipe approach, the build would not include the
+            <filename>.deb</filename> files.
+            Consequently, you would have to invalidate the whole build and rerun it.
+            Rerunning everything is not the best solution.
+            Also, in this case, the core must be "taught" much about specific tasks.
+            This methodology does not scale well and does not allow users to easily add new tasks
+            in layers or as external recipes without touching the packaged-staging core.
+        </para>
+    </section>
+
+    <section id='checksums'>
+        <title>Checksums (Signatures)</title>
+
+        <para>
+            The shared state code uses a checksum, which is a unique signature of a task's
+            inputs, to determine if a task needs to be run again.
+            Because it is a change in a task's inputs that triggers a rerun, the process
+            needs to detect all the inputs to a given task.
+            For shell tasks, this turns out to be fairly easy because
+            the build process generates a "run" shell script for each task and
+            it is possible to create a checksum that gives you a good idea of when
+            the task's data changes.
+        </para>
+
+        <para>
+            To complicate the problem, there are things that should not be included in
+            the checksum.
+            First, there is the actual specific build path of a given task -
+            the <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
+            It does not matter if the work directory changes because it should not
+            affect the output for target packages.
+            Also, the build process has the objective of making native or cross packages relocatable.
+            The checksum therefore needs to exclude <filename>WORKDIR</filename>.
+            The simplistic approach for excluding the work directory is to set
+            <filename>WORKDIR</filename> to some fixed value and create the checksum
+            for the "run" script.
+        </para>
+
+        <para>
+            Another problem results from the "run" scripts containing functions that
+            might or might not get called.
+            The incremental build solution contains code that figures out dependencies
+            between shell functions.
+            This code is used to prune the "run" scripts down to the minimum set,
+            thereby alleviating this problem and making the "run" scripts much more
+            readable as a bonus.
+        </para>
+
+        <para>
+            So far we have solutions for shell scripts.
+            What about Python tasks?
+            The same approach applies even though these tasks are more difficult.
+            The process needs to figure out what variables a Python function accesses
+            and what functions it calls.
+            Again, the incremental build solution contains code that first figures out
+            the variable and function dependencies, and then creates a checksum for the data
+            used as the input to the task.
+        </para>
+
+        <para>
+            Like the <filename>WORKDIR</filename> case, situations exist where dependencies
+            should be ignored.
+            For these cases, you can instruct the build process to ignore a dependency
+            by using a line like the following:
+            <literallayout class='monospaced'>
+     PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
+            </literallayout>
+            This example ensures that the
+            <link linkend='var-PACKAGE_ARCHS'><filename>PACKAGE_ARCHS</filename></link>
+            variable does not
+            depend on the value of
+            <link linkend='var-MACHINE'><filename>MACHINE</filename></link>,
+            even if it does reference it.
+        </para>
+
+        <para>
+            Equally, there are cases where we need to add dependencies BitBake is not able to find.
+            You can accomplish this by using a line like the following:
+            <literallayout class='monospaced'>
+      PACKAGE_ARCHS[vardeps] = "MACHINE"
+            </literallayout>
+            This example explicitly adds the <filename>MACHINE</filename> variable as a
+            dependency for <filename>PACKAGE_ARCHS</filename>.
+        </para>
+
+        <para>
+            Consider a case with in-line Python, for example, where BitBake is not
+            able to figure out dependencies.
+            When running in debug mode (i.e. using <filename>-DDD</filename>), BitBake
+            produces output when it discovers something for which it cannot figure out
+            dependencies.
+            The Yocto Project team has currently not managed to cover those dependencies
+            in detail and is aware of the need to fix this situation.
+        </para>
+
+        <para>
+            Thus far, this section has limited discussion to the direct inputs into a task.
+            Information based on direct inputs is referred to as the "basehash" in the
+            code.
+            However, there is still the question of a task's indirect inputs - the
+            things that were already built and present in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+            The checksum (or signature) for a particular task needs to add the hashes
+            of all the tasks on which the particular task depends.
+            Choosing which dependencies to add is a policy decision.
+            However, the effect is to generate a master checksum that combines the basehash
+            and the hashes of the task's dependencies.
+        </para>
+
+        <para>
+            At the code level, there are a variety of ways both the basehash and the
+            dependent task hashes can be influenced.
+            Within the BitBake configuration file, we can give BitBake some extra information
+            to help it construct the basehash.
+            The following statement effectively results in a list of global variable
+            dependency excludes - variables never included in any checksum:
+            <literallayout class='monospaced'>
+     BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \
+         SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \
+         USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \
+         PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \
+         CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"
+            </literallayout>
+            The previous example excludes
+            <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
+            since that variable is actually constructed as a path within
+            <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>, which is on
+            the whitelist.
+        </para>
+
+        <para>
+            The rules for deciding which hashes of dependent tasks to include through
+            dependency chains are more complex and are generally accomplished with a
+            Python function.
+            The code in <filename>meta/lib/oe/sstatesig.py</filename> shows two examples
+            of this and also illustrates how you can insert your own policy into the system
+            if so desired.
+            This file defines the two basic signature generators <filename>OE-Core</filename>
+            uses:  "OEBasic" and "OEBasicHash".
+            By default, there is a dummy "noop" signature handler enabled in BitBake.
+            This means that behavior is unchanged from previous versions.
+            <filename>OE-Core</filename> uses the "OEBasicHash" signature handler by default
+            through this setting in the <filename>bitbake.conf</filename> file:
+            <literallayout class='monospaced'>
+     BB_SIGNATURE_HANDLER ?= "OEBasicHash"
+            </literallayout>
+            The "OEBasicHash" <filename>BB_SIGNATURE_HANDLER</filename> is the same as the
+            "OEBasic" version but adds the task hash to the stamp files.
+            This results in any
+            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+            change that changes the task hash, automatically
+            causing the task to be run again.
+            This removes the need to bump <link linkend='var-PR'><filename>PR</filename></link>
+            values, and changes to Metadata automatically ripple across the build.
+        </para>
+
+        <para>
+            It is also worth noting that the end result of these signature generators is to
+            make some dependency and hash information available to the build.
+            This information includes:
+            <itemizedlist>
+                <listitem><para><filename>BB_BASEHASH_task-</filename><replaceable>taskname</replaceable>:
+                    The base hashes for each task in the recipe.
+                    </para></listitem>
+                <listitem><para><filename>BB_BASEHASH_</filename><replaceable>filename</replaceable><filename>:</filename><replaceable>taskname</replaceable>:
+                    The base hashes for each dependent task.
+                    </para></listitem>
+                <listitem><para><filename>BBHASHDEPS_</filename><replaceable>filename</replaceable><filename>:</filename><replaceable>taskname</replaceable>:
+                    The task dependencies for each task.
+                    </para></listitem>
+                <listitem><para><filename>BB_TASKHASH</filename>:
+                    The hash of the currently running task.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='shared-state'>
+        <title>Shared State</title>
+
+        <para>
+            Checksums and dependencies, as discussed in the previous section, solve half the
+            problem of supporting a shared state.
+            The other part of the problem is being able to use checksum information during the build
+            and being able to reuse or rebuild specific components.
+        </para>
+
+        <para>
+            The
+            <link linkend='ref-classes-sstate'><filename>sstate</filename></link>
+            class is a relatively generic implementation of how to "capture"
+            a snapshot of a given task.
+            The idea is that the build process does not care about the source of a task's output.
+            Output could be freshly built or it could be downloaded and unpacked from
+            somewhere - the build process does not need to worry about its origin.
+        </para>
+
+        <para>
+            There are two types of output, one is just about creating a directory
+            in <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
+            A good example is the output of either
+            <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+            or
+            <link linkend='ref-tasks-package'><filename>do_package</filename></link>.
+            The other type of output occurs when a set of data is merged into a shared directory
+            tree such as the sysroot.
+        </para>
+
+        <para>
+            The Yocto Project team has tried to keep the details of the
+            implementation hidden in <filename>sstate</filename> class.
+            From a user's perspective, adding shared state wrapping to a task
+            is as simple as this
+            <link linkend='ref-tasks-deploy'><filename>do_deploy</filename></link>
+            example taken from the
+            <link linkend='ref-classes-deploy'><filename>deploy</filename></link>
+            class:
+            <literallayout class='monospaced'>
+     DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
+     SSTATETASKS += "do_deploy"
+     do_deploy[sstate-name] = "deploy"
+     do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
+     do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
+
+     python do_deploy_setscene () {
+         sstate_setscene(d)
+     }
+     addtask do_deploy_setscene
+     do_deploy[dirs] = "${DEPLOYDIR} ${B}"
+            </literallayout>
+            In this example, we add some extra flags to the task, a name field ("deploy"), an
+            input directory where the task sends data, and the output
+            directory where the data from the task should eventually be copied.
+            We also add a <filename>_setscene</filename> variant of the task and add the task
+            name to the <filename>SSTATETASKS</filename> list.
+        </para>
+
+        <para>
+            If you have a directory whose contents you need to preserve, you can do this with
+            a line like the following:
+            <literallayout class='monospaced'>
+     do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
+            </literallayout>
+            This method, as well as the following example, also works for multiple directories.
+            <literallayout class='monospaced'>
+     do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
+     do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
+     do_package[sstate-lockfile] = "${PACKAGELOCK}"
+            </literallayout>
+            These methods also include the ability to take a lockfile when manipulating
+            shared state directory structures since some cases are sensitive to file
+            additions or removals.
+        </para>
+
+        <para>
+            Behind the scenes, the shared state code works by looking in
+            <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link> and
+            <link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>
+            for shared state files.
+            Here is an example:
+            <literallayout class='monospaced'>
+     SSTATE_MIRRORS ?= "\
+     file://.* http://someserver.tld/share/sstate/PATH \n \
+     file://.* file:///some/local/dir/sstate/PATH"
+            </literallayout>
+            <note>
+                The shared state directory (<filename>SSTATE_DIR</filename>) is
+                organized into two-character subdirectories, where the subdirectory
+                names are based on the first two characters of the hash.
+                If the shared state directory structure for a mirror has the
+                same structure as <filename>SSTATE_DIR</filename>, you must
+                specify "PATH" as part of the URI to enable the build system
+                to map to the appropriate subdirectory.
+            </note>
+        </para>
+
+        <para>
+            The shared state package validity can be detected just by looking at the
+            filename since the filename contains the task checksum (or signature) as
+            described earlier in this section.
+            If a valid shared state package is found, the build process downloads it
+            and uses it to accelerate the task.
+        </para>
+
+        <para>
+            The build processes use the <filename>*_setscene</filename> tasks
+            for the task acceleration phase.
+            BitBake goes through this phase before the main execution code and tries
+            to accelerate any tasks for which it can find shared state packages.
+            If a shared state package for a task is available, the shared state
+            package is used.
+            This means the task and any tasks on which it is dependent are not
+            executed.
+        </para>
+
+        <para>
+            As a real world example, the aim is when building an IPK-based image,
+            only the
+            <link linkend='ref-tasks-package_write_ipk'><filename>do_package_write_ipk</filename></link>
+            tasks would have their
+            shared state packages fetched and extracted.
+            Since the sysroot is not used, it would never get extracted.
+            This is another reason why a task-based approach is preferred over a
+            recipe-based approach, which would have to install the output from every task.
+        </para>
+    </section>
+
+    <section id='tips-and-tricks'>
+        <title>Tips and Tricks</title>
+
+        <para>
+            The code in the build system that supports incremental builds is not
+            simple code.
+            This section presents some tips and tricks that help you work around
+            issues related to shared state code.
+        </para>
+
+        <section id='debugging'>
+            <title>Debugging</title>
+
+            <para>
+                When things go wrong, debugging needs to be straightforward.
+                Because of this, the Yocto Project includes strong debugging
+                tools:
+                <itemizedlist>
+                    <listitem><para>Whenever a shared state package is written out, so is a
+                        corresponding <filename>.siginfo</filename> file.
+                        This practice results in a pickled Python database of all
+                        the metadata that went into creating the hash for a given shared state
+                        package.</para></listitem>
+                    <listitem><para>If you run BitBake with the <filename>--dump-signatures</filename>
+                        (or <filename>-S</filename>) option, BitBake dumps out
+                        <filename>.siginfo</filename> files in
+                        the stamp directory for every task it would have executed instead of
+                        building the specified target package.</para></listitem>
+                    <listitem><para>There is a <filename>bitbake-diffsigs</filename> command that
+                        can process <filename>.siginfo</filename> files.
+                        If you specify one of these files, BitBake dumps out the dependency
+                        information in the file.
+                        If you specify two files, BitBake compares the two files and dumps out
+                        the differences between the two.
+                        This more easily helps answer the question of "What
+                        changed between X and Y?"</para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='invalidating-shared-state'>
+            <title>Invalidating Shared State</title>
+
+            <para>
+                The OpenEmbedded build system uses checksums and shared state
+                cache to avoid unnecessarily rebuilding tasks.
+                Collectively, this scheme is known as "shared state code."
+            </para>
+
+            <para>
+                As with all schemes, this one has some drawbacks.
+                It is possible that you could make implicit changes to your
+                code that the checksum calculations do not take into
+                account.
+                These implicit changes affect a task's output but do not trigger
+                the shared state code into rebuilding a recipe.
+                Consider an example during which a tool changes its output.
+                Assume that the output of <filename>rpmdeps</filename> changes.
+                The result of the change should be that all the
+                <filename>package</filename> and
+                <filename>package_write_rpm</filename> shared state cache
+                items become invalid.
+                However, because the change to the output is
+                external to the code and therefore implicit,
+                the associated shared state cache items do not become
+                invalidated.
+                In this case, the build process uses the cached items rather
+                than running the task again.
+                Obviously, these types of implicit changes can cause problems.
+            </para>
+
+            <para>
+                To avoid these problems during the build, you need to
+                understand the effects of any changes you make.
+                Realize that changes you make directly to a function
+                are automatically factored into the checksum calculation.
+                Thus, these explicit changes invalidate the associated area of
+                shared state cache.
+                However, you need to be aware of any implicit changes that
+                are not obvious changes to the code and could affect the output
+                of a given task.
+            </para>
+
+            <para>
+                When you identify an implicit change, you can easily take steps
+                to invalidate the cache and force the tasks to run.
+                The steps you can take are as simple as changing a function's
+                comments in the source code.
+                For example, to invalidate package shared state files, change
+                the comment statements of
+                <link linkend='ref-tasks-package'><filename>do_package</filename></link>
+                or the comments of one of the functions it calls.
+                Even though the change is purely cosmetic, it causes the
+                checksum to be recalculated and forces the OpenEmbedded build
+                system to run the task again.
+            </para>
+
+            <note>
+                For an example of a commit that makes a cosmetic change to
+                invalidate shared state, see this
+                <ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54'>commit</ulink>.
+            </note>
+        </section>
+    </section>
+</section>
+
+<section id='x32'>
+    <title>x32</title>
+
+    <para>
+        x32 is a processor-specific Application Binary Interface (psABI) for x86_64.
+        An ABI defines the calling conventions between functions in a processing environment.
+        The interface determines what registers are used and what the sizes are for various C data types.
+    </para>
+
+    <para>
+        Some processing environments prefer using 32-bit applications even when running
+        on Intel 64-bit platforms.
+        Consider the i386 psABI, which is a very old 32-bit ABI for Intel 64-bit platforms.
+        The i386 psABI does not provide efficient use and access of the Intel 64-bit processor resources,
+        leaving the system underutilized.
+        Now consider the x86_64 psABI.
+        This ABI is newer and uses 64-bits for data sizes and program pointers.
+        The extra bits increase the footprint size of the programs, libraries,
+        and also increases the memory and file system size requirements.
+        Executing under the x32 psABI enables user programs to utilize CPU and system resources
+        more efficiently while keeping the memory footprint of the applications low.
+        Extra bits are used for registers but not for addressing mechanisms.
+    </para>
+
+    <section id='support'>
+        <title>Support</title>
+
+        <para>
+            This Yocto Project release supports the final specifications of x32
+            psABI.
+            Support for x32 psABI exists as follows:
+            <itemizedlist>
+                <listitem><para>You can create packages and images in x32 psABI format on x86_64 architecture targets.
+                    </para></listitem>
+                <listitem><para>You can successfully build many recipes with the x32 toolchain.</para></listitem>
+                <listitem><para>You can create and boot <filename>core-image-minimal</filename> and
+                    <filename>core-image-sato</filename> images.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='completing-x32'>
+        <title>Completing x32</title>
+
+        <para>
+            Future Plans for the x32 psABI in the Yocto Project include the following:
+            <itemizedlist>
+                <listitem><para>Enhance and fix the few remaining recipes so they
+                    work with and support x32 toolchains.</para></listitem>
+                <listitem><para>Enhance RPM Package Manager (RPM) support for x32 binaries.</para></listitem>
+                <listitem><para>Support larger images.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='using-x32-right-now'>
+        <title>Using x32 Right Now</title>
+
+        <para>
+            Follow these steps to use the x32 spABI:
+            <itemizedlist>
+                <listitem><para>Enable the x32 psABI tuning file for <filename>x86_64</filename>
+                    machines by editing the <filename>conf/local.conf</filename> like this:
+                    <literallayout class='monospaced'>
+      MACHINE = "qemux86-64"
+      DEFAULTTUNE = "x86-64-x32"
+      baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE', True) \
+         or 'INVALID'), True) or 'lib'}"
+      #MACHINE = "genericx86"
+      #DEFAULTTUNE = "core2-64-x32"
+                    </literallayout></para></listitem>
+                <listitem><para>As usual, use BitBake to build an image that supports the x32 psABI.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     $ bitbake core-image-sato
+                    </literallayout></para></listitem>
+                <listitem><para>As usual, run your image using QEMU:
+                    <literallayout class='monospaced'>
+     $ runqemu qemux86-64 core-image-sato
+                    </literallayout></para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
+
+<section id="wayland">
+    <title>Wayland</title>
+
+    <para>
+        <ulink url='http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)'>Wayland</ulink>
+        is a computer display server protocol that
+        provides a method for compositing window managers to communicate
+        directly with applications and video hardware and expects them to
+        communicate with input hardware using other libraries.
+        Using Wayland with supporting targets can result in better control
+        over graphics frame rendering than an application might otherwise
+        achieve.
+    </para>
+
+    <para>
+        The Yocto Project provides the Wayland protocol libraries and the
+        reference
+        <ulink url='http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Weston'>Weston</ulink>
+        compositor as part of its release.
+        This section describes what you need to do to implement Wayland and
+        use the compositor when building an image for a supporting target.
+    </para>
+
+    <section id="wayland-support">
+        <title>Support</title>
+
+        <para>
+            The Wayland protocol libraries and the reference Weston compositor
+            ship as integrated packages in the <filename>meta</filename> layer
+            of the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            Specifically, you can find the recipes that build both Wayland
+            and Weston at <filename>meta/recipes-graphics/wayland</filename>.
+        </para>
+
+        <para>
+            You can build both the Wayland and Weston packages for use only
+            with targets that accept the
+            <ulink url='http://dri.freedesktop.org/wiki/'>Mesa 3D and Direct Rendering Infrastructure</ulink>,
+            which is also known as Mesa DRI.
+            This implies that you cannot build and use the packages if your
+            target uses, for example, the
+            <trademark class='registered'>Intel</trademark> Embedded Media and
+            Graphics Driver (<trademark class='registered'>Intel</trademark>
+            EMGD) that overrides Mesa DRI.
+        </para>
+
+        <note>
+            Due to lack of EGL support, Weston 1.0.3 will not run directly on
+            the emulated QEMU hardware.
+            However, this version of Weston will run under X emulation without
+            issues.
+        </note>
+    </section>
+
+    <section id="enabling-wayland-in-an-image">
+        <title>Enabling Wayland in an Image</title>
+
+        <para>
+            To enable Wayland, you need to enable it to be built and enable
+            it to be included in the image.
+        </para>
+
+        <section id="enable-building">
+            <title>Building</title>
+
+            <para>
+                To cause Mesa to build the <filename>wayland-egl</filename>
+                platform and Weston to build Wayland with Kernel Mode
+                Setting
+                (<ulink url='https://wiki.archlinux.org/index.php/Kernel_Mode_Setting'>KMS</ulink>)
+                support, include the "wayland" flag in the
+                <link linkend="var-DISTRO_FEATURES"><filename>DISTRO_FEATURES</filename></link>
+                statement in your <filename>local.conf</filename> file:
+                <literallayout class='monospaced'>
+     DISTRO_FEATURES_append = " wayland"
+                </literallayout>
+            </para>
+
+            <note>
+                If X11 has been enabled elsewhere, Weston will build Wayland
+                with X11 support
+            </note>
+        </section>
+
+        <section id="enable-installation-in-an-image">
+            <title>Installing</title>
+
+            <para>
+                To install the Wayland feature into an image, you must
+                include the following
+                <link linkend='var-CORE_IMAGE_EXTRA_INSTALL'><filename>CORE_IMAGE_EXTRA_INSTALL</filename></link>
+                statement in your <filename>local.conf</filename> file:
+                <literallayout class='monospaced'>
+     CORE_IMAGE_EXTRA_INSTALL += "wayland weston"
+                </literallayout>
+            </para>
+        </section>
+    </section>
+
+    <section id="running-weston">
+        <title>Running Weston</title>
+
+        <para>
+            To run Weston inside X11, enabling it as described earlier and
+            building a Sato image is sufficient.
+            If you are running your image under Sato, a Weston Launcher appears
+            in the "Utility" category.
+        </para>
+
+        <para>
+            Alternatively, you can run Weston through the command-line
+            interpretor (CLI), which is better suited for development work.
+            To run Weston under the CLI, you need to do the following after
+            your image is built:
+            <orderedlist>
+                <listitem><para>Run these commands to export
+                    <filename>XDG_RUNTIME_DIR</filename>:
+                    <literallayout class='monospaced'>
+     mkdir -p /tmp/$USER-weston
+     chmod 0700 /tmp/$USER-weston
+     export XDG_RUNTIME_DIR=/tmp/$USER-weston
+                    </literallayout></para></listitem>
+                <listitem><para>Launch Weston in the shell:
+                    <literallayout class='monospaced'>
+     weston
+                    </literallayout></para></listitem>
+            </orderedlist>
+        </para>
+    </section>
+</section>
+
+<section id="licenses">
+    <title>Licenses</title>
+
+    <para>
+        This section describes the mechanism by which the OpenEmbedded build system
+        tracks changes to licensing text.
+        The section also describes how to enable commercially licensed recipes,
+        which by default are disabled.
+    </para>
+
+    <para>
+        For information that can help you maintain compliance with various open
+        source licensing during the lifecycle of the product, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Project's Lifecycle</ulink>" section
+        in the Yocto Project Development Manual.
+    </para>
+
+    <section id="usingpoky-configuring-LIC_FILES_CHKSUM">
+        <title>Tracking License Changes</title>
+
+        <para>
+            The license of an upstream project might change in the future.
+            In order to prevent these changes going unnoticed, the
+            <filename><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link></filename>
+            variable tracks changes to the license text. The checksums are validated at the end of the
+            configure step, and if the checksums do not match, the build will fail.
+        </para>
+
+        <section id="usingpoky-specifying-LIC_FILES_CHKSUM">
+            <title>Specifying the <filename>LIC_FILES_CHKSUM</filename> Variable</title>
+
+            <para>
+                The <filename>LIC_FILES_CHKSUM</filename>
+                variable contains checksums of the license text in the source code for the recipe.
+                Following is an example of how to specify <filename>LIC_FILES_CHKSUM</filename>:
+                <literallayout class='monospaced'>
+     LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
+                         file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
+                         file://licfile2.txt;endline=50;md5=zzzz \
+                         ..."
+                </literallayout>
+            </para>
+
+            <para>
+                The build system uses the
+                <filename><link linkend='var-S'>S</link></filename> variable as
+                the default directory when searching files listed in
+                <filename>LIC_FILES_CHKSUM</filename>.
+                The previous example employs the default directory.
+            </para>
+
+            <para>
+                Consider this next example:
+                <literallayout class='monospaced'>
+     LIC_FILES_CHKSUM = "file://src/ls.c;beginline=5;endline=16;\
+                                         md5=bb14ed3c4cda583abc85401304b5cd4e"
+     LIC_FILES_CHKSUM = "file://${WORKDIR}/license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
+                </literallayout>
+            </para>
+
+            <para>
+                The first line locates a file in
+                <filename>${S}/src/ls.c</filename>.
+                The second line refers to a file in
+                <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>.
+            </para>
+            <para>
+                Note that <filename>LIC_FILES_CHKSUM</filename> variable is
+                mandatory for all recipes, unless the
+                <filename>LICENSE</filename> variable is set to "CLOSED".
+            </para>
+        </section>
+
+        <section id="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax">
+            <title>Explanation of Syntax</title>
+            <para>
+                As mentioned in the previous section, the
+                <filename>LIC_FILES_CHKSUM</filename> variable lists all the
+                important files that contain the license text for the source code.
+                It is possible to specify a checksum for an entire file, or a specific section of a
+                file (specified by beginning and ending line numbers with the "beginline" and "endline"
+                parameters, respectively).
+                The latter is useful for source files with a license notice header,
+                README documents, and so forth.
+                If you do not use the "beginline" parameter, then it is assumed that the text begins on the
+                first line of the file.
+                Similarly, if you do not use the "endline" parameter, it is assumed that the license text
+                ends with the last line of the file.
+            </para>
+
+            <para>
+                The "md5" parameter stores the md5 checksum of the license text.
+                If the license text changes in any way as compared to this parameter
+                then a mismatch occurs.
+                This mismatch triggers a build failure and notifies the developer.
+                Notification allows the developer to review and address the license text changes.
+                Also note that if a mismatch occurs during the build, the correct md5
+                checksum is placed in the build log and can be easily copied to the recipe.
+            </para>
+
+            <para>
+                There is no limit to how many files you can specify using the
+                <filename>LIC_FILES_CHKSUM</filename> variable.
+                Generally, however, every project requires a few specifications for license tracking.
+                Many projects have a "COPYING" file that stores the license information for all the source
+                code files.
+                This practice allows you to just track the "COPYING" file as long as it is kept up to date.
+            </para>
+
+            <tip>
+                If you specify an empty or invalid "md5" parameter, BitBake returns an md5 mis-match
+                error and displays the correct "md5" parameter value during the build.
+                The correct parameter is also captured in the build log.
+            </tip>
+
+            <tip>
+                If the whole file contains only license text, you do not need to use the "beginline" and
+                "endline" parameters.
+            </tip>
+        </section>
+    </section>
+
+    <section id="enabling-commercially-licensed-recipes">
+        <title>Enabling Commercially Licensed Recipes</title>
+
+        <para>
+            By default, the OpenEmbedded build system disables
+            components that have commercial or other special licensing
+            requirements.
+            Such requirements are defined on a
+            recipe-by-recipe basis through the
+            <link linkend='var-LICENSE_FLAGS'><filename>LICENSE_FLAGS</filename></link>
+            variable definition in the affected recipe.
+            For instance, the
+            <filename>poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</filename>
+            recipe contains the following statement:
+            <literallayout class='monospaced'>
+     LICENSE_FLAGS = "commercial"
+            </literallayout>
+            Here is a slightly more complicated example that contains both an
+            explicit recipe name and version (after variable expansion):
+            <literallayout class='monospaced'>
+     LICENSE_FLAGS = "license_${PN}_${PV}"
+            </literallayout>
+                In order for a component restricted by a <filename>LICENSE_FLAGS</filename>
+                definition to be enabled and included in an image, it
+                needs to have a matching entry in the global
+                <link linkend='var-LICENSE_FLAGS_WHITELIST'><filename>LICENSE_FLAGS_WHITELIST</filename></link>
+            variable, which is a variable
+                typically defined in your <filename>local.conf</filename> file.
+            For example, to enable
+                the <filename>poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</filename>
+                package, you could add either the string
+                "commercial_gst-plugins-ugly" or the more general string
+                "commercial" to <filename>LICENSE_FLAGS_WHITELIST</filename>.
+            See the
+            "<link linkend='license-flag-matching'>License Flag Matching</link>" section
+            for a full explanation of how <filename>LICENSE_FLAGS</filename> matching works.
+            Here is the example:
+            <literallayout class='monospaced'>
+     LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly"
+            </literallayout>
+                Likewise, to additionally enable the package built from the recipe containing
+                <filename>LICENSE_FLAGS = "license_${PN}_${PV}"</filename>, and assuming
+                that the actual recipe name was <filename>emgd_1.10.bb</filename>,
+                the following string would enable that package as well as
+                the original <filename>gst-plugins-ugly</filename> package:
+            <literallayout class='monospaced'>
+     LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10"
+            </literallayout>
+                As a convenience, you do not need to specify the complete license string
+                in the whitelist for every package.
+            You can use an abbreviated form, which consists
+                of just the first portion or portions of the license string before
+                the initial underscore character or characters.
+            A partial string will match
+                any license that contains the given string as the first
+                portion of its license.
+            For example, the following
+                whitelist string will also match both of the packages
+                previously mentioned as well as any other packages that have
+                licenses starting with "commercial" or "license".
+            <literallayout class='monospaced'>
+     LICENSE_FLAGS_WHITELIST = "commercial license"
+            </literallayout>
+        </para>
+
+        <section id="license-flag-matching">
+            <title>License Flag Matching</title>
+
+            <para>
+                        License flag matching allows you to control what recipes the
+                OpenEmbedded build system includes in the build.
+                Fundamentally, the build system attempts to match
+                <link linkend='var-LICENSE_FLAGS'><filename>LICENSE_FLAGS</filename></link>
+                strings found in recipes against
+                <link linkend='var-LICENSE_FLAGS_WHITELIST'><filename>LICENSE_FLAGS_WHITELIST</filename></link>
+                strings found in the whitelist.
+                A match causes the build system to include a recipe in the
+                build, while failure to find a match causes the build system to
+                exclude a recipe.
+            </para>
+
+            <para>
+                In general, license flag matching is simple.
+                However, understanding some concepts will help you
+                correctly and effectively use matching.
+            </para>
+
+            <para>
+                Before a flag
+                defined by a particular recipe is tested against the
+                contents of the whitelist, the expanded string
+                <filename>_${PN}</filename> is appended to the flag.
+                This expansion makes each <filename>LICENSE_FLAGS</filename>
+                value recipe-specific.
+                After expansion, the string is then matched against the
+                whitelist.
+                Thus, specifying
+                <filename>LICENSE_FLAGS = "commercial"</filename>
+                in recipe "foo", for example, results in the string
+                <filename>"commercial_foo"</filename>.
+                And, to create a match, that string must appear in the
+                whitelist.
+            </para>
+
+            <para>
+                Judicious use of the <filename>LICENSE_FLAGS</filename>
+                strings and the contents of the
+                <filename>LICENSE_FLAGS_WHITELIST</filename> variable
+                allows you a lot of flexibility for including or excluding
+                recipes based on licensing.
+                For example, you can broaden the matching capabilities by
+                using license flags string subsets in the whitelist.
+                <note>When using a string subset, be sure to use the part of
+                    the expanded string that precedes the appended underscore
+                    character (e.g. <filename>usethispart_1.3</filename>,
+                    <filename>usethispart_1.4</filename>, and so forth).
+                </note>
+                For example, simply specifying the string "commercial" in
+                the whitelist matches any expanded
+                <filename>LICENSE_FLAGS</filename> definition that starts with
+                the string "commercial" such as "commercial_foo" and
+                "commercial_bar", which are the strings the build system
+                automatically generates for hypothetical recipes named
+                "foo" and "bar" assuming those recipes simply specify the
+                following:
+                <literallayout class='monospaced'>
+     LICENSE_FLAGS = "commercial"
+                </literallayout>
+                Thus, you can choose to exhaustively
+                enumerate each license flag in the whitelist and
+                allow only specific recipes into the image, or
+                you can use a string subset that causes a broader range of
+                matches to allow a range of recipes into the image.
+            </para>
+
+            <para>
+                This scheme works even if the
+                <filename>LICENSE_FLAGS</filename> string already
+                has <filename>_${PN}</filename> appended.
+                For example, the build system turns the license flag
+                "commercial_1.2_foo" into "commercial_1.2_foo_foo" and would
+                match both the general "commercial" and the specific
+                "commercial_1.2_foo" strings found in the whitelist, as
+                expected.
+            </para>
+
+            <para>
+                Here are some other scenarios:
+                <itemizedlist>
+                    <listitem><para>You can specify a versioned string in the
+                        recipe such as "commercial_foo_1.2" in a "foo" recipe.
+                        The build system expands this string to
+                        "commercial_foo_1.2_foo".
+                        Combine this license flag with a whitelist that has
+                        the string "commercial" and you match the flag along
+                        with any other flag that starts with the string
+                        "commercial".</para></listitem>
+                    <listitem><para>Under the same circumstances, you can
+                        use "commercial_foo" in the whitelist and the
+                        build system not only matches "commercial_foo_1.2" but
+                        also matches any license flag with the string
+                        "commercial_foo", regardless of the version.
+                        </para></listitem>
+                    <listitem><para>You can be very specific and use both the
+                        package and version parts in the whitelist (e.g.
+                        "commercial_foo_1.2") to specifically match a
+                        versioned recipe.</para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id="other-variables-related-to-commercial-licenses">
+            <title>Other Variables Related to Commercial Licenses</title>
+
+            <para>
+                Other helpful variables related to commercial
+                license handling exist and are defined in the
+                <filename>poky/meta/conf/distro/include/default-distrovars.inc</filename> file:
+                <literallayout class='monospaced'>
+     COMMERCIAL_AUDIO_PLUGINS ?= ""
+     COMMERCIAL_VIDEO_PLUGINS ?= ""
+     COMMERCIAL_QT = ""
+                </literallayout>
+                If you want to enable these components, you can do so by making sure you have
+                statements similar to the following
+                in your <filename>local.conf</filename> configuration file:
+                <literallayout class='monospaced'>
+     COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad \
+        gst-plugins-ugly-mpegaudioparse"
+     COMMERCIAL_VIDEO_PLUGINS = "gst-plugins-ugly-mpeg2dec \
+        gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"
+     COMMERCIAL_QT ?= "qmmp"
+     LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp"
+                </literallayout>
+                Of course, you could also create a matching whitelist
+                for those components using the more general "commercial"
+                in the whitelist, but that would also enable all the
+                other packages with
+                <link linkend='var-LICENSE_FLAGS'><filename>LICENSE_FLAGS</filename></link>
+                containing "commercial", which you may or may not want:
+                <literallayout class='monospaced'>
+     LICENSE_FLAGS_WHITELIST = "commercial"
+                </literallayout>
+            </para>
+
+            <para>
+                Specifying audio and video plug-ins as part of the
+                <filename>COMMERCIAL_AUDIO_PLUGINS</filename> and
+                <filename>COMMERCIAL_VIDEO_PLUGINS</filename> statements
+                or commercial Qt components as part of
+                the <filename>COMMERCIAL_QT</filename> statement (along
+                with the enabling <filename>LICENSE_FLAGS_WHITELIST</filename>) includes the
+                plug-ins or components into built images, thus adding
+                support for media formats or components.
+            </para>
+        </section>
+    </section>
+</section>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/usingpoky.xml b/documentation/ref-manual/usingpoky.xml
new file mode 100644
index 0000000000..2116852163
--- /dev/null
+++ b/documentation/ref-manual/usingpoky.xml
@@ -0,0 +1,915 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='usingpoky'>
+<title>Using the Yocto Project</title>
+
+    <para>
+        This chapter describes common usage for the Yocto Project.
+        The information is introductory in nature as other manuals in the Yocto Project
+        documentation set provide more details on how to use the Yocto Project.
+    </para>
+
+<section id='usingpoky-build'>
+    <title>Running a Build</title>
+
+    <para>
+        This section provides a summary of the build process and provides information
+        for less obvious aspects of the build process.
+        For general information on how to build an image using the OpenEmbedded build
+        system, see the
+        "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>"
+        section of the Yocto Project Quick Start.
+    </para>
+
+    <section id='build-overview'>
+        <title>Build Overview</title>
+
+        <para>
+            The first thing you need to do is set up the OpenEmbedded build
+            environment by sourcing an environment setup script
+            (i.e.
+            <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+            or
+            <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
+            Here is an example:
+            <literallayout class='monospaced'>
+     $ source &OE_INIT_FILE; [<replaceable>build_dir</replaceable>]
+            </literallayout>
+        </para>
+
+        <para>
+            The <replaceable>build_dir</replaceable> argument is optional and specifies the directory the
+            OpenEmbedded build system uses for the build -
+            the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+            If you do not specify a Build Directory, it defaults to a directory
+            named <filename>build</filename> in your current working directory.
+            A common practice is to use a different Build Directory for different targets.
+            For example, <filename>~/build/x86</filename> for a <filename>qemux86</filename>
+            target, and <filename>~/build/arm</filename> for a <filename>qemuarm</filename> target.
+        </para>
+
+        <para>
+            Once the build environment is set up, you can build a target using:
+            <literallayout class='monospaced'>
+     $ bitbake <replaceable>target</replaceable>
+            </literallayout>
+        </para>
+
+        <para>
+            The <replaceable>target</replaceable> is the name of the recipe you want to build.
+            Common targets are the images in <filename>meta/recipes-core/images</filename>,
+            <filename>meta/recipes-sato/images</filename>, etc. all found in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            Or, the target can be the name of a recipe for a specific piece of software such as
+            BusyBox.
+            For more details about the images the OpenEmbedded build system supports, see the
+            "<link linkend="ref-images">Images</link>" chapter.
+        </para>
+
+        <note>
+            Building an image without GNU General Public License Version
+            3 (GPLv3), or similarly licensed, components is supported for
+            only minimal and base images.
+            See the "<link linkend='ref-images'>Images</link>" chapter for more information.
+        </note>
+    </section>
+
+    <section id='building-an-image-using-gpl-components'>
+        <title>Building an Image Using GPL Components</title>
+
+        <para>
+            When building an image using GPL components, you need to maintain your original
+            settings and not switch back and forth applying different versions of the GNU
+            General Public License.
+            If you rebuild using different versions of GPL, dependency errors might occur
+            due to some components not being rebuilt.
+        </para>
+    </section>
+</section>
+
+<section id='usingpoky-install'>
+    <title>Installing and Using the Result</title>
+
+    <para>
+        Once an image has been built, it often needs to be installed.
+        The images and kernels built by the OpenEmbedded build system are placed in the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink> in
+        <filename class="directory">tmp/deploy/images</filename>.
+        For information on how to run pre-built images such as <filename>qemux86</filename>
+        and <filename>qemuarm</filename>, see the
+        "<ulink url='&YOCTO_DOCS_QS_URL;#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
+        section in the Yocto Project Quick Start.
+        For information about how to install these images, see the documentation for your
+        particular board or machine.
+    </para>
+</section>
+
+<section id='usingpoky-debugging'>
+    <title>Debugging Build Failures</title>
+
+    <para>
+        The exact method for debugging build failures depends on the nature of
+        the problem and on the system's area from which the bug originates.
+        Standard debugging practices such as comparison against the last
+        known working version with examination of the changes and the
+        re-application of steps to identify the one causing the problem are
+        valid for the Yocto Project just as they are for any other system.
+        Even though it is impossible to detail every possible potential failure,
+        this section provides some general tips to aid in debugging.
+    </para>
+
+    <para>
+        A useful feature for debugging is the error reporting tool.
+        Configuring the Yocto Project to use this tool causes the
+        OpenEmbedded build system to produce error reporting commands as
+        part of the console output.
+        You can enter the commands after the build completes
+        to log error information
+        into a common database, that can help you figure out what might be
+        going wrong.
+        For information on how to enable and use this feature, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#using-the-error-reporting-tool'>Using the Error Reporting Tool</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+
+    <para>
+        For discussions on debugging, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug'>Debugging With the GNU Project Debugger (GDB) Remotely</ulink>"
+        and
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#adt-eclipse'>Working within Eclipse</ulink>"
+        sections in the Yocto Project Development Manual.
+    </para>
+
+    <note>
+        The remainder of this section presents many examples of the
+        <filename>bitbake</filename> command.
+        You can learn about BitBake by reading the
+        <ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual'>BitBake User Manual</ulink>.
+    </note>
+
+
+    <section id='usingpoky-debugging-taskfailures'>
+        <title>Task Failures</title>
+
+        <para>The log file for shell tasks is available in
+            <filename>${WORKDIR}/temp/log.do_<replaceable>taskname</replaceable>.pid</filename>.
+            For example, the <filename>do_compile</filename> task for the QEMU minimal image for the x86
+            machine (<filename>qemux86</filename>) might be
+            <filename>tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_compile.20830</filename>.
+            To see what
+            <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>
+            runs to generate that log, look at the corresponding
+            <filename>run.do_<replaceable>taskname</replaceable>.pid</filename> file located in the same directory.
+        </para>
+
+        <para>
+            Presently, the output from Python tasks is sent directly to the console.
+        </para>
+    </section>
+
+    <section id='usingpoky-debugging-taskrunning'>
+        <title>Running Specific Tasks</title>
+
+        <para>
+            Any given package consists of a set of tasks.
+            The standard BitBake behavior in most cases is:
+            <filename>do_fetch</filename>,
+            <filename>do_unpack</filename>,
+            <filename>do_patch</filename>, <filename>do_configure</filename>,
+            <filename>do_compile</filename>, <filename>do_install</filename>,
+            <filename>do_package</filename>,
+            <filename>do_package_write_*</filename>, and
+            <filename>do_build</filename>.
+            The default task is <filename>do_build</filename> and any tasks
+            on which it depends build first.
+            Some tasks, such as <filename>do_devshell</filename>, are not part
+            of the default build chain.
+            If you wish to run a task that is not part of the default build
+            chain, you can use the <filename>-c</filename> option in BitBake.
+            Here is an example:
+            <literallayout class='monospaced'>
+     $ bitbake matchbox-desktop -c devshell
+            </literallayout>
+        </para>
+
+        <para>
+            If you wish to rerun a task, use the <filename>-f</filename> force
+            option.
+            For example, the following sequence forces recompilation after
+            changing files in the work directory.
+            <literallayout class='monospaced'>
+     $ bitbake matchbox-desktop
+               .
+               .
+        <replaceable>make some changes to the source code in the work directory</replaceable>
+               .
+               .
+     $ bitbake matchbox-desktop -c compile -f
+     $ bitbake matchbox-desktop
+            </literallayout>
+        </para>
+
+        <para>
+            This sequence first builds and then recompiles
+            <filename>matchbox-desktop</filename>.
+            The last command reruns all tasks (basically the packaging tasks)
+            after the compile.
+            BitBake recognizes that the <filename>do_compile</filename>
+            task was rerun and therefore understands that the other tasks
+            also need to be run again.
+        </para>
+
+        <para>
+            You can view a list of tasks in a given package by running the
+            <filename>do_listtasks</filename> task as follows:
+            <literallayout class='monospaced'>
+     $ bitbake matchbox-desktop -c listtasks
+            </literallayout>
+            The results appear as output to the console and are also in the
+            file <filename>${WORKDIR}/temp/log.do_listtasks</filename>.
+        </para>
+    </section>
+
+    <section id='usingpoky-debugging-dependencies'>
+        <title>Dependency Graphs</title>
+
+        <para>
+            Sometimes it can be hard to see why BitBake wants to build
+            other packages before building a given package you have specified.
+            The <filename>bitbake -g <replaceable>targetname</replaceable></filename> command
+            creates the <filename>pn-buildlist</filename>,
+            <filename>pn-depends.dot</filename>,
+            <filename>package-depends.dot</filename>, and
+            <filename>task-depends.dot</filename> files in the current
+            directory.
+            These files show what will be built and the package and task
+            dependencies, which are useful for debugging problems.
+            You can use the
+            <filename>bitbake -g -u depexp <replaceable>targetname</replaceable></filename>
+            command to display the results in a more human-readable form.
+        </para>
+    </section>
+
+    <section id='usingpoky-debugging-bitbake'>
+        <title>General BitBake Problems</title>
+
+        <para>
+            You can see debug output from BitBake by using the <filename>-D</filename> option.
+            The debug output gives more information about what BitBake
+            is doing and the reason behind it.
+            Each <filename>-D</filename> option you use increases the logging level.
+            The most common usage is <filename>-DDD</filename>.
+        </para>
+
+        <para>
+            The output from <filename>bitbake -DDD -v</filename> <replaceable>targetname</replaceable> can reveal why
+            BitBake chose a certain version of a package or why BitBake
+            picked a certain provider.
+            This command could also help you in a situation where you think BitBake did something
+            unexpected.
+        </para>
+    </section>
+
+    <section id='development-host-system-issues'>
+        <title>Development Host System Issues</title>
+
+        <para>
+            Sometimes issues on the host development system can cause your
+            build to fail.
+            Following are known, host-specific problems.
+            Be sure to always consult the
+            <ulink url='&YOCTO_RELEASE_NOTES;'>Release Notes</ulink>
+            for a look at all release-related issues.
+            <itemizedlist>
+                <listitem><para><emphasis><filename>glibc-initial</filename> fails to build</emphasis>:
+                    If your development host system has the unpatched
+                    <filename>GNU Make 3.82</filename>,
+                    the
+                    <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+                    task fails for <filename>glibc-initial</filename> during
+                    the build.</para>
+                    <para>Typically, every distribution that ships
+                    <filename>GNU Make 3.82</filename> as
+                    the default already has the patched version.
+                    However, some distributions, such as Debian, have
+                    <filename>GNU Make 3.82</filename> as an option, which
+                    is unpatched.
+                    You will see this error on these types of distributions.
+                    Switch to <filename>GNU Make 3.81</filename> or patch
+                    your <filename>make</filename> to solve the problem.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='usingpoky-debugging-buildfile'>
+        <title>Building with No Dependencies</title>
+        <para>
+            To build a specific recipe (<filename>.bb</filename> file),
+            you can use the following command form:
+            <literallayout class='monospaced'>
+     $ bitbake -b <replaceable>somepath</replaceable>/<replaceable>somerecipe</replaceable>.bb
+            </literallayout>
+            This command form does not check for dependencies.
+            Consequently, you should use it
+            only when you know existing dependencies have been met.
+            <note>
+                You can also specify fragments of the filename.
+                In this case, BitBake checks for a unique match.
+            </note>
+        </para>
+    </section>
+
+    <section id='usingpoky-debugging-variables'>
+        <title>Variables</title>
+        <para>
+            You can use the <filename>-e</filename> BitBake option to
+            display the parsing environment for a configuration.
+            The following displays the general parsing environment:
+            <literallayout class='monospaced'>
+     $ bitbake -e
+            </literallayout>
+            This next example shows the parsing environment for a specific
+            recipe:
+            <literallayout class='monospaced'>
+     $ bitbake -e <replaceable>recipename</replaceable>
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='recipe-logging-mechanisms'>
+        <title>Recipe Logging Mechanisms</title>
+        <para>
+            Best practices exist while writing recipes that both log build progress and
+            act on build conditions such as warnings and errors.
+            Both Python and Bash language bindings exist for the logging mechanism:
+            <itemizedlist>
+                <listitem><para><emphasis>Python:</emphasis> For Python functions, BitBake
+                    supports several loglevels: <filename>bb.fatal</filename>,
+                    <filename>bb.error</filename>, <filename>bb.warn</filename>,
+                    <filename>bb.note</filename>, <filename>bb.plain</filename>,
+                    and <filename>bb.debug</filename>.</para></listitem>
+                <listitem><para><emphasis>Bash:</emphasis> For Bash functions, the same set
+                    of loglevels exist and are accessed with a similar syntax:
+                    <filename>bbfatal</filename>, <filename>bberror</filename>,
+                    <filename>bbwarn</filename>, <filename>bbnote</filename>,
+                    <filename>bbplain</filename>, and <filename>bbdebug</filename>.</para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            For guidance on how logging is handled in both Python and Bash recipes, see the
+            <filename>logging.bbclass</filename> file in the
+            <filename>meta/classes</filename> folder of the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        </para>
+
+        <section id='logging-with-python'>
+            <title>Logging With Python</title>
+            <para>
+                When creating recipes using Python and inserting code that handles build logs,
+                keep in mind the goal is to have informative logs while keeping the console as
+                "silent" as possible.
+                Also, if you want status messages in the log, use the "debug" loglevel.
+            </para>
+
+            <para>
+                Following is an example written in Python.
+                The code handles logging for a function that determines the
+                number of tasks needed to be run.
+                See the
+                "<link linkend='ref-tasks-listtasks'><filename>do_listtasks</filename></link>"
+                section for additional information:
+                <literallayout class='monospaced'>
+     python do_listtasks() {
+         bb.debug(2, "Starting to figure out the task list")
+         if noteworthy_condition:
+             bb.note("There are 47 tasks to run")
+         bb.debug(2, "Got to point xyz")
+         if warning_trigger:
+             bb.warn("Detected warning_trigger, this might be a problem later.")
+         if recoverable_error:
+             bb.error("Hit recoverable_error, you really need to fix this!")
+         if fatal_error:
+             bb.fatal("fatal_error detected, unable to print the task list")
+         bb.plain("The tasks present are abc")
+         bb.debug(2, "Finished figuring out the tasklist")
+     }
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='logging-with-bash'>
+            <title>Logging With Bash</title>
+            <para>
+                When creating recipes using Bash and inserting code that handles build
+                logs, you have the same goals - informative with minimal console output.
+                The syntax you use for recipes written in Bash is similar to that of
+                recipes written in Python described in the previous section.
+            </para>
+
+            <para>
+                Following is an example written in Bash.
+                The code logs the progress of the <filename>do_my_function</filename> function.
+                <literallayout class='monospaced'>
+     do_my_function() {
+         bbdebug 2 "Running do_my_function"
+         if [ exceptional_condition ]; then
+             bbnote "Hit exceptional_condition"
+         fi
+         bbdebug 2  "Got to point xyz"
+         if [ warning_trigger ]; then
+             bbwarn "Detected warning_trigger, this might cause a problem later."
+         fi
+         if [ recoverable_error ]; then
+             bberror "Hit recoverable_error, correcting"
+         fi
+         if [ fatal_error ]; then
+             bbfatal "fatal_error detected"
+         fi
+         bbdebug 2 "Completed do_my_function"
+     }
+                </literallayout>
+            </para>
+        </section>
+    </section>
+
+    <section id='usingpoky-debugging-others'>
+        <title>Other Tips</title>
+
+        <para>
+            Here are some other tips that you might find useful:
+            <itemizedlist>
+                <listitem><para>When adding new packages, it is worth watching for
+                    undesirable items making their way into compiler command lines.
+                    For example, you do not want references to local system files like
+                    <filename>/usr/lib/</filename> or <filename>/usr/include/</filename>.
+                    </para></listitem>
+                <listitem><para>If you want to remove the <filename>psplash</filename>
+                    boot splashscreen,
+                    add <filename>psplash=false</filename> to  the kernel command line.
+                    Doing so prevents <filename>psplash</filename> from loading
+                    and thus allows you to see the console.
+                    It is also possible to switch out of the splashscreen by
+                    switching the virtual console (e.g. Fn+Left or Fn+Right on a Zaurus).
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
+
+<section id='maintaining-build-output-quality'>
+    <title>Maintaining Build Output Quality</title>
+
+    <para>
+        Many factors can influence the quality of a build.
+        For example, if you upgrade a recipe to use a new version of an upstream software
+        package or you experiment with some new configuration options, subtle changes
+        can occur that you might not detect until later.
+        Consider the case where your recipe is using a newer version of an upstream package.
+        In this case, a new version of a piece of software might introduce an optional
+        dependency on another library, which is auto-detected.
+        If that library has already been built when the software is building,
+        the software will link to the built library and that library will be pulled
+        into your image along with the new software even if you did not want the
+        library.
+    </para>
+
+    <para>
+        The
+        <link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
+        class exists to help you maintain
+        the quality of your build output.
+        You can use the class to highlight unexpected and possibly unwanted
+        changes in the build output.
+        When you enable build history, it records information about the contents of
+        each package and image and then commits that information to a local Git
+        repository where you can examine the information.
+    </para>
+
+    <para>
+        The remainder of this section describes the following:
+        <itemizedlist>
+           <listitem><para>How you can enable and disable
+               build history</para></listitem>
+           <listitem><para>How to understand what the build history contains
+               </para></listitem>
+           <listitem><para>How to limit the information used for build history
+               </para></listitem>
+           <listitem><para>How to examine the build history from both a
+               command-line and web interface</para></listitem>
+       </itemizedlist>
+    </para>
+
+    <section id='enabling-and-disabling-build-history'>
+        <title>Enabling and Disabling Build History</title>
+
+        <para>
+            Build history is disabled by default.
+            To enable it, add the following <filename>INHERIT</filename>
+            statement and set the
+            <link linkend='var-BUILDHISTORY_COMMIT'><filename>BUILDHISTORY_COMMIT</filename></link>
+            variable to "1" at the end of your
+            <filename>conf/local.conf</filename> file found in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
+            <literallayout class='monospaced'>
+     INHERIT += "buildhistory"
+     BUILDHISTORY_COMMIT = "1"
+            </literallayout>
+            Enabling build history as previously described
+            causes the build process to collect build
+            output information and commit it to a local
+            <ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink> repository.
+            <note>
+                Enabling build history increases your build times slightly,
+                particularly for images, and increases the amount of disk
+                space used during the build.
+            </note>
+        </para>
+
+        <para>
+            You can disable build history by removing the previous statements
+            from your <filename>conf/local.conf</filename> file.
+        </para>
+    </section>
+
+    <section id='understanding-what-the-build-history-contains'>
+        <title>Understanding What the Build History Contains</title>
+
+        <para>
+            Build history information is kept in
+            <filename>${</filename><link linkend='var-TOPDIR'><filename>TOPDIR</filename></link><filename>}/buildhistory</filename>
+            in the Build Directory as defined by the
+            <link linkend='var-BUILDHISTORY_DIR'><filename>BUILDHISTORY_DIR</filename></link>
+            variable.
+            The following is an example abbreviated listing:
+            <imagedata fileref="figures/buildhistory.png" align="center" width="6in" depth="4in" />
+        </para>
+
+        <para>
+            At the top level, there is a <filename>metadata-revs</filename> file
+            that lists the revisions of the repositories for the layers enabled
+            when the build was produced.
+            The rest of the data splits into separate
+            <filename>packages</filename>, <filename>images</filename> and
+            <filename>sdk</filename> directories, the contents of which are
+            described below.
+        </para>
+
+        <section id='build-history-package-information'>
+            <title>Build History Package Information</title>
+
+            <para>
+                The history for each package contains a text file that has
+                name-value pairs with information about the package.
+                For example, <filename>buildhistory/packages/i586-poky-linux/busybox/busybox/latest</filename>
+                contains the following:
+                <literallayout class='monospaced'>
+     PV = 1.22.1
+     PR = r32
+     RPROVIDES =
+     RDEPENDS = glibc (>= 2.20) update-alternatives-opkg
+     RRECOMMENDS = busybox-syslog busybox-udhcpc update-rc.d
+     PKGSIZE = 540168
+     FILES = /usr/bin/* /usr/sbin/* /usr/lib/busybox/* /usr/lib/lib*.so.* \
+        /etc /com /var /bin/* /sbin/* /lib/*.so.* /lib/udev/rules.d \
+        /usr/lib/udev/rules.d /usr/share/busybox /usr/lib/busybox/* \
+        /usr/share/pixmaps /usr/share/applications /usr/share/idl \
+        /usr/share/omf /usr/share/sounds /usr/lib/bonobo/servers
+     FILELIST = /bin/busybox /bin/busybox.nosuid /bin/busybox.suid /bin/sh \
+        /etc/busybox.links.nosuid /etc/busybox.links.suid
+                </literallayout>
+                Most of these name-value pairs correspond to variables used
+                to produce the package.
+                The exceptions are <filename>FILELIST</filename>, which is the
+                actual list of files in the package, and
+                <filename>PKGSIZE</filename>, which is the total size of files
+                in the package in bytes.
+            </para>
+
+            <para>
+                There is also a file corresponding to the recipe from which the
+                package came (e.g.
+                <filename>buildhistory/packages/i586-poky-linux/busybox/latest</filename>):
+                <literallayout class='monospaced'>
+     PV = 1.22.1
+     PR = r32
+     DEPENDS = initscripts kern-tools-native update-rc.d-native \
+        virtual/i586-poky-linux-compilerlibs virtual/i586-poky-linux-gcc \
+        virtual/libc virtual/update-alternatives
+     PACKAGES = busybox-ptest busybox-httpd busybox-udhcpd busybox-udhcpc \
+        busybox-syslog busybox-mdev busybox-hwclock busybox-dbg \
+        busybox-staticdev busybox-dev busybox-doc busybox-locale busybox
+                </literallayout>
+            </para>
+
+            <para>
+                Finally, for those recipes fetched from a version control
+                system (e.g., Git), a file exists that lists source revisions
+                that are specified in the recipe and lists the actual revisions
+                used during the build.
+                Listed and actual revisions might differ when
+                <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
+                is set to
+                <filename>${<link linkend='var-AUTOREV'>AUTOREV</link>}</filename>.
+                Here is an example assuming
+                <filename>buildhistory/packages/qemux86-poky-linux/linux-yocto/latest_srcrev</filename>):
+                <literallayout class='monospaced'>
+     # SRCREV_machine = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
+     SRCREV_machine = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
+     # SRCREV_meta = "a227f20eff056e511d504b2e490f3774ab260d6f"
+     SRCREV_meta = "a227f20eff056e511d504b2e490f3774ab260d6f"
+                </literallayout>
+                You can use the <filename>buildhistory-collect-srcrevs</filename>
+                command with the <filename>-a</filename> option to
+                collect the stored <filename>SRCREV</filename> values
+                from build history and report them in a format suitable for
+                use in global configuration (e.g.,
+                <filename>local.conf</filename> or a distro include file) to
+                override floating <filename>AUTOREV</filename> values to a
+                fixed set of revisions.
+                Here is some example output from this command:
+                <literallayout class='monospaced'>
+     $ buildhistory-collect-srcrevs -a
+     # i586-poky-linux
+     SRCREV_pn-glibc = "b8079dd0d360648e4e8de48656c5c38972621072"
+     SRCREV_pn-glibc-initial = "b8079dd0d360648e4e8de48656c5c38972621072"
+     SRCREV_pn-opkg-utils = "53274f087565fd45d8452c5367997ba6a682a37a"
+     SRCREV_pn-kmod = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
+     # x86_64-linux
+     SRCREV_pn-gtk-doc-stub-native = "1dea266593edb766d6d898c79451ef193eb17cfa"
+     SRCREV_pn-dtc-native = "65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf"
+     SRCREV_pn-update-rc.d-native = "eca680ddf28d024954895f59a241a622dd575c11"
+     SRCREV_glibc_pn-cross-localedef-native = "b8079dd0d360648e4e8de48656c5c38972621072"
+     SRCREV_localedef_pn-cross-localedef-native = "c833367348d39dad7ba018990bfdaffaec8e9ed3"
+     SRCREV_pn-prelink-native = "faa069deec99bf61418d0bab831c83d7c1b797ca"
+     SRCREV_pn-opkg-utils-native = "53274f087565fd45d8452c5367997ba6a682a37a"
+     SRCREV_pn-kern-tools-native = "23345b8846fe4bd167efdf1bd8a1224b2ba9a5ff"
+     SRCREV_pn-kmod-native = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
+     # qemux86-poky-linux
+     SRCREV_machine_pn-linux-yocto = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
+     SRCREV_meta_pn-linux-yocto = "a227f20eff056e511d504b2e490f3774ab260d6f"
+     # all-poky-linux
+     SRCREV_pn-update-rc.d = "eca680ddf28d024954895f59a241a622dd575c11"
+                </literallayout>
+                <note>
+                    Here are some notes on using the
+                    <filename>buildhistory-collect-srcrevs</filename> command:
+                    <itemizedlist>
+                        <listitem><para>By default, only values where the
+                            <filename>SRCREV</filename> was
+                            not hardcoded (usually when <filename>AUTOREV</filename>
+                            was used) are reported.
+                            Use the <filename>-a</filename> option to see all
+                            <filename>SRCREV</filename> values.
+                            </para></listitem>
+                        <listitem><para>The output statements might not have any effect
+                            if overrides are applied elsewhere in the build system
+                            configuration.
+                            Use the <filename>-f</filename> option to add the
+                            <filename>forcevariable</filename> override to each output line
+                            if you need to work around this restriction.
+                            </para></listitem>
+                        <listitem><para>The script does apply special handling when
+                            building for multiple machines.
+                            However, the script does place a
+                            comment before each set of values that specifies
+                            which triplet to which they belong as shown above
+                            (e.g., <filename>i586-poky-linux</filename>).
+                            </para></listitem>
+                    </itemizedlist>
+                </note>
+            </para>
+        </section>
+
+        <section id='build-history-image-information'>
+            <title>Build History Image Information</title>
+
+            <para>
+                The files produced for each image are as follows:
+                <itemizedlist>
+                    <listitem><para><filename>image-files:</filename>
+                        A directory containing selected files from the root
+                        filesystem.
+                        The files are defined by
+                        <link linkend='var-BUILDHISTORY_IMAGE_FILES'><filename>BUILDHISTORY_IMAGE_FILES</filename></link>.
+                        </para></listitem>
+                    <listitem><para><filename>build-id.txt:</filename>
+                        Human-readable information about the build configuration
+                        and metadata source revisions.
+                        This file contains the full build header as printed
+                        by BitBake.</para></listitem>
+                    <listitem><para><filename>*.dot:</filename>
+                        Dependency graphs for the image that are
+                        compatible with <filename>graphviz</filename>.
+                        </para></listitem>
+                    <listitem><para><filename>files-in-image.txt:</filename>
+                            A list of files in the image with permissions,
+                        owner, group, size, and symlink information.
+                        </para></listitem>
+                    <listitem><para><filename>image-info.txt:</filename>
+                        A text file containing name-value pairs with information
+                        about the image.
+                        See the following listing example for more information.
+                        </para></listitem>
+                    <listitem><para><filename>installed-package-names.txt:</filename>
+                        A list of installed packages by name only.</para></listitem>
+                    <listitem><para><filename>installed-package-sizes.txt:</filename>
+                        A list of installed packages ordered by size.
+                        </para></listitem>
+                    <listitem><para><filename>installed-packages.txt:</filename>
+                        A list of installed packages with full package
+                        filenames.</para></listitem>
+                </itemizedlist>
+                <note>
+                    Installed package information is able to be gathered and
+                    produced even if package management is disabled for the final
+                    image.
+                </note>
+            </para>
+
+            <para>
+                Here is an example of <filename>image-info.txt</filename>:
+                <literallayout class='monospaced'>
+     DISTRO = poky
+     DISTRO_VERSION = 1.7
+     USER_CLASSES = buildstats image-mklibs image-prelink
+     IMAGE_CLASSES = image_types
+     IMAGE_FEATURES = debug-tweaks
+     IMAGE_LINGUAS =
+     IMAGE_INSTALL = packagegroup-core-boot run-postinsts
+     BAD_RECOMMENDATIONS =
+     NO_RECOMMENDATIONS =
+     PACKAGE_EXCLUDE =
+     ROOTFS_POSTPROCESS_COMMAND = write_package_manifest; license_create_manifest; \
+        write_image_manifest ; buildhistory_list_installed_image ; \
+        buildhistory_get_image_installed ; ssh_allow_empty_password;  \
+        postinst_enable_logging; rootfs_update_timestamp ; ssh_disable_dns_lookup ;
+     IMAGE_POSTPROCESS_COMMAND =   buildhistory_get_imageinfo ;
+     IMAGESIZE = 6900
+                </literallayout>
+                Other than <filename>IMAGESIZE</filename>, which is the
+                total size of the files in the image in Kbytes, the
+                name-value pairs are variables that may have influenced the
+                content of the image.
+                This information is often useful when you are trying to determine
+                why a change in the package or file listings has occurred.
+            </para>
+        </section>
+
+        <section id='using-build-history-to-gather-image-information-only'>
+            <title>Using Build History to Gather Image Information Only</title>
+
+            <para>
+                As you can see, build history produces image information,
+                including dependency graphs, so you can see why something
+                was pulled into the image.
+                If you are just interested in this information and not
+                interested in collecting specific package or SDK information,
+                you can enable writing only image information without
+                any history by adding the following to your
+                <filename>conf/local.conf</filename> file found in the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
+                <literallayout class='monospaced'>
+     INHERIT += "buildhistory"
+     BUILDHISTORY_COMMIT = "0"
+     BUILDHISTORY_FEATURES = "image"
+                </literallayout>
+                Here, you set the
+                <link linkend='var-BUILDHISTORY_FEATURES'><filename>BUILDHISTORY_FEATURES</filename></link>
+                variable to use the image feature only.
+            </para>
+        </section>
+
+        <section id='build-history-sdk-information'>
+            <title>Build History SDK Information</title>
+            <para>
+                Build history collects similar information on the contents
+                of SDKs (e.g. <filename>meta-toolchain</filename>
+                or <filename>bitbake -c populate_sdk imagename</filename>)
+                as compared to information it collects for images.
+                The following list shows the files produced for each SDK:
+                <itemizedlist>
+                    <listitem><para><filename>files-in-sdk.txt:</filename>
+                        A list of files in the SDK with permissions,
+                        owner, group, size, and symlink information.
+                        This list includes both the host and target parts
+                        of the SDK.
+                        </para></listitem>
+                    <listitem><para><filename>sdk-info.txt:</filename>
+                        A text file containing name-value pairs with information
+                        about the SDK.
+                        See the following listing example for more information.
+                        </para></listitem>
+                    <listitem><para>The following information appears under
+                        each of the <filename>host</filename>
+                        and <filename>target</filename> directories
+                        for the portions of the SDK that run on the host and
+                        on the target, respectively:
+                        <itemizedlist>
+                            <listitem><para><filename>depends.dot:</filename>
+                                Dependency graph for the SDK that is
+                                compatible with <filename>graphviz</filename>.
+                                </para></listitem>
+                            <listitem><para><filename>installed-package-names.txt:</filename>
+                                A list of installed packages by name only.
+                                </para></listitem>
+                            <listitem><para><filename>installed-package-sizes.txt:</filename>
+                                A list of installed packages ordered by size.
+                                </para></listitem>
+                            <listitem><para><filename>installed-packages.txt:</filename>
+                                A list of installed packages with full package
+                                filenames.</para></listitem>
+                            </itemizedlist>
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                Here is an example of <filename>sdk-info.txt</filename>:
+                <literallayout class='monospaced'>
+     DISTRO = poky
+     DISTRO_VERSION = 1.3+snapshot-20130327
+     SDK_NAME = poky-glibc-i686-arm
+     SDK_VERSION = 1.3+snapshot
+     SDKMACHINE =
+     SDKIMAGE_FEATURES = dev-pkgs dbg-pkgs
+     BAD_RECOMMENDATIONS =
+     SDKSIZE = 352712
+                </literallayout>
+                Other than <filename>SDKSIZE</filename>, which is the
+                total size of the files in the SDK in Kbytes, the
+                name-value pairs are variables that might have influenced the
+                content of the SDK.
+                This information is often useful when you are trying to
+                determine why a change in the package or file listings
+                has occurred.
+            </para>
+        </section>
+
+        <section id='examining-build-history-information'>
+            <title>Examining Build History Information</title>
+
+            <para>
+                You can examine build history output from the command line or
+                from a web interface.
+            </para>
+
+            <para>
+                To see any changes that have occurred (assuming you have
+                <link linkend='var-BUILDHISTORY_COMMIT'><filename>BUILDHISTORY_COMMIT = "1"</filename></link>),
+                you can simply
+                use any Git command that allows you to view the history of
+                a repository.
+                Here is one method:
+                <literallayout class='monospaced'>
+      $ git log -p
+                </literallayout>
+                You need to realize, however, that this method does show
+                changes that are not significant (e.g. a package's size
+                changing by a few bytes).
+            </para>
+
+            <para>
+                A command-line tool called <filename>buildhistory-diff</filename>
+                does exist, though, that queries the Git repository and prints just
+                the differences that might be significant in human-readable form.
+                Here is an example:
+                <literallayout class='monospaced'>
+     $ ~/poky/poky/scripts/buildhistory-diff . HEAD^
+     Changes to images/qemux86_64/glibc/core-image-minimal (files-in-image.txt):
+        /etc/anotherpkg.conf was added
+        /sbin/anotherpkg was added
+        * (installed-package-names.txt):
+        *   anotherpkg was added
+     Changes to images/qemux86_64/glibc/core-image-minimal (installed-package-names.txt):
+        anotherpkg was added
+     packages/qemux86_64-poky-linux/v86d: PACKAGES: added "v86d-extras"
+        * PR changed from "r0" to "r1"
+        * PV changed from "0.1.10" to "0.1.12"
+     packages/qemux86_64-poky-linux/v86d/v86d: PKGSIZE changed from 110579 to 144381 (+30%)
+        * PR changed from "r0" to "r1"
+        * PV changed from "0.1.10" to "0.1.12"
+                </literallayout>
+            </para>
+
+            <para>
+                To see changes to the build history using a web interface, follow
+                the instruction in the <filename>README</filename> file here.
+                <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/buildhistory-web/'></ulink>.
+            </para>
+
+            <para>
+                Here is a sample screenshot of the interface:
+                <imagedata fileref="figures/buildhistory-web.png" align="center" scalefit="1" width="130%" contentdepth="130%" />
+            </para>
+        </section>
+    </section>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/template/Vera.ttf b/documentation/template/Vera.ttf
new file mode 100644
index 0000000000..58cd6b5e61
--- /dev/null
+++ b/documentation/template/Vera.ttf
diff --git a/documentation/template/Vera.xml b/documentation/template/Vera.xml
new file mode 100644
index 0000000000..3c82043e35
--- /dev/null
+++ b/documentation/template/Vera.xml
@@ -0,0 +1 @@
+<?xml version="1.0" encoding="UTF-8"?><font-metrics type="TYPE0"><font-name>BitstreamVeraSans</font-name><embed/><cap-height>729</cap-height><x-height>546</x-height><ascender>928</ascender><descender>-235</descender><bbox><left>-183</left><bottom>-235</bottom><right>1287</right><top>928</top></bbox><flags>32</flags><stemv>0</stemv><italicangle>0</italicangle><subtype>TYPE0</subtype><multibyte-extras><cid-type>CIDFontType2</cid-type><default-width>0</default-width><bfranges><bf gi="3" ue="126" us="32"/><bf gi="172" ue="160" us="160"/><bf gi="163" ue="161" us="161"/><bf gi="132" ue="163" us="162"/><bf gi="189" ue="164" us="164"/><bf gi="150" ue="165" us="165"/><bf gi="231" ue="166" us="166"/><bf gi="134" ue="167" us="167"/><bf gi="142" ue="168" us="168"/><bf gi="139" ue="169" us="169"/><bf gi="157" ue="170" us="170"/><bf gi="169" ue="171" us="171"/><bf gi="164" ue="172" us="172"/><bf gi="256" ue="173" us="173"/><bf gi="138" ue="174" us="174"/><bf gi="217" ue="175" us="175"/><bf gi="131" ue="176" us="176"/><bf gi="147" ue="177" us="177"/><bf gi="241" ue="179" us="178"/><bf gi="141" ue="180" us="180"/><bf gi="151" ue="181" us="181"/><bf gi="136" ue="182" us="182"/><bf gi="195" ue="183" us="183"/><bf gi="221" ue="184" us="184"/><bf gi="240" ue="185" us="185"/><bf gi="158" ue="186" us="186"/><bf gi="170" ue="187" us="187"/><bf gi="243" ue="190" us="188"/><bf gi="162" ue="191" us="191"/><bf gi="173" ue="192" us="192"/><bf gi="201" ue="193" us="193"/><bf gi="199" ue="194" us="194"/><bf gi="174" ue="195" us="195"/><bf gi="98" ue="197" us="196"/><bf gi="144" ue="198" us="198"/><bf gi="100" ue="199" us="199"/><bf gi="203" ue="200" us="200"/><bf gi="101" ue="201" us="201"/><bf gi="200" ue="202" us="202"/><bf gi="202" ue="203" us="203"/><bf gi="207" ue="204" us="204"/><bf gi="204" ue="207" us="205"/><bf gi="232" ue="208" us="208"/><bf gi="102" ue="209" us="209"/><bf gi="210" ue="210" us="210"/><bf gi="208" ue="212" us="211"/><bf gi="175" ue="213" us="213"/><bf gi="103" ue="214" us="214"/><bf gi="239" ue="215" us="215"/><bf gi="145" ue="216" us="216"/><bf gi="213" ue="217" us="217"/><bf gi="211" ue="219" us="218"/><bf gi="104" ue="220" us="220"/><bf gi="234" ue="221" us="221"/><bf gi="236" ue="222" us="222"/><bf gi="137" ue="223" us="223"/><bf gi="106" ue="224" us="224"/><bf gi="105" ue="225" us="225"/><bf gi="107" ue="226" us="226"/><bf gi="109" ue="227" us="227"/><bf gi="108" ue="228" us="228"/><bf gi="110" ue="229" us="229"/><bf gi="160" ue="230" us="230"/><bf gi="111" ue="231" us="231"/><bf gi="113" ue="232" us="232"/><bf gi="112" ue="233" us="233"/><bf gi="114" ue="235" us="234"/><bf gi="117" ue="236" us="236"/><bf gi="116" ue="237" us="237"/><bf gi="118" ue="239" us="238"/><bf gi="233" ue="240" us="240"/><bf gi="120" ue="241" us="241"/><bf gi="122" ue="242" us="242"/><bf gi="121" ue="243" us="243"/><bf gi="123" ue="244" us="244"/><bf gi="125" ue="245" us="245"/><bf gi="124" ue="246" us="246"/><bf gi="184" ue="247" us="247"/><bf gi="161" ue="248" us="248"/><bf gi="127" ue="249" us="249"/><bf gi="126" ue="250" us="250"/><bf gi="128" ue="252" us="251"/><bf gi="235" ue="253" us="253"/><bf gi="237" ue="254" us="254"/><bf gi="186" ue="255" us="255"/><bf gi="251" ue="263" us="262"/><bf gi="253" ue="269" us="268"/><bf gi="0" ue="270" us="270"/><bf gi="0" ue="271" us="271"/><bf gi="0" ue="272" us="272"/><bf gi="255" ue="273" us="273"/><bf gi="246" ue="287" us="286"/><bf gi="248" ue="304" us="304"/><bf gi="214" ue="305" us="305"/><bf gi="225" ue="322" us="321"/><bf gi="176" ue="339" us="338"/><bf gi="249" ue="351" us="350"/><bf gi="227" ue="353" us="352"/><bf gi="187" ue="376" us="376"/><bf gi="229" ue="382" us="381"/><bf gi="166" ue="402" us="402"/><bf gi="215" ue="710" us="710"/><bf gi="224" ue="711" us="711"/><bf gi="218" ue="730" us="728"/><bf gi="223" ue="731" us="731"/><bf gi="216" ue="732" us="732"/><bf gi="222" ue="733" us="733"/><bf gi="159" ue="937" us="937"/><bf gi="155" ue="960" us="960"/><bf gi="178" ue="8212" us="8211"/><bf gi="0" ue="8213" us="8213"/><bf gi="0" ue="8214" us="8214"/><bf gi="0" ue="8215" us="8215"/><bf gi="182" ue="8217" us="8216"/><bf gi="196" ue="8218" us="8218"/><bf gi="0" ue="8219" us="8219"/><bf gi="180" ue="8221" us="8220"/><bf gi="197" ue="8222" us="8222"/><bf gi="0" ue="8223" us="8223"/><bf gi="130" ue="8224" us="8224"/><bf gi="194" ue="8225" us="8225"/><bf gi="135" ue="8226" us="8226"/><bf gi="0" ue="8227" us="8227"/><bf gi="0" ue="8228" us="8228"/><bf gi="0" ue="8229" us="8229"/><bf gi="171" ue="8230" us="8230"/><bf gi="198" ue="8240" us="8240"/><bf gi="190" ue="8250" us="8249"/><bf gi="258" ue="8364" us="8364"/><bf gi="140" ue="8482" us="8482"/><bf gi="152" ue="8706" us="8706"/><bf gi="0" ue="8707" us="8707"/><bf gi="0" ue="8708" us="8708"/><bf gi="0" ue="8709" us="8709"/><bf gi="168" ue="8710" us="8710"/><bf gi="154" ue="8719" us="8719"/><bf gi="0" ue="8720" us="8720"/><bf gi="153" ue="8721" us="8721"/><bf gi="238" ue="8722" us="8722"/><bf gi="0" ue="8723" us="8723"/><bf gi="0" ue="8724" us="8724"/><bf gi="188" ue="8725" us="8725"/><bf gi="0" ue="8726" us="8726"/><bf gi="0" ue="8727" us="8727"/><bf gi="0" ue="8728" us="8728"/><bf gi="257" ue="8729" us="8729"/><bf gi="165" ue="8730" us="8730"/><bf gi="0" ue="8731" us="8731"/><bf gi="0" ue="8732" us="8732"/><bf gi="0" ue="8733" us="8733"/><bf gi="146" ue="8734" us="8734"/><bf gi="156" ue="8747" us="8747"/><bf gi="167" ue="8776" us="8776"/><bf gi="143" ue="8800" us="8800"/><bf gi="0" ue="8801" us="8801"/><bf gi="0" ue="8802" us="8802"/><bf gi="0" ue="8803" us="8803"/><bf gi="148" ue="8805" us="8804"/><bf gi="185" ue="9674" us="9674"/><bf gi="192" ue="64258" us="64257"/><bf gi="0" ue="65535" us="65535"/></bfranges><cid-widths start-index="0"><wx w="600"/><wx w="0"/><wx w="317"/><wx w="317"/><wx w="400"/><wx w="459"/><wx w="837"/><wx w="636"/><wx w="950"/><wx w="779"/><wx w="274"/><wx w="390"/><wx w="390"/><wx w="500"/><wx w="837"/><wx w="317"/><wx w="360"/><wx w="317"/><wx w="336"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="336"/><wx w="336"/><wx w="837"/><wx w="837"/><wx w="837"/><wx w="530"/><wx w="1000"/><wx w="684"/><wx w="686"/><wx w="698"/><wx w="770"/><wx w="631"/><wx w="575"/><wx w="774"/><wx w="751"/><wx w="294"/><wx w="294"/><wx w="655"/><wx w="557"/><wx w="862"/><wx w="748"/><wx w="787"/><wx w="603"/><wx w="787"/><wx w="694"/><wx w="634"/><wx w="610"/><wx w="731"/><wx w="684"/><wx w="988"/><wx w="685"/><wx w="610"/><wx w="685"/><wx w="390"/><wx w="336"/><wx w="390"/><wx w="837"/><wx w="500"/><wx w="500"/><wx w="612"/><wx w="634"/><wx w="549"/><wx w="634"/><wx w="615"/><wx w="352"/><wx w="634"/><wx w="633"/><wx w="277"/><wx w="277"/><wx w="579"/><wx w="277"/><wx w="974"/><wx w="633"/><wx w="611"/><wx w="634"/><wx w="634"/><wx w="411"/><wx w="520"/><wx w="392"/><wx w="633"/><wx w="591"/><wx w="817"/><wx w="591"/><wx w="591"/><wx w="524"/><wx w="636"/><wx w="336"/><wx w="636"/><wx w="837"/><wx w="684"/><wx w="684"/><wx w="698"/><wx w="631"/><wx w="748"/><wx w="787"/><wx w="731"/><wx w="612"/><wx w="612"/><wx w="612"/><wx w="612"/><wx w="612"/><wx w="612"/><wx w="549"/><wx w="615"/><wx w="615"/><wx w="615"/><wx w="615"/><wx w="277"/><wx w="277"/><wx w="277"/><wx w="277"/><wx w="633"/><wx w="611"/><wx w="611"/><wx w="611"/><wx w="611"/><wx w="611"/><wx w="633"/><wx w="633"/><wx w="633"/><wx w="633"/><wx w="500"/><wx w="500"/><wx w="636"/><wx w="636"/><wx w="500"/><wx w="589"/><wx w="636"/><wx w="629"/><wx w="1000"/><wx w="1000"/><wx w="1000"/><wx w="500"/><wx w="500"/><wx w="837"/><wx w="974"/><wx w="787"/><wx w="833"/><wx w="837"/><wx w="837"/><wx w="837"/><wx w="636"/><wx w="636"/><wx w="517"/><wx w="673"/><wx w="756"/><wx w="588"/><wx w="520"/><wx w="471"/><wx w="471"/><wx w="764"/><wx w="981"/><wx w="611"/><wx w="530"/><wx w="400"/><wx w="837"/><wx w="637"/><wx w="636"/><wx w="837"/><wx w="668"/><wx w="611"/><wx w="611"/><wx w="1000"/><wx w="636"/><wx w="684"/><wx w="684"/><wx w="787"/><wx w="1069"/><wx w="1022"/><wx w="500"/><wx w="1000"/><wx w="518"/><wx w="518"/><wx w="317"/><wx w="317"/><wx w="837"/><wx w="494"/><wx w="591"/><wx w="610"/><wx w="166"/><wx w="636"/><wx w="399"/><wx w="399"/><wx w="629"/><wx w="629"/><wx w="500"/><wx w="317"/><wx w="317"/><wx w="518"/><wx w="1341"/><wx w="684"/><wx w="631"/><wx w="684"/><wx w="631"/><wx w="631"/><wx w="294"/><wx w="294"/><wx w="294"/><wx w="294"/><wx w="787"/><wx w="787"/><wx w="787"/><wx w="731"/><wx w="731"/><wx w="731"/><wx w="277"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="562"/><wx w="284"/><wx w="634"/><wx w="520"/><wx w="685"/><wx w="524"/><wx w="336"/><wx w="774"/><wx w="611"/><wx w="610"/><wx w="591"/><wx w="604"/><wx w="634"/><wx w="837"/><wx w="837"/><wx w="400"/><wx w="400"/><wx w="400"/><wx w="969"/><wx w="969"/><wx w="969"/><wx w="774"/><wx w="634"/><wx w="294"/><wx w="634"/><wx w="520"/><wx w="698"/><wx w="549"/><wx w="698"/><wx w="549"/><wx w="634"/><wx w="360"/><wx w="317"/><wx w="636"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="400"/><wx w="500"/><wx w="500"/></cid-widths></multibyte-extras><kerning kpx1="246"><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="169"/><pair kern="-26" kpx2="197"/><pair kern="-35" kpx2="55"/><pair kern="-49" kpx2="60"/><pair kern="-49" kpx2="187"/><pair kern="-21" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-49" kpx2="234"/></kerning><kerning kpx1="235"><pair kern="-142" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-146" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-72" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="43"><pair kern="-35" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-35" kpx2="197"/><pair kern="-30" kpx2="181"/></kerning><kerning kpx1="16"><pair kern="36" kpx2="246"/><pair kern="-17" kpx2="235"/><pair kern="-21" kpx2="199"/><pair kern="18" kpx2="123"/><pair kern="27" kpx2="208"/><pair kern="-118" kpx2="187"/><pair kern="-49" kpx2="59"/><pair kern="18" kpx2="124"/><pair kern="-21" kpx2="201"/><pair kern="-118" kpx2="60"/><pair kern="36" kpx2="52"/><pair kern="18" kpx2="125"/><pair kern="36" kpx2="42"/><pair kern="-118" kpx2="234"/><pair kern="18" kpx2="122"/><pair kern="27" kpx2="210"/><pair kern="-21" kpx2="36"/><pair kern="18" kpx2="82"/><pair kern="-40" kpx2="58"/><pair kern="-91" kpx2="55"/><pair kern="-17" kpx2="186"/><pair kern="27" kpx2="175"/><pair kern="27" kpx2="50"/><pair kern="27" kpx2="209"/><pair kern="27" kpx2="103"/><pair kern="-21" kpx2="98"/><pair kern="55" kpx2="45"/><pair kern="-21" kpx2="173"/><pair kern="-17" kpx2="92"/><pair kern="-26" kpx2="89"/><pair kern="18" kpx2="121"/><pair kern="-58" kpx2="57"/><pair kern="-35" kpx2="37"/><pair kern="-21" kpx2="174"/></kerning><kerning kpx1="112"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="123"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="251"><pair kern="-17" kpx2="169"/><pair kern="-17" kpx2="60"/><pair kern="-17" kpx2="187"/><pair kern="18" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-17" kpx2="234"/></kerning><kerning kpx1="213"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning><kerning kpx1="208"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="187"><pair kern="-114" kpx2="126"/><pair kern="-137" kpx2="107"/><pair kern="-132" kpx2="72"/><pair kern="-77" kpx2="199"/><pair kern="-118" kpx2="16"/><pair kern="-132" kpx2="123"/><pair kern="-132" kpx2="112"/><pair kern="-54" kpx2="251"/><pair kern="-54" kpx2="208"/><pair kern="-132" kpx2="113"/><pair kern="-54" kpx2="180"/><pair kern="-137" kpx2="105"/><pair kern="-114" kpx2="129"/><pair kern="-132" kpx2="124"/><pair kern="-109" kpx2="169"/><pair kern="-77" kpx2="201"/><pair kern="-54" kpx2="253"/><pair kern="-137" kpx2="106"/><pair kern="-132" kpx2="29"/><pair kern="-132" kpx2="125"/><pair kern="-72" kpx2="170"/><pair kern="-132" kpx2="115"/><pair kern="-114" kpx2="88"/><pair kern="-132" kpx2="122"/><pair kern="-54" kpx2="100"/><pair kern="-137" kpx2="68"/><pair kern="-54" kpx2="210"/><pair kern="-77" kpx2="36"/><pair kern="-132" kpx2="82"/><pair kern="-132" kpx2="114"/><pair kern="-54" kpx2="175"/><pair kern="-114" kpx2="127"/><pair kern="-54" kpx2="50"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-137" kpx2="108"/><pair kern="-77" kpx2="98"/><pair kern="-35" kpx2="76"/><pair kern="-17" kpx2="181"/><pair kern="-202" kpx2="17"/><pair kern="-114" kpx2="128"/><pair kern="-77" kpx2="173"/><pair kern="-137" kpx2="109"/><pair kern="-128" kpx2="197"/><pair kern="-54" kpx2="38"/><pair kern="-132" kpx2="121"/><pair kern="-137" kpx2="110"/><pair kern="-77" kpx2="174"/></kerning><kerning kpx1="113"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="144"><pair kern="-40" kpx2="180"/><pair kern="-54" kpx2="197"/><pair kern="-44" kpx2="181"/></kerning><kerning kpx1="59"><pair kern="-72" kpx2="100"/><pair kern="-63" kpx2="210"/><pair kern="-17" kpx2="55"/><pair kern="-44" kpx2="114"/><pair kern="-44" kpx2="72"/><pair kern="-63" kpx2="175"/><pair kern="-49" kpx2="16"/><pair kern="-63" kpx2="50"/><pair kern="-63" kpx2="209"/><pair kern="-44" kpx2="112"/><pair kern="-72" kpx2="251"/><pair kern="-63" kpx2="103"/><pair kern="-63" kpx2="208"/><pair kern="-44" kpx2="113"/><pair kern="-40" kpx2="181"/><pair kern="-77" kpx2="180"/><pair kern="-54" kpx2="169"/><pair kern="-21" kpx2="197"/><pair kern="-72" kpx2="38"/><pair kern="-72" kpx2="253"/><pair kern="-44" kpx2="115"/></kerning><kerning kpx1="73"><pair kern="31" kpx2="180"/><pair kern="-17" kpx2="90"/><pair kern="-72" kpx2="17"/><pair kern="-17" kpx2="235"/><pair kern="-35" kpx2="169"/><pair kern="-114" kpx2="197"/><pair kern="-17" kpx2="186"/><pair kern="-17" kpx2="92"/><pair kern="-17" kpx2="87"/><pair kern="-54" kpx2="16"/><pair kern="-35" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="41"><pair kern="-17" kpx2="227"/><pair kern="-54" kpx2="126"/><pair kern="-91" kpx2="107"/><pair kern="-91" kpx2="235"/><pair kern="-54" kpx2="72"/><pair kern="-91" kpx2="199"/><pair kern="-35" kpx2="123"/><pair kern="-54" kpx2="112"/><pair kern="-54" kpx2="113"/><pair kern="-17" kpx2="54"/><pair kern="-21" kpx2="180"/><pair kern="-91" kpx2="105"/><pair kern="-54" kpx2="129"/><pair kern="-35" kpx2="124"/><pair kern="-91" kpx2="201"/><pair kern="-72" kpx2="85"/><pair kern="-91" kpx2="106"/><pair kern="-77" kpx2="29"/><pair kern="-35" kpx2="125"/><pair kern="-54" kpx2="115"/><pair kern="-54" kpx2="88"/><pair kern="-35" kpx2="122"/><pair kern="-91" kpx2="68"/><pair kern="-91" kpx2="36"/><pair kern="-35" kpx2="82"/><pair kern="-91" kpx2="186"/><pair kern="-17" kpx2="55"/><pair kern="-54" kpx2="114"/><pair kern="-54" kpx2="127"/><pair kern="-91" kpx2="108"/><pair kern="-91" kpx2="98"/><pair kern="-72" kpx2="76"/><pair kern="-160" kpx2="17"/><pair kern="-54" kpx2="128"/><pair kern="-91" kpx2="173"/><pair kern="-91" kpx2="109"/><pair kern="-183" kpx2="197"/><pair kern="-91" kpx2="92"/><pair kern="-35" kpx2="121"/><pair kern="-91" kpx2="110"/><pair kern="-91" kpx2="174"/><pair kern="-17" kpx2="249"/></kerning><kerning kpx1="124"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="169"><pair kern="-17" kpx2="90"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="246"/><pair kern="-17" kpx2="235"/><pair kern="-17" kpx2="58"/><pair kern="-17" kpx2="186"/><pair kern="-54" kpx2="55"/><pair kern="-17" kpx2="251"/><pair kern="-72" kpx2="187"/><pair kern="-17" kpx2="39"/><pair kern="73" kpx2="144"/><pair kern="-17" kpx2="45"/><pair kern="-17" kpx2="92"/><pair kern="-17" kpx2="38"/><pair kern="-72" kpx2="60"/><pair kern="-17" kpx2="89"/><pair kern="-17" kpx2="253"/><pair kern="-54" kpx2="57"/><pair kern="-17" kpx2="37"/><pair kern="-17" kpx2="42"/><pair kern="-72" kpx2="234"/></kerning><kerning kpx1="201"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="60"><pair kern="-114" kpx2="126"/><pair kern="-137" kpx2="107"/><pair kern="-132" kpx2="72"/><pair kern="-77" kpx2="199"/><pair kern="-118" kpx2="16"/><pair kern="-132" kpx2="123"/><pair kern="-132" kpx2="112"/><pair kern="-54" kpx2="251"/><pair kern="-54" kpx2="208"/><pair kern="-132" kpx2="113"/><pair kern="-54" kpx2="180"/><pair kern="-137" kpx2="105"/><pair kern="-114" kpx2="129"/><pair kern="-132" kpx2="124"/><pair kern="-109" kpx2="169"/><pair kern="-77" kpx2="201"/><pair kern="-54" kpx2="253"/><pair kern="-137" kpx2="106"/><pair kern="-132" kpx2="29"/><pair kern="-132" kpx2="125"/><pair kern="-72" kpx2="170"/><pair kern="-132" kpx2="115"/><pair kern="-114" kpx2="88"/><pair kern="-132" kpx2="122"/><pair kern="-54" kpx2="100"/><pair kern="-137" kpx2="68"/><pair kern="-54" kpx2="210"/><pair kern="-77" kpx2="36"/><pair kern="-132" kpx2="82"/><pair kern="-132" kpx2="114"/><pair kern="-54" kpx2="175"/><pair kern="-114" kpx2="127"/><pair kern="-54" kpx2="50"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-137" kpx2="108"/><pair kern="-77" kpx2="98"/><pair kern="-35" kpx2="76"/><pair kern="-17" kpx2="181"/><pair kern="-202" kpx2="17"/><pair kern="-114" kpx2="128"/><pair kern="-77" kpx2="173"/><pair kern="-137" kpx2="109"/><pair kern="-128" kpx2="197"/><pair kern="-54" kpx2="38"/><pair kern="-132" kpx2="121"/><pair kern="-137" kpx2="110"/><pair kern="-77" kpx2="174"/></kerning><kerning kpx1="85"><pair kern="-21" kpx2="254"/><pair kern="-21" kpx2="72"/><pair kern="-63" kpx2="16"/><pair kern="-21" kpx2="112"/><pair kern="-21" kpx2="123"/><pair kern="-17" kpx2="80"/><pair kern="-21" kpx2="113"/><pair kern="-17" kpx2="71"/><pair kern="-21" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-21" kpx2="252"/><pair kern="-21" kpx2="70"/><pair kern="-17" kpx2="85"/><pair kern="-17" kpx2="29"/><pair kern="-21" kpx2="125"/><pair kern="-21" kpx2="115"/><pair kern="-21" kpx2="111"/><pair kern="-21" kpx2="122"/><pair kern="-21" kpx2="82"/><pair kern="-17" kpx2="75"/><pair kern="-21" kpx2="114"/><pair kern="-26" kpx2="91"/><pair kern="-17" kpx2="81"/><pair kern="41" kpx2="181"/><pair kern="-91" kpx2="17"/><pair kern="-151" kpx2="197"/><pair kern="-17" kpx2="74"/><pair kern="-17" kpx2="84"/><pair kern="-21" kpx2="121"/><pair kern="-17" kpx2="247"/><pair kern="-17" kpx2="120"/></kerning><kerning kpx1="61"><pair kern="-17" kpx2="180"/><pair kern="-17" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-17" kpx2="181"/></kerning><kerning kpx1="234"><pair kern="-114" kpx2="126"/><pair kern="-137" kpx2="107"/><pair kern="-132" kpx2="72"/><pair kern="-77" kpx2="199"/><pair kern="-118" kpx2="16"/><pair kern="-132" kpx2="123"/><pair kern="-132" kpx2="112"/><pair kern="-54" kpx2="251"/><pair kern="-54" kpx2="208"/><pair kern="-132" kpx2="113"/><pair kern="-54" kpx2="180"/><pair kern="-137" kpx2="105"/><pair kern="-114" kpx2="129"/><pair kern="-132" kpx2="124"/><pair kern="-109" kpx2="169"/><pair kern="-77" kpx2="201"/><pair kern="-54" kpx2="253"/><pair kern="-137" kpx2="106"/><pair kern="-132" kpx2="29"/><pair kern="-132" kpx2="125"/><pair kern="-72" kpx2="170"/><pair kern="-132" kpx2="115"/><pair kern="-114" kpx2="88"/><pair kern="-132" kpx2="122"/><pair kern="-54" kpx2="100"/><pair kern="-137" kpx2="68"/><pair kern="-54" kpx2="210"/><pair kern="-77" kpx2="36"/><pair kern="-132" kpx2="82"/><pair kern="-132" kpx2="114"/><pair kern="-54" kpx2="175"/><pair kern="-114" kpx2="127"/><pair kern="-54" kpx2="50"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-137" kpx2="108"/><pair kern="-77" kpx2="98"/><pair kern="-35" kpx2="76"/><pair kern="-17" kpx2="181"/><pair kern="-202" kpx2="17"/><pair kern="-114" kpx2="128"/><pair kern="-77" kpx2="173"/><pair kern="-137" kpx2="109"/><pair kern="-128" kpx2="197"/><pair kern="-54" kpx2="38"/><pair kern="-132" kpx2="121"/><pair kern="-137" kpx2="110"/><pair kern="-77" kpx2="174"/></kerning><kerning kpx1="100"><pair kern="-17" kpx2="169"/><pair kern="-17" kpx2="60"/><pair kern="-17" kpx2="187"/><pair kern="18" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-17" kpx2="234"/></kerning><kerning kpx1="122"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="47"><pair kern="-17" kpx2="126"/><pair kern="-91" kpx2="235"/><pair kern="-49" kpx2="104"/><pair kern="-17" kpx2="72"/><pair kern="22" kpx2="199"/><pair kern="-17" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-49" kpx2="213"/><pair kern="-35" kpx2="208"/><pair kern="-132" kpx2="187"/><pair kern="-17" kpx2="113"/><pair kern="-202" kpx2="180"/><pair kern="-17" kpx2="129"/><pair kern="-17" kpx2="124"/><pair kern="22" kpx2="201"/><pair kern="-132" kpx2="60"/><pair kern="-49" kpx2="211"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="115"/><pair kern="-132" kpx2="234"/><pair kern="-17" kpx2="88"/><pair kern="-17" kpx2="122"/><pair kern="-35" kpx2="210"/><pair kern="22" kpx2="36"/><pair kern="-17" kpx2="82"/><pair kern="-91" kpx2="58"/><pair kern="-91" kpx2="186"/><pair kern="-137" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-35" kpx2="175"/><pair kern="-17" kpx2="127"/><pair kern="-35" kpx2="50"/><pair kern="-35" kpx2="209"/><pair kern="-35" kpx2="103"/><pair kern="22" kpx2="98"/><pair kern="-262" kpx2="181"/><pair kern="-17" kpx2="128"/><pair kern="22" kpx2="173"/><pair kern="-49" kpx2="212"/><pair kern="-91" kpx2="92"/><pair kern="-17" kpx2="121"/><pair kern="-109" kpx2="57"/><pair kern="22" kpx2="174"/><pair kern="-49" kpx2="56"/></kerning><kerning kpx1="210"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="58"><pair kern="-35" kpx2="126"/><pair kern="-63" kpx2="107"/><pair kern="-17" kpx2="235"/><pair kern="-58" kpx2="72"/><pair kern="-54" kpx2="199"/><pair kern="-40" kpx2="16"/><pair kern="-58" kpx2="112"/><pair kern="-58" kpx2="123"/><pair kern="-58" kpx2="113"/><pair kern="-17" kpx2="180"/><pair kern="-63" kpx2="105"/><pair kern="-35" kpx2="129"/><pair kern="-58" kpx2="124"/><pair kern="-54" kpx2="169"/><pair kern="-54" kpx2="201"/><pair kern="-44" kpx2="85"/><pair kern="-63" kpx2="106"/><pair kern="-58" kpx2="29"/><pair kern="-58" kpx2="125"/><pair kern="-17" kpx2="170"/><pair kern="-58" kpx2="115"/><pair kern="-35" kpx2="88"/><pair kern="-58" kpx2="122"/><pair kern="-63" kpx2="68"/><pair kern="-54" kpx2="36"/><pair kern="-58" kpx2="82"/><pair kern="-17" kpx2="186"/><pair kern="-58" kpx2="114"/><pair kern="-35" kpx2="127"/><pair kern="-63" kpx2="108"/><pair kern="-54" kpx2="98"/><pair kern="-21" kpx2="76"/><pair kern="-114" kpx2="17"/><pair kern="-35" kpx2="128"/><pair kern="-54" kpx2="173"/><pair kern="-63" kpx2="109"/><pair kern="-128" kpx2="197"/><pair kern="-17" kpx2="92"/><pair kern="-58" kpx2="121"/><pair kern="-63" kpx2="110"/><pair kern="-54" kpx2="174"/></kerning><kerning kpx1="82"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="186"><pair kern="-142" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-146" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-72" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="175"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="209"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="103"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="81"><pair kern="-72" kpx2="180"/><pair kern="-44" kpx2="197"/><pair kern="-54" kpx2="181"/></kerning><kerning kpx1="98"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="212"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning><kerning kpx1="229"><pair kern="-17" kpx2="180"/><pair kern="-17" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-17" kpx2="181"/></kerning><kerning kpx1="38"><pair kern="-17" kpx2="169"/><pair kern="-17" kpx2="60"/><pair kern="-17" kpx2="187"/><pair kern="18" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-17" kpx2="234"/></kerning><kerning kpx1="121"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="57"><pair kern="-67" kpx2="126"/><pair kern="-77" kpx2="107"/><pair kern="-26" kpx2="235"/><pair kern="-77" kpx2="72"/><pair kern="-63" kpx2="199"/><pair kern="-58" kpx2="16"/><pair kern="-77" kpx2="123"/><pair kern="-77" kpx2="112"/><pair kern="-17" kpx2="208"/><pair kern="-77" kpx2="113"/><pair kern="-77" kpx2="105"/><pair kern="-67" kpx2="129"/><pair kern="-77" kpx2="124"/><pair kern="-86" kpx2="169"/><pair kern="-63" kpx2="201"/><pair kern="-77" kpx2="106"/><pair kern="-81" kpx2="29"/><pair kern="-77" kpx2="125"/><pair kern="-54" kpx2="170"/><pair kern="-77" kpx2="115"/><pair kern="-67" kpx2="88"/><pair kern="-77" kpx2="122"/><pair kern="-77" kpx2="68"/><pair kern="-17" kpx2="210"/><pair kern="-63" kpx2="36"/><pair kern="-77" kpx2="82"/><pair kern="-26" kpx2="186"/><pair kern="-77" kpx2="114"/><pair kern="-17" kpx2="175"/><pair kern="-67" kpx2="127"/><pair kern="-17" kpx2="50"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="-77" kpx2="108"/><pair kern="-63" kpx2="98"/><pair kern="-21" kpx2="76"/><pair kern="-128" kpx2="17"/><pair kern="-67" kpx2="128"/><pair kern="-63" kpx2="173"/><pair kern="-77" kpx2="109"/><pair kern="-137" kpx2="197"/><pair kern="-26" kpx2="92"/><pair kern="-77" kpx2="121"/><pair kern="-77" kpx2="110"/><pair kern="-63" kpx2="174"/></kerning><kerning kpx1="37"><pair kern="-17" kpx2="227"/><pair kern="-17" kpx2="246"/><pair kern="-17" kpx2="251"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-17" kpx2="54"/><pair kern="-54" kpx2="180"/><pair kern="-30" kpx2="169"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="170"/><pair kern="-54" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="210"/><pair kern="-35" kpx2="58"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="50"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="-54" kpx2="181"/><pair kern="-40" kpx2="197"/><pair kern="-17" kpx2="38"/><pair kern="-30" kpx2="57"/><pair kern="-17" kpx2="249"/></kerning><kerning kpx1="120"><pair kern="-72" kpx2="180"/><pair kern="-44" kpx2="197"/><pair kern="-54" kpx2="181"/></kerning><kerning kpx1="249"><pair kern="18" kpx2="173"/><pair kern="18" kpx2="36"/><pair kern="18" kpx2="201"/><pair kern="18" kpx2="199"/><pair kern="18" kpx2="174"/><pair kern="18" kpx2="98"/></kerning><kerning kpx1="227"><pair kern="18" kpx2="173"/><pair kern="18" kpx2="36"/><pair kern="18" kpx2="201"/><pair kern="18" kpx2="199"/><pair kern="18" kpx2="174"/><pair kern="18" kpx2="98"/></kerning><kerning kpx1="51"><pair kern="-17" kpx2="126"/><pair kern="-44" kpx2="107"/><pair kern="-35" kpx2="72"/><pair kern="-63" kpx2="199"/><pair kern="-21" kpx2="16"/><pair kern="-35" kpx2="123"/><pair kern="-35" kpx2="112"/><pair kern="-21" kpx2="187"/><pair kern="-35" kpx2="113"/><pair kern="-17" kpx2="86"/><pair kern="18" kpx2="180"/><pair kern="-44" kpx2="105"/><pair kern="-17" kpx2="129"/><pair kern="-35" kpx2="124"/><pair kern="-17" kpx2="169"/><pair kern="-63" kpx2="201"/><pair kern="-17" kpx2="85"/><pair kern="-21" kpx2="60"/><pair kern="-44" kpx2="106"/><pair kern="-35" kpx2="125"/><pair kern="-35" kpx2="115"/><pair kern="-21" kpx2="234"/><pair kern="-17" kpx2="88"/><pair kern="-35" kpx2="122"/><pair kern="-44" kpx2="68"/><pair kern="-63" kpx2="36"/><pair kern="-35" kpx2="82"/><pair kern="-35" kpx2="114"/><pair kern="-17" kpx2="250"/><pair kern="-17" kpx2="127"/><pair kern="-44" kpx2="108"/><pair kern="-63" kpx2="98"/><pair kern="-17" kpx2="81"/><pair kern="-21" kpx2="76"/><pair kern="18" kpx2="181"/><pair kern="-155" kpx2="17"/><pair kern="-17" kpx2="128"/><pair kern="-63" kpx2="173"/><pair kern="-44" kpx2="109"/><pair kern="-160" kpx2="197"/><pair kern="-35" kpx2="121"/><pair kern="-17" kpx2="228"/><pair kern="-44" kpx2="110"/><pair kern="-63" kpx2="174"/><pair kern="-17" kpx2="120"/></kerning><kerning kpx1="104"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning><kerning kpx1="72"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="199"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="54"><pair kern="18" kpx2="173"/><pair kern="18" kpx2="36"/><pair kern="18" kpx2="201"/><pair kern="18" kpx2="199"/><pair kern="18" kpx2="174"/><pair kern="18" kpx2="98"/></kerning><kerning kpx1="180"><pair kern="-35" kpx2="235"/><pair kern="-35" kpx2="246"/><pair kern="-30" kpx2="43"/><pair kern="-72" kpx2="123"/><pair kern="-35" kpx2="251"/><pair kern="-35" kpx2="208"/><pair kern="-188" kpx2="144"/><pair kern="-58" kpx2="59"/><pair kern="-35" kpx2="73"/><pair kern="-30" kpx2="41"/><pair kern="-72" kpx2="124"/><pair kern="-54" kpx2="85"/><pair kern="-128" kpx2="201"/><pair kern="-17" kpx2="61"/><pair kern="-35" kpx2="100"/><pair kern="-72" kpx2="122"/><pair kern="-30" kpx2="47"/><pair kern="-35" kpx2="210"/><pair kern="-72" kpx2="82"/><pair kern="-35" kpx2="186"/><pair kern="-35" kpx2="175"/><pair kern="-35" kpx2="209"/><pair kern="-35" kpx2="103"/><pair kern="-128" kpx2="98"/><pair kern="-54" kpx2="81"/><pair kern="-17" kpx2="229"/><pair kern="-35" kpx2="38"/><pair kern="-72" kpx2="121"/><pair kern="-30" kpx2="37"/><pair kern="-54" kpx2="120"/><pair kern="-30" kpx2="51"/><pair kern="-128" kpx2="199"/><pair kern="-30" kpx2="53"/><pair kern="-30" kpx2="137"/><pair kern="-35" kpx2="233"/><pair kern="-35" kpx2="253"/><pair kern="-35" kpx2="52"/><pair kern="-72" kpx2="125"/><pair kern="-35" kpx2="42"/><pair kern="-35" kpx2="90"/><pair kern="-128" kpx2="36"/><pair kern="-35" kpx2="50"/><pair kern="-30" kpx2="39"/><pair kern="-30" kpx2="236"/><pair kern="-30" kpx2="45"/><pair kern="-128" kpx2="173"/><pair kern="-35" kpx2="92"/><pair kern="-35" kpx2="89"/><pair kern="-30" kpx2="46"/><pair kern="-128" kpx2="174"/></kerning><kerning kpx1="53"><pair kern="-21" kpx2="107"/><pair kern="-54" kpx2="235"/><pair kern="-40" kpx2="16"/><pair kern="-44" kpx2="112"/><pair kern="-44" kpx2="123"/><pair kern="-49" kpx2="251"/><pair kern="-44" kpx2="113"/><pair kern="-63" kpx2="187"/><pair kern="-44" kpx2="129"/><pair kern="-44" kpx2="124"/><pair kern="-54" kpx2="169"/><pair kern="-63" kpx2="60"/><pair kern="-40" kpx2="201"/><pair kern="-21" kpx2="106"/><pair kern="-30" kpx2="29"/><pair kern="-63" kpx2="234"/><pair kern="-49" kpx2="100"/><pair kern="-44" kpx2="122"/><pair kern="-21" kpx2="68"/><pair kern="-40" kpx2="58"/><pair kern="-44" kpx2="82"/><pair kern="-54" kpx2="186"/><pair kern="-40" kpx2="98"/><pair kern="-63" kpx2="181"/><pair kern="-35" kpx2="17"/><pair kern="-49" kpx2="38"/><pair kern="-44" kpx2="121"/><pair kern="-54" kpx2="57"/><pair kern="-44" kpx2="126"/><pair kern="-44" kpx2="72"/><pair kern="-40" kpx2="199"/><pair kern="-72" kpx2="180"/><pair kern="-21" kpx2="105"/><pair kern="-49" kpx2="253"/><pair kern="-44" kpx2="125"/><pair kern="-44" kpx2="115"/><pair kern="-17" kpx2="170"/><pair kern="-44" kpx2="88"/><pair kern="-40" kpx2="36"/><pair kern="-44" kpx2="114"/><pair kern="-72" kpx2="55"/><pair kern="-44" kpx2="127"/><pair kern="-21" kpx2="108"/><pair kern="-44" kpx2="128"/><pair kern="-40" kpx2="173"/><pair kern="-21" kpx2="109"/><pair kern="-54" kpx2="92"/><pair kern="-17" kpx2="197"/><pair kern="-21" kpx2="110"/><pair kern="-40" kpx2="174"/></kerning><kerning kpx1="137"><pair kern="-54" kpx2="180"/><pair kern="-40" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-54" kpx2="181"/></kerning><kerning kpx1="233"><pair kern="-44" kpx2="180"/><pair kern="-35" kpx2="197"/><pair kern="-54" kpx2="181"/></kerning><kerning kpx1="253"><pair kern="-17" kpx2="169"/><pair kern="-17" kpx2="60"/><pair kern="-17" kpx2="187"/><pair kern="18" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-17" kpx2="234"/></kerning><kerning kpx1="211"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning><kerning kpx1="78"><pair kern="-17" kpx2="107"/><pair kern="-30" kpx2="126"/><pair kern="-35" kpx2="235"/><pair kern="-35" kpx2="72"/><pair kern="-35" kpx2="112"/><pair kern="-35" kpx2="123"/><pair kern="-35" kpx2="113"/><pair kern="-17" kpx2="105"/><pair kern="-30" kpx2="129"/><pair kern="-35" kpx2="124"/><pair kern="-17" kpx2="106"/><pair kern="-35" kpx2="125"/><pair kern="-35" kpx2="115"/><pair kern="-30" kpx2="88"/><pair kern="-35" kpx2="122"/><pair kern="-17" kpx2="68"/><pair kern="-35" kpx2="82"/><pair kern="-35" kpx2="114"/><pair kern="-35" kpx2="186"/><pair kern="-30" kpx2="127"/><pair kern="-17" kpx2="108"/><pair kern="-30" kpx2="128"/><pair kern="-17" kpx2="109"/><pair kern="-35" kpx2="92"/><pair kern="-35" kpx2="121"/><pair kern="-17" kpx2="110"/></kerning><kerning kpx1="52"><pair kern="-21" kpx2="180"/><pair kern="-63" kpx2="197"/><pair kern="27" kpx2="16"/><pair kern="-17" kpx2="181"/></kerning><kerning kpx1="125"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="42"><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="169"/><pair kern="-26" kpx2="197"/><pair kern="-35" kpx2="55"/><pair kern="-49" kpx2="60"/><pair kern="-49" kpx2="187"/><pair kern="-21" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-49" kpx2="234"/></kerning><kerning kpx1="170"><pair kern="-17" kpx2="235"/><pair kern="-35" kpx2="199"/><pair kern="-17" kpx2="251"/><pair kern="-109" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-54" kpx2="59"/><pair kern="-109" kpx2="60"/><pair kern="-35" kpx2="201"/><pair kern="-17" kpx2="253"/><pair kern="-109" kpx2="234"/><pair kern="-17" kpx2="90"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="210"/><pair kern="-35" kpx2="36"/><pair kern="-54" kpx2="58"/><pair kern="-91" kpx2="55"/><pair kern="-17" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="50"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="-17" kpx2="39"/><pair kern="-35" kpx2="98"/><pair kern="-17" kpx2="45"/><pair kern="-35" kpx2="173"/><pair kern="-17" kpx2="92"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="89"/><pair kern="-86" kpx2="57"/><pair kern="-35" kpx2="37"/><pair kern="-35" kpx2="174"/></kerning><kerning kpx1="115"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="90"><pair kern="-91" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-104" kpx2="197"/><pair kern="-54" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="36"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="55"><pair kern="-165" kpx2="107"/><pair kern="-155" kpx2="235"/><pair kern="-91" kpx2="16"/><pair kern="-169" kpx2="112"/><pair kern="-169" kpx2="123"/><pair kern="-58" kpx2="251"/><pair kern="-169" kpx2="113"/><pair kern="-165" kpx2="86"/><pair kern="-151" kpx2="129"/><pair kern="-169" kpx2="124"/><pair kern="-91" kpx2="169"/><pair kern="-169" kpx2="252"/><pair kern="-169" kpx2="70"/><pair kern="-146" kpx2="85"/><pair kern="-77" kpx2="201"/><pair kern="-165" kpx2="106"/><pair kern="-109" kpx2="29"/><pair kern="-58" kpx2="100"/><pair kern="-169" kpx2="122"/><pair kern="-165" kpx2="68"/><pair kern="-169" kpx2="82"/><pair kern="-155" kpx2="186"/><pair kern="-165" kpx2="250"/><pair kern="-77" kpx2="98"/><pair kern="-21" kpx2="181"/><pair kern="-118" kpx2="17"/><pair kern="-58" kpx2="38"/><pair kern="-169" kpx2="121"/><pair kern="-165" kpx2="228"/><pair kern="-169" kpx2="254"/><pair kern="-151" kpx2="126"/><pair kern="-169" kpx2="72"/><pair kern="-77" kpx2="199"/><pair kern="-165" kpx2="105"/><pair kern="-58" kpx2="253"/><pair kern="-169" kpx2="125"/><pair kern="-169" kpx2="115"/><pair kern="-54" kpx2="170"/><pair kern="-151" kpx2="88"/><pair kern="-169" kpx2="111"/><pair kern="-165" kpx2="90"/><pair kern="-77" kpx2="36"/><pair kern="-17" kpx2="55"/><pair kern="-169" kpx2="114"/><pair kern="-151" kpx2="127"/><pair kern="-165" kpx2="108"/><pair kern="-30" kpx2="76"/><pair kern="-151" kpx2="128"/><pair kern="-77" kpx2="173"/><pair kern="-165" kpx2="109"/><pair kern="-155" kpx2="92"/><pair kern="-128" kpx2="197"/><pair kern="-165" kpx2="110"/><pair kern="-77" kpx2="174"/></kerning><kerning kpx1="114"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="50"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="91"><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="111"/><pair kern="-30" kpx2="122"/><pair kern="-30" kpx2="82"/><pair kern="-30" kpx2="114"/><pair kern="-30" kpx2="72"/><pair kern="-30" kpx2="112"/><pair kern="-30" kpx2="123"/><pair kern="-30" kpx2="113"/><pair kern="-30" kpx2="124"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-30" kpx2="121"/><pair kern="-30" kpx2="125"/><pair kern="-30" kpx2="115"/></kerning><kerning kpx1="39"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="-17" kpx2="98"/><pair kern="-54" kpx2="187"/><pair kern="-26" kpx2="181"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-17" kpx2="170"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="236"><pair kern="-17" kpx2="180"/><pair kern="-72" kpx2="17"/><pair kern="-91" kpx2="197"/><pair kern="-35" kpx2="29"/></kerning><kerning kpx1="45"><pair kern="-35" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="169"/><pair kern="-54" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-17" kpx2="199"/><pair kern="-35" kpx2="16"/><pair kern="-17" kpx2="174"/><pair kern="-17" kpx2="98"/><pair kern="-30" kpx2="181"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="173"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="197"><pair kern="-35" kpx2="246"/><pair kern="-54" kpx2="235"/><pair kern="-35" kpx2="43"/><pair kern="-35" kpx2="123"/><pair kern="-54" kpx2="251"/><pair kern="-183" kpx2="187"/><pair kern="-54" kpx2="208"/><pair kern="18" kpx2="144"/><pair kern="-35" kpx2="59"/><pair kern="-17" kpx2="73"/><pair kern="-35" kpx2="41"/><pair kern="-35" kpx2="124"/><pair kern="-35" kpx2="85"/><pair kern="-183" kpx2="60"/><pair kern="18" kpx2="201"/><pair kern="-183" kpx2="234"/><pair kern="-54" kpx2="100"/><pair kern="-35" kpx2="122"/><pair kern="-35" kpx2="47"/><pair kern="-54" kpx2="210"/><pair kern="-35" kpx2="82"/><pair kern="-123" kpx2="58"/><pair kern="-54" kpx2="186"/><pair kern="-54" kpx2="175"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-35" kpx2="81"/><pair kern="18" kpx2="98"/><pair kern="-54" kpx2="38"/><pair kern="-35" kpx2="121"/><pair kern="-183" kpx2="57"/><pair kern="-35" kpx2="37"/><pair kern="-35" kpx2="120"/><pair kern="-35" kpx2="51"/><pair kern="18" kpx2="199"/><pair kern="-35" kpx2="53"/><pair kern="-35" kpx2="137"/><pair kern="-35" kpx2="233"/><pair kern="-54" kpx2="253"/><pair kern="-54" kpx2="52"/><pair kern="-35" kpx2="125"/><pair kern="-35" kpx2="42"/><pair kern="-95" kpx2="90"/><pair kern="18" kpx2="36"/><pair kern="-137" kpx2="55"/><pair kern="-54" kpx2="50"/><pair kern="-35" kpx2="39"/><pair kern="-35" kpx2="236"/><pair kern="22" kpx2="45"/><pair kern="18" kpx2="173"/><pair kern="-54" kpx2="92"/><pair kern="-114" kpx2="89"/><pair kern="-35" kpx2="46"/><pair kern="18" kpx2="174"/></kerning><kerning kpx1="92"><pair kern="-142" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-146" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-72" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="89"><pair kern="-77" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-132" kpx2="197"/><pair kern="-26" kpx2="16"/><pair kern="-54" kpx2="29"/><pair kern="-17" kpx2="181"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="46"><pair kern="-17" kpx2="107"/><pair kern="-72" kpx2="235"/><pair kern="-104" kpx2="16"/><pair kern="-49" kpx2="112"/><pair kern="-49" kpx2="123"/><pair kern="-54" kpx2="251"/><pair kern="-26" kpx2="213"/><pair kern="-49" kpx2="113"/><pair kern="-35" kpx2="187"/><pair kern="-54" kpx2="208"/><pair kern="-49" kpx2="129"/><pair kern="-49" kpx2="124"/><pair kern="-63" kpx2="169"/><pair kern="-35" kpx2="60"/><pair kern="-17" kpx2="201"/><pair kern="-17" kpx2="106"/><pair kern="-35" kpx2="234"/><pair kern="-54" kpx2="100"/><pair kern="-49" kpx2="122"/><pair kern="-17" kpx2="68"/><pair kern="-54" kpx2="210"/><pair kern="-35" kpx2="58"/><pair kern="-49" kpx2="82"/><pair kern="-72" kpx2="186"/><pair kern="-54" kpx2="175"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-17" kpx2="98"/><pair kern="-30" kpx2="181"/><pair kern="-26" kpx2="212"/><pair kern="-54" kpx2="38"/><pair kern="-49" kpx2="121"/><pair kern="-49" kpx2="126"/><pair kern="-26" kpx2="104"/><pair kern="-49" kpx2="72"/><pair kern="-17" kpx2="199"/><pair kern="-30" kpx2="180"/><pair kern="-17" kpx2="105"/><pair kern="-54" kpx2="253"/><pair kern="-26" kpx2="211"/><pair kern="-49" kpx2="125"/><pair kern="-49" kpx2="115"/><pair kern="-49" kpx2="88"/><pair kern="-17" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-49" kpx2="114"/><pair kern="-54" kpx2="50"/><pair kern="-49" kpx2="127"/><pair kern="-17" kpx2="108"/><pair kern="-49" kpx2="128"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="109"/><pair kern="-72" kpx2="92"/><pair kern="-17" kpx2="110"/><pair kern="-17" kpx2="174"/><pair kern="-26" kpx2="56"/></kerning><kerning kpx1="174"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="56"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning></font-metrics>
\ No newline at end of file
diff --git a/documentation/template/VeraMoBd.ttf b/documentation/template/VeraMoBd.ttf
new file mode 100644
index 0000000000..9be6547ed6
--- /dev/null
+++ b/documentation/template/VeraMoBd.ttf
diff --git a/documentation/template/VeraMoBd.xml b/documentation/template/VeraMoBd.xml
new file mode 100644
index 0000000000..9b33107a44
--- /dev/null
+++ b/documentation/template/VeraMoBd.xml
@@ -0,0 +1 @@
+<?xml version="1.0" encoding="UTF-8"?><font-metrics metrics-version="2" type="TYPE0"><font-name>BitstreamVeraSansMono-Bold</font-name><full-name>Bitstream Vera Sans Mono Bold</full-name><family-name>Bitstream Vera Sans Mono</family-name><embed/><cap-height>729</cap-height><x-height>546</x-height><ascender>759</ascender><descender>-240</descender><bbox><left>-19</left><bottom>-235</bottom><right>605</right><top>928</top></bbox><flags>34</flags><stemv>0</stemv><italicangle>0</italicangle><subtype>TYPE0</subtype><multibyte-extras><cid-type>CIDFontType2</cid-type><default-width>0</default-width><bfranges><bf gi="3" ue="126" us="32"/><bf gi="172" ue="160" us="160"/><bf gi="163" ue="161" us="161"/><bf gi="132" ue="163" us="162"/><bf gi="189" ue="164" us="164"/><bf gi="150" ue="165" us="165"/><bf gi="231" ue="166" us="166"/><bf gi="134" ue="167" us="167"/><bf gi="142" ue="168" us="168"/><bf gi="139" ue="169" us="169"/><bf gi="157" ue="170" us="170"/><bf gi="169" ue="171" us="171"/><bf gi="164" ue="172" us="172"/><bf gi="256" ue="173" us="173"/><bf gi="138" ue="174" us="174"/><bf gi="217" ue="175" us="175"/><bf gi="131" ue="176" us="176"/><bf gi="147" ue="177" us="177"/><bf gi="241" ue="179" us="178"/><bf gi="141" ue="180" us="180"/><bf gi="151" ue="181" us="181"/><bf gi="136" ue="182" us="182"/><bf gi="195" ue="183" us="183"/><bf gi="221" ue="184" us="184"/><bf gi="240" ue="185" us="185"/><bf gi="158" ue="186" us="186"/><bf gi="170" ue="187" us="187"/><bf gi="243" ue="190" us="188"/><bf gi="162" ue="191" us="191"/><bf gi="173" ue="192" us="192"/><bf gi="201" ue="193" us="193"/><bf gi="199" ue="194" us="194"/><bf gi="174" ue="195" us="195"/><bf gi="98" ue="197" us="196"/><bf gi="144" ue="198" us="198"/><bf gi="100" ue="199" us="199"/><bf gi="203" ue="200" us="200"/><bf gi="101" ue="201" us="201"/><bf gi="200" ue="202" us="202"/><bf gi="202" ue="203" us="203"/><bf gi="207" ue="204" us="204"/><bf gi="204" ue="207" us="205"/><bf gi="232" ue="208" us="208"/><bf gi="102" ue="209" us="209"/><bf gi="210" ue="210" us="210"/><bf gi="208" ue="212" us="211"/><bf gi="175" ue="213" us="213"/><bf gi="103" ue="214" us="214"/><bf gi="239" ue="215" us="215"/><bf gi="145" ue="216" us="216"/><bf gi="213" ue="217" us="217"/><bf gi="211" ue="219" us="218"/><bf gi="104" ue="220" us="220"/><bf gi="234" ue="221" us="221"/><bf gi="236" ue="222" us="222"/><bf gi="137" ue="223" us="223"/><bf gi="106" ue="224" us="224"/><bf gi="105" ue="225" us="225"/><bf gi="107" ue="226" us="226"/><bf gi="109" ue="227" us="227"/><bf gi="108" ue="228" us="228"/><bf gi="110" ue="229" us="229"/><bf gi="160" ue="230" us="230"/><bf gi="111" ue="231" us="231"/><bf gi="113" ue="232" us="232"/><bf gi="112" ue="233" us="233"/><bf gi="114" ue="235" us="234"/><bf gi="117" ue="236" us="236"/><bf gi="116" ue="237" us="237"/><bf gi="118" ue="239" us="238"/><bf gi="233" ue="240" us="240"/><bf gi="120" ue="241" us="241"/><bf gi="122" ue="242" us="242"/><bf gi="121" ue="243" us="243"/><bf gi="123" ue="244" us="244"/><bf gi="125" ue="245" us="245"/><bf gi="124" ue="246" us="246"/><bf gi="184" ue="247" us="247"/><bf gi="161" ue="248" us="248"/><bf gi="127" ue="249" us="249"/><bf gi="126" ue="250" us="250"/><bf gi="128" ue="252" us="251"/><bf gi="235" ue="253" us="253"/><bf gi="237" ue="254" us="254"/><bf gi="186" ue="255" us="255"/><bf gi="251" ue="263" us="262"/><bf gi="253" ue="269" us="268"/><bf gi="0" ue="270" us="270"/><bf gi="0" ue="271" us="271"/><bf gi="0" ue="272" us="272"/><bf gi="255" ue="273" us="273"/><bf gi="246" ue="287" us="286"/><bf gi="248" ue="304" us="304"/><bf gi="214" ue="305" us="305"/><bf gi="225" ue="322" us="321"/><bf gi="176" ue="339" us="338"/><bf gi="249" ue="351" us="350"/><bf gi="227" ue="353" us="352"/><bf gi="187" ue="376" us="376"/><bf gi="229" ue="382" us="381"/><bf gi="166" ue="402" us="402"/><bf gi="215" ue="710" us="710"/><bf gi="224" ue="711" us="711"/><bf gi="218" ue="730" us="728"/><bf gi="223" ue="731" us="731"/><bf gi="216" ue="732" us="732"/><bf gi="222" ue="733" us="733"/><bf gi="159" ue="937" us="937"/><bf gi="155" ue="960" us="960"/><bf gi="178" ue="8212" us="8211"/><bf gi="0" ue="8213" us="8213"/><bf gi="0" ue="8214" us="8214"/><bf gi="0" ue="8215" us="8215"/><bf gi="182" ue="8217" us="8216"/><bf gi="196" ue="8218" us="8218"/><bf gi="0" ue="8219" us="8219"/><bf gi="180" ue="8221" us="8220"/><bf gi="197" ue="8222" us="8222"/><bf gi="0" ue="8223" us="8223"/><bf gi="130" ue="8224" us="8224"/><bf gi="194" ue="8225" us="8225"/><bf gi="135" ue="8226" us="8226"/><bf gi="0" ue="8227" us="8227"/><bf gi="0" ue="8228" us="8228"/><bf gi="0" ue="8229" us="8229"/><bf gi="171" ue="8230" us="8230"/><bf gi="198" ue="8240" us="8240"/><bf gi="190" ue="8250" us="8249"/><bf gi="258" ue="8364" us="8364"/><bf gi="140" ue="8482" us="8482"/><bf gi="152" ue="8706" us="8706"/><bf gi="0" ue="8707" us="8707"/><bf gi="0" ue="8708" us="8708"/><bf gi="0" ue="8709" us="8709"/><bf gi="168" ue="8710" us="8710"/><bf gi="154" ue="8719" us="8719"/><bf gi="0" ue="8720" us="8720"/><bf gi="153" ue="8721" us="8721"/><bf gi="238" ue="8722" us="8722"/><bf gi="0" ue="8723" us="8723"/><bf gi="0" ue="8724" us="8724"/><bf gi="188" ue="8725" us="8725"/><bf gi="0" ue="8726" us="8726"/><bf gi="0" ue="8727" us="8727"/><bf gi="0" ue="8728" us="8728"/><bf gi="257" ue="8729" us="8729"/><bf gi="165" ue="8730" us="8730"/><bf gi="0" ue="8731" us="8731"/><bf gi="0" ue="8732" us="8732"/><bf gi="0" ue="8733" us="8733"/><bf gi="146" ue="8734" us="8734"/><bf gi="156" ue="8747" us="8747"/><bf gi="167" ue="8776" us="8776"/><bf gi="143" ue="8800" us="8800"/><bf gi="0" ue="8801" us="8801"/><bf gi="0" ue="8802" us="8802"/><bf gi="0" ue="8803" us="8803"/><bf gi="148" ue="8805" us="8804"/><bf gi="185" ue="9674" us="9674"/><bf gi="192" ue="64258" us="64257"/><bf gi="0" ue="65535" us="65535"/></bfranges><cid-widths start-index="0"><wx w="602"/><wx w="0"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/></cid-widths></multibyte-extras></font-metrics>
\ No newline at end of file
diff --git a/documentation/template/VeraMono.ttf b/documentation/template/VeraMono.ttf
new file mode 100644
index 0000000000..139f0b4311
--- /dev/null
+++ b/documentation/template/VeraMono.ttf
diff --git a/documentation/template/VeraMono.xml b/documentation/template/VeraMono.xml
new file mode 100644
index 0000000000..3a0a86659c
--- /dev/null
+++ b/documentation/template/VeraMono.xml
@@ -0,0 +1 @@
+<?xml version="1.0" encoding="UTF-8"?><font-metrics metrics-version="2" type="TYPE0"><font-name>BitstreamVeraSansMono-Roman</font-name><full-name>Bitstream Vera Sans Mono</full-name><family-name>Bitstream Vera Sans Mono</family-name><embed/><cap-height>729</cap-height><x-height>546</x-height><ascender>759</ascender><descender>-240</descender><bbox><left>-4</left><bottom>-235</bottom><right>605</right><top>928</top></bbox><flags>34</flags><stemv>0</stemv><italicangle>0</italicangle><subtype>TYPE0</subtype><multibyte-extras><cid-type>CIDFontType2</cid-type><default-width>0</default-width><bfranges><bf gi="3" ue="126" us="32"/><bf gi="172" ue="160" us="160"/><bf gi="163" ue="161" us="161"/><bf gi="132" ue="163" us="162"/><bf gi="189" ue="164" us="164"/><bf gi="150" ue="165" us="165"/><bf gi="231" ue="166" us="166"/><bf gi="134" ue="167" us="167"/><bf gi="142" ue="168" us="168"/><bf gi="139" ue="169" us="169"/><bf gi="157" ue="170" us="170"/><bf gi="169" ue="171" us="171"/><bf gi="164" ue="172" us="172"/><bf gi="256" ue="173" us="173"/><bf gi="138" ue="174" us="174"/><bf gi="217" ue="175" us="175"/><bf gi="131" ue="176" us="176"/><bf gi="147" ue="177" us="177"/><bf gi="241" ue="179" us="178"/><bf gi="141" ue="180" us="180"/><bf gi="151" ue="181" us="181"/><bf gi="136" ue="182" us="182"/><bf gi="195" ue="183" us="183"/><bf gi="221" ue="184" us="184"/><bf gi="240" ue="185" us="185"/><bf gi="158" ue="186" us="186"/><bf gi="170" ue="187" us="187"/><bf gi="243" ue="190" us="188"/><bf gi="162" ue="191" us="191"/><bf gi="173" ue="192" us="192"/><bf gi="201" ue="193" us="193"/><bf gi="199" ue="194" us="194"/><bf gi="174" ue="195" us="195"/><bf gi="98" ue="197" us="196"/><bf gi="144" ue="198" us="198"/><bf gi="100" ue="199" us="199"/><bf gi="203" ue="200" us="200"/><bf gi="101" ue="201" us="201"/><bf gi="200" ue="202" us="202"/><bf gi="202" ue="203" us="203"/><bf gi="207" ue="204" us="204"/><bf gi="204" ue="207" us="205"/><bf gi="232" ue="208" us="208"/><bf gi="102" ue="209" us="209"/><bf gi="210" ue="210" us="210"/><bf gi="208" ue="212" us="211"/><bf gi="175" ue="213" us="213"/><bf gi="103" ue="214" us="214"/><bf gi="239" ue="215" us="215"/><bf gi="145" ue="216" us="216"/><bf gi="213" ue="217" us="217"/><bf gi="211" ue="219" us="218"/><bf gi="104" ue="220" us="220"/><bf gi="234" ue="221" us="221"/><bf gi="236" ue="222" us="222"/><bf gi="137" ue="223" us="223"/><bf gi="106" ue="224" us="224"/><bf gi="105" ue="225" us="225"/><bf gi="107" ue="226" us="226"/><bf gi="109" ue="227" us="227"/><bf gi="108" ue="228" us="228"/><bf gi="110" ue="229" us="229"/><bf gi="160" ue="230" us="230"/><bf gi="111" ue="231" us="231"/><bf gi="113" ue="232" us="232"/><bf gi="112" ue="233" us="233"/><bf gi="114" ue="235" us="234"/><bf gi="117" ue="236" us="236"/><bf gi="116" ue="237" us="237"/><bf gi="118" ue="239" us="238"/><bf gi="233" ue="240" us="240"/><bf gi="120" ue="241" us="241"/><bf gi="122" ue="242" us="242"/><bf gi="121" ue="243" us="243"/><bf gi="123" ue="244" us="244"/><bf gi="125" ue="245" us="245"/><bf gi="124" ue="246" us="246"/><bf gi="184" ue="247" us="247"/><bf gi="161" ue="248" us="248"/><bf gi="127" ue="249" us="249"/><bf gi="126" ue="250" us="250"/><bf gi="128" ue="252" us="251"/><bf gi="235" ue="253" us="253"/><bf gi="237" ue="254" us="254"/><bf gi="186" ue="255" us="255"/><bf gi="251" ue="263" us="262"/><bf gi="253" ue="269" us="268"/><bf gi="0" ue="270" us="270"/><bf gi="0" ue="271" us="271"/><bf gi="0" ue="272" us="272"/><bf gi="255" ue="273" us="273"/><bf gi="246" ue="287" us="286"/><bf gi="248" ue="304" us="304"/><bf gi="214" ue="305" us="305"/><bf gi="225" ue="322" us="321"/><bf gi="176" ue="339" us="338"/><bf gi="249" ue="351" us="350"/><bf gi="227" ue="353" us="352"/><bf gi="187" ue="376" us="376"/><bf gi="229" ue="382" us="381"/><bf gi="166" ue="402" us="402"/><bf gi="215" ue="710" us="710"/><bf gi="224" ue="711" us="711"/><bf gi="218" ue="730" us="728"/><bf gi="223" ue="731" us="731"/><bf gi="216" ue="732" us="732"/><bf gi="222" ue="733" us="733"/><bf gi="159" ue="937" us="937"/><bf gi="155" ue="960" us="960"/><bf gi="178" ue="8212" us="8211"/><bf gi="0" ue="8213" us="8213"/><bf gi="0" ue="8214" us="8214"/><bf gi="0" ue="8215" us="8215"/><bf gi="182" ue="8217" us="8216"/><bf gi="196" ue="8218" us="8218"/><bf gi="0" ue="8219" us="8219"/><bf gi="180" ue="8221" us="8220"/><bf gi="197" ue="8222" us="8222"/><bf gi="0" ue="8223" us="8223"/><bf gi="130" ue="8224" us="8224"/><bf gi="194" ue="8225" us="8225"/><bf gi="135" ue="8226" us="8226"/><bf gi="0" ue="8227" us="8227"/><bf gi="0" ue="8228" us="8228"/><bf gi="0" ue="8229" us="8229"/><bf gi="171" ue="8230" us="8230"/><bf gi="198" ue="8240" us="8240"/><bf gi="190" ue="8250" us="8249"/><bf gi="258" ue="8364" us="8364"/><bf gi="140" ue="8482" us="8482"/><bf gi="152" ue="8706" us="8706"/><bf gi="0" ue="8707" us="8707"/><bf gi="0" ue="8708" us="8708"/><bf gi="0" ue="8709" us="8709"/><bf gi="168" ue="8710" us="8710"/><bf gi="154" ue="8719" us="8719"/><bf gi="0" ue="8720" us="8720"/><bf gi="153" ue="8721" us="8721"/><bf gi="238" ue="8722" us="8722"/><bf gi="0" ue="8723" us="8723"/><bf gi="0" ue="8724" us="8724"/><bf gi="188" ue="8725" us="8725"/><bf gi="0" ue="8726" us="8726"/><bf gi="0" ue="8727" us="8727"/><bf gi="0" ue="8728" us="8728"/><bf gi="257" ue="8729" us="8729"/><bf gi="165" ue="8730" us="8730"/><bf gi="0" ue="8731" us="8731"/><bf gi="0" ue="8732" us="8732"/><bf gi="0" ue="8733" us="8733"/><bf gi="146" ue="8734" us="8734"/><bf gi="156" ue="8747" us="8747"/><bf gi="167" ue="8776" us="8776"/><bf gi="143" ue="8800" us="8800"/><bf gi="0" ue="8801" us="8801"/><bf gi="0" ue="8802" us="8802"/><bf gi="0" ue="8803" us="8803"/><bf gi="148" ue="8805" us="8804"/><bf gi="185" ue="9674" us="9674"/><bf gi="192" ue="64258" us="64257"/><bf gi="0" ue="65535" us="65535"/></bfranges><cid-widths start-index="0"><wx w="602"/><wx w="0"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/></cid-widths></multibyte-extras></font-metrics>
\ No newline at end of file
diff --git a/documentation/template/component.title.xsl b/documentation/template/component.title.xsl
new file mode 100644
index 0000000000..ee21d59ad5
--- /dev/null
+++ b/documentation/template/component.title.xsl
@@ -0,0 +1,39 @@
+<xsl:stylesheet version="1.0"
+  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+  xmlns:d="http://docbook.org/ns/docbook"
+  xmlns="http://www.w3.org/1999/xhtml"
+  exclude-result-prefixes="d">
+
+  <xsl:template name="component.title">
+    <xsl:param name="node" select="."/>
+
+    <xsl:variable name="level">
+      <xsl:choose>
+        <xsl:when test="ancestor::d:section">
+          <xsl:value-of select="count(ancestor::d:section)+1"/>
+        </xsl:when>
+        <xsl:when test="ancestor::sect5">6</xsl:when>
+        <xsl:when test="ancestor::sect4">5</xsl:when>
+        <xsl:when test="ancestor::sect3">4</xsl:when>
+        <xsl:when test="ancestor::sect2">3</xsl:when>
+        <xsl:when test="ancestor::sect1">2</xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:element name="h{$level+1}" namespace="http://www.w3.org/1999/xhtml">
+      <xsl:attribute name="class">title</xsl:attribute>
+      <xsl:if test="$generate.id.attributes = 0">
+        <xsl:call-template name="anchor">
+          <xsl:with-param name="node" select="$node"/>
+          <xsl:with-param name="conditional" select="0"/>
+        </xsl:call-template>
+      </xsl:if>
+      <xsl:apply-templates select="$node" mode="object.title.markup">
+        <xsl:with-param name="allow-anchors" select="1"/>
+      </xsl:apply-templates>
+      <xsl:call-template name="permalink">
+        <xsl:with-param name="node" select="$node"/>
+      </xsl:call-template>
+    </xsl:element>
+  </xsl:template>
+</xsl:stylesheet>
diff --git a/documentation/template/division.title.xsl b/documentation/template/division.title.xsl
new file mode 100644
index 0000000000..6c265970d5
--- /dev/null
+++ b/documentation/template/division.title.xsl
@@ -0,0 +1,24 @@
+<xsl:stylesheet version="1.0"
+  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+  xmlns:d="http://docbook.org/ns/docbook"
+  xmlns="http://www.w3.org/1999/xhtml"
+  exclude-result-prefixes="d">
+  
+  <xsl:template name="division.title">
+    <xsl:param name="node" select="."/>
+    
+    <h1>
+      <xsl:attribute name="class">title</xsl:attribute>
+      <xsl:call-template name="anchor">
+        <xsl:with-param name="node" select="$node"/>
+        <xsl:with-param name="conditional" select="0"/>
+      </xsl:call-template>
+      <xsl:apply-templates select="$node" mode="object.title.markup">
+        <xsl:with-param name="allow-anchors" select="1"/>
+      </xsl:apply-templates>
+      <xsl:call-template name="permalink">
+        <xsl:with-param name="node" select="$node"/>
+      </xsl:call-template>
+    </h1>
+  </xsl:template>
+</xsl:stylesheet>
diff --git a/documentation/template/draft.png b/documentation/template/draft.png
new file mode 100644
index 0000000000..53051a9ddd
--- /dev/null
+++ b/documentation/template/draft.png
diff --git a/documentation/template/fop-config.xml b/documentation/template/fop-config.xml
new file mode 100644
index 0000000000..09cc5ca0f5
--- /dev/null
+++ b/documentation/template/fop-config.xml
@@ -0,0 +1,58 @@
+<fop version="1.0">
+
+  <!-- Strict user configuration -->
+  <strict-configuration>true</strict-configuration>
+
+  <!-- Strict FO validation -->
+  <strict-validation>true</strict-validation>
+
+   <!--
+    Set the baseDir so common/openedhand.svg references in plans still
+    work ok. Note, relative file references to current dir should still work.
+    --> 
+  <base>../template</base>
+  <font-base>../template</font-base>
+ 
+  <!-- Source resolution in dpi (dots/pixels per inch) for determining the
+       size of pixels in SVG and bitmap images, default: 72dpi -->
+  <!-- <source-resolution>72</source-resolution> -->
+  <!-- Target resolution in dpi (dots/pixels per inch) for specifying the
+       target resolution for generated bitmaps, default: 72dpi -->
+  <!-- <target-resolution>72</target-resolution> -->
+ 
+  <!-- default page-height and page-width, in case
+       value is specified as auto -->
+  <default-page-settings height="11in" width="8.26in"/> 
+ 
+  <!-- <use-cache>false</use-cache> -->
+ 
+  <renderers>
+    <renderer mime="application/pdf">
+      <fonts>
+        <font  metrics-file="VeraMono.xml"
+               kerning="yes" 
+               embed-url="VeraMono.ttf">
+          <font-triplet name="veramono" style="normal" weight="normal"/>
+        </font>
+
+        <font  metrics-file="VeraMoBd.xml"
+               kerning="yes" 
+               embed-url="VeraMoBd.ttf">
+          <font-triplet name="veramono" style="normal" weight="bold"/>
+        </font>
+
+        <font  metrics-file="Vera.xml"
+               kerning="yes" 
+               embed-url="Vera.ttf">
+          <font-triplet name="verasans" style="normal" weight="normal"/>
+          <font-triplet name="verasans" style="normal" weight="bold"/>
+          <font-triplet name="verasans" style="italic" weight="normal"/>
+          <font-triplet name="verasans" style="italic" weight="bold"/>
+        </font>
+        
+        <auto-detect/>
+      </fonts>
+    </renderer>
+  </renderers>
+</fop>
+
diff --git a/documentation/template/formal.object.heading.xsl b/documentation/template/formal.object.heading.xsl
new file mode 100644
index 0000000000..1a5e697808
--- /dev/null
+++ b/documentation/template/formal.object.heading.xsl
@@ -0,0 +1,21 @@
+<xsl:stylesheet version="1.0"
+  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+  xmlns:d="http://docbook.org/ns/docbook"
+  xmlns="http://www.w3.org/1999/xhtml"
+  exclude-result-prefixes="d">
+  
+  <xsl:template name="formal.object.heading">
+    <xsl:param name="object" select="."/>
+    <xsl:param name="title">
+      <xsl:apply-templates select="$object" mode="object.title.markup">
+        <xsl:with-param name="allow-anchors" select="1"/>
+      </xsl:apply-templates>
+    </xsl:param>
+    <p class="title">
+      <b><xsl:copy-of select="$title"/></b>
+      <xsl:call-template name="permalink">
+        <xsl:with-param name="node" select="$object"/>
+      </xsl:call-template>
+    </p>
+  </xsl:template>
+</xsl:stylesheet>
diff --git a/documentation/template/gloss-permalinks.xsl b/documentation/template/gloss-permalinks.xsl
new file mode 100644
index 0000000000..6bf58116f6
--- /dev/null
+++ b/documentation/template/gloss-permalinks.xsl
@@ -0,0 +1,14 @@
+<xsl:stylesheet version="1.0"

+  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

+  xmlns:d="http://docbook.org/ns/docbook"

+  xmlns="http://www.w3.org/1999/xhtml">

+

+  <xsl:template match="glossentry/glossterm">

+    <xsl:apply-imports/>

+    <xsl:if test="$generate.permalink != 0">

+      <xsl:call-template name="permalink">

+        <xsl:with-param name="node" select=".."/>

+      </xsl:call-template>

+    </xsl:if>

+  </xsl:template>

+</xsl:stylesheet>

diff --git a/documentation/template/ohand-color.svg b/documentation/template/ohand-color.svg
new file mode 100644
index 0000000000..e42ff9c6fc
--- /dev/null
+++ b/documentation/template/ohand-color.svg
@@ -0,0 +1,150 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://web.resource.org/cc/"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="141.17999"
+   height="55.34"
+   id="svg2207"
+   sodipodi:version="0.32"
+   inkscape:version="0.45"
+   version="1.0"
+   sodipodi:docname="ohand-color.svg"
+   inkscape:output_extension="org.inkscape.output.svg.inkscape"
+   sodipodi:docbase="/home/mallum/Projects/admin/oh-doc-tools/common"
+   sodipodi:modified="true">
+  <defs
+     id="defs3" />
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="1.2"
+     inkscape:cx="160"
+     inkscape:cy="146.21189"
+     inkscape:document-units="mm"
+     inkscape:current-layer="layer1"
+     height="55.34px"
+     width="141.18px"
+     inkscape:window-width="772"
+     inkscape:window-height="581"
+     inkscape:window-x="5"
+     inkscape:window-y="48" />
+  <metadata
+     id="metadata2211">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1">
+    <g
+       id="g2094"
+       style="fill:#6d6d70;fill-opacity:1"
+       inkscape:export-filename="/home/mallum/Desktop/g2126.png"
+       inkscape:export-xdpi="312.71841"
+       inkscape:export-ydpi="312.71841"
+       transform="matrix(0.5954767,0,0,0.5954767,31.793058,-18.471052)">
+      <g
+         id="g19"
+         style="fill:#6d6d70;fill-opacity:1">
+        <path
+           style="fill:#6d6d70;fill-opacity:1"
+           id="path21"
+           d="M 48.693,50.633 C 40.282,50.633 33.439,57.477 33.439,65.888 L 33.439,81.142 L 41.066,81.142 L 41.066,65.888 C 41.066,61.684 44.486,58.261 48.692,58.261 C 52.897,58.261 56.32,61.684 56.32,65.888 C 56.32,70.093 52.897,73.516 48.692,73.516 C 45.677,73.516 43.065,71.756 41.828,69.211 L 41.828,79.504 C 43.892,80.549 46.224,81.142 48.692,81.142 C 57.103,81.142 63.947,74.3 63.947,65.888 C 63.948,57.477 57.104,50.633 48.693,50.633 z " />
+      </g>
+      <path
+         style="fill:#6d6d70;fill-opacity:1"
+         id="path23"
+         d="M 18.486,50.557 C 26.942,50.557 33.819,57.435 33.819,65.888 C 33.819,74.344 26.942,81.223 18.486,81.223 C 10.032,81.223 3.152,74.344 3.152,65.888 C 3.152,57.435 10.032,50.557 18.486,50.557 z M 18.486,73.556 C 22.713,73.556 26.153,70.118 26.153,65.888 C 26.153,61.661 22.713,58.222 18.486,58.222 C 14.258,58.222 10.819,61.661 10.819,65.888 C 10.82,70.117 14.259,73.556 18.486,73.556 z " />
+      <path
+         style="fill:#6d6d70;fill-opacity:1"
+         id="path25"
+         d="M 94.074,107.465 L 94.074,96.016 C 94.074,87.605 87.233,80.763 78.822,80.763 C 70.41,80.763 63.567,87.605 63.567,96.016 C 63.567,104.427 70.41,111.269 78.822,111.269 C 81.289,111.269 83.621,110.676 85.685,109.631 L 85.685,99.339 C 84.448,101.885 81.836,103.644 78.822,103.644 C 74.615,103.644 71.194,100.221 71.194,96.016 C 71.194,91.81 74.615,88.388 78.822,88.388 C 83.026,88.388 86.448,91.81 86.448,96.016 L 86.448,107.456 C 86.448,109.562 88.156,111.268 90.262,111.268 C 92.364,111.269 94.068,109.566 94.074,107.465 z " />
+      <path
+         style="fill:#6d6d70;fill-opacity:1"
+         id="path27"
+         d="M 124.197,95.814 C 124.088,87.496 117.293,80.762 108.949,80.762 C 100.59,80.762 93.783,87.52 93.697,95.856 L 93.693,95.856 L 93.695,107.456 C 93.695,109.562 95.402,111.268 97.509,111.268 C 99.611,111.268 101.316,109.566 101.321,107.464 L 101.321,95.994 L 101.321,95.994 C 101.333,91.798 104.747,88.388 108.948,88.388 C 113.147,88.388 116.563,91.798 116.575,95.994 L 116.575,107.456 C 116.575,109.562 118.282,111.268 120.387,111.268 C 122.492,111.268 124.201,109.562 124.201,107.456 L 124.201,95.814 L 124.197,95.814 z " />
+      <path
+         style="fill:#6d6d70;fill-opacity:1"
+         id="path29"
+         d="M 63.946,96.005 L 63.946,95.854 L 63.943,95.854 L 63.943,95.815 L 63.942,95.815 C 63.833,87.497 57.037,80.761 48.693,80.761 C 48.682,80.761 48.671,80.763 48.658,80.763 C 48.382,80.763 48.107,80.772 47.833,80.786 C 47.75,80.791 47.668,80.799 47.586,80.806 C 47.378,80.822 47.172,80.838 46.968,80.862 C 46.884,80.873 46.801,80.882 46.719,80.893 C 46.508,80.92 46.298,80.952 46.091,80.987 C 46.024,80.999 45.958,81.01 45.891,81.024 C 45.649,81.068 45.406,81.119 45.168,81.175 C 45.14,81.183 45.112,81.189 45.085,81.195 C 43.656,81.542 42.306,82.092 41.065,82.812 L 41.065,80.761 L 33.438,80.761 L 33.438,95.857 L 33.435,95.857 L 33.435,107.457 C 33.435,109.563 35.142,111.269 37.248,111.269 C 39.093,111.269 40.632,109.958 40.984,108.217 C 41.036,107.963 41.065,107.702 41.065,107.435 L 41.065,95.873 C 41.086,94.732 41.357,93.65 41.828,92.685 L 41.828,92.693 C 42.598,91.106 43.905,89.824 45.511,89.085 C 45.519,89.08 45.529,89.076 45.536,89.073 C 45.849,88.928 46.174,88.807 46.508,88.707 C 46.523,88.704 46.536,88.699 46.55,88.696 C 46.699,88.651 46.85,88.614 47.004,88.576 C 47.025,88.575 47.046,88.567 47.069,88.562 C 47.234,88.527 47.402,88.495 47.572,88.469 C 47.586,88.468 47.6,88.466 47.615,88.463 C 47.763,88.443 47.916,88.427 48.067,88.415 C 48.106,88.41 48.145,88.407 48.186,88.404 C 48.352,88.393 48.52,88.386 48.691,88.386 C 52.888,88.387 56.304,91.797 56.316,95.992 L 56.316,107.454 C 56.316,109.56 58.023,111.266 60.13,111.266 C 61.976,111.266 63.516,109.954 63.867,108.211 C 63.919,107.963 63.946,107.706 63.946,107.442 L 63.946,96.024 C 63.946,96.021 63.947,96.018 63.947,96.015 C 63.948,96.011 63.946,96.008 63.946,96.005 z " />
+      <path
+         style="fill:#6d6d70;fill-opacity:1"
+         id="path31"
+         d="M 180.644,50.633 C 178.539,50.633 176.832,52.341 176.832,54.447 L 176.832,65.887 C 176.832,70.092 173.41,73.513 169.203,73.513 C 164.998,73.513 161.576,70.092 161.576,65.887 C 161.576,61.683 164.998,58.26 169.203,58.26 C 172.219,58.26 174.83,60.019 176.068,62.565 L 176.068,52.271 C 174.004,51.225 171.673,50.632 169.203,50.632 C 160.793,50.632 153.951,57.476 153.951,65.887 C 153.951,74.298 160.793,81.141 169.203,81.141 C 177.615,81.141 184.459,74.298 184.459,65.887 L 184.459,54.447 C 184.458,52.341 182.751,50.633 180.644,50.633 z " />
+      <path
+         style="fill:#6d6d70;fill-opacity:1"
+         id="path33"
+         d="M 124.203,77.339 L 124.203,65.687 L 124.197,65.687 C 124.088,57.371 117.293,50.633 108.949,50.633 C 100.592,50.633 93.783,57.393 93.697,65.731 L 93.695,65.731 L 93.695,65.877 C 93.695,65.882 93.693,65.885 93.693,65.888 C 93.693,65.891 93.695,65.896 93.695,65.899 L 93.695,77.33 C 93.695,79.435 95.402,81.142 97.509,81.142 C 99.614,81.142 101.321,79.435 101.321,77.33 L 101.321,65.868 C 101.333,61.672 104.747,58.261 108.948,58.261 C 113.147,58.261 116.563,61.672 116.575,65.868 L 116.575,65.868 L 116.575,77.329 C 116.575,79.434 118.282,81.141 120.389,81.141 C 122.492,81.142 124.197,79.44 124.203,77.339 z " />
+      <path
+         style="fill:#6d6d70;fill-opacity:1"
+         id="path35"
+         d="M 150.517,80.761 C 148.41,80.761 146.703,82.469 146.703,84.575 L 146.703,96.015 C 146.703,100.22 143.283,103.643 139.076,103.643 C 134.871,103.643 131.449,100.22 131.449,96.015 C 131.449,91.808 134.871,88.387 139.076,88.387 C 142.092,88.387 144.703,90.145 145.941,92.692 L 145.941,82.397 C 143.875,81.353 141.545,80.76 139.076,80.76 C 130.666,80.76 123.822,87.604 123.822,96.015 C 123.822,104.426 130.666,111.268 139.076,111.268 C 147.486,111.268 154.33,104.426 154.33,96.015 L 154.33,84.575 C 154.33,82.469 152.623,80.761 150.517,80.761 z " />
+      <path
+         style="fill:#6d6d70;fill-opacity:1"
+         id="path37"
+         d="M 82.625,77.345 C 82.625,75.247 80.923,73.547 78.826,73.547 L 78.826,81.142 C 80.922,81.142 82.625,79.442 82.625,77.345 z " />
+      <path
+         style="fill:#6d6d70;fill-opacity:1"
+         id="path39"
+         d="M 90.252,69.685 C 92.35,69.685 94.048,67.987 94.048,65.888 L 86.453,65.888 C 86.453,67.986 88.154,69.685 90.252,69.685 z " />
+      <path
+         style="fill:#6d6d70;fill-opacity:1"
+         id="path41"
+         d="M 93.832,77.329 C 93.832,75.223 92.125,73.516 90.018,73.516 L 78.825,73.516 C 74.619,73.516 71.199,70.093 71.199,65.888 C 71.199,61.684 74.619,58.261 78.825,58.261 C 83.032,58.261 86.453,61.684 86.453,65.888 C 86.453,68.904 84.694,71.514 82.149,72.752 L 92.442,72.752 C 93.488,70.689 94.08,68.356 94.08,65.888 C 94.08,57.477 87.237,50.633 78.826,50.633 C 70.415,50.633 63.571,57.477 63.571,65.888 C 63.571,74.3 70.415,81.142 78.826,81.142 L 90.018,81.142 C 92.125,81.142 93.832,79.435 93.832,77.329 z " />
+      <path
+         style="fill:#6d6d70;fill-opacity:1"
+         id="path43"
+         d="M 142.869,77.345 C 142.869,75.247 141.168,73.547 139.07,73.547 L 139.07,81.142 C 141.167,81.142 142.869,79.442 142.869,77.345 z " />
+      <path
+         style="fill:#6d6d70;fill-opacity:1"
+         id="path45"
+         d="M 150.496,69.685 C 152.594,69.685 154.293,67.987 154.293,65.888 L 146.699,65.888 C 146.699,67.986 148.398,69.685 150.496,69.685 z " />
+      <path
+         style="fill:#6d6d70;fill-opacity:1"
+         id="path47"
+         d="M 154.076,77.329 C 154.076,75.223 152.367,73.516 150.262,73.516 L 139.07,73.516 C 134.865,73.516 131.443,70.093 131.443,65.888 C 131.443,61.684 134.865,58.261 139.07,58.261 C 143.275,58.261 146.699,61.684 146.699,65.888 C 146.699,68.904 144.939,71.514 142.392,72.752 L 152.687,72.752 C 153.73,70.689 154.324,68.356 154.324,65.888 C 154.324,57.477 147.48,50.633 139.07,50.633 C 130.66,50.633 123.816,57.477 123.816,65.888 C 123.816,74.3 130.66,81.142 139.07,81.142 L 150.261,81.142 C 152.367,81.142 154.076,79.435 154.076,77.329 z " />
+    </g>
+    <g
+       id="g2126"
+       transform="matrix(0.7679564,0,0,0.7679564,-66.520631,11.42903)"
+       inkscape:export-xdpi="312.71841"
+       inkscape:export-ydpi="312.71841"
+       style="fill:#35992a;fill-opacity:1">
+      <g
+         transform="translate(86.33975,4.23985e-2)"
+         style="fill:#35992a;fill-opacity:1"
+         id="g2114">
+        <g
+           style="fill:#35992a;fill-opacity:1"
+           id="g2116">
+          <path
+             id="path2118"
+             transform="translate(-86.33975,-4.239934e-2)"
+             d="M 89.96875,0.03125 C 87.962748,0.031250001 86.34375,1.6815001 86.34375,3.6875 L 86.34375,17.71875 L 86.34375,19.6875 L 86.34375,28.90625 C 86.343752,39.06825 94.61925,47.34375 104.78125,47.34375 L 113.375,47.34375 L 123.1875,47.34375 L 127.15625,47.34375 C 129.16325,47.343749 130.8125,45.72475 130.8125,43.71875 C 130.8125,41.71275 129.16325,40.09375 127.15625,40.09375 L 123.1875,40.09375 L 123.1875,19.6875 L 123.1875,14.65625 L 123.1875,3.6875 C 123.1875,1.6815 121.5675,0.03125 119.5625,0.03125 C 117.5555,0.031250001 115.9375,1.6815001 115.9375,3.6875 L 115.9375,14.28125 C 115.1185,13.65425 114.26275,13.109 113.34375,12.625 L 113.34375,3.6875 C 113.34475,1.6815 111.6925,0.03125 109.6875,0.03125 C 107.6825,0.031250001 106.0625,1.6815001 106.0625,3.6875 L 106.0625,10.5625 C 105.6305,10.5325 105.22025,10.5 104.78125,10.5 C 104.34125,10.5 103.90075,10.5325 103.46875,10.5625 L 103.46875,3.6875 C 103.46975,1.6815 101.84975,0.03125 99.84375,0.03125 C 97.837749,0.031250001 96.21875,1.6815001 96.21875,3.6875 L 96.21875,12.625 C 95.299754,13.109 94.41375,13.65425 93.59375,14.28125 L 93.59375,3.6875 C 93.59475,1.6815 91.97475,0.03125 89.96875,0.03125 z M 104.78125,14.34375 C 112.80825,14.34375 119.3125,20.87925 119.3125,28.90625 C 119.3125,36.93325 112.80825,43.46875 104.78125,43.46875 C 96.754254,43.46875 90.21875,36.93425 90.21875,28.90625 C 90.218752,20.87825 96.753253,14.34375 104.78125,14.34375 z "
+             style="fill:#35992a;fill-opacity:1" />
+        </g>
+      </g>
+      <path
+         style="fill:#35992a;fill-opacity:1"
+         id="path2122"
+         d="M 112.04875,28.913399 C 112.04875,24.899399 108.78275,21.634399 104.76975,21.634399 C 100.75675,21.634399 97.490753,24.900399 97.490753,28.913399 C 97.490753,32.926399 100.75675,36.192399 104.76975,36.192399 C 108.78275,36.192399 112.04875,32.927399 112.04875,28.913399 z " />
+    </g>
+  </g>
+</svg>
diff --git a/documentation/template/permalinks.xsl b/documentation/template/permalinks.xsl
new file mode 100644
index 0000000000..d2a1c14524
--- /dev/null
+++ b/documentation/template/permalinks.xsl
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xsl:stylesheet version="1.0"
+  xmlns="http://www.w3.org/1999/xhtml"
+  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
+
+  <xsl:param name="generate.permalink" select="1"/>
+  <xsl:param name="permalink.text">¶</xsl:param>
+
+  <xsl:template name="permalink">
+    <xsl:param name="node"/>
+
+    <xsl:if test="$generate.permalink != '0'">
+      <span class="permalink">
+        <a alt="Permalink" title="Permalink">
+          <xsl:attribute name="href">
+            <xsl:call-template name="href.target">
+              <xsl:with-param name="object"  select="$node"/>
+            </xsl:call-template>
+          </xsl:attribute>
+          <xsl:copy-of select="$permalink.text"/>
+        </a>
+      </span>
+    </xsl:if>
+  </xsl:template>
+</xsl:stylesheet>
diff --git a/documentation/template/poky-db-pdf.xsl b/documentation/template/poky-db-pdf.xsl
new file mode 100644
index 0000000000..f8a3df103d
--- /dev/null
+++ b/documentation/template/poky-db-pdf.xsl
@@ -0,0 +1,64 @@
+<?xml version='1.0'?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
+
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl" />
+
+  <!-- check project-plan.sh for how this is generated, needed to tweak
+       the cover page
+    -->
+  <xsl:include href="/tmp/titlepage.xsl"/>
+
+  <!-- To force a page break in document, i.e per section add a
+      <?hard-pagebreak?> tag.
+  -->
+ <xsl:template match="processing-instruction('hard-pagebreak')">
+   <fo:block break-before='page' />
+ </xsl:template>
+
+  <!--Fix for defualt indent getting TOC all wierd..
+      See http://sources.redhat.com/ml/docbook-apps/2005-q1/msg00455.html
+      FIXME: must be a better fix
+    -->
+  <xsl:param name="body.start.indent" select="'0'"/>
+  <!--<xsl:param name="title.margin.left" select="'0'"/>-->
+
+  <!-- stop long-ish header titles getting wrapped -->
+  <xsl:param name="header.column.widths">1 10 1</xsl:param>
+
+  <!-- customise headers and footers a little -->
+
+  <xsl:template name="head.sep.rule">
+   <xsl:if test="$header.rule != 0">
+     <xsl:attribute name="border-bottom-width">0.5pt</xsl:attribute>
+     <xsl:attribute name="border-bottom-style">solid</xsl:attribute>
+     <xsl:attribute name="border-bottom-color">#999999</xsl:attribute>
+   </xsl:if>
+  </xsl:template>
+
+  <xsl:template name="foot.sep.rule">
+    <xsl:if test="$footer.rule != 0">
+     <xsl:attribute name="border-top-width">0.5pt</xsl:attribute>
+     <xsl:attribute name="border-top-style">solid</xsl:attribute>
+     <xsl:attribute name="border-top-color">#999999</xsl:attribute>
+    </xsl:if>
+  </xsl:template>
+
+  <xsl:attribute-set name="header.content.properties">
+    <xsl:attribute name="color">#999999</xsl:attribute>
+  </xsl:attribute-set>
+
+  <xsl:attribute-set name="footer.content.properties">
+    <xsl:attribute name="color">#999999</xsl:attribute>
+  </xsl:attribute-set>
+
+
+  <!-- general settings -->
+
+  <xsl:param name="fop1.extensions" select="1"></xsl:param>
+  <xsl:param name="paper.type" select="'A4'"></xsl:param>
+  <xsl:param name="section.autolabel" select="1"></xsl:param>
+  <xsl:param name="body.font.family" select="'verasans'"></xsl:param>
+  <xsl:param name="title.font.family" select="'verasans'"></xsl:param>
+  <xsl:param name="monospace.font.family" select="'veramono'"></xsl:param>
+
+</xsl:stylesheet>
diff --git a/documentation/template/poky-ref-manual.png b/documentation/template/poky-ref-manual.png
new file mode 100644
index 0000000000..2085edb467
--- /dev/null
+++ b/documentation/template/poky-ref-manual.png
diff --git a/documentation/template/poky.svg b/documentation/template/poky.svg
new file mode 100644
index 0000000000..a4ea5e2f45
--- /dev/null
+++ b/documentation/template/poky.svg
@@ -0,0 +1,163 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   version="1.0"
+   width="158.56076"
+   height="79.284424"
+   viewBox="-40.981 -92.592 300 300"
+   id="svg2"
+   xml:space="preserve">
+<defs
+   id="defs4">
+</defs>
+<path
+   d="M -36.585379,54.412576 L -36.585379,54.421305 L -36.582469,54.421305 L -36.582469,54.243829 C -36.57956,54.302018 -36.585379,54.357297 -36.585379,54.412576 z "
+   style="fill:#6ac7bd"
+   id="path6" />
+<g
+   transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
+   style="opacity:0.65"
+   id="g8">
+        <g
+   id="g10">
+                <path
+   d="M 24.482,23.998 L 24.482,23.995 C 10.961,23.994 0,34.955 0,48.476 L 0.001,48.479 L 0.001,48.482 C 0.003,62.001 10.962,72.96 24.482,72.96 L 24.482,72.96 L 0,72.96 L 0,97.442 L 0.003,97.442 C 13.523,97.44 24.482,86.48 24.482,72.961 L 24.485,72.961 C 38.005,72.959 48.963,62 48.963,48.479 L 48.963,48.476 C 48.962,34.957 38.001,23.998 24.482,23.998 z M 24.482,50.928 C 23.13,50.928 22.034,49.832 22.034,48.48 C 22.034,47.128 23.13,46.032 24.482,46.032 C 25.834,46.032 26.93,47.128 26.93,48.48 C 26.93,49.832 25.834,50.928 24.482,50.928 z "
+   style="fill:#ef412a"
+   id="path12" />
+        </g>
+</g>
+<g
+   transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
+   style="opacity:0.65"
+   id="g14">
+        <g
+   id="g16">
+                <path
+   d="M 119.96,48.842 C 120.024,47.548 121.086,46.516 122.397,46.516 C 123.707,46.516 124.768,47.548 124.833,48.843 C 137.211,47.62 146.879,37.181 146.879,24.483 L 122.397,24.483 C 122.396,10.961 111.435,0 97.915,0 L 97.915,24.485 C 97.917,37.183 107.584,47.619 119.96,48.842 z M 124.833,49.084 C 124.769,50.379 123.707,51.411 122.397,51.411 L 122.396,51.411 L 122.396,73.444 L 146.878,73.444 L 146.878,73.441 C 146.876,60.745 137.208,50.308 124.833,49.084 z M 119.949,48.963 L 97.915,48.963 L 97.915,73.442 L 97.915,73.442 C 110.613,73.442 121.052,63.774 122.275,51.399 C 120.981,51.334 119.949,50.274 119.949,48.963 z "
+   style="fill:#a9c542"
+   id="path18" />
+        </g>
+</g>
+<g
+   transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
+   style="opacity:0.65"
+   id="g20">
+        <g
+   id="g22">
+                <path
+   d="M 168.912,48.967 C 168.912,47.656 169.945,46.596 171.24,46.531 C 170.018,34.152 159.579,24.482 146.879,24.482 L 146.879,48.963 C 146.879,62.484 157.84,73.444 171.361,73.444 L 171.361,51.414 C 170.007,51.415 168.912,50.319 168.912,48.967 z M 195.841,48.978 C 195.841,48.973 195.842,48.969 195.842,48.964 L 195.842,24.482 L 195.838,24.482 C 183.14,24.484 172.702,34.154 171.482,46.531 C 172.776,46.595 173.808,47.656 173.808,48.967 C 173.808,50.278 172.776,51.339 171.481,51.403 C 172.679,63.59 182.814,73.146 195.244,73.445 L 171.361,73.445 L 171.361,97.927 L 171.364,97.927 C 184.879,97.925 195.834,86.973 195.842,73.46 L 195.844,73.46 L 195.844,48.979 L 195.841,48.978 z M 195.832,48.964 L 195.842,48.964 L 195.842,48.978 L 195.832,48.964 z "
+   style="fill:#f9c759"
+   id="path24" />
+        </g>
+</g>
+<g
+   transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
+   style="opacity:0.65"
+   id="g26">
+        <g
+   id="g28">
+                <path
+   d="M 70.994,48.479 L 48.962,48.479 L 48.962,48.481 L 70.995,48.481 C 70.995,48.481 70.994,48.48 70.994,48.479 z M 73.44,24.001 L 73.437,24.001 L 73.437,46.032 C 73.439,46.032 73.44,46.032 73.442,46.032 C 74.794,46.032 75.89,47.128 75.89,48.48 C 75.89,49.832 74.794,50.928 73.442,50.928 C 72.091,50.928 70.996,49.834 70.994,48.483 L 48.958,48.483 L 48.958,48.486 C 48.96,62.005 59.919,72.964 73.437,72.964 C 86.955,72.964 97.914,62.005 97.916,48.486 L 97.916,48.483 C 97.916,34.963 86.958,24.003 73.44,24.001 z "
+   style="fill:#6ac7bd"
+   id="path30" />
+        </g>
+</g>
+<g
+   transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
+   style="opacity:0.65"
+   id="g32">
+        <g
+   id="g34">
+                <path
+   d="M 24.482,23.998 L 24.482,23.995 C 10.961,23.994 0,34.955 0,48.476 L 22.034,48.476 C 22.036,47.125 23.131,46.031 24.482,46.031 C 25.834,46.031 26.93,47.127 26.93,48.479 C 26.93,49.831 25.834,50.927 24.482,50.927 L 24.482,72.937 C 24.469,59.427 13.514,48.479 0,48.479 L 0,72.96 L 24.481,72.96 L 24.481,72.96 L 0,72.96 L 0,97.442 L 0.003,97.442 C 13.523,97.44 24.482,86.48 24.482,72.961 L 24.485,72.961 C 38.005,72.959 48.963,62 48.963,48.479 L 48.963,48.476 C 48.962,34.957 38.001,23.998 24.482,23.998 z "
+   style="fill:#ef412a"
+   id="path36" />
+        </g>
+</g>
+<g
+   transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
+   style="opacity:0.65"
+   id="g38">
+        <g
+   id="g40">
+                <path
+   d="M 122.397,46.516 C 123.707,46.516 124.768,47.548 124.833,48.843 C 137.211,47.62 146.879,37.181 146.879,24.483 L 122.397,24.483 L 122.397,46.516 L 122.397,46.516 z M 97.915,0 L 97.915,24.482 L 122.396,24.482 C 122.396,10.961 111.435,0 97.915,0 z M 122.275,46.528 C 121.052,34.151 110.613,24.482 97.914,24.482 L 97.914,48.964 L 97.914,48.964 L 97.914,73.443 L 97.914,73.443 C 110.612,73.443 121.051,63.775 122.274,51.4 C 120.98,51.335 119.948,50.275 119.948,48.964 C 119.949,47.653 120.98,46.593 122.275,46.528 z M 124.833,49.084 C 124.769,50.379 123.707,51.411 122.397,51.411 L 122.396,51.411 L 122.396,73.444 L 146.878,73.444 L 146.878,73.441 C 146.876,60.745 137.208,50.308 124.833,49.084 z "
+   style="fill:#a9c542"
+   id="path42" />
+        </g>
+</g>
+<g
+   transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
+   style="opacity:0.65"
+   id="g44">
+        <g
+   id="g46">
+                <path
+   d="M 173.795,49.1 C 173.724,50.389 172.666,51.415 171.36,51.415 C 170.006,51.415 168.911,50.319 168.911,48.967 C 168.911,47.656 169.944,46.596 171.239,46.531 C 170.017,34.152 159.578,24.482 146.878,24.482 L 146.878,48.963 C 146.878,62.484 157.839,73.444 171.36,73.444 L 171.36,97.926 L 171.363,97.926 C 184.878,97.924 195.833,86.972 195.841,73.459 L 195.842,73.459 L 195.842,73.443 L 195.841,73.443 C 195.833,60.753 186.167,50.322 173.795,49.1 z M 195.838,24.482 C 183.14,24.484 172.702,34.154 171.482,46.531 C 172.775,46.595 173.806,47.655 173.808,48.964 L 195.841,48.964 L 195.841,48.979 C 195.841,48.974 195.842,48.969 195.842,48.964 L 195.842,24.482 L 195.838,24.482 z "
+   style="fill:#f9c759"
+   id="path48" />
+        </g>
+</g>
+<g
+   transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
+   style="opacity:0.65"
+   id="g50">
+        <g
+   id="g52">
+                <path
+   d="M 71.007,48.347 C 71.075,47.105 72.062,46.117 73.304,46.046 C 72.509,38.02 67.85,31.133 61.201,27.284 C 57.601,25.2 53.424,24 48.965,24 L 48.962,24 C 48.962,28.46 50.161,32.638 52.245,36.24 C 56.093,42.891 62.98,47.552 71.007,48.347 z M 48.962,48.418 C 48.962,48.438 48.961,48.456 48.961,48.476 L 48.961,48.479 L 48.962,48.479 L 48.962,48.418 z M 70.995,48.482 C 70.995,48.481 70.995,48.481 70.995,48.48 L 48.962,48.48 L 48.962,48.482 L 70.995,48.482 z M 73.44,24.001 L 73.437,24.001 L 73.437,46.032 C 73.439,46.032 73.44,46.032 73.442,46.032 C 74.794,46.032 75.89,47.128 75.89,48.48 C 75.89,49.832 74.794,50.928 73.442,50.928 C 72.091,50.928 70.996,49.834 70.994,48.483 L 48.958,48.483 L 48.958,48.486 C 48.96,62.005 59.919,72.964 73.437,72.964 C 86.955,72.964 97.914,62.005 97.916,48.486 L 97.916,48.483 C 97.916,34.963 86.958,24.003 73.44,24.001 z "
+   style="fill:#6ac7bd"
+   id="path54" />
+        </g>
+</g>
+<g
+   transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
+   style="opacity:0.65"
+   id="g56">
+        <g
+   id="g58">
+                <path
+   d="M 24.482,23.998 L 24.482,23.995 C 10.961,23.994 0,34.955 0,48.476 L 22.034,48.476 C 22.036,47.125 23.131,46.031 24.482,46.031 C 25.834,46.031 26.93,47.127 26.93,48.479 C 26.93,49.831 25.834,50.927 24.482,50.927 C 23.171,50.927 22.11,49.894 22.046,48.6 C 9.669,49.824 0.001,60.262 0.001,72.96 L 0,72.96 L 0,97.442 L 0.003,97.442 C 13.523,97.44 24.482,86.48 24.482,72.961 L 24.485,72.961 C 38.005,72.959 48.963,62 48.963,48.479 L 48.963,48.476 C 48.962,34.957 38.001,23.998 24.482,23.998 z "
+   style="fill:#ef412a"
+   id="path60" />
+        </g>
+</g>
+<g
+   transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
+   style="opacity:0.65"
+   id="g62">
+        <g
+   id="g64">
+                <path
+   d="M 119.949,48.963 C 119.949,47.611 121.045,46.515 122.397,46.515 C 123.707,46.515 124.768,47.547 124.833,48.842 C 137.211,47.619 146.879,37.18 146.879,24.482 L 122.397,24.482 C 122.396,10.961 111.435,0 97.915,0 L 97.915,24.482 L 122.394,24.482 C 108.874,24.484 97.916,35.444 97.916,48.963 L 97.916,48.963 L 97.916,73.442 L 97.916,73.442 C 110.614,73.442 121.053,63.774 122.276,51.399 C 120.981,51.334 119.949,50.274 119.949,48.963 z M 124.833,49.084 C 124.769,50.379 123.707,51.411 122.397,51.411 L 122.396,51.411 L 122.396,73.444 L 146.878,73.444 L 146.878,73.441 C 146.876,60.745 137.208,50.308 124.833,49.084 z "
+   style="fill:#a9c542"
+   id="path66" />
+        </g>
+</g>
+<g
+   transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
+   style="opacity:0.65"
+   id="g68">
+        <g
+   id="g70">
+                <path
+   d="M 195.841,48.979 L 195.835,48.964 L 195.841,48.964 L 195.841,48.979 C 195.841,48.974 195.842,48.969 195.842,48.964 L 195.842,24.482 L 195.838,24.482 C 183.14,24.484 172.702,34.154 171.482,46.531 C 172.776,46.595 173.808,47.656 173.808,48.967 C 173.808,50.319 172.712,51.415 171.361,51.415 C 170.007,51.415 168.912,50.319 168.912,48.967 C 168.912,47.656 169.945,46.596 171.24,46.531 C 170.018,34.152 159.579,24.482 146.879,24.482 L 146.879,48.963 C 146.879,62.484 157.84,73.444 171.361,73.444 L 171.361,97.926 L 171.364,97.926 C 184.883,97.924 195.843,86.963 195.843,73.444 L 171.959,73.444 C 185.203,73.126 195.841,62.299 195.841,48.979 z "
+   style="fill:#f9c759"
+   id="path72" />
+        </g>
+</g>
+<g
+   transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
+   style="opacity:0.65"
+   id="g74">
+        <g
+   id="g76">
+                <path
+   d="M 73.44,24.001 L 73.437,24.001 C 59.919,24.003 48.96,34.959 48.958,48.476 L 48.958,48.479 L 48.961,48.479 L 48.961,48.481 L 48.957,48.482 L 48.957,48.485 C 48.959,62.004 59.918,72.963 73.436,72.963 C 86.954,72.963 97.913,62.004 97.915,48.485 L 97.915,48.482 C 97.916,34.963 86.958,24.003 73.44,24.001 z M 73.442,50.928 C 72.09,50.928 70.994,49.832 70.994,48.48 C 70.994,47.128 72.09,46.032 73.442,46.032 C 74.794,46.032 75.89,47.128 75.89,48.48 C 75.89,49.832 74.794,50.928 73.442,50.928 z "
+   style="fill:#6ac7bd"
+   id="path78" />
+        </g>
+</g>
+</svg>
\ No newline at end of file
diff --git a/documentation/template/qa-code-permalinks.xsl b/documentation/template/qa-code-permalinks.xsl
new file mode 100644
index 0000000000..a309095c60
--- /dev/null
+++ b/documentation/template/qa-code-permalinks.xsl
@@ -0,0 +1,23 @@
+<!--

+This XSL sheet enables creation of permalinks for <para><code>

+constructs.  Right now, this construct occurs only in the ref-manual

+book's qa issues and warnings chapter.  However, if the construct

+were to appear anywhere in that ref-manual, a permalink would be

+generated.  I don't foresee any <para><code> constructs being used

+in the future but if they are then a permalink with a generically

+numbered permalink would be generated.

+-->

+<xsl:stylesheet version="1.0"

+  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

+  xmlns:d="http://docbook.org/ns/docbook"

+  xmlns="http://www.w3.org/1999/xhtml">

+

+  <xsl:template match="para/code">

+    <xsl:apply-imports/>

+    <xsl:if test="$generate.permalink != 0">

+      <xsl:call-template name="permalink">

+        <xsl:with-param name="node" select=".."/>

+      </xsl:call-template>

+    </xsl:if>

+  </xsl:template>

+</xsl:stylesheet>

diff --git a/documentation/template/section.title.xsl b/documentation/template/section.title.xsl
new file mode 100644
index 0000000000..5c6ff9a96e
--- /dev/null
+++ b/documentation/template/section.title.xsl
@@ -0,0 +1,55 @@
+<xsl:stylesheet version="1.0"
+  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+  xmlns:d="http://docbook.org/ns/docbook"
+  xmlns="http://www.w3.org/1999/xhtml" exclude-result-prefixes="d">
+
+  <xsl:template name="section.title">
+    <xsl:variable name="section"
+      select="(ancestor::section |
+               ancestor::simplesect|
+               ancestor::sect1|
+               ancestor::sect2|
+               ancestor::sect3|
+               ancestor::sect4|
+               ancestor::sect5)[last()]"/>
+
+    <xsl:variable name="renderas">
+      <xsl:choose>
+        <xsl:when test="$section/@renderas = 'sect1'">1</xsl:when>
+        <xsl:when test="$section/@renderas = 'sect2'">2</xsl:when>
+        <xsl:when test="$section/@renderas = 'sect3'">3</xsl:when>
+        <xsl:when test="$section/@renderas = 'sect4'">4</xsl:when>
+        <xsl:when test="$section/@renderas = 'sect5'">5</xsl:when>
+        <xsl:otherwise><xsl:value-of select="''"/></xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+
+    <xsl:variable name="level">
+      <xsl:choose>
+        <xsl:when test="$renderas != ''">
+          <xsl:value-of select="$renderas"/>
+        </xsl:when>
+        <xsl:otherwise>
+          <xsl:call-template name="section.level">
+            <xsl:with-param name="node" select="$section"/>
+          </xsl:call-template>
+        </xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+
+    <xsl:call-template name="section.heading">
+      <xsl:with-param name="section" select="$section"/>
+      <xsl:with-param name="level" select="$level"/>
+      <xsl:with-param name="title">
+        <xsl:apply-templates select="$section" mode="object.title.markup">
+          <xsl:with-param name="allow-anchors" select="1"/>
+        </xsl:apply-templates>
+        <xsl:if test="$level &gt; 0">
+          <xsl:call-template name="permalink">
+            <xsl:with-param name="node" select="$section"/>
+          </xsl:call-template>
+        </xsl:if>
+      </xsl:with-param>
+    </xsl:call-template>
+  </xsl:template>
+</xsl:stylesheet>
diff --git a/documentation/template/titlepage.templates.xml b/documentation/template/titlepage.templates.xml
new file mode 100644
index 0000000000..f53f147002
--- /dev/null
+++ b/documentation/template/titlepage.templates.xml
@@ -0,0 +1,1227 @@
+<!DOCTYPE t:templates [
+<!ENTITY hsize0 "10pt">
+<!ENTITY hsize1 "12pt">
+<!ENTITY hsize2 "14.4pt">
+<!ENTITY hsize3 "17.28pt">
+<!ENTITY hsize4 "20.736pt">
+<!ENTITY hsize5 "24.8832pt">
+<!ENTITY hsize0space "7.5pt"> <!-- 0.75 * hsize0 -->
+<!ENTITY hsize1space "9pt"> <!-- 0.75 * hsize1 -->
+<!ENTITY hsize2space "10.8pt"> <!-- 0.75 * hsize2 -->
+<!ENTITY hsize3space "12.96pt"> <!-- 0.75 * hsize3 -->
+<!ENTITY hsize4space "15.552pt"> <!-- 0.75 * hsize4 -->
+<!ENTITY hsize5space "18.6624pt"> <!-- 0.75 * hsize5 -->
+]>
+<t:templates xmlns:t="http://nwalsh.com/docbook/xsl/template/1.0"
+             xmlns:param="http://nwalsh.com/docbook/xsl/template/1.0/param"
+             xmlns:fo="http://www.w3.org/1999/XSL/Format"
+             xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
+
+<!-- ********************************************************************
+     $Id: titlepage.templates.xml,v 1.23 2003/12/16 00:30:49 bobstayton Exp $
+     ********************************************************************
+
+     This file is part of the DocBook XSL Stylesheet distribution.
+     See ../README or http://docbook.sf.net/ for copyright
+     and other information.
+
+     ******************************************************************** -->
+
+<!-- ==================================================================== -->
+
+<t:titlepage t:element="article" t:wrapper="fo:block"
+             font-family="{$title.fontset}">
+
+  <t:titlepage-content t:side="recto"
+             text-align="center">
+
+    <mediaobject/>           
+
+    <title t:named-template="component.title"
+           param:node="ancestor-or-self::article[1]"
+           keep-with-next="always"
+           font-size="&hsize5;"
+           font-weight="bold"/>
+
+    <subtitle param:node="ancestor-or-self::article[1]"
+           keep-with-next="always"
+           font-size="&hsize3;"
+           font-weight="bold"
+       space-after="0.8em"/>
+
+    <corpauthor space-before="0.5em"
+                font-size="&hsize3;"/>
+    <authorgroup space-before="0.5em"
+                 font-size="&hsize2;"/>
+    <author space-before="0.5em"
+            font-size="&hsize2;" 
+            space-after="0.8em"/>
+
+    <email font-size="&hsize2;"/>
+
+    <othercredit space-before="0.5em"/>
+    <releaseinfo space-before="0.5em"/>
+    <copyright space-before="0.5em"/>
+    <legalnotice text-align="start"
+                 margin-left="0.5in"
+                 margin-right="0.5in"
+                 font-family="{$body.fontset}"/>
+    <pubdate space-before="0.5em"/>
+        <para></para>
+    <revision space-before="0.5em"/>
+    <revhistory space-before="0.5em"/>
+    <abstract space-before="0.5em"
+              text-align="start"
+              margin-left="0.5in"
+              margin-right="0.5in"
+              font-family="{$body.fontset}"/>
+
+    <para></para>
+  </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<!-- ==================================================================== -->
+
+<t:titlepage t:element="set" t:wrapper="fo:block">
+  <t:titlepage-content t:side="recto">
+      <title
+             t:named-template="division.title"
+             param:node="ancestor-or-self::set[1]"
+             text-align="center"
+             font-size="&hsize5;"
+             space-before="&hsize5space;"
+             font-weight="bold"
+             font-family="{$title.fontset}"/>
+    <subtitle
+              font-family="{$title.fontset}"
+              text-align="center"/>
+    <corpauthor/>
+    <authorgroup/>
+    <author/>
+    <othercredit/>
+    <releaseinfo/>
+    <copyright/>
+    <legalnotice/>
+    <pubdate/>
+    <revision/>
+    <revhistory/>
+    <abstract/>
+  </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<!-- ==================================================================== -->
+
+  <t:titlepage t:element="book" t:wrapper="fo:block">
+    <t:titlepage-content t:side="recto">
+
+      <mediaobject/>         
+
+      <subtitle
+                text-align="center"
+                font-size="&hsize4;"
+                space-before="&hsize4space;"
+                font-family="{$title.fontset}"/>
+      <corpauthor font-size="&hsize3;"
+                  keep-with-next="always"
+                  space-before="2in"/>
+      <authorgroup space-before="2in"/>
+      <author font-size="&hsize3;"
+              space-before="&hsize2space;"
+              keep-with-next="always"/>
+    </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+      <corpauthor/>
+      <authorgroup t:named-template="verso.authorgroup"/>
+      <author/>
+      <othercredit/>
+      <pubdate space-before="1em"/>
+      <copyright/>
+      <abstract/>
+      <legalnotice font-size="8pt"/>
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+      <fo:block break-after="page"/>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+      <fo:block break-after="page"/>
+  </t:titlepage-before>
+</t:titlepage>
+
+<!-- ==================================================================== -->
+
+<t:titlepage t:element="part" t:wrapper="fo:block">
+  <t:titlepage-content t:side="recto">
+      <title
+             t:named-template="division.title"
+             param:node="ancestor-or-self::part[1]"
+             text-align="center"
+             font-size="&hsize5;"
+             space-before="&hsize5space;"
+             font-weight="bold"
+             font-family="{$title.fontset}"/>
+    <subtitle
+              text-align="center"
+              font-size="&hsize4;"
+              space-before="&hsize4space;"
+              font-weight='bold'
+              font-style='italic'
+              font-family="{$title.fontset}"/>
+  </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<t:titlepage t:element="partintro" t:wrapper="fo:block">
+  <t:titlepage-content t:side="recto">
+    <title
+           text-align="center"
+           font-size="&hsize5;"
+           font-weight="bold"
+           space-before="1em"
+           font-family="{$title.fontset}"/>
+    <subtitle
+              text-align="center"
+              font-size="&hsize2;"
+              font-weight="bold"
+              font-style="italic"
+              font-family="{$title.fontset}"/>
+    <corpauthor/>
+    <authorgroup/>
+    <author/>
+    <othercredit/>
+    <releaseinfo/>
+    <copyright/>
+    <legalnotice/>
+    <pubdate/>
+    <revision/>
+    <revhistory/>
+    <abstract/>
+  </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<!-- ==================================================================== -->
+
+<t:titlepage t:element="reference" t:wrapper="fo:block">
+  <t:titlepage-content t:side="recto">
+      <title
+             t:named-template="division.title"
+             param:node="ancestor-or-self::reference[1]"
+             text-align="center"
+             font-size="&hsize5;"
+             space-before="&hsize5space;"
+             font-weight="bold"
+             font-family="{$title.fontset}"/>
+    <subtitle
+              font-family="{$title.fontset}"
+              text-align="center"/>
+    <corpauthor/>
+    <authorgroup/>
+    <author/>
+    <othercredit/>
+    <releaseinfo/>
+    <copyright/>
+    <legalnotice/>
+    <pubdate/>
+    <revision/>
+    <revhistory/>
+    <abstract/>
+  </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<!-- ==================================================================== -->
+
+<t:titlepage t:element="refsynopsisdiv" t:wrapper="fo:block">
+  <t:titlepage-content t:side="recto">
+    <title
+           font-family="{$title.fontset}"/>
+  </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<!-- ==================================================================== -->
+
+<t:titlepage t:element="refsection" t:wrapper="fo:block">
+  <t:titlepage-content t:side="recto">
+    <title
+           font-family="{$title.fontset}"/>
+  </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<!-- ==================================================================== -->
+
+<t:titlepage t:element="refsect1" t:wrapper="fo:block">
+  <t:titlepage-content t:side="recto">
+    <title
+           font-family="{$title.fontset}"/>
+  </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<!-- ==================================================================== -->
+
+<t:titlepage t:element="refsect2" t:wrapper="fo:block">
+  <t:titlepage-content t:side="recto">
+    <title
+           font-family="{$title.fontset}"/>
+  </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<!-- ==================================================================== -->
+
+<t:titlepage t:element="refsect3" t:wrapper="fo:block">
+  <t:titlepage-content t:side="recto">
+    <title
+           font-family="{$title.fontset}"/>
+  </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<!-- ==================================================================== -->
+
+  <t:titlepage t:element="dedication" t:wrapper="fo:block">
+    <t:titlepage-content t:side="recto">
+      <title
+             t:force="1"
+             t:named-template="component.title"
+             param:node="ancestor-or-self::dedication[1]"
+             margin-left="{$title.margin.left}"
+             font-size="&hsize5;"
+             font-family="{$title.fontset}"
+             font-weight="bold"/>
+      <subtitle
+                font-family="{$title.fontset}"/>
+    </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<!-- ==================================================================== -->
+
+  <t:titlepage t:element="preface" t:wrapper="fo:block">
+    <t:titlepage-content t:side="recto">
+      <title
+             t:force="1"
+             t:named-template="component.title"
+             param:node="ancestor-or-self::preface[1]"
+             margin-left="{$title.margin.left}"
+             font-size="&hsize5;"
+             font-family="{$title.fontset}"
+             font-weight="bold"/>
+      <subtitle
+                font-family="{$title.fontset}"/>
+      <corpauthor/>
+      <authorgroup/>
+      <author/>
+      <othercredit/>
+      <releaseinfo/>
+      <copyright/>
+      <legalnotice/>
+      <pubdate/>
+      <revision/>
+      <revhistory/>
+      <abstract/>
+    </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<!-- ==================================================================== -->
+
+  <t:titlepage t:element="chapter" t:wrapper="fo:block"
+               font-family="{$title.fontset}">
+    <t:titlepage-content t:side="recto" margin-left="{$title.margin.left}">
+      <title t:named-template="component.title"
+             param:node="ancestor-or-self::chapter[1]"
+             font-size="&hsize5;"
+             font-weight="bold"/>
+
+      <subtitle space-before="0.5em"
+                font-style="italic"
+                font-size="&hsize2;"
+                font-weight="bold"/>
+
+      <corpauthor  space-before="0.5em"
+                   space-after="0.5em"
+                   font-size="&hsize2;"/>
+
+      <authorgroup space-before="0.5em"
+                   space-after="0.5em"
+                   font-size="&hsize2;"/>
+
+      <author      space-before="0.5em"
+                   space-after="0.5em"
+                   font-size="&hsize2;"/>
+
+      <othercredit/>
+      <releaseinfo/>
+      <copyright/>
+      <legalnotice/>
+      <pubdate/>
+      <revision/>
+      <revhistory/>
+      <abstract/>
+    </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<!-- ==================================================================== -->
+
+  <t:titlepage t:element="appendix" t:wrapper="fo:block">
+    <t:titlepage-content t:side="recto">
+      <title
+             t:named-template="component.title"
+             param:node="ancestor-or-self::appendix[1]"
+             margin-left="{$title.margin.left}"
+             font-size="&hsize5;"
+             font-weight="bold"
+             font-family="{$title.fontset}"/>
+      <subtitle
+                font-family="{$title.fontset}"/>
+      <corpauthor/>
+      <authorgroup/>
+      <author/>
+      <othercredit/>
+      <releaseinfo/>
+      <copyright/>
+      <legalnotice/>
+      <pubdate/>
+      <revision/>
+      <revhistory/>
+      <abstract/>
+    </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<!-- ==================================================================== -->
+
+<t:titlepage t:element="section" t:wrapper="fo:block">
+  <t:titlepage-content t:side="recto">
+    <title
+           margin-left="{$title.margin.left}"
+           font-family="{$title.fontset}"/>
+    <subtitle
+              font-family="{$title.fontset}"/>
+    <corpauthor/>
+    <authorgroup/>
+    <author/>
+    <othercredit/>
+    <releaseinfo/>
+    <copyright/>
+    <legalnotice/>
+    <pubdate/>
+    <revision/>
+    <revhistory/>
+    <abstract/>
+  </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<t:titlepage t:element="sect1" t:wrapper="fo:block">
+  <t:titlepage-content t:side="recto">
+    <title
+           margin-left="{$title.margin.left}"
+           font-family="{$title.fontset}"/>
+    <subtitle
+              font-family="{$title.fontset}"/>
+    <corpauthor/>
+    <authorgroup/>
+    <author/>
+    <othercredit/>
+    <releaseinfo/>
+    <copyright/>
+    <legalnotice/>
+    <pubdate/>
+    <revision/>
+    <revhistory/>
+    <abstract/>
+  </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<t:titlepage t:element="sect2" t:wrapper="fo:block">
+  <t:titlepage-content t:side="recto">
+    <title
+           margin-left="{$title.margin.left}"
+           font-family="{$title.fontset}"/>
+    <subtitle
+              font-family="{$title.fontset}"/>
+    <corpauthor/>
+    <authorgroup/>
+    <author/>
+    <othercredit/>
+    <releaseinfo/>
+    <copyright/>
+    <legalnotice/>
+    <pubdate/>
+    <revision/>
+    <revhistory/>
+    <abstract/>
+  </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<t:titlepage t:element="sect3" t:wrapper="fo:block">
+  <t:titlepage-content t:side="recto">
+    <title
+           margin-left="{$title.margin.left}"
+           font-family="{$title.fontset}"/>
+    <subtitle
+              font-family="{$title.fontset}"/>
+    <corpauthor/>
+    <authorgroup/>
+    <author/>
+    <othercredit/>
+    <releaseinfo/>
+    <copyright/>
+    <legalnotice/>
+    <pubdate/>
+    <revision/>
+    <revhistory/>
+    <abstract/>
+  </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<t:titlepage t:element="sect4" t:wrapper="fo:block">
+  <t:titlepage-content t:side="recto">
+    <title
+           margin-left="{$title.margin.left}"
+           font-family="{$title.fontset}"/>
+    <subtitle
+              font-family="{$title.fontset}"/>
+    <corpauthor/>
+    <authorgroup/>
+    <author/>
+    <othercredit/>
+    <releaseinfo/>
+    <copyright/>
+    <legalnotice/>
+    <pubdate/>
+    <revision/>
+    <revhistory/>
+    <abstract/>
+  </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<t:titlepage t:element="sect5" t:wrapper="fo:block">
+  <t:titlepage-content t:side="recto">
+    <title
+           margin-left="{$title.margin.left}"
+           font-family="{$title.fontset}"/>
+    <subtitle
+              font-family="{$title.fontset}"/>
+    <corpauthor/>
+    <authorgroup/>
+    <author/>
+    <othercredit/>
+    <releaseinfo/>
+    <copyright/>
+    <legalnotice/>
+    <pubdate/>
+    <revision/>
+    <revhistory/>
+    <abstract/>
+  </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<t:titlepage t:element="simplesect" t:wrapper="fo:block">
+  <t:titlepage-content t:side="recto">
+    <title
+           margin-left="{$title.margin.left}"
+           font-family="{$title.fontset}"/>
+    <subtitle
+              font-family="{$title.fontset}"/>
+    <corpauthor/>
+    <authorgroup/>
+    <author/>
+    <othercredit/>
+    <releaseinfo/>
+    <copyright/>
+    <legalnotice/>
+    <pubdate/>
+    <revision/>
+    <revhistory/>
+    <abstract/>
+  </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<!-- ==================================================================== -->
+
+  <t:titlepage t:element="bibliography" t:wrapper="fo:block">
+    <t:titlepage-content t:side="recto">
+      <title
+             t:force="1"
+             t:named-template="component.title"
+             param:node="ancestor-or-self::bibliography[1]"
+             margin-left="{$title.margin.left}"
+             font-size="&hsize5;"
+             font-family="{$title.fontset}"
+             font-weight="bold"/>
+      <subtitle
+                font-family="{$title.fontset}"/>
+    </t:titlepage-content>
+
+    <t:titlepage-content t:side="verso">
+    </t:titlepage-content>
+
+    <t:titlepage-separator>
+    </t:titlepage-separator>
+
+    <t:titlepage-before t:side="recto">
+    </t:titlepage-before>
+
+    <t:titlepage-before t:side="verso">
+    </t:titlepage-before>
+  </t:titlepage>
+
+<!-- ==================================================================== -->
+
+  <t:titlepage t:element="bibliodiv" t:wrapper="fo:block">
+    <t:titlepage-content t:side="recto">
+      <title t:named-template="component.title"
+             param:node="ancestor-or-self::bibliodiv[1]"
+             margin-left="{$title.margin.left}"
+             font-size="&hsize4;"
+             font-family="{$title.fontset}"
+             font-weight="bold"/>
+      <subtitle
+                font-family="{$title.fontset}"/>
+    </t:titlepage-content>
+
+    <t:titlepage-content t:side="verso">
+    </t:titlepage-content>
+
+    <t:titlepage-separator>
+    </t:titlepage-separator>
+
+    <t:titlepage-before t:side="recto">
+    </t:titlepage-before>
+
+    <t:titlepage-before t:side="verso">
+    </t:titlepage-before>
+  </t:titlepage>
+
+<!-- ==================================================================== -->
+
+  <t:titlepage t:element="glossary" t:wrapper="fo:block">
+    <t:titlepage-content t:side="recto">
+      <title
+             t:force="1"
+             t:named-template="component.title"
+             param:node="ancestor-or-self::glossary[1]"
+             margin-left="{$title.margin.left}"
+             font-size="&hsize5;"
+             font-family="{$title.fontset}"
+             font-weight="bold"/>
+      <subtitle
+                font-family="{$title.fontset}"/>
+    </t:titlepage-content>
+
+    <t:titlepage-content t:side="verso">
+    </t:titlepage-content>
+
+    <t:titlepage-separator>
+    </t:titlepage-separator>
+
+    <t:titlepage-before t:side="recto">
+    </t:titlepage-before>
+
+    <t:titlepage-before t:side="verso">
+    </t:titlepage-before>
+  </t:titlepage>
+
+<!-- ==================================================================== -->
+
+  <t:titlepage t:element="glossdiv" t:wrapper="fo:block">
+    <t:titlepage-content t:side="recto">
+      <title t:named-template="component.title"
+             param:node="ancestor-or-self::glossdiv[1]"
+             margin-left="{$title.margin.left}"
+             font-size="&hsize4;"
+             font-family="{$title.fontset}"
+             font-weight="bold"/>
+      <subtitle
+                font-family="{$title.fontset}"/>
+    </t:titlepage-content>
+
+    <t:titlepage-content t:side="verso">
+    </t:titlepage-content>
+
+    <t:titlepage-separator>
+    </t:titlepage-separator>
+
+    <t:titlepage-before t:side="recto">
+    </t:titlepage-before>
+
+    <t:titlepage-before t:side="verso">
+    </t:titlepage-before>
+  </t:titlepage>
+
+<!-- ==================================================================== -->
+
+  <t:titlepage t:element="index" t:wrapper="fo:block">
+    <t:titlepage-content t:side="recto">
+      <title
+             t:force="1"
+             t:named-template="component.title"
+             param:node="ancestor-or-self::index[1]"
+             param:pagewide="1"
+             margin-left="0pt"
+             font-size="&hsize5;"
+             font-family="{$title.fontset}"
+             font-weight="bold"/>
+      <subtitle
+                font-family="{$title.fontset}"/>
+    </t:titlepage-content>
+
+    <t:titlepage-content t:side="verso">
+    </t:titlepage-content>
+
+    <t:titlepage-separator>
+    </t:titlepage-separator>
+
+    <t:titlepage-before t:side="recto">
+    </t:titlepage-before>
+
+    <t:titlepage-before t:side="verso">
+    </t:titlepage-before>
+  </t:titlepage>
+
+<!-- ==================================================================== -->
+
+  <!-- The indexdiv.title template is used so that manual and -->
+  <!-- automatically generated indexdiv titles get the same -->
+  <!-- formatting. -->
+
+  <t:titlepage t:element="indexdiv" t:wrapper="fo:block">
+    <t:titlepage-content t:side="recto">
+      <title t:force="1"
+             t:named-template="indexdiv.title"
+             param:title="title"/>
+      <subtitle
+                font-family="{$title.fontset}"/>
+    </t:titlepage-content>
+
+    <t:titlepage-content t:side="verso">
+    </t:titlepage-content>
+
+    <t:titlepage-separator>
+    </t:titlepage-separator>
+
+    <t:titlepage-before t:side="recto">
+    </t:titlepage-before>
+
+    <t:titlepage-before t:side="verso">
+    </t:titlepage-before>
+  </t:titlepage>
+
+<!-- ==================================================================== -->
+
+  <t:titlepage t:element="setindex" t:wrapper="fo:block">
+    <t:titlepage-content t:side="recto">
+      <title
+             t:force="1"
+             t:named-template="component.title"
+             param:node="ancestor-or-self::setindex[1]"
+             param:pagewide="1"
+             margin-left="0pt"
+             font-size="&hsize5;"
+             font-family="{$title.fontset}"
+             font-weight="bold"/>
+      <subtitle
+                font-family="{$title.fontset}"/>
+    </t:titlepage-content>
+
+    <t:titlepage-content t:side="verso">
+    </t:titlepage-content>
+
+    <t:titlepage-separator>
+    </t:titlepage-separator>
+
+    <t:titlepage-before t:side="recto">
+    </t:titlepage-before>
+
+    <t:titlepage-before t:side="verso">
+    </t:titlepage-before>
+  </t:titlepage>
+
+<!-- ==================================================================== -->
+
+  <t:titlepage t:element="colophon" t:wrapper="fo:block">
+    <t:titlepage-content t:side="recto">
+      <title
+             t:force="1"
+             t:named-template="component.title"
+             param:node="ancestor-or-self::colophon[1]"
+             margin-left="{$title.margin.left}"
+             font-size="&hsize5;"
+             font-family="{$title.fontset}"
+             font-weight="bold"/>
+      <subtitle
+                font-family="{$title.fontset}"/>
+    </t:titlepage-content>
+
+  <t:titlepage-content t:side="verso">
+  </t:titlepage-content>
+
+  <t:titlepage-separator>
+  </t:titlepage-separator>
+
+  <t:titlepage-before t:side="recto">
+  </t:titlepage-before>
+
+  <t:titlepage-before t:side="verso">
+  </t:titlepage-before>
+</t:titlepage>
+
+<!-- ==================================================================== -->
+
+  <t:titlepage t:element="table.of.contents" t:wrapper="fo:block">
+    <t:titlepage-content t:side="recto">
+      <title
+             t:force="1"
+             t:named-template="gentext"
+             param:key="'TableofContents'"
+             space-before.minimum="1em"
+             space-before.optimum="1.5em"
+             space-before.maximum="2em"
+             space-after="0.5em"
+             margin-left="{$title.margin.left}"
+             font-size="&hsize3;"
+             font-weight="bold"
+             font-family="{$title.fontset}"/>
+    </t:titlepage-content>
+
+    <t:titlepage-content t:side="verso">
+    </t:titlepage-content>
+
+    <t:titlepage-separator>
+    </t:titlepage-separator>
+
+    <t:titlepage-before t:side="recto">
+    </t:titlepage-before>
+
+    <t:titlepage-before t:side="verso">
+    </t:titlepage-before>
+  </t:titlepage>
+
+  <t:titlepage t:element="list.of.tables" t:wrapper="fo:block">
+    <t:titlepage-content t:side="recto">
+      <title
+             t:force="1"
+             t:named-template="gentext"
+             param:key="'ListofTables'"
+             space-before.minimum="1em"
+             space-before.optimum="1.5em"
+             space-before.maximum="2em"
+             space-after="0.5em"
+             margin-left="{$title.margin.left}"
+             font-size="&hsize3;"
+             font-weight="bold"
+             font-family="{$title.fontset}"/>
+    </t:titlepage-content>
+
+    <t:titlepage-content t:side="verso">
+    </t:titlepage-content>
+
+    <t:titlepage-separator>
+    </t:titlepage-separator>
+
+    <t:titlepage-before t:side="recto">
+    </t:titlepage-before>
+
+    <t:titlepage-before t:side="verso">
+    </t:titlepage-before>
+  </t:titlepage>
+
+  <t:titlepage t:element="list.of.figures" t:wrapper="fo:block">
+    <t:titlepage-content t:side="recto">
+      <title
+             t:force="1"
+             t:named-template="gentext"
+             param:key="'ListofFigures'"
+             space-before.minimum="1em"
+             space-before.optimum="1.5em"
+             space-before.maximum="2em"
+             space-after="0.5em"
+             margin-left="{$title.margin.left}"
+             font-size="&hsize3;"
+             font-weight="bold"
+             font-family="{$title.fontset}"/>
+    </t:titlepage-content>
+
+    <t:titlepage-content t:side="verso">
+    </t:titlepage-content>
+
+    <t:titlepage-separator>
+    </t:titlepage-separator>
+
+    <t:titlepage-before t:side="recto">
+    </t:titlepage-before>
+
+    <t:titlepage-before t:side="verso">
+    </t:titlepage-before>
+  </t:titlepage>
+
+  <t:titlepage t:element="list.of.examples" t:wrapper="fo:block">
+    <t:titlepage-content t:side="recto">
+      <title
+             t:force="1"
+             t:named-template="gentext"
+             param:key="'ListofExamples'"
+             space-before.minimum="1em"
+             space-before.optimum="1.5em"
+             space-before.maximum="2em"
+             space-after="0.5em"
+             margin-left="{$title.margin.left}"
+             font-size="&hsize3;"
+             font-weight="bold"
+             font-family="{$title.fontset}"/>
+    </t:titlepage-content>
+
+    <t:titlepage-content t:side="verso">
+    </t:titlepage-content>
+
+    <t:titlepage-separator>
+    </t:titlepage-separator>
+
+    <t:titlepage-before t:side="recto">
+    </t:titlepage-before>
+
+    <t:titlepage-before t:side="verso">
+    </t:titlepage-before>
+  </t:titlepage>
+
+  <t:titlepage t:element="list.of.equations" t:wrapper="fo:block">
+    <t:titlepage-content t:side="recto">
+      <title
+             t:force="1"
+             t:named-template="gentext"
+             param:key="'ListofEquations'"
+             space-before.minimum="1em"
+             space-before.optimum="1.5em"
+             space-before.maximum="2em"
+             space-after="0.5em"
+             margin-left="{$title.margin.left}"
+             font-size="&hsize3;"
+             font-weight="bold"
+             font-family="{$title.fontset}"/>
+    </t:titlepage-content>
+
+    <t:titlepage-content t:side="verso">
+    </t:titlepage-content>
+
+    <t:titlepage-separator>
+    </t:titlepage-separator>
+
+    <t:titlepage-before t:side="recto">
+    </t:titlepage-before>
+
+    <t:titlepage-before t:side="verso">
+    </t:titlepage-before>
+  </t:titlepage>
+
+  <t:titlepage t:element="list.of.procedures" t:wrapper="fo:block">
+    <t:titlepage-content t:side="recto">
+      <title
+             t:force="1"
+             t:named-template="gentext"
+             param:key="'ListofProcedures'"
+             space-before.minimum="1em"
+             space-before.optimum="1.5em"
+             space-before.maximum="2em"
+             space-after="0.5em"
+             margin-left="{$title.margin.left}"
+             font-size="&hsize3;"
+             font-weight="bold"
+             font-family="{$title.fontset}"/>
+    </t:titlepage-content>
+
+    <t:titlepage-content t:side="verso">
+    </t:titlepage-content>
+
+    <t:titlepage-separator>
+    </t:titlepage-separator>
+
+    <t:titlepage-before t:side="recto">
+    </t:titlepage-before>
+
+    <t:titlepage-before t:side="verso">
+    </t:titlepage-before>
+  </t:titlepage>
+
+  <t:titlepage t:element="list.of.unknowns" t:wrapper="fo:block">
+    <t:titlepage-content t:side="recto">
+      <title
+             t:force="1"
+             t:named-template="gentext"
+             param:key="'ListofUnknown'"
+             space-before.minimum="1em"
+             space-before.optimum="1.5em"
+             space-before.maximum="2em"
+             space-after="0.5em"
+             margin-left="{$title.margin.left}"
+             font-size="&hsize3;"
+             font-weight="bold"
+             font-family="{$title.fontset}"/>
+    </t:titlepage-content>
+
+    <t:titlepage-content t:side="verso">
+    </t:titlepage-content>
+
+    <t:titlepage-separator>
+    </t:titlepage-separator>
+
+    <t:titlepage-before t:side="recto">
+    </t:titlepage-before>
+
+    <t:titlepage-before t:side="verso">
+    </t:titlepage-before>
+  </t:titlepage>
+
+<!-- ==================================================================== -->
+
+</t:templates>
diff --git a/documentation/template/yocto-project-qs.png b/documentation/template/yocto-project-qs.png
new file mode 100644
index 0000000000..333442e0d6
--- /dev/null
+++ b/documentation/template/yocto-project-qs.png
diff --git a/documentation/tools/eclipse-help.sed b/documentation/tools/eclipse-help.sed
new file mode 100644
index 0000000000..38690bc938
--- /dev/null
+++ b/documentation/tools/eclipse-help.sed
@@ -0,0 +1,18 @@
+# Processes poky-ref-manual and yocto-project-qs manual (<word>-<word>-<word> style)
+# For example:
+#   "ulink" href="http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#faq"
+#   -> "link" href="../poky-ref-manual/faq.html"
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/[^\/]*\/\([a-z]*-[a-z]*-[a-z]*\)\/[a-z]*-[a-z]*-[a-z]*.html#\([^\"]*\)\"/\"link\" href=\"\.\.\/\1\/\2.html\"/g
+
+# Processes all other manuals (<word>-<word> style)
+# For example:
+#   "ulink" href="http://www.yoctoproject.org/docs/1.3/kernel-manual/kernel-manual.html#faq"
+#   -> "link" href="../kernel-manual/faq.html"
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/[^\/]*\/\([a-z]*-[a-z]*\)\/[a-z]*-[a-z]*.html#\([^\"]*\)\"/\"link\" href=\"\.\.\/\1\/\2.html\"/g
+
+# Process cases where just an external manual is referenced without an id anchor
+# For example:
+#   "ulink" href="http://www.yoctoproject.org/docs/1.3/kernel-manual/kernel-manual.html
+#   -> "link" href="../kernel-manual/index.html"
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/[^\/]*\/\([a-z]*-[a-z]*-[a-z]*\)\/[a-z]*-[a-z]*-[a-z]*.html\"/\"link\" href=\"\.\.\/\1\/index.html\"/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/[^\/]*\/\([a-z]*-[a-z]*\)\/[a-z]*-[a-z]*.html\"/\"link\" href=\"\.\.\/\1\/index.html\"/g
diff --git a/documentation/tools/mega-manual.sed b/documentation/tools/mega-manual.sed
new file mode 100644
index 0000000000..9f3a7ecbeb
--- /dev/null
+++ b/documentation/tools/mega-manual.sed
@@ -0,0 +1,31 @@
+# Processes poky-ref-manual and yocto-project-qs manual (<word>-<word>-<word> style).
+# This style is for manual folders like "yocto-project-qs" and "poky-ref-manual".
+# This is the old way that did it.  Can't do that now that we have "bitbake-user-manual" strings
+# in the mega-manual.
+# s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.2\/[a-z]*-[a-z]*-[a-z]*\/[a-z]*-[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.2\/yocto-project-qs\/yocto-project-qs.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.2\/poky-ref-manual\/poky-ref-manual.html#/\"link\" href=\"#/g
+
+# Processes all other manuals (<word>-<word> style) except for the BitBake User Manual because
+# it is not included in the mega-manual.
+# This style is for manual folders that use two word, which is the standard now (e.g. "ref-manual").
+# This was the one-liner that worked before we introduced the BitBake User Manual, which is
+# not in the mega-manual.
+# s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.2\/[a-z]*-[a-z]*\/[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
+
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.2\/adt-manual\/adt-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.2\/bsp-guide\/bsp-guide.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.2\/dev-manual\/dev-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.2\/kernel-dev\/kernel-dev.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.2\/profile-manual\/profile-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.2\/ref-manual\/ref-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.2\/yocto-project-qs\/yocto-project-qs.html#/\"link\" href=\"#/g
+
+# Process cases where just an external manual is referenced without an id anchor
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.2\/yocto-project-qs\/yocto-project-qs.html\" target=\"_top\">Yocto Project Quick Start<\/a>/Yocto Project Quick Start/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.2\/dev-manual\/dev-manual.html\" target=\"_top\">Yocto Project Development Manual<\/a>/Yocto Project Development Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.2\/adt-manual\/adt-manual.html\" target=\"_top\">Yocto Project Application Developer's Guide<\/a>/Yocto Project Application Developer's Guide/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.2\/bsp-guide\/bsp-guide.html\" target=\"_top\">Yocto Project Board Support Package (BSP) Developer's Guide<\/a>/Yocto Project Board Support Package (BSP) Developer's Guide/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.2\/profile-manual\/profile-manual.html\" target=\"_top\">Yocto Project Profiling and Tracing Manual<\/a>/Yocto Project Profiling and Tracing Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.2\/kernel-dev\/kernel-dev.html\" target=\"_top\">Yocto Project Linux Kernel Development Manual<\/a>/Yocto Project Linux Kernel Development Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.2\/ref-manual\/ref-manual.html\" target=\"_top\">Yocto Project Reference Manual<\/a>/Yocto Project Reference Manual/g
diff --git a/documentation/tools/poky-docbook-to-pdf b/documentation/tools/poky-docbook-to-pdf
new file mode 100755
index 0000000000..f55fd278af
--- /dev/null
+++ b/documentation/tools/poky-docbook-to-pdf
@@ -0,0 +1,51 @@
+#!/bin/sh
+        
+if [ -z "$1" -o -z "$2" ]; then
+   echo "usage: [-v] $0 <docbook file> <templatedir>"
+   echo
+   echo "*NOTE* you need xsltproc, fop and nwalsh docbook stylesheets" 
+   echo "       installed for this to work!"
+   echo
+   exit 0
+fi
+
+FO=`echo $1 | sed s/.xml/.fo/` || exit 1
+PDF=`echo $1 | sed s/.xml/.pdf/` || exit 1
+TEMPLATEDIR=$2
+
+##
+# These URI should be rewritten by your distribution's xml catalog to
+# match your localy installed XSL stylesheets.
+XSL_BASE_URI="http://docbook.sourceforge.net/release/xsl/current"
+
+# Creates a temporary XSL stylesheet based on titlepage.xsl
+xsltproc -o /tmp/titlepage.xsl                                           \
+         --xinclude                                                      \
+         $XSL_BASE_URI/template/titlepage.xsl \
+         $TEMPLATEDIR/titlepage.templates.xml || exit 1
+
+# Creates the file needed for FOP
+xsltproc --xinclude                    \
+         --stringparam hyphenate false \
+         --stringparam formal.title.placement "figure after" \
+         --stringparam ulink.show 1 \
+         --stringparam  body.font.master  9 \
+         --stringparam  title.font.master  11 \
+         --stringparam draft.watermark.image "$TEMPLATEDIR/draft.png" \
+         --stringparam  chapter.autolabel 1 \
+         --stringparam  appendix.autolabel A \
+         --stringparam  section.autolabel 1 \
+         --stringparam  section.label.includes.component.label 1 \
+         --output $FO               \
+         $TEMPLATEDIR/poky-db-pdf.xsl    \
+         $1                 || exit 1
+
+# Invokes the Java version of FOP.  Uses the additional configuration file common/fop-config.xml
+fop -c $TEMPLATEDIR/fop-config.xml -fo $FO -pdf $PDF       || exit 1
+
+rm -f $FO
+rm -f  /tmp/titlepage.xsl
+
+echo
+echo " #### Success! $PDF ready. ####"
+echo
diff --git a/documentation/yocto-project-qs/figures/building-an-image.png b/documentation/yocto-project-qs/figures/building-an-image.png
new file mode 100755
index 0000000000..1fbea5ab00
--- /dev/null
+++ b/documentation/yocto-project-qs/figures/building-an-image.png
diff --git a/documentation/yocto-project-qs/figures/using-a-pre-built-image.png b/documentation/yocto-project-qs/figures/using-a-pre-built-image.png
new file mode 100644
index 0000000000..b03130d123
--- /dev/null
+++ b/documentation/yocto-project-qs/figures/using-a-pre-built-image.png
diff --git a/documentation/yocto-project-qs/figures/yocto-environment.png b/documentation/yocto-project-qs/figures/yocto-environment.png
new file mode 100644
index 0000000000..82b7a55a35
--- /dev/null
+++ b/documentation/yocto-project-qs/figures/yocto-environment.png
diff --git a/documentation/yocto-project-qs/figures/yocto-project-transp.png b/documentation/yocto-project-qs/figures/yocto-project-transp.png
new file mode 100755
index 0000000000..31d2b147fd
--- /dev/null
+++ b/documentation/yocto-project-qs/figures/yocto-project-transp.png
diff --git a/documentation/yocto-project-qs/qs-style.css b/documentation/yocto-project-qs/qs-style.css
new file mode 100644
index 0000000000..235c85a1ba
--- /dev/null
+++ b/documentation/yocto-project-qs/qs-style.css
@@ -0,0 +1,983 @@
+/*
+   Generic XHTML / DocBook XHTML CSS Stylesheet.
+
+   Browser wrangling and typographic design by
+      Oyvind Kolas / pippin@gimp.org
+
+   Customised for Poky by
+      Matthew Allum / mallum@o-hand.com
+
+   Thanks to:
+     Liam R. E. Quin
+     William Skaggs
+     Jakub Steiner
+
+   Structure
+   ---------
+
+   The stylesheet is divided into the following sections:
+
+       Positioning
+          Margins, paddings, width, font-size, clearing.
+       Decorations
+          Borders, style
+       Colors
+          Colors
+       Graphics
+          Graphical backgrounds
+       Nasty IE tweaks
+          Workarounds needed to make it work in internet explorer,
+          currently makes the stylesheet non validating, but up until
+          this point it is validating.
+       Mozilla extensions
+          Transparency for footer
+          Rounded corners on boxes
+
+*/
+
+
+  /*************** /
+ /  Positioning   /
+/ ***************/
+
+body {
+  font-family: Verdana, Sans, sans-serif;
+
+  min-width: 640px;
+  width: 80%;
+  margin:  0em auto;
+  padding: 2em 5em 5em 5em;
+  color: #333;
+}
+
+h1,h2,h3,h4,h5,h6,h7 {
+  font-family: Arial, Sans;
+  color: #00557D;
+  clear: both;
+}
+
+h1 {
+  font-size: 2em;
+  text-align: left;
+  padding: 0em 0em 0em 0em;
+  margin: 2em 0em 0em 0em;
+}
+
+h2.subtitle {
+  margin: 0.10em 0em 3.0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 1.8em;
+  padding-left: 20%;
+  font-weight: normal;
+  font-style: italic;
+}
+
+h2 {
+  margin: 2em 0em 0.66em 0em;
+  padding: 0.5em 0em 0em 0em;
+  font-size: 1.5em;
+  font-weight: bold;
+}
+
+h3.subtitle {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 142.14%;
+  text-align: right;
+}
+
+h3 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 140%;
+  font-weight: bold;
+}
+
+h4 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 120%;
+  font-weight: bold;
+}
+
+h5 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+h6 {
+  margin: 1em 0em 0em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+.authorgroup {
+  background-color: transparent;
+  background-repeat: no-repeat;
+  padding-top: 256px;
+  background-position: top;
+  margin-top: -256px;
+  padding-right: 50px;
+  margin-left: 50px;
+  text-align: center;
+  width: 600px;
+}
+
+h3.author {
+  margin: 0em 0me 0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-weight: normal;
+  font-size: 100%;
+  color: #333;
+  clear: both;
+}
+
+.author tt.email {
+  font-size: 66%;
+}
+
+.titlepage hr {
+  width: 0em;
+  clear: both;
+}
+
+.revhistory {
+  padding-top: 2em;
+  clear: both;
+}
+
+.toc,
+.list-of-tables,
+.list-of-examples,
+.list-of-figures {
+  padding: 1.33em 0em 2.5em 0em;
+  color: #00557D;
+}
+
+.toc p,
+.list-of-tables p,
+.list-of-figures p,
+.list-of-examples p {
+  padding: 0em 0em 0em 0em;
+  padding: 0em 0em 0.3em;
+  margin: 1.5em 0em 0em 0em;
+}
+
+.toc p b,
+.list-of-tables p b,
+.list-of-figures p b,
+.list-of-examples p b{
+  font-size: 100.0%;
+  font-weight: bold;
+}
+
+.toc dl,
+.list-of-tables dl,
+.list-of-figures dl,
+.list-of-examples dl {
+  margin: 0em 0em 0.5em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dt {
+  margin: 0em 0em 0em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dd {
+  margin: 0em 0em 0em 2.6em;
+  padding: 0em 0em 0em 0em;
+}
+
+div.glossary dl,
+div.variablelist dl {
+}
+
+.glossary dl dt,
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  font-weight: normal;
+  width: 20em;
+  text-align: right;
+}
+
+.variablelist dl dt {
+  margin-top: 0.5em;
+}
+
+.glossary dl dd,
+.variablelist dl dd {
+  margin-top: -1em;
+  margin-left: 25.5em;
+}
+
+.glossary dd p,
+.variablelist dd p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+
+div.calloutlist table td {
+  padding: 0em 0em 0em 0em;
+  margin: 0em 0em 0em 0em;
+}
+
+div.calloutlist table td p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+div p.copyright {
+  text-align: left;
+}
+
+div.legalnotice p.legalnotice-title {
+  margin-bottom: 0em;
+}
+
+p {
+  line-height: 1.5em;
+  margin-top: 0em;
+
+}
+
+dl {
+  padding-top: 0em;
+}
+
+hr {
+  border: solid 1px;
+}
+
+
+.mediaobject,
+.mediaobjectco {
+  text-align: center;
+}
+
+img {
+  border: none;
+}
+
+ul {
+  padding: 0em 0em 0em 1.5em;
+}
+
+ul li {
+  padding: 0em 0em 0em 0em;
+}
+
+ul li p {
+  text-align: left;
+}
+
+table {
+  width :100%;
+}
+
+th {
+  padding: 0.25em;
+  text-align: left;
+  font-weight: normal;
+  vertical-align: top;
+}
+
+td {
+  padding: 0.25em;
+  vertical-align: top;
+}
+
+p a[id] {
+  margin: 0px;
+  padding: 0px;
+  display: inline;
+  background-image: none;
+}
+
+a {
+  text-decoration: underline;
+  color: #444;
+}
+
+pre {
+    overflow: auto;
+}
+
+a:hover {
+  text-decoration: underline;
+  /*font-weight: bold;*/
+}
+
+/* This style defines how the permalink character
+   appears by itself and when hovered over with
+   the mouse. */
+
+[alt='Permalink'] { color: #eee; }
+[alt='Permalink']:hover { color: black; }
+
+
+div.informalfigure,
+div.informalexample,
+div.informaltable,
+div.figure,
+div.table,
+div.example {
+  margin: 1em 0em;
+  padding: 1em;
+  page-break-inside: avoid;
+}
+
+
+div.informalfigure p.title b,
+div.informalexample p.title b,
+div.informaltable p.title b,
+div.figure p.title b,
+div.example p.title b,
+div.table p.title b{
+    padding-top: 0em;
+    margin-top: 0em;
+    font-size: 100%;
+    font-weight: normal;
+}
+
+.mediaobject .caption,
+.mediaobject .caption p  {
+  text-align: center;
+  font-size: 80%;
+  padding-top: 0.5em;
+  padding-bottom: 0.5em;
+}
+
+.epigraph {
+  padding-left: 55%;
+  margin-bottom: 1em;
+}
+
+.epigraph p {
+  text-align: left;
+}
+
+.epigraph .quote {
+  font-style: italic;
+}
+.epigraph .attribution {
+  font-style: normal;
+  text-align: right;
+}
+
+span.application {
+  font-style: italic;
+}
+
+.programlisting {
+  font-family: monospace;
+  font-size: 80%;
+  white-space: pre;
+  margin: 1.33em 0em;
+  padding: 1.33em;
+}
+
+.tip,
+.warning,
+.caution,
+.note {
+  margin-top: 1em;
+  margin-bottom: 1em;
+
+}
+
+/* force full width of table within div */
+.tip table,
+.warning table,
+.caution table,
+.note table {
+  border: none;
+  width: 100%;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  padding: 0.8em 0.0em 0.0em 0.0em;
+  margin : 0em 0em 0em 0em;
+}
+
+.tip p,
+.warning p,
+.caution p,
+.note p {
+  margin-top: 0.5em;
+  margin-bottom: 0.5em;
+  padding-right: 1em;
+  text-align: left;
+}
+
+.acronym {
+  text-transform: uppercase;
+}
+
+b.keycap,
+.keycap {
+  padding: 0.09em 0.3em;
+  margin: 0em;
+}
+
+.itemizedlist li {
+  clear: none;
+}
+
+.filename {
+  font-size: medium;
+  font-family: Courier, monospace;
+}
+
+
+div.navheader, div.heading{
+  position: absolute;
+  left: 0em;
+  top: 0em;
+  width: 100%;
+  background-color: #cdf;
+  width: 100%;
+}
+
+div.navfooter, div.footing{
+  position: fixed;
+  left: 0em;
+  bottom: 0em;
+  background-color: #eee;
+  width: 100%;
+}
+
+
+div.navheader td,
+div.navfooter td {
+  font-size: 66%;
+}
+
+div.navheader table th {
+  /*font-family: Georgia, Times, serif;*/
+  /*font-size: x-large;*/
+  font-size: 80%;
+}
+
+div.navheader table {
+  border-left: 0em;
+  border-right: 0em;
+  border-top: 0em;
+  width: 100%;
+}
+
+div.navfooter table {
+  border-left: 0em;
+  border-right: 0em;
+  border-bottom: 0em;
+  width: 100%;
+}
+
+div.navheader table td a,
+div.navfooter table td a {
+  color: #777;
+  text-decoration: none;
+}
+
+/* normal text in the footer */
+div.navfooter table td {
+  color: black;
+}
+
+div.navheader table td a:visited,
+div.navfooter table td a:visited {
+  color: #444;
+}
+
+
+/* links in header and footer */
+div.navheader table td a:hover,
+div.navfooter table td a:hover {
+  text-decoration: underline;
+  background-color: transparent;
+  color: #33a;
+}
+
+div.navheader hr,
+div.navfooter hr {
+  display: none;
+}
+
+
+.qandaset tr.question td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.qandaset tr.answer td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+.answer td {
+  padding-bottom: 1.5em;
+}
+
+.emphasis {
+  font-weight: bold;
+}
+
+
+  /************* /
+ / decorations  /
+/ *************/
+
+.titlepage {
+}
+
+.part .title {
+}
+
+.subtitle {
+    border: none;
+}
+
+/*
+h1 {
+  border: none;
+}
+
+h2 {
+  border-top: solid 0.2em;
+  border-bottom: solid 0.06em;
+}
+
+h3 {
+  border-top: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h4 {
+  border: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h5 {
+  border: 0em;
+}
+*/
+
+.programlisting {
+  border: solid 1px;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example {
+  border: 1px solid;
+}
+
+
+
+.tip,
+.warning,
+.caution,
+.note {
+  border: 1px solid;
+}
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom: 1px solid;
+}
+
+.question td {
+  border-top: 1px solid black;
+}
+
+.answer {
+}
+
+
+b.keycap,
+.keycap {
+  border: 1px solid;
+}
+
+
+div.navheader, div.heading{
+  border-bottom: 1px solid;
+}
+
+
+div.navfooter, div.footing{
+  border-top: 1px solid;
+}
+
+  /********* /
+ /  colors  /
+/ *********/
+
+body {
+  color: #333;
+  background: white;
+}
+
+a {
+  background: transparent;
+}
+
+a:hover {
+  background-color: #dedede;
+}
+
+
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7,
+h8 {
+  background-color: transparent;
+}
+
+hr {
+  border-color: #aaa;
+}
+
+
+.tip, .warning, .caution, .note {
+  border-color: #fff;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom-color: #fff;
+}
+
+
+.warning {
+  background-color: #f0f0f2;
+}
+
+.caution {
+  background-color: #f0f0f2;
+}
+
+.tip {
+  background-color: #f0f0f2;
+}
+
+.note {
+  background-color: #f0f0f2;
+}
+
+.glossary dl dt,
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  color: #044;
+}
+
+div.figure,
+div.table,
+div.example,
+div.informalfigure,
+div.informaltable,
+div.informalexample {
+  border-color: #aaa;
+}
+
+pre.programlisting {
+  color: black;
+  background-color: #fff;
+  border-color: #aaa;
+  border-width: 2px;
+}
+
+.guimenu,
+.guilabel,
+.guimenuitem {
+  background-color: #eee;
+}
+
+
+b.keycap,
+.keycap {
+  background-color: #eee;
+  border-color: #999;
+}
+
+
+div.navheader {
+  border-color: black;
+}
+
+
+div.navfooter {
+  border-color: black;
+}
+
+
+  /*********** /
+ /  graphics  /
+/ ***********/
+
+/*
+body {
+  background-image: url("images/body_bg.jpg");
+  background-attachment: fixed;
+}
+
+.navheader,
+.note,
+.tip {
+  background-image: url("images/note_bg.jpg");
+  background-attachment: fixed;
+}
+
+.warning,
+.caution {
+  background-image: url("images/warning_bg.jpg");
+  background-attachment: fixed;
+}
+
+.figure,
+.informalfigure,
+.example,
+.informalexample,
+.table,
+.informaltable {
+  background-image: url("images/figure_bg.jpg");
+  background-attachment: fixed;
+}
+
+*/
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7{
+}
+
+/*
+Example of how to stick an image as part of the title.
+
+div.article .titlepage .title
+{
+  background-image: url("figures/white-on-black.png");
+  background-position: center;
+  background-repeat: repeat-x;
+}
+*/
+
+div.preface .titlepage .title,
+div.colophon .title,
+div.chapter .titlepage .title,
+div.article .titlepage .title
+{
+}
+
+div.section div.section .titlepage .title,
+div.sect2 .titlepage .title {
+    background: none;
+}
+
+
+h1.title {
+  background-color: transparent;
+  background-repeat: no-repeat;
+  height: 256px;
+  text-indent: -9000px;
+  overflow:hidden;
+}
+
+h2.subtitle {
+  background-color: transparent;
+  text-indent: -9000px;
+  overflow:hidden;
+  width: 0px;
+  display: none;
+}
+
+  /*************************************** /
+ /  pippin.gimp.org specific alterations  /
+/ ***************************************/
+
+/*
+div.heading, div.navheader {
+  color: #777;
+  font-size: 80%;
+  padding: 0;
+  margin: 0;
+  text-align: left;
+  position: absolute;
+  top: 0px;
+  left: 0px;
+  width: 100%;
+  height: 50px;
+  background: url('/gfx/heading_bg.png') transparent;
+  background-repeat: repeat-x;
+  background-attachment: fixed;
+  border: none;
+}
+
+div.heading a {
+  color: #444;
+}
+
+div.footing, div.navfooter {
+  border: none;
+  color: #ddd;
+  font-size: 80%;
+  text-align:right;
+
+  width: 100%;
+  padding-top: 10px;
+  position: absolute;
+  bottom: 0px;
+  left: 0px;
+
+  background: url('/gfx/footing_bg.png') transparent;
+}
+*/
+
+
+
+  /****************** /
+ /  nasty ie tweaks  /
+/ ******************/
+
+/*
+div.heading, div.navheader {
+  width:expression(document.body.clientWidth + "px");
+}
+
+div.footing, div.navfooter {
+  width:expression(document.body.clientWidth + "px");
+  margin-left:expression("-5em");
+}
+body {
+  padding:expression("4em 5em 0em 5em");
+}
+*/
+
+  /**************************************** /
+ / mozilla vendor specific css extensions  /
+/ ****************************************/
+/*
+div.navfooter, div.footing{
+  -moz-opacity: 0.8em;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example,
+.tip,
+.warning,
+.caution,
+.note {
+  -moz-border-radius: 0.5em;
+}
+
+b.keycap,
+.keycap {
+  -moz-border-radius: 0.3em;
+}
+*/
+
+table tr td table tr td {
+  display: none;
+}
+
+
+hr {
+  display: none;
+}
+
+table {
+  border: 0em;
+}
+
+ .photo {
+  float: right;
+  margin-left:   1.5em;
+  margin-bottom: 1.5em;
+  margin-top: 0em;
+  max-width:      17em;
+  border:     1px solid gray;
+  padding:    3px;
+  background: white;
+}
+ .seperator {
+   padding-top: 2em;
+   clear: both;
+  }
+
+  #validators {
+      margin-top: 5em;
+      text-align: right;
+      color: #777;
+  }
+  @media print {
+      body {
+          font-size: 8pt;
+      }
+      .noprint {
+          display: none;
+      }
+  }
+
+
+.tip,
+.note {
+   background: #f0f0f2;
+   color: #333;
+   padding: 20px;
+   margin: 20px;
+}
+
+.tip h3,
+.note h3 {
+   padding: 0em;
+   margin: 0em;
+   font-size: 2em;
+   font-weight: bold;
+   color: #333;
+}
+
+.tip a,
+.note a {
+   color: #333;
+   text-decoration: underline;
+}
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
diff --git a/documentation/yocto-project-qs/yocto-project-qs-customization.xsl b/documentation/yocto-project-qs/yocto-project-qs-customization.xsl
new file mode 100644
index 0000000000..3dad6b96c5
--- /dev/null
+++ b/documentation/yocto-project-qs/yocto-project-qs-customization.xsl
@@ -0,0 +1,15 @@
+<?xml version='1.0'?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
+
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
+  <xsl:import href="yocto-project-qs-titlepage.xsl"/>
+
+  <xsl:include href="../template/permalinks.xsl"/>
+  <xsl:include href="../template/section.title.xsl"/>
+  <xsl:include href="../template/component.title.xsl"/>
+  <xsl:include href="../template/division.title.xsl"/>
+  <xsl:include href="../template/formal.object.heading.xsl"/>
+
+  <xsl:param name="generate.toc" select="'article nop'"></xsl:param>
+  <xsl:param name="html.stylesheet" select="'qs-style.css'" />
+</xsl:stylesheet>
diff --git a/documentation/yocto-project-qs/yocto-project-qs-eclipse-customization.xsl b/documentation/yocto-project-qs/yocto-project-qs-eclipse-customization.xsl
new file mode 100644
index 0000000000..f8f8930f27
--- /dev/null
+++ b/documentation/yocto-project-qs/yocto-project-qs-eclipse-customization.xsl
@@ -0,0 +1,25 @@
+<?xml version='1.0'?>
+<xsl:stylesheet
+        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+        xmlns="http://www.w3.org/1999/xhtml"
+        xmlns:fo="http://www.w3.org/1999/XSL/Format"
+        version="1.0">
+
+  <xsl:import
+          href="http://docbook.sourceforge.net/release/xsl/current/eclipse/eclipse3.xsl" />
+  <xsl:import href="yocto-project-qs-titlepage.xsl"/>
+
+  <xsl:param name="chunker.output.indent" select="'yes'"/>
+  <xsl:param name="chunk.quietly" select="1"/>
+  <xsl:param name="use.id.as.filename" select="1"/>
+  <xsl:param name="ulink.target" select="'_self'" />
+  <xsl:param name="base.dir" select="'html/yocto-project-qs/'"/>
+  <xsl:param name="chunk.section.depth" select="0"/>
+  <xsl:param name="html.stylesheet" select="'../book.css'"/>
+  <xsl:param name="eclipse.manifest" select="0"/>
+  <xsl:param name="create.plugin.xml" select="0"/>
+  <xsl:param name="suppress.navigation" select="1"/>
+  <xsl:param name="generate.index" select="0"/>
+  <xsl:param name="generate.toc" select="'article nop'"></xsl:param>
+  <xsl:param name="html.stylesheet" select="'style.css'" />
+</xsl:stylesheet>
diff --git a/documentation/yocto-project-qs/yocto-project-qs-titlepage.xsl b/documentation/yocto-project-qs/yocto-project-qs-titlepage.xsl
new file mode 100644
index 0000000000..a435ac77ab
--- /dev/null
+++ b/documentation/yocto-project-qs/yocto-project-qs-titlepage.xsl
@@ -0,0 +1,3820 @@
+<?xml version="1.0"?>
+
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:exsl="http://exslt.org/common" version="1.0" exclude-result-prefixes="exsl">
+
+<!-- This stylesheet was created by template/titlepage.xsl-->
+
+<xsl:template name="article.titlepage.recto">
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="articleinfo/abstract"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="artheader/abstract"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="info/abstract"/>
+  <xsl:choose>
+    <xsl:when test="articleinfo/title">
+      <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="articleinfo/title"/>
+    </xsl:when>
+    <xsl:when test="artheader/title">
+      <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="artheader/title"/>
+    </xsl:when>
+    <xsl:when test="info/title">
+      <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="info/title"/>
+    </xsl:when>
+    <xsl:when test="title">
+      <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="title"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:choose>
+    <xsl:when test="articleinfo/subtitle">
+      <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="articleinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="artheader/subtitle">
+      <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="artheader/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="articleinfo/corpauthor"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="artheader/corpauthor"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="info/corpauthor"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="articleinfo/authorgroup"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="artheader/authorgroup"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="info/authorgroup"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="articleinfo/author"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="artheader/author"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="info/author"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="articleinfo/othercredit"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="artheader/othercredit"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="info/othercredit"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="articleinfo/releaseinfo"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="artheader/releaseinfo"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="info/releaseinfo"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="articleinfo/copyright"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="artheader/copyright"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="info/copyright"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="articleinfo/legalnotice"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="artheader/legalnotice"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="info/legalnotice"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="articleinfo/pubdate"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="artheader/pubdate"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="info/pubdate"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="articleinfo/revision"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="artheader/revision"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="info/revision"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="articleinfo/revhistory"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="artheader/revhistory"/>
+  <xsl:apply-templates mode="article.titlepage.recto.auto.mode" select="info/revhistory"/>
+</xsl:template>
+
+<xsl:template name="article.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="article.titlepage.separator"><hr/>
+</xsl:template>
+
+<xsl:template name="article.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="article.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="article.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="article.titlepage.before.recto"/>
+      <xsl:call-template name="article.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="article.titlepage.before.verso"/>
+      <xsl:call-template name="article.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="article.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="article.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="article.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="abstract" mode="article.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="article.titlepage.recto.style">
+  <xsl:call-template name="anchor"/>
+  <xsl:apply-templates/>
+<!-- orignally generated content -->
+<!-- <xsl:apply-templates select="." mode="article.titlepage.recto.mode"/> -->
+</div>
+</xsl:template>
+
+<xsl:template match="title" mode="article.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="article.titlepage.recto.style">
+<xsl:apply-templates select="." mode="article.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="article.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="article.titlepage.recto.style">
+<xsl:apply-templates select="." mode="article.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="corpauthor" mode="article.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="article.titlepage.recto.style">
+<xsl:apply-templates select="." mode="article.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="authorgroup" mode="article.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="article.titlepage.recto.style">
+<xsl:apply-templates select="." mode="article.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="author" mode="article.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="article.titlepage.recto.style">
+<xsl:apply-templates select="." mode="article.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="othercredit" mode="article.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="article.titlepage.recto.style">
+<xsl:apply-templates select="." mode="article.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="releaseinfo" mode="article.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="article.titlepage.recto.style">
+<xsl:apply-templates select="." mode="article.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="copyright" mode="article.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="article.titlepage.recto.style">
+<xsl:apply-templates select="." mode="article.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="legalnotice" mode="article.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="article.titlepage.recto.style">
+<xsl:apply-templates select="." mode="article.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="pubdate" mode="article.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="article.titlepage.recto.style">
+<xsl:apply-templates select="." mode="article.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revision" mode="article.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="article.titlepage.recto.style">
+<xsl:apply-templates select="." mode="article.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revhistory" mode="article.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="article.titlepage.recto.style">
+<xsl:apply-templates select="." mode="article.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="set.titlepage.recto">
+  <xsl:choose>
+    <xsl:when test="setinfo/title">
+      <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="setinfo/title"/>
+    </xsl:when>
+    <xsl:when test="info/title">
+      <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="info/title"/>
+    </xsl:when>
+    <xsl:when test="title">
+      <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="title"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:choose>
+    <xsl:when test="setinfo/subtitle">
+      <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="setinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="setinfo/corpauthor"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="info/corpauthor"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="setinfo/authorgroup"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="info/authorgroup"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="setinfo/author"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="info/author"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="setinfo/othercredit"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="info/othercredit"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="setinfo/releaseinfo"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="info/releaseinfo"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="setinfo/copyright"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="info/copyright"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="setinfo/legalnotice"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="info/legalnotice"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="setinfo/pubdate"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="info/pubdate"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="setinfo/revision"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="info/revision"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="setinfo/revhistory"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="info/revhistory"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="setinfo/abstract"/>
+  <xsl:apply-templates mode="set.titlepage.recto.auto.mode" select="info/abstract"/>
+</xsl:template>
+
+<xsl:template name="set.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="set.titlepage.separator"><hr/>
+</xsl:template>
+
+<xsl:template name="set.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="set.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="set.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="set.titlepage.before.recto"/>
+      <xsl:call-template name="set.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="set.titlepage.before.verso"/>
+      <xsl:call-template name="set.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="set.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="set.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="set.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="title" mode="set.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="set.titlepage.recto.style">
+<xsl:apply-templates select="." mode="set.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="set.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="set.titlepage.recto.style">
+<xsl:apply-templates select="." mode="set.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="corpauthor" mode="set.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="set.titlepage.recto.style">
+<xsl:apply-templates select="." mode="set.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="authorgroup" mode="set.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="set.titlepage.recto.style">
+<xsl:apply-templates select="." mode="set.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="author" mode="set.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="set.titlepage.recto.style">
+<xsl:apply-templates select="." mode="set.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="othercredit" mode="set.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="set.titlepage.recto.style">
+<xsl:apply-templates select="." mode="set.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="releaseinfo" mode="set.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="set.titlepage.recto.style">
+<xsl:apply-templates select="." mode="set.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="copyright" mode="set.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="set.titlepage.recto.style">
+<xsl:apply-templates select="." mode="set.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="legalnotice" mode="set.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="set.titlepage.recto.style">
+<xsl:apply-templates select="." mode="set.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="pubdate" mode="set.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="set.titlepage.recto.style">
+<xsl:apply-templates select="." mode="set.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revision" mode="set.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="set.titlepage.recto.style">
+<xsl:apply-templates select="." mode="set.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revhistory" mode="set.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="set.titlepage.recto.style">
+<xsl:apply-templates select="." mode="set.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="abstract" mode="set.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="set.titlepage.recto.style">
+<xsl:apply-templates select="." mode="set.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="book.titlepage.recto">
+  <xsl:choose>
+    <xsl:when test="bookinfo/title">
+      <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="bookinfo/title"/>
+    </xsl:when>
+    <xsl:when test="info/title">
+      <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="info/title"/>
+    </xsl:when>
+    <xsl:when test="title">
+      <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="title"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:choose>
+    <xsl:when test="bookinfo/subtitle">
+      <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="bookinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="bookinfo/corpauthor"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="info/corpauthor"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="bookinfo/authorgroup"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="info/authorgroup"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="bookinfo/author"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="info/author"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="bookinfo/othercredit"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="info/othercredit"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="bookinfo/releaseinfo"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="info/releaseinfo"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="bookinfo/copyright"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="info/copyright"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="bookinfo/legalnotice"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="info/legalnotice"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="bookinfo/pubdate"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="info/pubdate"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="bookinfo/revision"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="info/revision"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="bookinfo/revhistory"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="info/revhistory"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="bookinfo/abstract"/>
+  <xsl:apply-templates mode="book.titlepage.recto.auto.mode" select="info/abstract"/>
+</xsl:template>
+
+<xsl:template name="book.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="book.titlepage.separator"><hr/>
+</xsl:template>
+
+<xsl:template name="book.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="book.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="book.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="book.titlepage.before.recto"/>
+      <xsl:call-template name="book.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="book.titlepage.before.verso"/>
+      <xsl:call-template name="book.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="book.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="book.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="book.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="title" mode="book.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="book.titlepage.recto.style">
+<xsl:apply-templates select="." mode="book.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="book.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="book.titlepage.recto.style">
+<xsl:apply-templates select="." mode="book.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="corpauthor" mode="book.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="book.titlepage.recto.style">
+<xsl:apply-templates select="." mode="book.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="authorgroup" mode="book.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="book.titlepage.recto.style">
+<xsl:apply-templates select="." mode="book.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="author" mode="book.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="book.titlepage.recto.style">
+<xsl:apply-templates select="." mode="book.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="othercredit" mode="book.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="book.titlepage.recto.style">
+<xsl:apply-templates select="." mode="book.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="releaseinfo" mode="book.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="book.titlepage.recto.style">
+<xsl:apply-templates select="." mode="book.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="copyright" mode="book.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="book.titlepage.recto.style">
+<xsl:apply-templates select="." mode="book.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="legalnotice" mode="book.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="book.titlepage.recto.style">
+<xsl:apply-templates select="." mode="book.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="pubdate" mode="book.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="book.titlepage.recto.style">
+<xsl:apply-templates select="." mode="book.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revision" mode="book.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="book.titlepage.recto.style">
+<xsl:apply-templates select="." mode="book.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revhistory" mode="book.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="book.titlepage.recto.style">
+<xsl:apply-templates select="." mode="book.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="abstract" mode="book.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="book.titlepage.recto.style">
+<xsl:apply-templates select="." mode="book.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="part.titlepage.recto">
+  <div xsl:use-attribute-sets="part.titlepage.recto.style">
+<xsl:call-template name="division.title">
+<xsl:with-param name="node" select="ancestor-or-self::part[1]"/>
+</xsl:call-template></div>
+  <xsl:choose>
+    <xsl:when test="partinfo/subtitle">
+      <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="partinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="docinfo/subtitle">
+      <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="docinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="partinfo/corpauthor"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="docinfo/corpauthor"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="info/corpauthor"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="partinfo/authorgroup"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="docinfo/authorgroup"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="info/authorgroup"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="partinfo/author"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="docinfo/author"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="info/author"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="partinfo/othercredit"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="docinfo/othercredit"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="info/othercredit"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="partinfo/releaseinfo"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="docinfo/releaseinfo"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="info/releaseinfo"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="partinfo/copyright"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="docinfo/copyright"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="info/copyright"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="partinfo/legalnotice"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="docinfo/legalnotice"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="info/legalnotice"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="partinfo/pubdate"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="docinfo/pubdate"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="info/pubdate"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="partinfo/revision"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="docinfo/revision"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="info/revision"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="partinfo/revhistory"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="docinfo/revhistory"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="info/revhistory"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="partinfo/abstract"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="docinfo/abstract"/>
+  <xsl:apply-templates mode="part.titlepage.recto.auto.mode" select="info/abstract"/>
+</xsl:template>
+
+<xsl:template name="part.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="part.titlepage.separator">
+</xsl:template>
+
+<xsl:template name="part.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="part.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="part.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="part.titlepage.before.recto"/>
+      <xsl:call-template name="part.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="part.titlepage.before.verso"/>
+      <xsl:call-template name="part.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="part.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="part.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="part.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="part.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="part.titlepage.recto.style">
+<xsl:apply-templates select="." mode="part.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="corpauthor" mode="part.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="part.titlepage.recto.style">
+<xsl:apply-templates select="." mode="part.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="authorgroup" mode="part.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="part.titlepage.recto.style">
+<xsl:apply-templates select="." mode="part.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="author" mode="part.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="part.titlepage.recto.style">
+<xsl:apply-templates select="." mode="part.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="othercredit" mode="part.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="part.titlepage.recto.style">
+<xsl:apply-templates select="." mode="part.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="releaseinfo" mode="part.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="part.titlepage.recto.style">
+<xsl:apply-templates select="." mode="part.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="copyright" mode="part.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="part.titlepage.recto.style">
+<xsl:apply-templates select="." mode="part.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="legalnotice" mode="part.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="part.titlepage.recto.style">
+<xsl:apply-templates select="." mode="part.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="pubdate" mode="part.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="part.titlepage.recto.style">
+<xsl:apply-templates select="." mode="part.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revision" mode="part.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="part.titlepage.recto.style">
+<xsl:apply-templates select="." mode="part.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revhistory" mode="part.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="part.titlepage.recto.style">
+<xsl:apply-templates select="." mode="part.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="abstract" mode="part.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="part.titlepage.recto.style">
+<xsl:apply-templates select="." mode="part.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="partintro.titlepage.recto">
+  <xsl:choose>
+    <xsl:when test="partintroinfo/title">
+      <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="partintroinfo/title"/>
+    </xsl:when>
+    <xsl:when test="docinfo/title">
+      <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="docinfo/title"/>
+    </xsl:when>
+    <xsl:when test="info/title">
+      <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="info/title"/>
+    </xsl:when>
+    <xsl:when test="title">
+      <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="title"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:choose>
+    <xsl:when test="partintroinfo/subtitle">
+      <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="partintroinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="docinfo/subtitle">
+      <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="docinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="partintroinfo/corpauthor"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="docinfo/corpauthor"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="info/corpauthor"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="partintroinfo/authorgroup"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="docinfo/authorgroup"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="info/authorgroup"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="partintroinfo/author"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="docinfo/author"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="info/author"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="partintroinfo/othercredit"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="docinfo/othercredit"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="info/othercredit"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="partintroinfo/releaseinfo"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="docinfo/releaseinfo"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="info/releaseinfo"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="partintroinfo/copyright"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="docinfo/copyright"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="info/copyright"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="partintroinfo/legalnotice"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="docinfo/legalnotice"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="info/legalnotice"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="partintroinfo/pubdate"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="docinfo/pubdate"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="info/pubdate"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="partintroinfo/revision"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="docinfo/revision"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="info/revision"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="partintroinfo/revhistory"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="docinfo/revhistory"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="info/revhistory"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="partintroinfo/abstract"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="docinfo/abstract"/>
+  <xsl:apply-templates mode="partintro.titlepage.recto.auto.mode" select="info/abstract"/>
+</xsl:template>
+
+<xsl:template name="partintro.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="partintro.titlepage.separator">
+</xsl:template>
+
+<xsl:template name="partintro.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="partintro.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="partintro.titlepage">
+  <div>
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="partintro.titlepage.before.recto"/>
+      <xsl:call-template name="partintro.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="partintro.titlepage.before.verso"/>
+      <xsl:call-template name="partintro.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="partintro.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="partintro.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="partintro.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="title" mode="partintro.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="partintro.titlepage.recto.style">
+<xsl:apply-templates select="." mode="partintro.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="partintro.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="partintro.titlepage.recto.style">
+<xsl:apply-templates select="." mode="partintro.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="corpauthor" mode="partintro.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="partintro.titlepage.recto.style">
+<xsl:apply-templates select="." mode="partintro.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="authorgroup" mode="partintro.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="partintro.titlepage.recto.style">
+<xsl:apply-templates select="." mode="partintro.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="author" mode="partintro.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="partintro.titlepage.recto.style">
+<xsl:apply-templates select="." mode="partintro.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="othercredit" mode="partintro.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="partintro.titlepage.recto.style">
+<xsl:apply-templates select="." mode="partintro.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="releaseinfo" mode="partintro.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="partintro.titlepage.recto.style">
+<xsl:apply-templates select="." mode="partintro.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="copyright" mode="partintro.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="partintro.titlepage.recto.style">
+<xsl:apply-templates select="." mode="partintro.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="legalnotice" mode="partintro.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="partintro.titlepage.recto.style">
+<xsl:apply-templates select="." mode="partintro.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="pubdate" mode="partintro.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="partintro.titlepage.recto.style">
+<xsl:apply-templates select="." mode="partintro.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revision" mode="partintro.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="partintro.titlepage.recto.style">
+<xsl:apply-templates select="." mode="partintro.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revhistory" mode="partintro.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="partintro.titlepage.recto.style">
+<xsl:apply-templates select="." mode="partintro.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="abstract" mode="partintro.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="partintro.titlepage.recto.style">
+<xsl:apply-templates select="." mode="partintro.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="reference.titlepage.recto">
+  <xsl:choose>
+    <xsl:when test="referenceinfo/title">
+      <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="referenceinfo/title"/>
+    </xsl:when>
+    <xsl:when test="docinfo/title">
+      <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="docinfo/title"/>
+    </xsl:when>
+    <xsl:when test="info/title">
+      <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="info/title"/>
+    </xsl:when>
+    <xsl:when test="title">
+      <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="title"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:choose>
+    <xsl:when test="referenceinfo/subtitle">
+      <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="referenceinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="docinfo/subtitle">
+      <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="docinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="referenceinfo/corpauthor"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="docinfo/corpauthor"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="info/corpauthor"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="referenceinfo/authorgroup"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="docinfo/authorgroup"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="info/authorgroup"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="referenceinfo/author"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="docinfo/author"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="info/author"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="referenceinfo/othercredit"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="docinfo/othercredit"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="info/othercredit"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="referenceinfo/releaseinfo"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="docinfo/releaseinfo"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="info/releaseinfo"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="referenceinfo/copyright"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="docinfo/copyright"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="info/copyright"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="referenceinfo/legalnotice"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="docinfo/legalnotice"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="info/legalnotice"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="referenceinfo/pubdate"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="docinfo/pubdate"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="info/pubdate"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="referenceinfo/revision"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="docinfo/revision"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="info/revision"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="referenceinfo/revhistory"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="docinfo/revhistory"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="info/revhistory"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="referenceinfo/abstract"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="docinfo/abstract"/>
+  <xsl:apply-templates mode="reference.titlepage.recto.auto.mode" select="info/abstract"/>
+</xsl:template>
+
+<xsl:template name="reference.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="reference.titlepage.separator"><hr/>
+</xsl:template>
+
+<xsl:template name="reference.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="reference.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="reference.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="reference.titlepage.before.recto"/>
+      <xsl:call-template name="reference.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="reference.titlepage.before.verso"/>
+      <xsl:call-template name="reference.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="reference.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="reference.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="reference.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="title" mode="reference.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="reference.titlepage.recto.style">
+<xsl:apply-templates select="." mode="reference.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="reference.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="reference.titlepage.recto.style">
+<xsl:apply-templates select="." mode="reference.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="corpauthor" mode="reference.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="reference.titlepage.recto.style">
+<xsl:apply-templates select="." mode="reference.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="authorgroup" mode="reference.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="reference.titlepage.recto.style">
+<xsl:apply-templates select="." mode="reference.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="author" mode="reference.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="reference.titlepage.recto.style">
+<xsl:apply-templates select="." mode="reference.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="othercredit" mode="reference.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="reference.titlepage.recto.style">
+<xsl:apply-templates select="." mode="reference.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="releaseinfo" mode="reference.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="reference.titlepage.recto.style">
+<xsl:apply-templates select="." mode="reference.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="copyright" mode="reference.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="reference.titlepage.recto.style">
+<xsl:apply-templates select="." mode="reference.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="legalnotice" mode="reference.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="reference.titlepage.recto.style">
+<xsl:apply-templates select="." mode="reference.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="pubdate" mode="reference.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="reference.titlepage.recto.style">
+<xsl:apply-templates select="." mode="reference.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revision" mode="reference.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="reference.titlepage.recto.style">
+<xsl:apply-templates select="." mode="reference.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revhistory" mode="reference.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="reference.titlepage.recto.style">
+<xsl:apply-templates select="." mode="reference.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="abstract" mode="reference.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="reference.titlepage.recto.style">
+<xsl:apply-templates select="." mode="reference.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="refentry.titlepage.recto">
+</xsl:template>
+
+<xsl:template name="refentry.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="refentry.titlepage.separator">
+</xsl:template>
+
+<xsl:template name="refentry.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="refentry.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="refentry.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="refentry.titlepage.before.recto"/>
+      <xsl:call-template name="refentry.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="refentry.titlepage.before.verso"/>
+      <xsl:call-template name="refentry.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="refentry.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="refentry.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="refentry.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template name="dedication.titlepage.recto">
+  <div xsl:use-attribute-sets="dedication.titlepage.recto.style">
+<xsl:call-template name="component.title">
+<xsl:with-param name="node" select="ancestor-or-self::dedication[1]"/>
+</xsl:call-template></div>
+  <xsl:choose>
+    <xsl:when test="dedicationinfo/subtitle">
+      <xsl:apply-templates mode="dedication.titlepage.recto.auto.mode" select="dedicationinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="docinfo/subtitle">
+      <xsl:apply-templates mode="dedication.titlepage.recto.auto.mode" select="docinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="dedication.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="dedication.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+</xsl:template>
+
+<xsl:template name="dedication.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="dedication.titlepage.separator">
+</xsl:template>
+
+<xsl:template name="dedication.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="dedication.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="dedication.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="dedication.titlepage.before.recto"/>
+      <xsl:call-template name="dedication.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="dedication.titlepage.before.verso"/>
+      <xsl:call-template name="dedication.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="dedication.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="dedication.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="dedication.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="dedication.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="dedication.titlepage.recto.style">
+<xsl:apply-templates select="." mode="dedication.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="acknowledgements.titlepage.recto">
+  <div xsl:use-attribute-sets="acknowledgements.titlepage.recto.style">
+<xsl:call-template name="component.title">
+<xsl:with-param name="node" select="ancestor-or-self::acknowledgements[1]"/>
+</xsl:call-template></div>
+  <xsl:choose>
+    <xsl:when test="acknowledgementsinfo/subtitle">
+      <xsl:apply-templates mode="acknowledgements.titlepage.recto.auto.mode" select="acknowledgementsinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="docinfo/subtitle">
+      <xsl:apply-templates mode="acknowledgements.titlepage.recto.auto.mode" select="docinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="acknowledgements.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="acknowledgements.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+</xsl:template>
+
+<xsl:template name="acknowledgements.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="acknowledgements.titlepage.separator">
+</xsl:template>
+
+<xsl:template name="acknowledgements.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="acknowledgements.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="acknowledgements.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="acknowledgements.titlepage.before.recto"/>
+      <xsl:call-template name="acknowledgements.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="acknowledgements.titlepage.before.verso"/>
+      <xsl:call-template name="acknowledgements.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="acknowledgements.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="acknowledgements.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="acknowledgements.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="acknowledgements.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="acknowledgements.titlepage.recto.style">
+<xsl:apply-templates select="." mode="acknowledgements.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="preface.titlepage.recto">
+  <xsl:choose>
+    <xsl:when test="prefaceinfo/title">
+      <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="prefaceinfo/title"/>
+    </xsl:when>
+    <xsl:when test="docinfo/title">
+      <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="docinfo/title"/>
+    </xsl:when>
+    <xsl:when test="info/title">
+      <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="info/title"/>
+    </xsl:when>
+    <xsl:when test="title">
+      <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="title"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:choose>
+    <xsl:when test="prefaceinfo/subtitle">
+      <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="prefaceinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="docinfo/subtitle">
+      <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="docinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="prefaceinfo/corpauthor"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="docinfo/corpauthor"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="info/corpauthor"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="prefaceinfo/authorgroup"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="docinfo/authorgroup"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="info/authorgroup"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="prefaceinfo/author"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="docinfo/author"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="info/author"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="prefaceinfo/othercredit"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="docinfo/othercredit"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="info/othercredit"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="prefaceinfo/releaseinfo"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="docinfo/releaseinfo"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="info/releaseinfo"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="prefaceinfo/copyright"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="docinfo/copyright"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="info/copyright"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="prefaceinfo/legalnotice"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="docinfo/legalnotice"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="info/legalnotice"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="prefaceinfo/pubdate"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="docinfo/pubdate"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="info/pubdate"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="prefaceinfo/revision"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="docinfo/revision"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="info/revision"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="prefaceinfo/revhistory"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="docinfo/revhistory"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="info/revhistory"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="prefaceinfo/abstract"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="docinfo/abstract"/>
+  <xsl:apply-templates mode="preface.titlepage.recto.auto.mode" select="info/abstract"/>
+</xsl:template>
+
+<xsl:template name="preface.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="preface.titlepage.separator">
+</xsl:template>
+
+<xsl:template name="preface.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="preface.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="preface.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="preface.titlepage.before.recto"/>
+      <xsl:call-template name="preface.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="preface.titlepage.before.verso"/>
+      <xsl:call-template name="preface.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="preface.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="preface.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="preface.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="title" mode="preface.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="preface.titlepage.recto.style">
+<xsl:apply-templates select="." mode="preface.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="preface.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="preface.titlepage.recto.style">
+<xsl:apply-templates select="." mode="preface.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="corpauthor" mode="preface.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="preface.titlepage.recto.style">
+<xsl:apply-templates select="." mode="preface.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="authorgroup" mode="preface.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="preface.titlepage.recto.style">
+<xsl:apply-templates select="." mode="preface.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="author" mode="preface.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="preface.titlepage.recto.style">
+<xsl:apply-templates select="." mode="preface.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="othercredit" mode="preface.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="preface.titlepage.recto.style">
+<xsl:apply-templates select="." mode="preface.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="releaseinfo" mode="preface.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="preface.titlepage.recto.style">
+<xsl:apply-templates select="." mode="preface.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="copyright" mode="preface.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="preface.titlepage.recto.style">
+<xsl:apply-templates select="." mode="preface.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="legalnotice" mode="preface.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="preface.titlepage.recto.style">
+<xsl:apply-templates select="." mode="preface.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="pubdate" mode="preface.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="preface.titlepage.recto.style">
+<xsl:apply-templates select="." mode="preface.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revision" mode="preface.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="preface.titlepage.recto.style">
+<xsl:apply-templates select="." mode="preface.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revhistory" mode="preface.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="preface.titlepage.recto.style">
+<xsl:apply-templates select="." mode="preface.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="abstract" mode="preface.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="preface.titlepage.recto.style">
+<xsl:apply-templates select="." mode="preface.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="chapter.titlepage.recto">
+  <xsl:choose>
+    <xsl:when test="chapterinfo/title">
+      <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="chapterinfo/title"/>
+    </xsl:when>
+    <xsl:when test="docinfo/title">
+      <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="docinfo/title"/>
+    </xsl:when>
+    <xsl:when test="info/title">
+      <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="info/title"/>
+    </xsl:when>
+    <xsl:when test="title">
+      <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="title"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:choose>
+    <xsl:when test="chapterinfo/subtitle">
+      <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="chapterinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="docinfo/subtitle">
+      <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="docinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="chapterinfo/corpauthor"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="docinfo/corpauthor"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="info/corpauthor"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="chapterinfo/authorgroup"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="docinfo/authorgroup"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="info/authorgroup"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="chapterinfo/author"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="docinfo/author"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="info/author"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="chapterinfo/othercredit"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="docinfo/othercredit"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="info/othercredit"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="chapterinfo/releaseinfo"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="docinfo/releaseinfo"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="info/releaseinfo"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="chapterinfo/copyright"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="docinfo/copyright"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="info/copyright"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="chapterinfo/legalnotice"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="docinfo/legalnotice"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="info/legalnotice"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="chapterinfo/pubdate"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="docinfo/pubdate"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="info/pubdate"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="chapterinfo/revision"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="docinfo/revision"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="info/revision"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="chapterinfo/revhistory"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="docinfo/revhistory"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="info/revhistory"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="chapterinfo/abstract"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="docinfo/abstract"/>
+  <xsl:apply-templates mode="chapter.titlepage.recto.auto.mode" select="info/abstract"/>
+</xsl:template>
+
+<xsl:template name="chapter.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="chapter.titlepage.separator">
+</xsl:template>
+
+<xsl:template name="chapter.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="chapter.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="chapter.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="chapter.titlepage.before.recto"/>
+      <xsl:call-template name="chapter.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="chapter.titlepage.before.verso"/>
+      <xsl:call-template name="chapter.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="chapter.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="chapter.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="chapter.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="title" mode="chapter.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="chapter.titlepage.recto.style">
+<xsl:apply-templates select="." mode="chapter.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="chapter.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="chapter.titlepage.recto.style">
+<xsl:apply-templates select="." mode="chapter.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="corpauthor" mode="chapter.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="chapter.titlepage.recto.style">
+<xsl:apply-templates select="." mode="chapter.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="authorgroup" mode="chapter.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="chapter.titlepage.recto.style">
+<xsl:apply-templates select="." mode="chapter.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="author" mode="chapter.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="chapter.titlepage.recto.style">
+<xsl:apply-templates select="." mode="chapter.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="othercredit" mode="chapter.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="chapter.titlepage.recto.style">
+<xsl:apply-templates select="." mode="chapter.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="releaseinfo" mode="chapter.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="chapter.titlepage.recto.style">
+<xsl:apply-templates select="." mode="chapter.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="copyright" mode="chapter.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="chapter.titlepage.recto.style">
+<xsl:apply-templates select="." mode="chapter.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="legalnotice" mode="chapter.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="chapter.titlepage.recto.style">
+<xsl:apply-templates select="." mode="chapter.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="pubdate" mode="chapter.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="chapter.titlepage.recto.style">
+<xsl:apply-templates select="." mode="chapter.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revision" mode="chapter.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="chapter.titlepage.recto.style">
+<xsl:apply-templates select="." mode="chapter.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revhistory" mode="chapter.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="chapter.titlepage.recto.style">
+<xsl:apply-templates select="." mode="chapter.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="abstract" mode="chapter.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="chapter.titlepage.recto.style">
+<xsl:apply-templates select="." mode="chapter.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="appendix.titlepage.recto">
+  <xsl:choose>
+    <xsl:when test="appendixinfo/title">
+      <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="appendixinfo/title"/>
+    </xsl:when>
+    <xsl:when test="docinfo/title">
+      <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="docinfo/title"/>
+    </xsl:when>
+    <xsl:when test="info/title">
+      <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="info/title"/>
+    </xsl:when>
+    <xsl:when test="title">
+      <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="title"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:choose>
+    <xsl:when test="appendixinfo/subtitle">
+      <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="appendixinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="docinfo/subtitle">
+      <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="docinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="appendixinfo/corpauthor"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="docinfo/corpauthor"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="info/corpauthor"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="appendixinfo/authorgroup"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="docinfo/authorgroup"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="info/authorgroup"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="appendixinfo/author"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="docinfo/author"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="info/author"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="appendixinfo/othercredit"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="docinfo/othercredit"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="info/othercredit"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="appendixinfo/releaseinfo"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="docinfo/releaseinfo"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="info/releaseinfo"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="appendixinfo/copyright"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="docinfo/copyright"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="info/copyright"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="appendixinfo/legalnotice"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="docinfo/legalnotice"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="info/legalnotice"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="appendixinfo/pubdate"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="docinfo/pubdate"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="info/pubdate"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="appendixinfo/revision"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="docinfo/revision"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="info/revision"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="appendixinfo/revhistory"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="docinfo/revhistory"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="info/revhistory"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="appendixinfo/abstract"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="docinfo/abstract"/>
+  <xsl:apply-templates mode="appendix.titlepage.recto.auto.mode" select="info/abstract"/>
+</xsl:template>
+
+<xsl:template name="appendix.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="appendix.titlepage.separator">
+</xsl:template>
+
+<xsl:template name="appendix.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="appendix.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="appendix.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="appendix.titlepage.before.recto"/>
+      <xsl:call-template name="appendix.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="appendix.titlepage.before.verso"/>
+      <xsl:call-template name="appendix.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="appendix.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="appendix.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="appendix.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="title" mode="appendix.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="appendix.titlepage.recto.style">
+<xsl:apply-templates select="." mode="appendix.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="appendix.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="appendix.titlepage.recto.style">
+<xsl:apply-templates select="." mode="appendix.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="corpauthor" mode="appendix.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="appendix.titlepage.recto.style">
+<xsl:apply-templates select="." mode="appendix.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="authorgroup" mode="appendix.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="appendix.titlepage.recto.style">
+<xsl:apply-templates select="." mode="appendix.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="author" mode="appendix.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="appendix.titlepage.recto.style">
+<xsl:apply-templates select="." mode="appendix.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="othercredit" mode="appendix.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="appendix.titlepage.recto.style">
+<xsl:apply-templates select="." mode="appendix.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="releaseinfo" mode="appendix.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="appendix.titlepage.recto.style">
+<xsl:apply-templates select="." mode="appendix.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="copyright" mode="appendix.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="appendix.titlepage.recto.style">
+<xsl:apply-templates select="." mode="appendix.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="legalnotice" mode="appendix.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="appendix.titlepage.recto.style">
+<xsl:apply-templates select="." mode="appendix.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="pubdate" mode="appendix.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="appendix.titlepage.recto.style">
+<xsl:apply-templates select="." mode="appendix.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revision" mode="appendix.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="appendix.titlepage.recto.style">
+<xsl:apply-templates select="." mode="appendix.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revhistory" mode="appendix.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="appendix.titlepage.recto.style">
+<xsl:apply-templates select="." mode="appendix.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="abstract" mode="appendix.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="appendix.titlepage.recto.style">
+<xsl:apply-templates select="." mode="appendix.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="section.titlepage.recto">
+  <xsl:choose>
+    <xsl:when test="sectioninfo/title">
+      <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="sectioninfo/title"/>
+    </xsl:when>
+    <xsl:when test="info/title">
+      <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="info/title"/>
+    </xsl:when>
+    <xsl:when test="title">
+      <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="title"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:choose>
+    <xsl:when test="sectioninfo/subtitle">
+      <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="sectioninfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="sectioninfo/corpauthor"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="info/corpauthor"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="sectioninfo/authorgroup"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="info/authorgroup"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="sectioninfo/author"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="info/author"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="sectioninfo/othercredit"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="info/othercredit"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="sectioninfo/releaseinfo"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="info/releaseinfo"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="sectioninfo/copyright"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="info/copyright"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="sectioninfo/legalnotice"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="info/legalnotice"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="sectioninfo/pubdate"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="info/pubdate"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="sectioninfo/revision"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="info/revision"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="sectioninfo/revhistory"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="info/revhistory"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="sectioninfo/abstract"/>
+  <xsl:apply-templates mode="section.titlepage.recto.auto.mode" select="info/abstract"/>
+</xsl:template>
+
+<xsl:template name="section.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="section.titlepage.separator"><xsl:if test="count(parent::*)='0'"><hr/></xsl:if>
+</xsl:template>
+
+<xsl:template name="section.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="section.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="section.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="section.titlepage.before.recto"/>
+      <xsl:call-template name="section.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="section.titlepage.before.verso"/>
+      <xsl:call-template name="section.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="section.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="section.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="section.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="title" mode="section.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="section.titlepage.recto.style">
+<xsl:apply-templates select="." mode="section.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="section.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="section.titlepage.recto.style">
+<xsl:apply-templates select="." mode="section.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="corpauthor" mode="section.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="section.titlepage.recto.style">
+<xsl:apply-templates select="." mode="section.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="authorgroup" mode="section.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="section.titlepage.recto.style">
+<xsl:apply-templates select="." mode="section.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="author" mode="section.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="section.titlepage.recto.style">
+<xsl:apply-templates select="." mode="section.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="othercredit" mode="section.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="section.titlepage.recto.style">
+<xsl:apply-templates select="." mode="section.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="releaseinfo" mode="section.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="section.titlepage.recto.style">
+<xsl:apply-templates select="." mode="section.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="copyright" mode="section.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="section.titlepage.recto.style">
+<xsl:apply-templates select="." mode="section.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="legalnotice" mode="section.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="section.titlepage.recto.style">
+<xsl:apply-templates select="." mode="section.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="pubdate" mode="section.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="section.titlepage.recto.style">
+<xsl:apply-templates select="." mode="section.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revision" mode="section.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="section.titlepage.recto.style">
+<xsl:apply-templates select="." mode="section.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revhistory" mode="section.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="section.titlepage.recto.style">
+<xsl:apply-templates select="." mode="section.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="abstract" mode="section.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="section.titlepage.recto.style">
+<xsl:apply-templates select="." mode="section.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="sect1.titlepage.recto">
+  <xsl:choose>
+    <xsl:when test="sect1info/title">
+      <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="sect1info/title"/>
+    </xsl:when>
+    <xsl:when test="info/title">
+      <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="info/title"/>
+    </xsl:when>
+    <xsl:when test="title">
+      <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="title"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:choose>
+    <xsl:when test="sect1info/subtitle">
+      <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="sect1info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="sect1info/corpauthor"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="info/corpauthor"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="sect1info/authorgroup"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="info/authorgroup"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="sect1info/author"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="info/author"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="sect1info/othercredit"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="info/othercredit"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="sect1info/releaseinfo"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="info/releaseinfo"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="sect1info/copyright"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="info/copyright"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="sect1info/legalnotice"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="info/legalnotice"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="sect1info/pubdate"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="info/pubdate"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="sect1info/revision"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="info/revision"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="sect1info/revhistory"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="info/revhistory"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="sect1info/abstract"/>
+  <xsl:apply-templates mode="sect1.titlepage.recto.auto.mode" select="info/abstract"/>
+</xsl:template>
+
+<xsl:template name="sect1.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="sect1.titlepage.separator"><xsl:if test="count(parent::*)='0'"><hr/></xsl:if>
+</xsl:template>
+
+<xsl:template name="sect1.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="sect1.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="sect1.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="sect1.titlepage.before.recto"/>
+      <xsl:call-template name="sect1.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="sect1.titlepage.before.verso"/>
+      <xsl:call-template name="sect1.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="sect1.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="sect1.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="sect1.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="title" mode="sect1.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect1.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect1.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="sect1.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect1.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect1.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="corpauthor" mode="sect1.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect1.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect1.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="authorgroup" mode="sect1.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect1.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect1.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="author" mode="sect1.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect1.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect1.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="othercredit" mode="sect1.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect1.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect1.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="releaseinfo" mode="sect1.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect1.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect1.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="copyright" mode="sect1.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect1.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect1.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="legalnotice" mode="sect1.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect1.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect1.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="pubdate" mode="sect1.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect1.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect1.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revision" mode="sect1.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect1.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect1.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revhistory" mode="sect1.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect1.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect1.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="abstract" mode="sect1.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect1.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect1.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="sect2.titlepage.recto">
+  <xsl:choose>
+    <xsl:when test="sect2info/title">
+      <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="sect2info/title"/>
+    </xsl:when>
+    <xsl:when test="info/title">
+      <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="info/title"/>
+    </xsl:when>
+    <xsl:when test="title">
+      <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="title"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:choose>
+    <xsl:when test="sect2info/subtitle">
+      <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="sect2info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="sect2info/corpauthor"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="info/corpauthor"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="sect2info/authorgroup"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="info/authorgroup"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="sect2info/author"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="info/author"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="sect2info/othercredit"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="info/othercredit"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="sect2info/releaseinfo"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="info/releaseinfo"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="sect2info/copyright"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="info/copyright"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="sect2info/legalnotice"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="info/legalnotice"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="sect2info/pubdate"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="info/pubdate"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="sect2info/revision"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="info/revision"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="sect2info/revhistory"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="info/revhistory"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="sect2info/abstract"/>
+  <xsl:apply-templates mode="sect2.titlepage.recto.auto.mode" select="info/abstract"/>
+</xsl:template>
+
+<xsl:template name="sect2.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="sect2.titlepage.separator"><xsl:if test="count(parent::*)='0'"><hr/></xsl:if>
+</xsl:template>
+
+<xsl:template name="sect2.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="sect2.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="sect2.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="sect2.titlepage.before.recto"/>
+      <xsl:call-template name="sect2.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="sect2.titlepage.before.verso"/>
+      <xsl:call-template name="sect2.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="sect2.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="sect2.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="sect2.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="title" mode="sect2.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect2.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect2.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="sect2.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect2.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect2.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="corpauthor" mode="sect2.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect2.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect2.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="authorgroup" mode="sect2.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect2.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect2.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="author" mode="sect2.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect2.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect2.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="othercredit" mode="sect2.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect2.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect2.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="releaseinfo" mode="sect2.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect2.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect2.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="copyright" mode="sect2.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect2.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect2.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="legalnotice" mode="sect2.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect2.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect2.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="pubdate" mode="sect2.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect2.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect2.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revision" mode="sect2.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect2.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect2.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revhistory" mode="sect2.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect2.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect2.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="abstract" mode="sect2.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect2.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect2.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="sect3.titlepage.recto">
+  <xsl:choose>
+    <xsl:when test="sect3info/title">
+      <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="sect3info/title"/>
+    </xsl:when>
+    <xsl:when test="info/title">
+      <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="info/title"/>
+    </xsl:when>
+    <xsl:when test="title">
+      <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="title"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:choose>
+    <xsl:when test="sect3info/subtitle">
+      <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="sect3info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="sect3info/corpauthor"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="info/corpauthor"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="sect3info/authorgroup"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="info/authorgroup"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="sect3info/author"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="info/author"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="sect3info/othercredit"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="info/othercredit"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="sect3info/releaseinfo"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="info/releaseinfo"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="sect3info/copyright"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="info/copyright"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="sect3info/legalnotice"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="info/legalnotice"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="sect3info/pubdate"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="info/pubdate"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="sect3info/revision"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="info/revision"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="sect3info/revhistory"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="info/revhistory"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="sect3info/abstract"/>
+  <xsl:apply-templates mode="sect3.titlepage.recto.auto.mode" select="info/abstract"/>
+</xsl:template>
+
+<xsl:template name="sect3.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="sect3.titlepage.separator"><xsl:if test="count(parent::*)='0'"><hr/></xsl:if>
+</xsl:template>
+
+<xsl:template name="sect3.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="sect3.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="sect3.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="sect3.titlepage.before.recto"/>
+      <xsl:call-template name="sect3.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="sect3.titlepage.before.verso"/>
+      <xsl:call-template name="sect3.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="sect3.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="sect3.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="sect3.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="title" mode="sect3.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect3.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect3.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="sect3.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect3.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect3.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="corpauthor" mode="sect3.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect3.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect3.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="authorgroup" mode="sect3.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect3.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect3.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="author" mode="sect3.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect3.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect3.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="othercredit" mode="sect3.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect3.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect3.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="releaseinfo" mode="sect3.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect3.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect3.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="copyright" mode="sect3.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect3.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect3.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="legalnotice" mode="sect3.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect3.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect3.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="pubdate" mode="sect3.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect3.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect3.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revision" mode="sect3.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect3.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect3.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revhistory" mode="sect3.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect3.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect3.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="abstract" mode="sect3.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect3.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect3.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="sect4.titlepage.recto">
+  <xsl:choose>
+    <xsl:when test="sect4info/title">
+      <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="sect4info/title"/>
+    </xsl:when>
+    <xsl:when test="info/title">
+      <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="info/title"/>
+    </xsl:when>
+    <xsl:when test="title">
+      <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="title"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:choose>
+    <xsl:when test="sect4info/subtitle">
+      <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="sect4info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="sect4info/corpauthor"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="info/corpauthor"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="sect4info/authorgroup"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="info/authorgroup"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="sect4info/author"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="info/author"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="sect4info/othercredit"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="info/othercredit"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="sect4info/releaseinfo"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="info/releaseinfo"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="sect4info/copyright"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="info/copyright"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="sect4info/legalnotice"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="info/legalnotice"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="sect4info/pubdate"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="info/pubdate"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="sect4info/revision"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="info/revision"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="sect4info/revhistory"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="info/revhistory"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="sect4info/abstract"/>
+  <xsl:apply-templates mode="sect4.titlepage.recto.auto.mode" select="info/abstract"/>
+</xsl:template>
+
+<xsl:template name="sect4.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="sect4.titlepage.separator"><xsl:if test="count(parent::*)='0'"><hr/></xsl:if>
+</xsl:template>
+
+<xsl:template name="sect4.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="sect4.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="sect4.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="sect4.titlepage.before.recto"/>
+      <xsl:call-template name="sect4.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="sect4.titlepage.before.verso"/>
+      <xsl:call-template name="sect4.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="sect4.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="sect4.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="sect4.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="title" mode="sect4.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect4.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect4.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="sect4.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect4.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect4.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="corpauthor" mode="sect4.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect4.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect4.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="authorgroup" mode="sect4.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect4.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect4.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="author" mode="sect4.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect4.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect4.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="othercredit" mode="sect4.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect4.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect4.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="releaseinfo" mode="sect4.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect4.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect4.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="copyright" mode="sect4.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect4.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect4.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="legalnotice" mode="sect4.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect4.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect4.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="pubdate" mode="sect4.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect4.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect4.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revision" mode="sect4.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect4.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect4.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revhistory" mode="sect4.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect4.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect4.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="abstract" mode="sect4.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect4.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect4.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="sect5.titlepage.recto">
+  <xsl:choose>
+    <xsl:when test="sect5info/title">
+      <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="sect5info/title"/>
+    </xsl:when>
+    <xsl:when test="info/title">
+      <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="info/title"/>
+    </xsl:when>
+    <xsl:when test="title">
+      <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="title"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:choose>
+    <xsl:when test="sect5info/subtitle">
+      <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="sect5info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="sect5info/corpauthor"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="info/corpauthor"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="sect5info/authorgroup"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="info/authorgroup"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="sect5info/author"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="info/author"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="sect5info/othercredit"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="info/othercredit"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="sect5info/releaseinfo"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="info/releaseinfo"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="sect5info/copyright"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="info/copyright"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="sect5info/legalnotice"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="info/legalnotice"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="sect5info/pubdate"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="info/pubdate"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="sect5info/revision"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="info/revision"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="sect5info/revhistory"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="info/revhistory"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="sect5info/abstract"/>
+  <xsl:apply-templates mode="sect5.titlepage.recto.auto.mode" select="info/abstract"/>
+</xsl:template>
+
+<xsl:template name="sect5.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="sect5.titlepage.separator"><xsl:if test="count(parent::*)='0'"><hr/></xsl:if>
+</xsl:template>
+
+<xsl:template name="sect5.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="sect5.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="sect5.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="sect5.titlepage.before.recto"/>
+      <xsl:call-template name="sect5.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="sect5.titlepage.before.verso"/>
+      <xsl:call-template name="sect5.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="sect5.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="sect5.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="sect5.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="title" mode="sect5.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect5.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect5.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="sect5.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect5.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect5.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="corpauthor" mode="sect5.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect5.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect5.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="authorgroup" mode="sect5.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect5.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect5.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="author" mode="sect5.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect5.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect5.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="othercredit" mode="sect5.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect5.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect5.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="releaseinfo" mode="sect5.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect5.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect5.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="copyright" mode="sect5.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect5.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect5.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="legalnotice" mode="sect5.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect5.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect5.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="pubdate" mode="sect5.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect5.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect5.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revision" mode="sect5.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect5.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect5.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revhistory" mode="sect5.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect5.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect5.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="abstract" mode="sect5.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sect5.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sect5.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="simplesect.titlepage.recto">
+  <xsl:choose>
+    <xsl:when test="simplesectinfo/title">
+      <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="simplesectinfo/title"/>
+    </xsl:when>
+    <xsl:when test="docinfo/title">
+      <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="docinfo/title"/>
+    </xsl:when>
+    <xsl:when test="info/title">
+      <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="info/title"/>
+    </xsl:when>
+    <xsl:when test="title">
+      <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="title"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:choose>
+    <xsl:when test="simplesectinfo/subtitle">
+      <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="simplesectinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="docinfo/subtitle">
+      <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="docinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="simplesectinfo/corpauthor"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="docinfo/corpauthor"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="info/corpauthor"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="simplesectinfo/authorgroup"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="docinfo/authorgroup"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="info/authorgroup"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="simplesectinfo/author"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="docinfo/author"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="info/author"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="simplesectinfo/othercredit"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="docinfo/othercredit"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="info/othercredit"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="simplesectinfo/releaseinfo"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="docinfo/releaseinfo"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="info/releaseinfo"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="simplesectinfo/copyright"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="docinfo/copyright"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="info/copyright"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="simplesectinfo/legalnotice"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="docinfo/legalnotice"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="info/legalnotice"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="simplesectinfo/pubdate"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="docinfo/pubdate"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="info/pubdate"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="simplesectinfo/revision"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="docinfo/revision"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="info/revision"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="simplesectinfo/revhistory"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="docinfo/revhistory"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="info/revhistory"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="simplesectinfo/abstract"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="docinfo/abstract"/>
+  <xsl:apply-templates mode="simplesect.titlepage.recto.auto.mode" select="info/abstract"/>
+</xsl:template>
+
+<xsl:template name="simplesect.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="simplesect.titlepage.separator"><xsl:if test="count(parent::*)='0'"><hr/></xsl:if>
+</xsl:template>
+
+<xsl:template name="simplesect.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="simplesect.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="simplesect.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="simplesect.titlepage.before.recto"/>
+      <xsl:call-template name="simplesect.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="simplesect.titlepage.before.verso"/>
+      <xsl:call-template name="simplesect.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="simplesect.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="simplesect.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="simplesect.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="title" mode="simplesect.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="simplesect.titlepage.recto.style">
+<xsl:apply-templates select="." mode="simplesect.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="simplesect.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="simplesect.titlepage.recto.style">
+<xsl:apply-templates select="." mode="simplesect.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="corpauthor" mode="simplesect.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="simplesect.titlepage.recto.style">
+<xsl:apply-templates select="." mode="simplesect.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="authorgroup" mode="simplesect.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="simplesect.titlepage.recto.style">
+<xsl:apply-templates select="." mode="simplesect.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="author" mode="simplesect.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="simplesect.titlepage.recto.style">
+<xsl:apply-templates select="." mode="simplesect.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="othercredit" mode="simplesect.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="simplesect.titlepage.recto.style">
+<xsl:apply-templates select="." mode="simplesect.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="releaseinfo" mode="simplesect.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="simplesect.titlepage.recto.style">
+<xsl:apply-templates select="." mode="simplesect.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="copyright" mode="simplesect.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="simplesect.titlepage.recto.style">
+<xsl:apply-templates select="." mode="simplesect.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="legalnotice" mode="simplesect.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="simplesect.titlepage.recto.style">
+<xsl:apply-templates select="." mode="simplesect.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="pubdate" mode="simplesect.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="simplesect.titlepage.recto.style">
+<xsl:apply-templates select="." mode="simplesect.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revision" mode="simplesect.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="simplesect.titlepage.recto.style">
+<xsl:apply-templates select="." mode="simplesect.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="revhistory" mode="simplesect.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="simplesect.titlepage.recto.style">
+<xsl:apply-templates select="." mode="simplesect.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template match="abstract" mode="simplesect.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="simplesect.titlepage.recto.style">
+<xsl:apply-templates select="." mode="simplesect.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="bibliography.titlepage.recto">
+  <div xsl:use-attribute-sets="bibliography.titlepage.recto.style">
+<xsl:call-template name="component.title">
+<xsl:with-param name="node" select="ancestor-or-self::bibliography[1]"/>
+</xsl:call-template></div>
+  <xsl:choose>
+    <xsl:when test="bibliographyinfo/subtitle">
+      <xsl:apply-templates mode="bibliography.titlepage.recto.auto.mode" select="bibliographyinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="docinfo/subtitle">
+      <xsl:apply-templates mode="bibliography.titlepage.recto.auto.mode" select="docinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="bibliography.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="bibliography.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+</xsl:template>
+
+<xsl:template name="bibliography.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="bibliography.titlepage.separator">
+</xsl:template>
+
+<xsl:template name="bibliography.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="bibliography.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="bibliography.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="bibliography.titlepage.before.recto"/>
+      <xsl:call-template name="bibliography.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="bibliography.titlepage.before.verso"/>
+      <xsl:call-template name="bibliography.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="bibliography.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="bibliography.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="bibliography.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="bibliography.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="bibliography.titlepage.recto.style">
+<xsl:apply-templates select="." mode="bibliography.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="glossary.titlepage.recto">
+  <div xsl:use-attribute-sets="glossary.titlepage.recto.style">
+<xsl:call-template name="component.title">
+<xsl:with-param name="node" select="ancestor-or-self::glossary[1]"/>
+</xsl:call-template></div>
+  <xsl:choose>
+    <xsl:when test="glossaryinfo/subtitle">
+      <xsl:apply-templates mode="glossary.titlepage.recto.auto.mode" select="glossaryinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="docinfo/subtitle">
+      <xsl:apply-templates mode="glossary.titlepage.recto.auto.mode" select="docinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="glossary.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="glossary.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+</xsl:template>
+
+<xsl:template name="glossary.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="glossary.titlepage.separator">
+</xsl:template>
+
+<xsl:template name="glossary.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="glossary.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="glossary.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="glossary.titlepage.before.recto"/>
+      <xsl:call-template name="glossary.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="glossary.titlepage.before.verso"/>
+      <xsl:call-template name="glossary.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="glossary.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="glossary.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="glossary.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="glossary.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="glossary.titlepage.recto.style">
+<xsl:apply-templates select="." mode="glossary.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="index.titlepage.recto">
+  <div xsl:use-attribute-sets="index.titlepage.recto.style">
+<xsl:call-template name="component.title">
+<xsl:with-param name="node" select="ancestor-or-self::index[1]"/>
+</xsl:call-template></div>
+  <xsl:choose>
+    <xsl:when test="indexinfo/subtitle">
+      <xsl:apply-templates mode="index.titlepage.recto.auto.mode" select="indexinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="docinfo/subtitle">
+      <xsl:apply-templates mode="index.titlepage.recto.auto.mode" select="docinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="index.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="index.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+</xsl:template>
+
+<xsl:template name="index.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="index.titlepage.separator">
+</xsl:template>
+
+<xsl:template name="index.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="index.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="index.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="index.titlepage.before.recto"/>
+      <xsl:call-template name="index.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="index.titlepage.before.verso"/>
+      <xsl:call-template name="index.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="index.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="index.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="index.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="index.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="index.titlepage.recto.style">
+<xsl:apply-templates select="." mode="index.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="setindex.titlepage.recto">
+  <div xsl:use-attribute-sets="setindex.titlepage.recto.style">
+<xsl:call-template name="component.title">
+<xsl:with-param name="node" select="ancestor-or-self::setindex[1]"/>
+</xsl:call-template></div>
+  <xsl:choose>
+    <xsl:when test="setindexinfo/subtitle">
+      <xsl:apply-templates mode="setindex.titlepage.recto.auto.mode" select="setindexinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="docinfo/subtitle">
+      <xsl:apply-templates mode="setindex.titlepage.recto.auto.mode" select="docinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="setindex.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="setindex.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+</xsl:template>
+
+<xsl:template name="setindex.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="setindex.titlepage.separator">
+</xsl:template>
+
+<xsl:template name="setindex.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="setindex.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="setindex.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="setindex.titlepage.before.recto"/>
+      <xsl:call-template name="setindex.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="setindex.titlepage.before.verso"/>
+      <xsl:call-template name="setindex.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="setindex.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="setindex.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="setindex.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="setindex.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="setindex.titlepage.recto.style">
+<xsl:apply-templates select="." mode="setindex.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+<xsl:template name="sidebar.titlepage.recto">
+  <xsl:choose>
+    <xsl:when test="sidebarinfo/title">
+      <xsl:apply-templates mode="sidebar.titlepage.recto.auto.mode" select="sidebarinfo/title"/>
+    </xsl:when>
+    <xsl:when test="docinfo/title">
+      <xsl:apply-templates mode="sidebar.titlepage.recto.auto.mode" select="docinfo/title"/>
+    </xsl:when>
+    <xsl:when test="info/title">
+      <xsl:apply-templates mode="sidebar.titlepage.recto.auto.mode" select="info/title"/>
+    </xsl:when>
+    <xsl:when test="title">
+      <xsl:apply-templates mode="sidebar.titlepage.recto.auto.mode" select="title"/>
+    </xsl:when>
+  </xsl:choose>
+
+  <xsl:choose>
+    <xsl:when test="sidebarinfo/subtitle">
+      <xsl:apply-templates mode="sidebar.titlepage.recto.auto.mode" select="sidebarinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="docinfo/subtitle">
+      <xsl:apply-templates mode="sidebar.titlepage.recto.auto.mode" select="docinfo/subtitle"/>
+    </xsl:when>
+    <xsl:when test="info/subtitle">
+      <xsl:apply-templates mode="sidebar.titlepage.recto.auto.mode" select="info/subtitle"/>
+    </xsl:when>
+    <xsl:when test="subtitle">
+      <xsl:apply-templates mode="sidebar.titlepage.recto.auto.mode" select="subtitle"/>
+    </xsl:when>
+  </xsl:choose>
+
+</xsl:template>
+
+<xsl:template name="sidebar.titlepage.verso">
+</xsl:template>
+
+<xsl:template name="sidebar.titlepage.separator">
+</xsl:template>
+
+<xsl:template name="sidebar.titlepage.before.recto">
+</xsl:template>
+
+<xsl:template name="sidebar.titlepage.before.verso">
+</xsl:template>
+
+<xsl:template name="sidebar.titlepage">
+  <div class="titlepage">
+    <xsl:variable name="recto.content">
+      <xsl:call-template name="sidebar.titlepage.before.recto"/>
+      <xsl:call-template name="sidebar.titlepage.recto"/>
+    </xsl:variable>
+    <xsl:variable name="recto.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($recto.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($recto.content) != '') or ($recto.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$recto.content"/></div>
+    </xsl:if>
+    <xsl:variable name="verso.content">
+      <xsl:call-template name="sidebar.titlepage.before.verso"/>
+      <xsl:call-template name="sidebar.titlepage.verso"/>
+    </xsl:variable>
+    <xsl:variable name="verso.elements.count">
+      <xsl:choose>
+        <xsl:when test="function-available('exsl:node-set')"><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:when test="contains(system-property('xsl:vendor'), 'Apache Software Foundation')">
+          <!--Xalan quirk--><xsl:value-of select="count(exsl:node-set($verso.content)/*)"/></xsl:when>
+        <xsl:otherwise>1</xsl:otherwise>
+      </xsl:choose>
+    </xsl:variable>
+    <xsl:if test="(normalize-space($verso.content) != '') or ($verso.elements.count &gt; 0)">
+      <div><xsl:copy-of select="$verso.content"/></div>
+    </xsl:if>
+    <xsl:call-template name="sidebar.titlepage.separator"/>
+  </div>
+</xsl:template>
+
+<xsl:template match="*" mode="sidebar.titlepage.recto.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="*" mode="sidebar.titlepage.verso.mode">
+  <!-- if an element isn't found in this mode, -->
+  <!-- try the generic titlepage.mode -->
+  <xsl:apply-templates select="." mode="titlepage.mode"/>
+</xsl:template>
+
+<xsl:template match="title" mode="sidebar.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sidebar.titlepage.recto.style">
+<xsl:call-template name="formal.object.heading">
+<xsl:with-param name="object" select="ancestor-or-self::sidebar[1]"/>
+</xsl:call-template>
+</div>
+</xsl:template>
+
+<xsl:template match="subtitle" mode="sidebar.titlepage.recto.auto.mode">
+<div xsl:use-attribute-sets="sidebar.titlepage.recto.style">
+<xsl:apply-templates select="." mode="sidebar.titlepage.recto.mode"/>
+</div>
+</xsl:template>
+
+</xsl:stylesheet>
+
diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml
new file mode 100644
index 0000000000..d0f0d113da
--- /dev/null
+++ b/documentation/yocto-project-qs/yocto-project-qs.xml
@@ -0,0 +1,968 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<article id='intro'>
+    <articleinfo>
+        <title>Yocto Project Quick Start</title>
+
+        <copyright>
+            <year>&COPYRIGHT_YEAR;</year>
+            <holder>Linux Foundation</holder>
+        </copyright>
+
+        <legalnotice>
+            <para>
+                Permission is granted to copy, distribute and/or modify this document under
+                the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
+            </para>
+            <note>
+                For the latest version of this manual associated with this
+                Yocto Project release, see the
+                <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>
+                from the Yocto Project website.
+            </note>
+        </legalnotice>
+
+
+        <abstract>
+            <imagedata fileref="figures/yocto-project-transp.png"
+                        width="6in" depth="1in"
+                        align="right" scale="25" />
+        </abstract>
+    </articleinfo>
+
+<section id='welcome'>
+    <title>Welcome!</title>
+    <para>
+        Welcome to the Yocto Project!
+        The Yocto Project is an open-source collaboration project focused on
+        embedded Linux developers.
+        Among other things, the Yocto Project uses a build system based on the
+        OpenEmbedded (OE) project, which uses the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>
+        tool, to construct complete Linux images.
+        The BitBake and OE components are combined together to form
+        <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink>,
+        a reference build system.
+    </para>
+
+    <para>
+        If you don't have a system that runs Linux and you want to give the Yocto Project a test run,
+        you might consider using the Yocto Project Build Appliance.
+        The Build Appliance allows you to build and boot a custom embedded Linux image with the Yocto
+        Project using a non-Linux development system.
+        See the <ulink url='https://www.yoctoproject.org/tools-resources/projects/build-appliance'>Yocto
+        Project Build Appliance</ulink> for more information.
+    </para>
+
+    <para>
+        On the other hand, if you know all about open-source development, Linux development environments,
+        Git source repositories and the like and you just want some quick information that lets you try out
+        the Yocto Project on your Linux system, skip right to the
+        "<link linkend='super-user'>Super User</link>" section at the end of this quick start.
+    </para>
+
+    <para>
+        For the rest of you, this short document will give you some basic information about the environment and
+        let you experience it in its simplest form.
+        After reading this document, you will have a basic understanding of what the Yocto Project is
+        and how to use some of its core components.
+        This document steps you through a simple example showing you how to build a small image
+        and run it using the Quick EMUlator (QEMU emulator).
+    </para>
+
+    <para>
+        For more detailed information on the Yocto Project, you should check out these resources:
+        <itemizedlist>
+            <listitem><para><emphasis>Website:</emphasis> The <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>
+                provides the latest builds, breaking news, full development documentation, and a rich Yocto
+                Project Development Community into which you can tap.
+                </para></listitem>
+            <listitem><para><emphasis>FAQs:</emphasis> Lists commonly asked Yocto Project questions and answers.
+                You can find two FAQs: <ulink url='&YOCTO_WIKI_URL;/wiki/FAQ'>Yocto Project FAQ</ulink> on
+                a wiki, and the
+                "<ulink url='&YOCTO_DOCS_REF_URL;#faq'>FAQ</ulink>" chapter in
+                the Yocto Project Reference Manual.
+                </para></listitem>
+            <listitem><para><emphasis>Developer Screencast:</emphasis> The
+                <ulink url='http://vimeo.com/36450321'>Getting Started with the Yocto Project - New Developer Screencast Tutorial</ulink>
+                provides a 30-minute video created for users unfamiliar with
+                the Yocto Project but familiar with Linux build systems.
+                While this screencast is somewhat dated, the introductory
+                and fundamental concepts are useful for the beginner.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='yp-intro'>
+    <title>Introducing the Yocto Project Development Environment</title>
+    <para>
+        The Yocto Project through the OpenEmbedded build system provides an open source development
+        environment targeting the ARM, MIPS, PowerPC and x86 architectures for a variety of
+        platforms including x86-64 and emulated ones.
+        You can use components from the Yocto Project to design, develop, build, debug, simulate,
+        and test the complete software stack using Linux, the X Window System, GNOME Mobile-based
+        application frameworks, and Qt frameworks.
+    </para>
+
+    <mediaobject>
+        <imageobject>
+            <imagedata fileref="figures/yocto-environment.png"
+                format="PNG" align='center' scalefit='1' width="100%"/>
+        </imageobject>
+        <caption>
+            <para>The Yocto Project Development Environment</para>
+        </caption>
+     </mediaobject>
+
+    <para>
+        Here are some highlights for the Yocto Project:
+    </para>
+
+    <itemizedlist>
+        <listitem>
+            <para>Provides a recent Linux kernel along with a set of system commands and libraries suitable for the embedded environment.</para>
+        </listitem>
+        <listitem>
+            <para>Makes available system components such as X11, GTK+, Qt, Clutter, and SDL
+            (among others) so you can create a rich user experience on devices
+            that have display hardware.
+            For devices that do not have a display or where you wish to use alternative UI
+            frameworks, these components need not be installed.</para>
+        </listitem>
+        <listitem>
+            <para>Creates a focused and stable core compatible with the OpenEmbedded
+            project with which you can easily and reliably build and develop.</para>
+        </listitem>
+        <listitem>
+            <para>Fully supports a wide range of hardware and device emulation through the QEMU
+            Emulator.</para>
+        </listitem>
+    </itemizedlist>
+
+    <para>
+        The Yocto Project can generate images for many kinds of devices.
+        However, the standard example machines target QEMU full-system emulation for x86, x86-64, ARM, MIPS,
+        and PPC-based architectures as well as specific hardware such as the
+        <trademark class='registered'>Intel</trademark> Desktop Board DH55TC.
+        Because an image developed with the Yocto Project can boot inside a QEMU emulator, the
+        development environment works nicely as a test platform for developing embedded software.
+    </para>
+
+    <para>
+        Another important Yocto Project feature is the Sato reference User Interface.
+        This optional GNOME mobile-based UI, which is intended for devices with
+        restricted screen sizes, sits neatly on top of a device using the
+        GNOME Mobile Stack and provides a well-defined user experience.
+        Implemented in its own layer, it makes it clear to developers how they can implement
+        their own user interface on top of a Linux image created with the Yocto Project.
+    </para>
+</section>
+
+<section id='yp-resources'>
+    <title>What You Need and How You Get It</title>
+
+    <para>
+        You need these things to develop projects in the Yocto Project
+        environment:
+    </para>
+
+    <itemizedlist>
+        <listitem><para>
+            A host system with a minimum of 50 Gbytes of free disk space that
+            is running a supported Linux distribution (i.e. recent releases
+            of Fedora, openSUSE, CentOS, Debian, or Ubuntu).
+            If the host system supports multiple cores and threads, you can
+            configure the Yocto Project build system to significantly
+            decrease the time needed to build images.
+            </para></listitem>
+        <listitem><para>
+            Appropriate packages installed on the system you are using for
+            builds.
+            </para></listitem>
+        <listitem><para>
+            A release of the Yocto Project.
+            </para></listitem>
+    </itemizedlist>
+
+    <section id='the-linux-distro'>
+        <title>The Linux Distribution</title>
+
+        <para>
+            The Yocto Project team is continually verifying more and more Linux
+            distributions with each release.
+            In general, if you have the current release minus one of the following
+            distributions you should have no problems.
+            <itemizedlist>
+                <listitem><para>Ubuntu</para></listitem>
+                <listitem><para>Fedora</para></listitem>
+                <listitem><para>openSUSE</para></listitem>
+                <listitem><para>CentOS</para></listitem>
+                <listitem><para>Debian</para></listitem>
+            </itemizedlist>
+            For a more detailed list of distributions that support the Yocto Project,
+            see the
+            "<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>" section
+            in the Yocto Project Reference Manual.
+            </para>
+        <para>
+            The OpenEmbedded build system should be able to run on any modern
+            distribution that has the following versions for Git, tar, and
+            Python.
+            <itemizedlist>
+                <listitem><para>Git 1.7.8 or greater</para></listitem>
+                <listitem><para>tar 1.24 or greater</para></listitem>
+                <listitem><para>Python 2.7.3 or greater excluding Python
+                   3.x, which is not supported.</para></listitem>
+            </itemizedlist>
+            Earlier releases of Python are known to not work and the
+            system does not support Python 3 at this time.
+            If your system does not meet any of these three listed
+            version requirements, you can
+            take steps to prepare the system so that you can still use the build
+            system.
+            See the
+            "<ulink url='&YOCTO_DOCS_REF_URL;#required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</ulink>"
+            section in the Yocto Project Reference Manual for information.
+        </para>
+        <para>
+            This document assumes you are running one of the previously noted
+            distributions on your Linux-based host systems.
+        </para>
+        <note>
+            <para>
+                If you attempt to use a distribution not in the above list,
+                you may or may not have success.
+                Yocto Project releases are tested against the stable Linux
+                distributions listed in the
+                "<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>"
+                section of the Yocto Project Reference Manual.
+                If you encounter problems, please go to
+                <ulink url='&YOCTO_BUGZILLA_URL;'>Yocto Project Bugzilla</ulink>
+                and submit a bug.
+                We are interested in hearing about your experience.
+            </para>
+        </note>
+    </section>
+
+    <section id='packages'>
+        <title>The Packages</title>
+
+        <para>
+            Packages and package installation vary depending on your development system
+            and on your intent.
+            For example, if you want to build an image that can run
+            on QEMU in graphical mode (a minimal, basic build
+            requirement), then the number of packages is different than if you want to
+            build an image on a headless system or build out the Yocto Project
+            documentation set.
+            Collectively, the number of required packages is large
+            if you want to be able to cover all cases.
+            <note>In general, you need to have root access and then install the
+                required packages.
+                Thus, the commands in the following section may or may not work
+                depending on whether or not your Linux distribution has
+                <filename>sudo</filename> installed.</note>
+        </para>
+
+        <para>
+            The next few sections list, by supported Linux Distributions, the required
+            packages needed to build an image that runs on QEMU in graphical mode
+            (e.g. essential plus graphics support).
+        </para>
+
+        <para>
+            For lists of required packages for other scenarios, see the
+            "<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-host-development-system'>Required Packages for the Host Development System</ulink>"
+            section in the Yocto Project Reference Manual.
+        </para>
+
+        <section id='ubuntu'>
+            <title>Ubuntu and Debian</title>
+
+            <para>
+                The essential and graphical support packages you need for a
+                supported Ubuntu or Debian distribution are shown in the
+                following command:
+                <literallayout class='monospaced'>
+     $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL; libsdl1.2-dev xterm
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='fedora'>
+            <title>Fedora</title>
+
+            <para>
+                The essential and graphical packages you need for a supported
+                Fedora distribution are shown in the following command:
+                <literallayout class='monospaced'>
+     $ sudo yum install &FEDORA_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='opensuse'>
+            <title>OpenSUSE</title>
+
+            <para>
+                The essential and graphical packages you need for a supported
+                OpenSUSE distribution are shown in the following command:
+                <literallayout class='monospaced'>
+     $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL; libSDL-devel xterm
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='centos'>
+            <title>CentOS</title>
+
+            <para>
+                The essential and graphical packages you need for a supported
+                CentOS distribution are shown in the following command:
+                <literallayout class='monospaced'>
+     $ sudo yum install &CENTOS_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
+                </literallayout>
+                <note>Depending on the CentOS version you are using, other requirements
+                    and dependencies might exist.
+                    For details, you should look at the CentOS sections on the
+                    <ulink url='https://wiki.yoctoproject.org/wiki/Poky/GettingStarted/Dependencies'>Poky/GettingStarted/Dependencies</ulink>
+                    wiki page.</note>
+            </para>
+        </section>
+    </section>
+
+    <section id='releases'>
+        <title>Yocto Project Release</title>
+
+        <para>
+            It is recommended that you get the latest Yocto Project files
+            by setting up (cloning in
+            <ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink> terms) a local
+            copy of the
+            <filename>poky</filename> Git repository on your host development
+            system.
+            Doing so allows you to contribute back to the Yocto Project project.
+            For information on how to get set up using this method, see the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#local-yp-release'>Yocto
+            Project Release</ulink>" item in the Yocto Project Development Manual.
+        </para>
+
+        <para>
+            You can also get the Yocto Project Files by downloading
+            Yocto Project releases from the
+            <ulink url="&YOCTO_HOME_URL;">Yocto Project website</ulink>.
+            From the website, you just click "Downloads" in the navigation pane
+            to the left to display all Yocto Project downloads.
+            Current and archived releases are available for download.
+            Nightly and developmental builds are also maintained at
+            <ulink url="&YOCTO_AB_NIGHTLY_URL;"></ulink>.
+            However, for this document a released version of Yocto Project is used.
+        </para>
+
+    </section>
+</section>
+
+<section id='test-run'>
+    <title>A Quick Test Run</title>
+
+    <para>
+        Now that you have your system requirements in order, you can give the Yocto Project a try.
+        This section presents some steps that let you do the following:
+    </para>
+
+    <itemizedlist>
+        <listitem>
+            <para>
+                Build an image and run it in the QEMU emulator.
+            </para>
+        </listitem>
+        <listitem>
+            <para>
+                Use a pre-built image and run it in the QEMU emulator.
+            </para>
+        </listitem>
+    </itemizedlist>
+
+    <section id='building-image'>
+        <title>Building an Image</title>
+
+        <para>
+            In the development environment you will need to build an image whenever you change hardware
+            support, add or change system libraries, or add or change services that have dependencies.
+        </para>
+
+        <mediaobject>
+            <imageobject>
+                <imagedata fileref="figures/building-an-image.png" format="PNG" align='center' scalefit='1'/>
+            </imageobject>
+            <caption>
+                <para>Building an Image</para>
+            </caption>
+         </mediaobject>
+
+         <para>
+             Use the following commands to build your image.
+             The OpenEmbedded build process creates an entire Linux
+             distribution, including the toolchain, from source.
+             <note><title>Note about Network Proxies</title>
+                 <para>
+                     By default, the build process searches for source code
+                     using a pre-determined order through a set of locations.
+                     If you are working behind a firewall and your build system
+                     is not set up for proxies, you could encounter problems
+                     with the build process when fetching source code (e.g.
+                     fetcher failures or Git failures).
+                 </para>
+
+                 <para>
+                     If you do not know your proxy settings, consult your
+                     local network infrastructure resources and get that
+                     information.
+                     A good starting point could also be to check your web
+                     browser settings.
+                     Finally, you can find more information on using the Yocto
+                     Project behind a firewall in the Yocto Project Reference
+                     Manual
+                     <ulink url='&YOCTO_DOCS_REF_URL;#how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>FAQ</ulink>
+                     and on the
+                     "<ulink url='https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy'>Working Behind a Network Proxy</ulink>"
+                     wiki page.
+                 </para>
+             </note>
+         </para>
+
+         <para>
+             <literallayout class='monospaced'>
+     $ git clone &YOCTO_GIT_URL;/git/poky
+     $ cd poky
+     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+     $ source &OE_INIT_FILE;
+             </literallayout>
+         </para>
+
+         <tip>
+             <para>
+                 To help conserve disk space during builds, you can add the
+                 following statement to your project's configuration file,
+                 which for this example is
+                 <filename>poky/build/conf/local.conf</filename>.
+                 Adding this statement deletes the work directory used for
+                 building a package once the package is built.
+                 <literallayout class='monospaced'>
+     INHERIT += "rm_work"
+                 </literallayout>
+             </para>
+         </tip>
+
+         <itemizedlist>
+             <listitem><para>In the previous example, the first command uses
+                 <ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink> to create
+                 a local repository named <filename>poky</filename> that is a
+                 clone of the upstream Yocto Project
+                 <filename>poky</filename> repository.</para></listitem>
+             <listitem><para>The third command checks out a local branch and
+                 names it <filename>&DISTRO_NAME;</filename>.
+                 The local branch tracks the upstream branch of the same name.
+                 Creating your own branch based on the released branch ensures
+                 you are using the latest files for that release.
+                 </para></listitem>
+             <listitem><para>
+                 The final command runs the Yocto Project
+                 <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                 environment setup script.
+                 Running this script defines OpenEmbedded build environment
+                 settings needed to complete the build.
+                 The script also creates the
+                 <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
+                 which is <filename>build</filename> in this case and is located
+                 in the
+                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                 After the script runs, your current working directory is set
+                 to the Build Directory.
+                 Later, when the build completes, the Build Directory contains
+                 all the files created during the build.
+                 <note>
+                     For information on running a memory-resident
+                     <ulink url='&YOCTO_DOCS_REF_URL;#usingpoky-components-bitbake'>BitBake</ulink>,
+                     see the
+                     <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>
+                     setup script.
+                 </note></para></listitem>
+         </itemizedlist>
+         <para>
+             Take some time to examine your <filename>local.conf</filename> file
+             in your project's configuration directory, which is found in the Build Directory.
+             The defaults in that file should work fine.
+             However, there are some variables of interest at which you might look.
+         </para>
+
+         <para>
+             By default, the target architecture for the build is <filename>qemux86</filename>,
+             which produces an image that can be used in the QEMU emulator and is targeted at an
+             <trademark class='registered'>Intel</trademark> 32-bit based architecture.
+             To change this default, edit the value of the
+             <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
+             variable in the configuration file before launching the build.
+         </para>
+
+         <para>
+             Another couple of variables of interest are the
+             <ulink url='&YOCTO_DOCS_REF_URL;#var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></ulink> and the
+             <ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></ulink> variables.
+             By default, these variables are set to the number of processor
+             cores your build host uses.
+             However, if your build host uses multiple processor cores,
+             you should increase these settings to twice the number of
+             cores used.
+             Doing so can significantly shorten your build time.
+         </para>
+
+        <para>
+            Another consideration before you build is the package manager used when creating
+            the image.
+            By default, the OpenEmbedded build system uses the RPM package manager.
+            You can control this configuration by using the
+            <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink></filename> variable.
+             For additional package manager selection information, see the
+             "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-package'><filename>package*.bbclass</filename></ulink>"
+             section in the Yocto Project Reference Manual.
+        </para>
+
+         <para>
+             Continue with the following command to build an OS image for the target, which is
+             <filename>core-image-sato</filename> in this example.
+             For information on the <filename>-k</filename> option use the
+             <filename>bitbake --help</filename> command, see the
+             "<ulink url='&YOCTO_DOCS_REF_URL;#usingpoky-components-bitbake'>BitBake</ulink>"
+             section in the Yocto Project Reference Manual, or see the
+             "<ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual-command'>BitBake Command</ulink>"
+             section in the BitBake User Manual.
+             <literallayout class='monospaced'>
+     $ bitbake -k core-image-sato
+             </literallayout>
+             <note>
+                 BitBake requires Python 2.6 or 2.7.  For more information on
+                 this requirement, see the
+                 "<ulink url='&YOCTO_DOCS_REF_URL;#required-git-tar-and-python-versions'>Required Git, tar, and Python</ulink>"
+                 section in the Yocto Project Reference Manual.
+             </note>
+             The final command runs the image using the QEMU emulator:
+             <literallayout class='monospaced'>
+     $ runqemu qemux86
+             </literallayout>
+             <note>
+                 <para>
+                     Depending on the number of processors and cores, the amount
+                     of RAM, the speed of your Internet connection and other
+                     factors, the build process could take several hours the
+                     first time you run it.
+                     Subsequent builds run much faster since parts of the build
+                     are cached.
+                 </para>
+             </note>
+         </para>
+    </section>
+
+    <section id='using-pre-built'>
+        <title>Using Pre-Built Binaries and QEMU</title>
+
+        <para>
+            If hardware, libraries and services are stable, you can get started by using a pre-built binary
+            of the filesystem image, kernel, and toolchain and run it using the QEMU emulator.
+            This scenario is useful for developing application software.
+        </para>
+
+        <mediaobject>
+            <imageobject>
+            <imagedata fileref="figures/using-a-pre-built-image.png" format="PNG" align='center' scalefit='1'/>
+            </imageobject>
+            <caption>
+                <para>Using a Pre-Built Image</para>
+            </caption>
+        </mediaobject>
+
+        <para>
+            For this scenario, you need to do several things:
+        </para>
+
+        <itemizedlist>
+            <listitem><para>Install the appropriate stand-alone toolchain tarball.</para></listitem>
+            <listitem><para>Download the pre-built image that will boot with QEMU.
+                You need to be sure to get the QEMU image that matches your target machine’s
+                architecture (e.g. x86, ARM, etc.).</para></listitem>
+            <listitem><para>Download the filesystem image for your target machine's architecture.
+                </para></listitem>
+            <listitem><para>Set up the environment to emulate the hardware and then start the QEMU emulator.
+                </para></listitem>
+        </itemizedlist>
+
+        <section id='installing-the-toolchain'>
+            <title>Installing the Toolchain</title>
+
+            <para>
+                You can download a tarball installer, which includes the
+                pre-built toolchain, the <filename>runqemu</filename>
+                script, and support files from the appropriate directory under
+                <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>.
+                Toolchains are available for 32-bit and 64-bit x86 development
+                systems from the <filename>i686</filename> and
+                <filename>x86_64</filename> directories, respectively.
+                The toolchains the Yocto Project provides are based off the
+                <filename>core-image-sato</filename> image and contain
+                libraries appropriate for developing against that image.
+                Each type of development system supports five or more target
+                architectures.
+            </para>
+
+            <para>
+                The names of the tarball installer scripts are such that a
+                string representing the host system appears first in the
+                filename and then is immediately followed by a string
+                representing the target architecture.
+            </para>
+
+            <literallayout class='monospaced'>
+     poky-glibc-<replaceable>host_system</replaceable>-<replaceable>image_type</replaceable>-<replaceable>arch</replaceable>-toolchain-<replaceable>release_version</replaceable>.sh
+
+     Where:
+         <replaceable>host_system</replaceable> is a string representing your development system:
+
+                    i686 or x86_64.
+
+         <replaceable>image_type</replaceable> is a string representing the image you wish to
+                develop a Software Development Toolkit (SDK) for use against.
+                The Yocto Project builds toolchain installers using the
+                following BitBake command:
+
+                    bitbake core-image-sato -c populate_sdk
+
+         <replaceable>arch</replaceable> is a string representing the tuned target architecture:
+
+                    i586, x86_64, powerpc, mips, armv7a or armv5te
+
+         <replaceable>release_version</replaceable> is a string representing the release number of the
+                Yocto Project:
+
+                    &DISTRO;, &DISTRO;+snapshot
+            </literallayout>
+
+            <para>
+                For example, the following toolchain installer is for a 64-bit
+                development host system and a i586-tuned target architecture
+                based off the SDK for <filename>core-image-sato</filename>:
+                <literallayout class='monospaced'>
+     poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
+                </literallayout>
+            </para>
+
+            <para>
+                Toolchains are self-contained and by default are installed into
+                <filename>/opt/poky</filename>.
+                However, when you run the toolchain installer, you can choose an
+                installation directory.
+            </para>
+
+            <para>
+                The following command shows how to run the installer given a toolchain tarball
+                for a 64-bit x86 development host system and a 32-bit x86 target architecture.
+                You must change the permissions on the toolchain
+                installer script so that it is executable.
+            </para>
+
+            <para>
+                The example assumes the toolchain installer is located in <filename>~/Downloads/</filename>.
+                <note>
+                    If you do not have write permissions for the directory into which you are installing
+                    the toolchain, the toolchain installer notifies you and exits.
+                    Be sure you have write permissions in the directory and run the installer again.
+                </note>
+            </para>
+
+            <para>
+                <literallayout class='monospaced'>
+     $ ~/Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
+                </literallayout>
+            </para>
+
+            <para>
+                For more information on how to install tarballs, see the
+                "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" and
+                "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-toolchain-from-within-the-build-tree'>Using BitBake and the Build Directory</ulink>" sections in the Yocto Project Application Developer's Guide.
+            </para>
+        </section>
+
+        <section id='downloading-the-pre-built-linux-kernel'>
+            <title>Downloading the Pre-Built Linux Kernel</title>
+
+            <para>
+                You can download the pre-built Linux kernel suitable for running in the QEMU emulator from
+                <ulink url='&YOCTO_QEMU_DL_URL;'></ulink>.
+                Be sure to use the kernel that matches the architecture you want to simulate.
+                Download areas exist for the five supported machine architectures:
+                <filename>qemuarm</filename>, <filename>qemumips</filename>, <filename>qemuppc</filename>,
+                <filename>qemux86</filename>, and <filename>qemux86-64</filename>.
+            </para>
+
+            <para>
+                Most kernel files have one of the following forms:
+                <literallayout class='monospaced'>
+     *zImage-qemu<replaceable>arch</replaceable>.bin
+     vmlinux-qemu<replaceable>arch</replaceable>.bin
+
+     Where:
+         <replaceable>arch</replaceable> is a string representing the target architecture:
+                x86, x86-64, ppc, mips, or arm.
+                </literallayout>
+            </para>
+
+            <para>
+                You can learn more about downloading a Yocto Project kernel in the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Yocto Project Kernel</ulink>"
+                bulleted item in the Yocto Project Development Manual.
+            </para>
+        </section>
+
+        <section id='downloading-the-filesystem'>
+            <title>Downloading the Filesystem</title>
+
+            <para>
+                You can also download the filesystem image suitable for your target architecture from
+                <ulink url='&YOCTO_QEMU_DL_URL;'></ulink>.
+                Again, be sure to use the filesystem that matches the architecture you want
+                to simulate.
+            </para>
+
+            <para>
+                The filesystem image has two tarball forms: <filename>ext3</filename> and
+                <filename>tar</filename>.
+                You must use the <filename>ext3</filename> form when booting an image using the
+                QEMU emulator.
+                The <filename>tar</filename> form can be flattened out in your host development system
+                and used for build purposes with the Yocto Project.
+                <literallayout class='monospaced'>
+     core-image-<replaceable>profile</replaceable>-qemu<replaceable>arch</replaceable>.ext3
+     core-image-<replaceable>profile</replaceable>-qemu<replaceable>arch</replaceable>.tar.bz2
+
+     Where:
+         <replaceable>profile</replaceable> is the filesystem image's profile:
+                   lsb, lsb-dev, lsb-sdk, lsb-qt3, minimal, minimal-dev, sato,
+                   sato-dev, or sato-sdk. For information on these types of image
+                   profiles, see the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>"
+                   chapter in the Yocto Project Reference Manual.
+
+         <replaceable>arch</replaceable> is a string representing the target architecture:
+                x86, x86-64, ppc, mips, or arm.
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='setting-up-the-environment-and-starting-the-qemu-emulator'>
+            <title>Setting Up the Environment and Starting the QEMU Emulator</title>
+
+            <para>
+                Before you start the QEMU emulator, you need to set up the emulation environment.
+                The following command form sets up the emulation environment.
+                <literallayout class='monospaced'>
+     $ source &YOCTO_ADTPATH_DIR;/environment-setup-<replaceable>arch</replaceable>-poky-linux-<replaceable>if</replaceable>
+
+     Where:
+         <replaceable>arch</replaceable> is a string representing the target architecture:
+                i586, x86_64, ppc603e, mips, or armv5te.
+
+         <replaceable>if</replaceable> is a string representing an embedded application binary interface.
+              Not all setup scripts include this string.
+                </literallayout>
+            </para>
+
+            <para>
+                Finally, this command form invokes the QEMU emulator
+                <literallayout class='monospaced'>
+     $ runqemu <replaceable>qemuarch</replaceable> <replaceable>kernel-image</replaceable> <replaceable>filesystem-image</replaceable>
+
+     Where:
+         <replaceable>qemuarch</replaceable> is a string representing the target architecture: qemux86, qemux86-64,
+                    qemuppc, qemumips, or qemuarm.
+
+         <replaceable>kernel-image</replaceable> is the architecture-specific kernel image.
+
+         <replaceable>filesystem-image</replaceable> is the .ext3 filesystem image.
+
+                </literallayout>
+            </para>
+
+            <para>
+                Continuing with the example, the following two commands setup the emulation
+                environment and launch QEMU.
+                This example assumes the root filesystem (<filename>.ext3</filename> file) and
+                the pre-built kernel image file both reside in your home directory.
+                The kernel and filesystem are for a 32-bit target architecture.
+                <literallayout class='monospaced'>
+     $ cd $HOME
+     $ source &YOCTO_ADTPATH_DIR;/environment-setup-i586-poky-linux
+     $ runqemu qemux86 bzImage-qemux86.bin \
+     core-image-sato-qemux86.ext3
+                </literallayout>
+            </para>
+
+            <para>
+                The environment in which QEMU launches varies depending on the filesystem image and on the
+                target architecture.
+                For example, if you source the environment for the ARM target
+                architecture and then boot the minimal QEMU image, the emulator comes up in a new
+                shell in command-line mode.
+                However, if you boot the SDK image, QEMU comes up with a GUI.
+                <note>Booting the PPC image results in QEMU launching in the same shell in
+                command-line mode.</note>
+            </para>
+        </section>
+    </section>
+</section>
+
+<section id='super-user'>
+    <title>Super User
+</title>
+
+    <para>
+        This section
+        <footnote>
+            <para>
+                Kudos and thanks to Robert P. J. Day of
+                <ulink url='http://www.crashcourse.ca'>CrashCourse</ulink> for providing the basis
+                for this "expert" section with information from one of his
+                <ulink url='http://www.crashcourse.ca/wiki/index.php/Yocto_Project_Quick_Start'>wiki</ulink>
+                pages.
+            </para>
+        </footnote>
+        gives you a minimal description of how to use the Yocto Project to build
+        images for Beaglebone hardware starting from scratch.
+        The steps were performed on a 64-bit Ubuntu 12.04 system that
+        has four cores.
+    </para>
+
+    <section id='getting-yocto'>
+        <title>Getting the Yocto Project</title>
+
+        <para>
+            Set up your
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            by using Git to clone the <filename>poky</filename>
+            repository and then check out the release branch:
+            <literallayout class='monospaced'>
+     $ cd ~
+     $ git clone git://git.yoctoproject.org/poky
+     $ cd poky
+     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='setting-up-your-host'>
+        <title>Setting Up Your Host</title>
+
+        <para>
+            You need some packages for everything to work.
+            Rather than duplicate them here, look at the
+            "<link linkend='packages'>The Packages</link>"
+            section earlier in this quick start.
+        </para>
+    </section>
+
+    <section id='initializing-the-build-environment'>
+        <title>Initializing the Build Environment</title>
+
+        <para>
+            From the root directory of your
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
+            initialize your environment and provide a meaningful
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            name:
+            <literallayout class='monospaced'>
+     $ source &OE_INIT_FILE; mybuilds
+            </literallayout>
+            At this point, the <filename>mybuilds</filename> directory has
+            been created for you and it is now your current working directory.
+            If you do not provide your own directory name,
+            it defaults to <filename>build</filename>,
+            which is inside the Source Directory.
+        </para>
+    </section>
+
+    <section id='configuring-the-local.conf-file'>
+        <title>Configuring the local.conf File</title>
+
+        <para>
+            Initializing the build environment creates a
+            <filename>conf/local.conf</filename> configuration file
+            in the Build Directory.
+            You need to manually edit this file to specify the machine you
+            are building and to optimize your build time.
+            Here are the minimal changes to make:
+            <literallayout class='monospaced'>
+     BB_NUMBER_THREADS = "8"
+     PARALLEL_MAKE = "-j 8"
+     MACHINE ?= "beaglebone"
+            </literallayout>
+            Briefly, set
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></ulink>
+            and
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></ulink> to
+            twice your host processor's number of cores.
+        </para>
+
+        <para>
+            A good deal that goes into a Yocto Project build is simply
+            downloading all of the source tarballs.
+            Steps exist that can help you be more efficient with gathering
+            source files.
+            For example, you can set up local mirrors that hold your
+            source tarballs or you can pre-fetch all your source without
+            initiating a build until later.
+            For more information, see the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#working-with-source-files'>Working with Source Files</ulink>"
+            section in the Yocto Project Development Manual.
+        </para>
+    </section>
+
+    <section id='building-the-image'>
+        <title>Building the Image</title>
+
+        <para>
+            At this point, you need to select an image to build for the
+            Beaglebone hardware.
+            If this is your first build using the Yocto Project, you should try
+            the smallest and simplest image:
+            <literallayout class='monospaced'>
+     $ bitbake core-image-minimal
+            </literallayout>
+            Now you just wait for the build to finish.
+        </para>
+
+        <para>
+            By default, BitBake aborts when it encounters an error during
+            the build.
+            If you want to make sure the build continues even when BitBake
+            encounters an error, use this variation:
+            <literallayout class='monospaced'>
+     $ bitbake -k core-image-minimal
+            </literallayout>
+        </para>
+
+        <para>
+            Once you have your image, you can take steps to load and boot it on
+            the target hardware.
+        </para>
+
+        <para>
+            You can learn about BitBake in general by reading the
+            <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
+        </para>
+    </section>
+</section>
+
+</article>
+<!--
+vim: expandtab tw=80 ts=4
+-->