On Fri, 24 May 2019 00:05:27 -0400
Kris Van Hees [off-list ref] wrote:

No, no, that is not at all what I am saying.  In DTrace, the particulars of
how you get to e.g. probe arguments or current task information are not
something that script writers need to concern themselves about.  Similar to
how BPF contexts have a public (uapi) declaration and a kernel-level context
declaration taht is used to actually implement accessing the data (using the
is_valid_access and convert_ctx_access functions that prog types implement).
DTrace exposes an abstract probe entity to script writers where they can
access probe arguments as arg0 through arg9.  Nothing in the userspace needs
to know how you obtain the value of those arguments.  So, scripts can be
written for any kind of probe, and the only information that is used to
verify programs is obtained from the abstract probe description (things like
its unique id, number of arguments, and possible type information for each
argument).  The knowledge of how to get to the value of the probe arguments
is only known at the level of the kernel, so that when the implementation of
the probe in the kernel is modified, the mapping from actual probe to abstract
representation of the probe (in the kernel) can be modified along with it,
and userspace won't even notice that anything changed.

Many parts of the kernel work the same way.  E.g. file system implementations
change, yet the API to use the file systems remains the same.

Another example is actually the tracefs events directory. It represents
normal trace events (tracepoints), kprobes, uprobes, and synthetic
events. You don't need to know what they are to use them as soon as
they are created. You can even add triggers and such on top of each,
and there shouldn't be any difference.

-- Steve