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>

1 files changed, 36 insertions, 36 deletions

diff --git a/documentation/profile-manual/profile-manual-usage.xml b/documentation/profile-manual/profile-manual-usage.xml
index 785fd5c4f9..e49acbf2df 100644
--- a/documentation/profile-manual/profile-manual-usage.xml
+++ b/documentation/profile-manual/profile-manual-usage.xml
@@ -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'>