Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752302AbaDDHgZ (ORCPT ); Fri, 4 Apr 2014 03:36:25 -0400 Received: from mail-wg0-f47.google.com ([74.125.82.47]:38638 "EHLO mail-wg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752252AbaDDHgU (ORCPT ); Fri, 4 Apr 2014 03:36:20 -0400 Date: Fri, 4 Apr 2014 09:36:17 +0200 From: Ingo Molnar To: Jovi Zhangwei Cc: Alexei Starovoitov , Ingo Molnar , Steven Rostedt , LKML , Masami Hiramatsu , Greg Kroah-Hartman , Frederic Weisbecker , Daniel Borkmann , Arnaldo Carvalho de Melo , Peter Zijlstra , Thomas Gleixner , Jiri Olsa , Geoff Levand Subject: Re: [RFC PATCH 00/28] ktap: A lightweight dynamic tracing tool for Linux Message-ID: <20140404073616.GC1637@gmail.com> References: <1396014469-5937-1-git-send-email-jovi.zhangwei@gmail.com> <20140331071749.GA1252@gmail.com> <20140402074322.GA22744@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Jovi Zhangwei wrote: > On Wed, Apr 2, 2014 at 3:43 PM, Ingo Molnar wrote: > > > > * Jovi Zhangwei wrote: > > > >> So based on all these input, I suggest: > >> > >> Put all these community efforts together, figure out the proper > >> design implementation of dynamic tracing tool, ktap can be a good > >> start to build upon it, evolve to a unified kernel script engine > >> with ebpf together, finally service for dynamic tracing and > >> network(if possible). > >> > >> Our goal is same and very clearly, we really want a "simple & > >> flexible & safe" dynamic scripting tracing tool for Linux, which > >> could compare or even better than Dtrace, this is the motivation of > >> ktap project. > >> > >> Two solution may be take: > >> > >> 1). upstream ktap into core trace and evolve it step by step, and > >> finally make a integrated bytecode engine, it's a long process, > >> but I think it's worth. > >> > >> 2). move ktap back into staging, and graduate from staging after the > >> code make tracing people and ebpf people both happy. > >> > >> The benefit is the process will be under the eyes of community. > >> > >> Ingo, steven, Greg, what do you think? > > > > For now I'm opting for a third option: > > > > 3) Maintain my NAK on the ktap patches until they address the > > fundamental design concerns outlined by Alexei and others in > > their review feedback: > > > > There is no fundamental design concerns outlined about ktap, [...] Well, the concerns that were outlined do raise to fundamental in my book. But as long as they are addressed it does not matter how we classify them. > I don't see any suggestion about integrating BPF before this review > cycle. Hm, I mentioned it at the kernel summit to folks who raised the ktap subject, but apparently not over email. I assumed a new ktap submission would come quickly. Anyway, considering how BPF is integrating with (and hopefully replacing) tracing filters, it makes sense to apply the same concept in the ktap case as well. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/