profile-manual: Fixed the "Tying it Together" side-lights.

Took them out of the colored Note format and replaced with
a simple line box to set them apart.

(From yocto-docs rev: 5efb84d3860d87f64371b718967ab33f47a3a4db)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark 2013-01-21 16:15:27 -06:00 committed by Richard Purdie
parent f3cb977699
commit b4b1dc1dd6
2 changed files with 39 additions and 39 deletions

View File

@ -32,12 +32,12 @@
</itemizedlist>
</para>
<note>
Tying It Together: Rather than enumerating here how each tool makes use of
<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.
</note>
</informalexample>
</section>
</chapter>
<!--

View File

@ -605,13 +605,13 @@
</literallayout>
</para>
<note>
Tying It Together: These are exactly the same set of events defined
<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.
</note>
</informalexample>
<para>
Only a subset of these would be of interest to us when looking at
@ -836,8 +836,8 @@
bindings, one for Python and one for Perl.
</para>
<note>
Tying It Together: Language bindings for manipulating and
<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
@ -849,7 +849,7 @@
in-kernel interpreter, created an elaborate compiler-based
machinery to translate its language into kernel modules written
in C.
</note>
</informalexample>
<para>
Now that we have the trace data in perf.data, we can use
@ -1132,15 +1132,15 @@
how to use filters, it's close enough.
</para>
<note>
Tying It Together: These are exactly the same set of event
<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.
</note>
</informalexample>
<note>
Tying It Together: These event filters are implemented by a
<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
@ -1161,7 +1161,7 @@
application is causing buffer I/O overruns, it probably
means that you aren't taking enough advantage of the
kernel filtering engine.
</note>
</informalexample>
</section>
</section>
@ -1274,18 +1274,18 @@
<imagedata fileref="figures/perf-probe-do_fork-profile.png" width="6in" depth="7in" align="center" scalefit="1" />
</para>
<note>
Tying It Together: The trace events subsystem accomodate static
<informalexample>
<emphasis>Tying it Together:</emphasis> The trace events subsystem accomodate 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.
</note>
</informalexample>
<note>
Tying It Together: Dynamic tracepoints are implemented under the
<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.
</note>
</informalexample>
</section>
</section>
@ -1496,10 +1496,10 @@
code works in a dynamic sense.
</para>
<note>
Tying It Together: The ftrace function tracer is also
<informalexample>
<emphasis>Tying it Together:</emphasis> The ftrace function tracer is also
available from within perf, as the ftrace:function tracepoint.
</note>
</informalexample>
<para>
It is a little more difficult to follow the call chains than
@ -1852,21 +1852,21 @@
including trace-cmd and kernelshark in the next section.
</para>
<note>
Tying It Together: These tracepoints and their representation
<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
</note>
</informalexample>
<note>
Tying It Together: Eventually all the special-purpose tracers
<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.
</note>
</informalexample>
</section>
<section id='trace-cmd-kernelshark'>
@ -2731,14 +2731,14 @@
<imagedata fileref="figures/oprofileui-busybox.png" width="6in" depth="7in" align="center" scalefit="1" />
</para>
<note>
Tying It Together: oprofile does have build options to enable
<informalexample>
<emphasis>Tying it Together:</emphasis> oprofile does have build options to enable
use of the perf_event subsystem and benefit from the perf_event
infrastructure by adding support for something other than
system-wide profiling i.e. per-process or workload profiling,
but the version in danny doesn't yet take advantage of
those capabilities.
</note>
</informalexample>
</section>
<section id='oprofile-documentation'>
@ -2852,23 +2852,23 @@
focus to the selected function, and so on.
</para>
<note>
Tying It Together: If you like sysprof's 'caller-oriented'
<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.
</note>
</informalexample>
<note>
Tying It Together: sysprof does have build options to enable
<informalexample>
<emphasis>Tying it Together:</emphasis> sysprof does have build options to enable
use of the perf_event subsystem and benefit from the perf_event
infrastructure by adding support for something other than
system-wide profiling i.e. per-process or workload profiling,
but the version in danny doesn't yet take advantage of those
capabilities (sysprof officially added the ability.
to make use of perf_events just as we were going to press).
</note>
</informalexample>
</section>
<section id='sysprof-documentation'>