[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180327131143.4b83534c@gandalf.local.home>
Date: Tue, 27 Mar 2018 13:11:43 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Alexei Starovoitov <ast@...com>
Cc: <davem@...emloft.net>, <daniel@...earbox.net>,
<torvalds@...ux-foundation.org>, <peterz@...radead.org>,
<netdev@...r.kernel.org>, <kernel-team@...com>,
<linux-api@...r.kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH v6 bpf-next 08/11] bpf: introduce BPF_RAW_TRACEPOINT
On Tue, 27 Mar 2018 13:02:11 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:
> Honestly, I think this is too much of a short cut and a hack. I know
> you want to keep it "simple" and save space, but you really should do
> it the same way ftrace and perf do it. That is, create a section and
> have all tracepoints create a structure that holds a pointer to the
> tracepoint and to the bpf probe function. Then you don't even need the
> kernel_tracepoint_find_by_name(), you just iterate over your table and
> you get the tracepoint and the bpf function associated to it.
Also, if you do it the perf/ftrace way, you get support for module
tracepoints pretty much for free. Which would include tracepoints in
networking code that is loaded by a module.
-- Steve
Powered by blists - more mailing lists