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

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Thu, May 23, 2019 at 01:46:10AM -0400, Kris Van Hees wrote:
> 
> I think there is a difference between a solution and a good solution.  Adding
> a lot of knowledge in the userspace component about how things are imeplemented
> at the kernel level makes for a more fragile infrastructure and involves
> breaking down well established boundaries in DTrace that are part of the design
> specifically to ensure that userspace doesn't need to depend on such intimate
> knowledge.

argh. see more below. This is fundamental disagreement.

> > > Another advantage of being able to operate on a more abstract probe concept
> > > that is not tied to a specific probe type is that the userspace component does
> > > not need to know about the implementation details of the specific probes.
> > 
> > If that is indeed the case that dtrace is broken _by design_
> > and nothing on the kernel side can fix it.
> > 
> > bpf prog attached to NMI is running in NMI.
> > That is very different execution context vs kprobe.
> > kprobe execution context is also different from syscall.
> > 
> > The user writing the script has to be aware in what context
> > that script will be executing.
> 
> The design behind DTrace definitely recognizes that different types of probes
> operate in different ways and have different data associated with them.  That
> is why probes (in legacy DTrace) are managed by providers, one for each type
> of probe.  The providers handle the specifics of a probe type, and provide a
> generic probe API to the processing component of DTrace:
> 
>     SDT probes -----> SDT provider -------+
>                                           |
>     FBT probes -----> FBT provider -------+--> DTrace engine
>                                           |
>     syscall probes -> systrace provider --+
> 
> This means that the DTrace processing component can be implemented based on a
> generic probe concept, and the providers will take care of the specifics.  In
> that sense, it is similar to so many other parts of the kernel where a generic
> API is exposed so that higher level components don't need to know implementation
> details.
> 
> In DTrace, people write scripts based on UAPI-style interfaces and they don't
> have to concern themselves with e.g. knowing how to get the value of the 3rd
> argument that was passed by the firing probe.  All they need to know is that
> the probe will have a 3rd argument, and that the 3rd argument to *any* probe
> can be accessed as 'arg2' (or args[2] for typed arguments, if the provider is
> capable of providing that).  Different probes have different ways of passing
> arguments, and only the provider code for each probe type needs to know how
> to retrieve the argument values.
> 
> Does this help bring clarity to the reasons why an abstract (generic) probe
> concept is part of DTrace's design?

It actually sounds worse than I thought.
If dtrace script reads some kernel field it's considered to be uapi?! ouch.
It means dtrace development philosophy is incompatible with the linux kernel.
There is no way kernel is going to bend itself to make dtrace scripts
runnable if that means that all dtrace accessible fields become uapi.

In stark contrast to dtrace all of bpf tracing scripts (bcc scripts
and bpftrace scripts) are written for specific kernel with intimate
knowledge of kernel details. They do break all the time when kernel changes.
kprobe and tracepoints are NOT uapi. All of them can change.
tracepoints are a bit more stable than kprobes, but they are not uapi.