mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-05-30 12:29:55 +00:00
Code Issues Projects Releases Wiki Activity

manuals: Spellcheck and capitalization fixes

Browse Source 
- Spelling fixes found using Emacs' spelling checker
  configured for US English
- Fixes for some capitalization issues, especially some
  project names (QEMU, openSUSE, BusyBox), that were not
  consistently used with the same capitalization anyway.
- A few whitespace fixes too

(From yocto-docs rev: 05d69f17490dcc4933dcd85e57d9db53b912084a)

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Reviewed-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Michael Opdenacker
2021-03-23 17:58:45 +01:00
committed by Richard Purdie
parent 07c7bdc6c2
commit c643a4749c
15 changed files with 50 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/profile-manual/usage.rst
+13 -13
View File
@@ -100,8 +100,8 @@ Using perf to do Basic Profiling
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
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. ::
root@crownbay:~# rm linux-2.6.19.2.tar.bz2; \
@@ -251,7 +251,7 @@ 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
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.
@@ -277,16 +277,16 @@ 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:
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:
.. image:: figures/perf-wget-busybox-expanded-stripped.png
:align: center
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.
Expanding the BusyBox entry doesn't make it any better.
The problem is that perf can't find the symbol information for the
busybox binary, which is actually stripped out by the Yocto build
@@ -299,7 +299,7 @@ when you build the image: ::
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.
install the debuginfo for the BusyBox package.
To generate the debug info for the packages in the image, we can add
``dbg-pkgs`` to :term:`EXTRA_IMAGE_FEATURES` in ``local.conf``. For example: ::
@@ -314,7 +314,7 @@ in the ``local.conf`` file: ::
PACKAGE_DEBUG_SPLIT_STYLE = 'debug-file-directory'
Once we've done that, we can install the
debuginfo for busybox. The debug packages once built can be found in
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: ::
@@ -325,7 +325,7 @@ Now install the debug rpm on the target: ::
root@crownbay:~# rpm -i busybox-dbg-1.20.2-r2.core2_32.rpm
Now that the debuginfo is installed, we see that the busybox entries now display
Now that the debuginfo is installed, we see that the BusyBox entries now display
their functions symbolically:
.. image:: figures/perf-wget-busybox-debuginfo.png
@@ -345,11 +345,11 @@ expanded all the nodes using the 'E' key):
.. image:: figures/perf-wget-busybox-dso-zoom.png
:align: center
Finally, we can see that now that the busybox debuginfo is installed,
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
copy-to-user overhead was initiated by the ``handle_input()`` BusyBox
function:
.. image:: figures/perf-wget-g-copy-to-user-expanded-debuginfo.png
@@ -1900,7 +1900,7 @@ the target: ::
meta-toolchain
meta-ide-support
You can also run generated qemu images with a command like 'runqemu qemux86-64'
You can also run generated QEMU images with a command like 'runqemu qemux86-64'
Once you've done that, you can cd to whatever
directory contains your scripts and use 'crosstap' to run the script: ::