blob: 8eb7bbfabd194d3843036a7f24a64a1c950d11b6 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<chapter id='profile-manual-arch'>
<title>Overall Architecture of the Linux Tracing and Profiling Tools</title>
<section id='architecture-of-the-tracing-and-profiling-tools'>
<title>Architecture of the Tracing and Profiling Tools</title>
<para>
It may seem surprising to see a section covering an 'overall architecture'
for what seems to be a random collection of tracing tools that together
make up the Linux tracing and profiling space.
The fact is, however, that in recent years this seemingly disparate
set of tools has started to converge on a 'core' set of underlying
mechanisms:
</para>
<para>
<itemizedlist>
<listitem>static tracepoints</listitem>
<listitem>dynamic tracepoints
<itemizedlist>
<listitem>kprobes</listitem>
<listitem>uprobes</listitem>
</itemizedlist>
</listitem>
<listitem>the perf_events subsystem</listitem>
<listitem>debugfs</listitem>
</itemizedlist>
</para>
<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.
</informalexample>
</section>
</chapter>
<!--
vim: expandtab tw=80 ts=4
-->
|
