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>

documentation/profile-manual/profile-manual-arch.xml

@@ -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>
 <!--

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'>