[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190710143048.3923d1d9@lwn.net>
Date: Wed, 10 Jul 2019 14:30:48 -0600
From: Jonathan Corbet <corbet@....net>
To: Daniel Borkmann <daniel@...earbox.net>
Cc: 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, 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.
There are still people interested in DTrace out there. How would you
recommend that Kris proceed at this point?
Thanks,
jon
Powered by blists - more mailing lists