a1d12f1e |
1 | |
2 | Mathieu Desnoyers, June 2007 |
3 | |
4 | Marker design |
5 | |
6 | Events are described in data structures in DECLARE_MARKER(), in the same file |
7 | the marker is in, or exported and in a globally included header. |
8 | |
9 | When a new marker is encountered (module load, marker armed), an event_load |
10 | event is traced in the facilities channel. If the marker refers to an already |
11 | existing marker declaration, nothing changes, except that it must check that the |
12 | types match. |
13 | |
14 | At trace start, we take the superset of the filtered in events and arm their |
15 | markers. We trace an event load event for each armed marker encountered. |
16 | |
17 | Format string verification by GCC. |
18 | |
19 | Format string extensions (sequence, structs, arrays..) |
20 | |
21 | Field names. |
22 | |
23 | |
24 | User space tracing |
25 | |
26 | Declare their own DECLARE_MARKER, use MARK() macros that refers to it. At module |
27 | load, (to decide) either the kernel or the library walks on the markers sections |
28 | and issues a marker_load system call. Facility namespacing prefix "user_" is |
29 | used for userspace facilities. |
30 | |
31 | We have to deal with multiple registrations of the same event with different |
32 | caracteristics but same name. |
33 | |
34 | Markers must be enabled by the kernel, if activated and tracing starts. |
35 | |
36 | Modify linker script to get section start and end in programs. |
37 | |
38 | |
39 | ------------------------- |
40 | |
41 | Maybe DECLARE_MARKER is not necessary: |
42 | |
43 | Use LTTV dictionnary to add information about events. |
44 | event and field description. |
45 | |
46 | <facility name="fac"> |
47 | <event name="event"> <description> assdfas </description> </event> |
48 | <field name="field1"> <description> asdfasdf </description> </field> |
49 | <field name="field2"> <enum>....</enum><description> asdfasdf </description> </field> |
50 | </facility> |
51 | |
52 | Field names |
53 | |
54 | trace_mark(facility_event, "field1 %u field2 %p", asdf, asdf); |
55 | |
56 | Extract the field names from the format string. |
57 | Check for format string equivalence before enabling a marker. Allow enabling |
58 | markers with the same format string as the first one found, but warn about the |
59 | others which do not match. |
60 | Trace an event_load event for each enabled marker with non-NULL format string at |
61 | trace start and when they are activated. Since we want to keep the same format |
62 | string if module loads/unload/reload, and we cannot point into this module's |
63 | memory, we reallocate the entry and copy the format string whenever the newly |
64 | loaded module contains active markers and these markers have a NULL format |
65 | string. |
66 | When we enable a marker, if the marker has a non null format string, we trace a |
67 | marker_load. |
68 | |
69 | Default : cardinal field1, field2.... |
70 | Calling: ltt_trace |
71 | callback[0]: ltt_serialize_data |
72 | |
73 | Types |
74 | |
75 | -- Add network byte ordering to types. |
76 | -- Change format strings to use backward compatible types. (format check) |
77 | |
78 | Reserve 8 IDs for core events. Never allow wrapping over 65535 IDs during a |
79 | trace : need compaction when no trace is active. |
80 | |
81 | Marker hash table points to a structure containing the marker's event ID (16 |
82 | bits). Assign event ID when a probe is registered. |
83 | |
84 | Compact channel. Use separate 8 bits event IDs for events going in the |
85 | compact channel. Identified by registering probe with id type MARKER_ID_COMPACT. |
86 | |
87 | update probes (temp) |
88 | |
89 | -- Enabling a marker: |
90 | -- give: state marker name, channel. |
91 | /proc/markers: enable/disable name [channel] |
92 | |
93 | probe_data should provide, for ltt: |
a1d12f1e |
94 | callbacks |
95 | id <-- will stay in marker because otherwise we would need another hash table. |
282ae6d3 |
96 | channel index : put inside the marker structure (parameter to register). |
97 | A marker control module |
a1d12f1e |
98 | |
99 | Q: field names in dictionnary or in marker ? |
100 | |
101 | |
282ae6d3 |
102 | What users will do with marker interface: |
103 | |
104 | from userspace: |
105 | enable/disable marker_name (act on any marker, reg by module or other) |
106 | channel marker_name channel_name (act on any marker) |
107 | |
108 | Default: use serializer |
109 | But.. module can override _default_ probe with a "register" operation. |
110 | |
111 | Use case |
112 | Set channel |
113 | Register by specific module (unregister default, register specific) |
114 | activate. |
115 | |
116 | Serve as a proxy for probe registration. |
117 | |
118 | |
a1d12f1e |
119 | |