LKML Archive on
 help / color / Atom feed
From: Aleksa Sarai <>
To: Kris Van Hees <>
Cc: Brendan Gregg <>,,
Subject: Re: [RFC] DTrace based on eBPF and other tracing facilities
Date: Sun, 18 Nov 2018 19:32:20 +1100
Message-ID: <20181118083220.vxwcy2oq6uln3wa2@yavin> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 3422 bytes --]

On 2018-11-15, Kris Van Hees <> wrote:
> A lot of work has been done on various aspects of the tracing infrastructure
> in Linux in the past years and with the further development of BPF a quite
> powerful execution engine has become available as well.
> One of the difficulties we have experienced in furthering DTrace on Linux is
> that we have to duplicate functionality already available in the kernel
> because that functionality is not easy to make use of.
> In the past year or so we have been working towards changing that.  There is
> no point in having multiple projects reinvent the same wheel a couple of times
> over, especially when there are ways where everyone can benefit from actually
> cooperating.  Our current (lofty) goal is to rework the DTrace implementation 
> that we currently have to make it more modular and less self-sufficient.  We
> are envisioning a future for DTrace where we can leverage its strengths in the
> areas where it matters most (e.g. very efficient handling of large amounts of
> kernel probes, well defined and understood D language, user familiarity with
> existing providers, ...) while building on the existing tracing infrastructure
> in Linux.  That also means that we can contribute better to existing pieces
> in the infrastructure and work together with other tracing projects to continue
> to improve tracing on Linux.
> Ideally we would like to see an infrastructure where any tracers can attach
> actions to any kind of probe source, and have data generated according to the
> actions the tracer associated with the probe source when a specific probe
> fires.  The execution of those actions would be done using BPF.
> We believe that this proposal would be a benefit to all because it allows us
> to pool resources in the areas that really need it.  E.g. if we all depend on
> BPF as execution engine we invariably work together to make it as solid as can
> be.
> Obviously we cannot do this work on our own, and we cannot do it behind closed
> doors.  We've created a github repository for the kernel with DTrace added in
> at:
> We also have a branch there with the most recent BPF-based work:
> Since most (if not all) tracing tools have similar requirements for what may
> need to be done when a probe fires, we really want to join forces.

Have you taken a look at bpftrace[1]? It uses LLVM to compile to BPF
bytecode and has a DTrace-like syntax. Yes, it's a from-scratch
reimplementation, but as a user of tracing I don't really mind either
way (I think most people like DTrace because of how seamlessly all
aspects of probing work -- but I believe that most of this is a result
of the DTrace kernel infrastructure more than the user-space tooling).

I'm not entirely sure how USDT interacts with the current Linux tracing
tools, but it would be nice if USDT worked on Linux the same way it
worked on Solaris (though I will admit I haven't played with it much on
Linux, I'm sure the other tracing folks will be able to comment on this
far more than myself).


Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply index

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-16  6:02 Kris Van Hees
2018-11-18  8:32 ` Aleksa Sarai [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181118083220.vxwcy2oq6uln3wa2@yavin \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.git
	git clone --mirror lkml/git/8.git
	git clone --mirror lkml/git/9.git
	git clone --mirror lkml/git/10.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ \
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone