[DTrace-devel] [PATCH v3 2/2] doc: Update the sdt provider documentation

Fri Dec 19 06:13:41 UTC 2025

On Mon, Dec 08, 2025 at 05:14:01PM -0500, eugene.loh at oracle.com wrote:
> From: Eugene Loh <eugene.loh at oracle.com>
> 
> The documentation had been describing the legacy provider, in which sdt
> probes were DTrace-specific instrumentation points in the kernel to
> support other providers.  In the current implementation, the sdt
> provider simply exposes Linux kernel tracepoints.
> 
> Signed-off-by: Eugene Loh <eugene.loh at oracle.com>

Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>

> ---
>  doc/userguide/index.md                        |  3 --
>  .../reference/dtrace_providers_rawtp.md       |  8 ++-
>  .../reference/dtrace_providers_sdt.md         | 53 ++++++++-----------
>  3 files changed, 29 insertions(+), 35 deletions(-)
> 
> diff --git a/doc/userguide/index.md b/doc/userguide/index.md
> index 3e057d4de..7d6b1caec 100644
> --- a/doc/userguide/index.md
> +++ b/doc/userguide/index.md
> @@ -255,9 +255,6 @@
>          -   [sched Examples](reference/dtrace_providers_sched.md#dt_ref_schedexamples_prov)
>          -   [sched Stability](reference/dtrace_providers_sched.md#dt_ref_schedstab_prov)
>      -   [SDT Provider](reference/dtrace_providers_sdt.md#dt_ref_sdt_prov)
> -        -   [Creating sdt Probes](reference/dtrace_providers_sdt.md#dt_ref_sdtcreatep_prov)
> -            -   [Declaring Probes](reference/dtrace_providers_sdt.md#dt_ref_sdtdeclp_prov)
> -            -   [sdt Probe Arguments](reference/dtrace_providers_sdt.md#dt_ref_sdtparg_prov)
>          -   [sdt Stability](reference/dtrace_providers_sdt.md#dt_ref_sdtstab_prov)
>      -   [Stapsdt Provider](reference/dtrace_providers_stapsdt.md)
>          -   [stapsdt Probes](reference/dtrace_providers_stapsdt.md#dt_ref_stapsdtprobes_prov)
> diff --git a/doc/userguide/reference/dtrace_providers_rawtp.md b/doc/userguide/reference/dtrace_providers_rawtp.md
> index 67cb0bedc..aa98f9c43 100644
> --- a/doc/userguide/reference/dtrace_providers_rawtp.md
> +++ b/doc/userguide/reference/dtrace_providers_rawtp.md
> @@ -1,7 +1,13 @@
>  
>  # Rawtp Provider <a id="dt_ref_rawtp_prov">
>  
> -The `rawtp` provider gives DTrace users access to the raw tracepoints exposed by the kernel tracing system, including access to the untranslated arguments of the associated tracepoint events.
> +The `rawtp` provider gives DTrace users access to the tracepoints exposed by the kernel tracing system.
> +
> +In contrast with the [sdt](../reference/dtrace_providers_sdt.md) provider,
> +however, the `rawtp` provider delivers the raw arguments that the kernel
> +provides to the tracepoint.
> +For more information on kernel tracepoints, see
> +<https://github.com/torvalds/linux/blob/master/Documentation/trace/tracepoints.rst>.
>  
>  To see what raw tracepoints are available on a system, use:
>  
> diff --git a/doc/userguide/reference/dtrace_providers_sdt.md b/doc/userguide/reference/dtrace_providers_sdt.md
> index b4490401a..fc512484d 100644
> --- a/doc/userguide/reference/dtrace_providers_sdt.md
> +++ b/doc/userguide/reference/dtrace_providers_sdt.md
> @@ -1,46 +1,37 @@
>  
>  # SDT Provider <a id="dt_ref_sdt_prov">
>  
> -The Statically Defined Tracing \(SDT\) provider \(`sdt`\) creates probes at sites that a software programmer has formally designated. Thus, the SDT provider is chiefly of interest only to developers of new providers. Most users access SDT only indirectly by using other providers.
> +The Statically Defined Tracing \(SDT\) provider \(`sdt`\) is for
> +tracing markers that have been added manually to the kernel source code.
>  
> -The SDT mechanism enables programmers to consciously choose locations of interest to users of DTrace and to convey some semantic knowledge about each location through the probe name.
> +Historically, DTrace has used SDT instrumentation of the
> +kernel source code to provide a number of other providers,
> +such as `io`, `lockstat`, `ip`, `tcp`, and `udp`.
> +With DTrace on Linux, however, DTrace is a user-space tool,
> +avoiding modifications of the kernel source code,
> +implementating those other providers on top of pre-existing probes.
>  
> -Importantly, SDT can act as a metaprovider by registering probes so that they appear to come from other providers, such as `io`, `lockstat`, `proc`, and `sched`.
> +Therefore, the SDT provider now simply exposes kernel *tracepoints*,
> +introduced by various kernel developers at semantically meaningful points of execution,
> +making them available as DTrace probes.
>  
> -Both the name stability and the data stability of the probes are Private, which reflects the kernel's implementation and should not be interpreted as a commitment to preserve these interfaces.
> +Probe arguments are converted from raw arguments provided by the kernel
> +to a format specified by the tracepoint definition in the kernel source
> +code and described in
> +`/sys/kernel/debug/tracing/events/`*subsystem*/*tracepoint*/`format`.
>  
> -**Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
> -
> -## Creating sdt Probes <a id="dt_ref_sdtcreatep_prov">
> -
> -If you are a device driver developer, you might be interested in creating `sdt` probes for a Linux driver that you are working on. The disabled probe effect of SDT is only the cost of several no-operation machine instructions. You are therefore encouraged to add `sdt` probes to device driver code as needed. Unless these probes negatively affect performance, you can leave them in shipped code.
> -
> -DTrace also provides a mechanism for application developers to define user-space static probes.
> -
> -### Declaring Probes <a id="dt_ref_sdtdeclp_prov">
> -
> -The `sdt` probes are declared by using the `DTRACE_PROBE` macro from `<linux/sdt.h>`.
> +To access the raw arguments,
> +use the [rawtp](../reference/dtrace_providers_rawtp.md) provider.
>  
> -The module name and function name of an SDT-based probe correspond to the kernel module name and function name where the probe is declared. DTrace includes the kernel module name and function name as part of the tuple used to identify the probe in the probe description, so you don't need to explicitly include this information when devising the probe name. You can still specify the module and function name when referring to the probe in a DTrace program to prevent namespace collisions. Use the `dtrace -l -m *mymodule*` command to list the probes that *mymodule* has installed and the full names that are seen by DTrace users.
> +For more information on kernel tracepoints, see
> +<https://github.com/torvalds/linux/blob/master/Documentation/trace/tracepoints.rst>.
>  
> -The name of the probe depends on the name that's provided in the `DTRACE_PROBE` macro. If the name doesn't contain two consecutive underscores \(`__`\), the name of the probe is as written in the macro. If the name contains two consecutive underscores, the probe name converts the consecutive underscores to a single dash \(`-`\). For example, if a `DTRACE_PROBE` macro specifies `transaction__start`, the SDT probe is named `transaction-start`. This substitution enables C code to provide macro names that aren't valid C identifiers without specifying a string.
> -
> -SDT can also act as a metaprovider by registering probes so that they appear to come from other providers, such as `io`, `proc`, and `sched`, which don't have dedicated modules of their own. For example, `kernel/exit.c` contains calls to the `DTRACE_PROC` macro, which are defined as follows in `<linux/sdt.h>`:
> -
> -```
> -# define DTRACE_PROC(name) \
> -         DTRACE_PROBE(__proc_##name);
> -```
> -
> -Probes that use such macros appear to come from a provider other than `sdt`. The leading double underscore, provider name, and trailing underscore in the `name` argument are used to match the provider and aren't included in the probe name.
> -
> -### sdt Probe Arguments <a id="dt_ref_sdtparg_prov">
> -
> -The arguments for each `sdt` probe are the arguments that are specified in the kernel source code in the corresponding `DTRACE_PROBE` macro reference. When declaring `sdt` probes, you can minimize their disabled probe effect by not dereferencing pointers and by not loading from global variables in the probe arguments. Both pointer dereferencing and global variable loading can be done safely in D functions that enable probes, so DTrace users can request these functions only when they're needed.
> +**Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
>  
>  ## sdt Stability <a id="dt_ref_sdtstab_prov">
>  
> -The `sdt` provider uses DTrace's stability mechanism to describe its stabilities. These values are listed in the following table.
> +The `sdt` provider uses DTrace's stability mechanism to describe its stabilities.
> +These values are listed in the following table.
>  
>  | Element   | Name Stability | Data Stability | Dependency Class |
>  | :---      | :---           | :---           | :---             |
> -- 
> 2.47.3
>