On Wed, Jul 3, 2019 at 8:17 PM Kris Van Hees <kris.van.hees@xxxxxxxxxx> wrote: > > This initial implementation of a tiny subset of DTrace functionality > provides the following options: > > dtrace [-lvV] [-b bufsz] -s script > -b set trace buffer size > -l list probes (only works with '-s script' for now) > -s enable or list probes for the specified BPF program > -V report DTrace API version > > The patch comprises quite a bit of code due to DTrace requiring a few > crucial components, even in its most basic form. This patchset has moved from adding tests (which actually belong in selftests, not tools/dtrace), to the start of adding a giant tracer to the kernel code base. First, in some ways you're doing this for me -- I've been the number one user of DTrace for 15 years -- and thanks, but no thanks. I don't need this anymore. I needed this 6 years ago, and I would have helped you build it, but in the meantime Linux has built something better, built from the ground up for BPF: bpftrace. Second, you argued that DTrace was needed because of speculative tracing (a feature I never used), as you had customers who wanted it. Those customers aren't going to be happy with this initial tiny implementation of DTrace -- this is really the start of adding a large and complex tracer to the kernel. We've all been working under the assumption that these user-space tracers did not belong in the kernel, and so far that's been working fine for us. Is it now open season for tracers in the kernel? Let's have: tools/bpftrace tools/ply tools/systemtap tools/LTTng tools/sysdig tools/ktap etc Yes, that's ridiculous. If there's only going to be one, let's have the best one, bpftrace. We'll offer a version that is GPL, C, and has no dependencies. But it would be news to us all that we're allowed to have even one. There are more things that don't make sense about this, but I'll stop here for now. Brendan
