linux-kernel - Re: [RFC PATCH 00/28] ktap: A lightweight dynamic tracing tool for Linux

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140402074322.GA22744@gmail.com>
Date:	Wed, 2 Apr 2014 09:43:22 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Jovi Zhangwei <jovi.zhangwei@...il.com>
Cc:	Alexei Starovoitov <ast@...mgrid.com>,
	Ingo Molnar <mingo@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Daniel Borkmann <dborkman@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jiri Olsa <jolsa@...hat.com>,
	Geoff Levand <geoff@...radead.org>
Subject: Re: [RFC PATCH 00/28] ktap: A lightweight dynamic tracing tool for
 Linux


* Jovi Zhangwei <jovi.zhangwei@...il.com> 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:

     NAKed-by: Ingo Molnar <mingo@...nel.org>

The thing is, I've outlined some of the concerns in my previous 
review. Not much happened on that front, for example ktap did not get 
any closer in integrating with BPF. Many months have passed since the 
previous ktap submission, still I see no progress on the 'design' 
front. That really needs to change.

Please keep me Cc:-ed to any and all future ktap submissions so I can 
monitor ktap's progress and lift the NAK if the design concerns have 
been addressed.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/