Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

[Steven Rostedt <rostedt@goodmis.org>]

On Fri, 24 May 2019 00:05:27 -0400
Kris Van Hees <kris.van.hees@oracle.com> 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