projects / lttng-docs.git / blame
| Commit | Line | Data |
|---|---|---|
| 5e0cbfb0 PP |
1 | --- |
| 2 | id: domain | |
| 3 | --- | |
| 4 | ||
| 5 | A tracing _domain_ is the official term the LTTng project uses to | |
| 6 | designate a tracer category. | |
| 7 | ||
| ce42e181 | 8 | There are currently five known domains: |
| 5e0cbfb0 PP |
9 | |
| 10 | * Linux kernel | |
| 11 | * user space | |
| c23b8cb1 PP |
12 | * `java.util.logging` (JUL) |
| 13 | * log4j | |
| ce42e181 | 14 | * Python (2 and 3 are supported) |
| 5e0cbfb0 PP |
15 | |
| 16 | Different tracers expose common features in their own interfaces, but, | |
| 17 | from a user's perspective, you still need to target a specific type of | |
| 18 | tracer to perform some actions. For example, since both kernel and user | |
| 19 | space tracers support named tracepoints (probes manually inserted in | |
| 20 | source code), you need to specify which one is concerned when enabling | |
| 21 | an event because both domains could have existing events with the same | |
| 22 | name. | |
| 23 | ||
| 9f13d176 PP |
24 | Some features are reserved for some domains. Dynamic function entry/return |
| 25 | instrumentation, for example, is currently only supported in the kernel | |
| 26 | domain, but support for other domains could be added in the future. |