LKML Archive on
 help / color / Atom feed
* [RFC] DTrace based on eBPF and other tracing facilities
@ 2018-11-16  6:02 Kris Van Hees
  2018-11-18  8:32 ` Aleksa Sarai
  0 siblings, 1 reply; 2+ messages in thread
From: Kris Van Hees @ 2018-11-16  6:02 UTC (permalink / raw)
  To: linux-kernel, netdev

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

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

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.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-16  6:02 [RFC] DTrace based on eBPF and other tracing facilities Kris Van Hees
2018-11-18  8:32 ` Aleksa Sarai

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