From 9bd69b1f1d71a9692189beeac75af9dfbad816cc Mon Sep 17 00:00:00 2001 From: Nicolas Dechesne Date: Fri, 26 Jun 2020 19:10:51 +0200 Subject: 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 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 Signed-off-by: Richard Purdie --- .../profile-manual/profile-manual-intro.rst | 67 ++++++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 documentation/profile-manual/profile-manual-intro.rst (limited to 'documentation/profile-manual/profile-manual-intro.rst') diff --git a/documentation/profile-manual/profile-manual-intro.rst b/documentation/profile-manual/profile-manual-intro.rst new file mode 100644 index 0000000000..40febd8b4e --- /dev/null +++ b/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' -- cgit v1.2.3-54-g00ecf