[DTrace-devel] Some fun stuff happening on DTrace v2 dev

[Kris Van Hees]

Development is currently focusing on building the new metadata structures that
are needed to manage enabled probes.  This task was previously shared between
the kernel and userspace (with quite a bit of duplication of data because both
ends needed it).  Legacy DTrace managed the list of all probes in the kernel,
and userspace only cached probes that were actually going to be used.  The
userspace component would then query additional information from the kernel,
and keep that around (things like probe arguments).  On the other hand, since
userspace had all the knowledge about what data should be recorded when a probe
fires, that was kept in metadata structures at the userspace level, while the
kernel would analyze the DIF code it was passed to determine some of this
information as well.

We are in a much nicer position now where userspace can manage all of this, and
simply generate code that does not require data structures at the kernel level.
Or at least, no datastructures that need additional compiled-in code.  Instead,
userspace generates programs that obtain information from BPF maps.  When the
programs are compiled (or loaded, depending on the specific data), BPF maps are
populated with information that the BPF programs may need at runtime (things
like probe naming component, epid, ...).

Right now, BPF does not support sharing functions between BPF programs (in the
sense of true sharing - i.e. where there is only one copy of the shared code in
the kernel).  But I am designing DTrace v2 as if true sharing is available
because that is a feature that the BPF developers seem to want in the future
anyway.  Might as well prepare for it, and it results in cleaner BPF programs
anyway.

I've had to rework some patches (we're up to a patch set with 67 pieces from
the most recent legacy DTrace version) so if you have been looking at this code
with a checked out tree, a pull-rebase or re-checking out is probably going to
be needed due to the force-pushes.

>From now on, expect more frequent pushes and emails with the latest changes.
I will also post new patches directly to the list, though it is possible that
we'll still see some modifications to earlier patches as I discover mistakes
that I may have made in how the earlier patches were constructed.  Mea culpa!

Ongoing development of DTrace (v2) can be found on the 2.0-branch-dev of
the oracle/dtrace-utils repo on GitHub.  The URL is:

        https://github.com/oracle/dtrace-utils/tree/2.0-branch-dev

This branch shows the ongoing development of converting DTrace to be based on
eBPF.  Keep in mind that this is a development branch so I will be pushing
changes to it as development occurs and force-pushes are likely to happen at
times.

	Kris