update compat
[lttv.git] / doc / developer / markers-update.txt
1
2 Tracepoint proposal
3
4 - Tracepoint infrastructure
5 - In-kernel users
6 - Complete typing, verified by the compiler
7 - Dynamically linked and activated
8
9 - Marker infrastructure
10 - Exported API to userland
11 - Basic types only
12
13 - Dynamic vs static
14 - In-kernel probes are dynamically linked, dynamically activated, connected to
15 tracepoints. Type verification is done at compile-time. Those in-kernel
16 probes can be a probe extracting the information to put in a marker or a
17 specific in-kernel tracer such as ftrace.
18 - Information sinks (LTTng, SystemTAP) are dynamically connected to the
19 markers inserted in the probes and are dynamically activated.
20
21 - Near instrumentation site vs in a separate tracer module
22
23 A probe module, only if provided with the kernel tree, could connect to internal
24 tracing sites. This argues for keeping the tracepoing probes near the
25 instrumentation site code. However, if a tracer is general purpose and exports
26 typing information to userspace through some mechanism, it should only export
27 the "basic type" information and could be therefore shipped outside of the
28 kernel tree.
29
30 In-kernel probes should be integrated to the kernel tree. They would be close to
31 the instrumented kernel code and would translate between the in-kernel
32 instrumentation and the "basic type" exports. Other in-kernel probes could
33 provide a different output (statistics available through debugfs for instance).
34 ftrace falls into this category.
35
36 Generic or specialized information "sinks" (LTTng, systemtap) could be connected
37 to the markers put in tracepoint probes to extract the information to userspace.
38 They would extract both typing information and the per-tracepoint execution
39 information to userspace.
40
41 Therefore, the code would look like :
42
43 kernel/sched.c:
44
45 #include "sched-trace.h"
46
47 schedule()
48 {
49 ...
50 trace_sched_switch(prev, next);
51 ...
52 }
53
54
55 kernel/sched-trace.h:
56
57 DEFINE_TRACE(sched_switch, struct task_struct *prev, struct task_struct *next);
58
59
60 kernel/sched-trace.c:
61
62 #include "sched-trace.h"
63
64 static probe_sched_switch(struct task_struct *prev, struct task_struct
65 *next)
66 {
67 trace_mark(kernel_sched_switch, "prev_pid %d next_pid %d prev_state %ld",
68 prev->pid, next->pid, prev->state);
69 }
70
71 int __init init(void)
72 {
73 return register_sched_switch(probe_sched_switch);
74 }
75
76 void __exit exit(void)
77 {
78 unregister_sched_switch(probe_sched_switch);
79 }
80
81
82 Where DEFINE_TRACE internals declare a structure, a trace_* inline function,
83 a register_trace_* and unregister_trace_* inline functions :
84
85 static instrumentation site structure, containing function pointers to
86 deactivated functions and activation boolean. It also contains the
87 "sched_switch" string. This structure is placed in a special section to create
88 an array of these structures.
89
90 static inline void trace_sched_switch(struct task_struct *prev,
91 struct task_struct *next)
92 {
93 if (sched_switch tracing is activated)
94 marshall_probes(&instrumentation_site_structure, prev, next);
95 }
96
97 static inline int register_trace_sched_switch(
98 void (*probe)(struct task_struct *prev, struct task_struct *next)
99 {
100 return do_register_probe("sched_switch", (void *)probe);
101 }
102
103 static inline void unregister_trace_sched_switch(
104 void (*probe)(struct task_struct *prev, struct task_struct *next)
105 {
106 do_unregister_probe("sched_switch", (void *)probe);
107 }
108
109
110 We need a a new kernel probe API :
111
112 do_register_probe / do_unregister_probe
113 - Connects the in-kernel probe to the site
114 - Activates the site tracing (probe reference counting)
115
116
This page took 0.032351 seconds and 4 git commands to generate.