Date:   Wed, 10 Jul 2019 17:36:37 -0400
From:   Kris Van Hees <kris.van.hees@...cle.com>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     Jonathan Corbet <corbet@....net>,
        Kris Van Hees <kris.van.hees@...cle.com>,
        netdev@...r.kernel.org, bpf@...r.kernel.org,
        dtrace-devel@....oracle.com, linux-kernel@...r.kernel.org,
        rostedt@...dmis.org, mhiramat@...nel.org, acme@...nel.org,
        ast@...nel.org, Peter Zijlstra <peterz@...radead.org>,
        Chris Mason <clm@...com>, brendan.d.gregg@...il.com,
        davem@...emloft.net
Subject: Re: [PATCH V2 1/1 (was 0/1 by accident)] tools/dtrace: initial
 implementation of DTrace

On Wed, Jul 10, 2019 at 11:19:43PM +0200, Daniel Borkmann wrote:
> On 07/10/2019 10:30 PM, Jonathan Corbet wrote:
> > On Wed, 10 Jul 2019 21:32:25 +0200
> > Daniel Borkmann <daniel@...earbox.net> wrote:
> > 
> >> Looks like you missed Brendan Gregg's prior feedback from v1 [0]. I haven't
> >> seen a strong compelling argument for why this needs to reside in the kernel
> >> tree given we also have all the other tracing tools and many of which also
> >> rely on BPF such as bcc, bpftrace, ply, systemtap, sysdig, lttng to just name
> >> a few.
> > 
> > So I'm just watching from the sidelines here, but I do feel the need to
> > point out that Kris appears to be trying to follow the previous feedback
> > he got from Alexei, where creating tools/dtrace is exactly what he was
> > told to do:
> > 
> >   https://lwn.net/ml/netdev/20190521175617.ipry6ue7o24a2e6n@ast-mbp.dhcp.thefacebook.com/
> > 
> > Now he's being told the exact opposite.  Not the best experience for
> > somebody who is trying to make the kernel better.
> 
> Ugh, agree, sorry for the misleading direction. Alexei is currently offgrid
> this week, he might comment later.
> 
> It has nothing to do with making the _kernel_ better, it's a /user space/ front
> end for the existing kernel infrastructure like many of the other tracers out
> there. Don't get me wrong, adding the missing /kernel parts/ for it is a totally
> different subject [and _that_ is what is making the kernel better, not the former].

I disagree.  Yes, the current patch obviously isn't making the kernel better
because it doesn't touch the kernel.  But DTrace as a whole is not just a
/front end/ to the existing kernel infrastructure, and I did make that point
at LPC 2018 and in my emails.  Some of its more advanced features will lead
to contributions to the kernel that (by virtue of being developed as part of
this DTrace re-implementation) will more often than not be able to benefit
other tracers as well.  I do think that aspect qualifies as working towards
making the kenrel better.

> Hypothetical question: does it make the _kernel_ better if we suddenly add a huge
> and complex project like tools/mysql/ to the kernel tree? Nope.
> 
> > There are still people interested in DTrace out there.  How would you
> > recommend that Kris proceed at this point?
> 
> My recommendation to proceed is to maintain the dtrace user space tooling in
> its own separate project like the vast majority of all the other tracing projects
> (see also the other advantages that Steven pointed out from his experience), and
> extend the kernel bits whenever needed.

I wish that would have been the initial recommendation because it certainly
would have avoided me going down a path that was going to lead to rejection.

Either way, I do hope that as work progresses and contributions to the kernel
code are submitted in support of advancing tracing on Linux, those patches
will receive a fair review and consideration.  I can appreciate that some
people do not like DTrace or feel that it is not necessary, but personal
opinions about tools should not be a deciding factor in whether a contribution
has merit or not.

	Kris

Powered by blists - more mailing lists