On Wed, Jul 10, 2019 at 2:36 PM Kris Van Hees <kris.van.hees@xxxxxxxxxx> wrote: > > 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > > > > > 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. Hey Kris -- so you're referring to me, and I've used DTrace more than anyone over the past 15 years, and I don't think anyone has used all the different Linux tracers more than I have. I think my opinion has a lot of value. Brendan
