sphinx: initial sphinx support

This commit is autogenerated pandoc to generate an inital set
of reST files based on DocBook XML files.

A .rst file is generated for each .xml files in all manuals with this
command:

cd <manual>
for i in *.xml; do \
  pandoc -f docbook -t rst --shift-heading-level-by=-1 \
  $i -o $(basename $i .xml).rst \
done

The conversion was done with: pandoc 2.9.2.1-91 (Arch Linux).

Also created an initial top level index file for each document, and
added all 'books' to the top leve index.rst file.

The YP manuals layout is organized as:

Book
  Chapter
    Section
      Section
        Section

Sphinx uses section headers to create the document structure.
ReStructuredText defines sections headers like that:

   To break longer text up into sections, you use section headers. These
   are a single line of text (one or more words) with adornment: an
   underline alone, or an underline and an overline together, in dashes
   "-----", equals "======", tildes "~~~~~~" or any of the
   non-alphanumeric characters = - ` : ' " ~ ^ _ * + # < > that you feel
   comfortable with. An underline-only adornment is distinct from an
   overline-and-underline adornment using the same character. The
   underline/overline must be at least as long as the title text. Be
   consistent, since all sections marked with the same adornment style
   are deemed to be at the same level:

Let's define the following convention when converting from Docbook:

Book                => overline ===   (Title)
  Chapter           => overline ***   (1.)
    Section         => ====           (1.1)
      Section       => ----           (1.1.1)
        Section     => ~~~~           (1.1.1.1)
          Section   => ^^^^           (1.1.1.1.1)

During the conversion with pandoc, we used --shift-heading-level=-1 to
convert most of DocBook headings automatically. However with this
setting, the Chapter header was removed, so I added it back
manually. Without this setting all headings were off by one, which was
more difficult to manually fix.

At least with this change, we now have the same TOC with Sphinx and
DocBook.

(From yocto-docs rev: 3c73d64a476d4423ee4c6808c685fa94d88d7df8)

Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

documentation/profile-manual/profile-manual-arch.rst

@@ -0,0 +1,28 @@
+*************************************************************
+Overall Architecture of the Linux Tracing and Profiling Tools
+*************************************************************
+
+Architecture of the Tracing and Profiling Tools
+===============================================
+
+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:
+
+-  static tracepoints
+-  dynamic tracepoints
+
+   -  kprobes
+   -  uprobes
+
+-  the perf_events subsystem
+-  debugfs
+
+.. container:: informalexample
+
+   Tying it Together:
+   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.

documentation/profile-manual/profile-manual-examples.rst

@@ -0,0 +1,20 @@
+*******************
+Real-World Examples
+*******************
+
+This chapter contains real-world examples.
+
+Slow Write Speed on Live Images
+===============================
+
+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.
+
+The problem (and solution) was discovered by using the Yocto tracing
+tools, in this case 'perf stat', 'perf script', 'perf record' and 'perf
+report'.
+
+See all the unvarnished details of how this bug was diagnosed and solved
+here: Yocto Bug #3049

documentation/profile-manual/profile-manual-intro.rst

@@ -0,0 +1,67 @@
+******************************************
+Yocto Project Profiling and Tracing Manual
+******************************************
+
+.. _profile-intro:
+
+Introduction
+============
+
+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.
+
+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.
+
+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.
+
+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!
+
+.. _profile-manual-general-setup:
+
+General Setup
+=============
+
+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. $ bitbake core-image-sato-sdk or alternatively by
+adding 'tools-profile' to the EXTRA_IMAGE_FEATURES line in your
+local.conf: EXTRA_IMAGE_FEATURES = "debug-tweaks tools-profile" 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.: $ bitbake core-image-sato
+
+.. note::
+
+   By default, the Yocto build system strips symbols from the binaries
+   it packages, which makes it difficult to use some of the tools.
+
+   You can prevent that by setting the
+   ```INHIBIT_PACKAGE_STRIP`` <&YOCTO_DOCS_REF_URL;#var-INHIBIT_PACKAGE_STRIP>`__
+   variable to "1" in your ``local.conf`` when you build the image:
+
+INHIBIT_PACKAGE_STRIP = "1" The above setting will noticeably increase
+the size of your image.
+
+If you've already built a stripped image, you can generate debug
+packages (xxx-dbg) which you can manually install as needed.
+
+To generate debug info for packages, you can add dbg-pkgs to
+EXTRA_IMAGE_FEATURES in local.conf. For example: EXTRA_IMAGE_FEATURES =
+"debug-tweaks tools-profile dbg-pkgs" Additionally, in order to generate
+the right type of debuginfo, we also need to set
+```PACKAGE_DEBUG_SPLIT_STYLE`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_DEBUG_SPLIT_STYLE>`__
+in the ``local.conf`` file: PACKAGE_DEBUG_SPLIT_STYLE =
+'debug-file-directory'

documentation/profile-manual/profile-manual.rst

@@ -0,0 +1,12 @@
+==========================================
+Yocto Project Profiling and Tracing Manual
+==========================================
+
+.. toctree::
+   :caption: Table of Contents
+   :numbered:
+
+   profile-manual-intro
+   profile-manual-arch
+   profile-manual-usage
+   profile-manual-examples