On Tue, May 21, 2019 at 05:36:18PM -0400, Steven Rostedt wrote: > On Tue, 21 May 2019 13:55:34 -0700 > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > > > The reasons for these patches is because I cannot do the same with the existing > > > implementation. Yes, I can do some of it or use some workarounds to accomplish > > > kind of the same thing, but at the expense of not being able to do what I need > > > to do but rather do some kind of best effort alternative. That is not the goal > > > here. > > > > what you call 'workaround' other people call 'feature'. > > The kernel community doesn't accept extra code into the kernel > > when user space can do the same. > > If that was really true, all file systems would be implemented on > FUSE ;-) > > I was just at a technical conference that was not Linux focused, and I > talked to a lot of admins that said they would love to have Dtrace > scripts working on Linux unmodified. > > I need to start getting more familiar with the workings of eBPF and > then look at what Dtrace has to see where something like this can be > achieved, but right now just NACKing patches outright isn't being > helpful. If you are not happy with this direction, I would love to see > conversations where Kris shows you exactly what is required (from a > feature perspective, not an implementation one) and we come up with a > solution. Steve, sounds like you've missed all prior threads. The feedback was given to Kris it was very clear: implement dtrace the same way as bpftrace is working with bpf. No changes are necessary to dtrace scripts and no kernel changes are necessary.
