ktap and ebpf integration

[Posted April 21, 2014 by corbet]

From:		Jovi Zhangwei <jovi.zhangwei-AT-gmail.com>
To:		Alexei Starovoitov <ast-AT-plumgrid.com>, Ingo Molnar <mingo-AT-redhat.com>
Subject:		ktap and ebpf integration
Date:		Fri, 4 Apr 2014 09:21:16 +0800
Message-ID:		<CAGdX0WEeZJ9hxq1y-gmGC=kdtU0ecLbs5gVYb_8ZE6sOW_PPvg@mail.gmail.com>
Cc:		Steven Rostedt <rostedt-AT-goodmis.org>, Masami Hiramatsu <masami.hiramatsu.pt-AT-hitachi.com>, Greg KH <gregkh-AT-linuxfoundation.org>, Andi Kleen <andi-AT-firstfloor.org>, LKML <linux-kernel-AT-vger.kernel.org>
Archive‑link:		Article

Hi Alexei,

We talked a lot on ktap and ebpf integration in these days,
Now I think we can put into deeply to thinking out some
technical issues in there.

Firstly, I want to make sure you are support this ktap and
ebpf integration direction, I aware you have ongoing 'bpf filter'
patch set work, which actually overlapping with ktap integration
efforts (IMO the interface should be unified and simple for user,
 so I think filter debugfs file is not a good interface), so please let
me know your answer about this.

If the answer is yes, then we can go through ebpf core
improvement, for example:
- support global variable access
  this is mandatory for dynamic tracing, otherwise, there have
  no possible to run a simple script like get function execution
  time.
- support timer in kernel
  The final solution must need to support kernel timer for profiling,
  and sampling stack.
- support register multi-event in one script
- support trace_end


If the answer of first question is no, you still believe your "bpf filter"
solution is a correct way, that's means there have no need to
integrate ktap and ebpf, and don't need any ktap upstream efforts,
I 'm fine with it, then I can make another technical plan for ktap.

Thank you.

Jovi