[lkml]   [2019]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use
On Tue, May 21, 2019 at 05:36:18PM -0400, Steven Rostedt wrote:
> On Tue, 21 May 2019 13:55:34 -0700
> Alexei Starovoitov <> 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.

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.

 \ /
  Last update: 2019-05-21 23:44    [W:0.108 / U:0.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site