linux-kernel - Re: Re: ktap inclusion in drivers/staging/?

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: <526DFAAC.9070409@hitachi.com>
Date:	Mon, 28 Oct 2013 14:48:28 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Jovi Zhangwei <jovi.zhangwei@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"zhangwei(Jovi)" <jovi.zhangwei@...wei.com>,
	Frédéric Weisbecker 
	<fweisbec@...il.com>, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Tom Zanussi <tom.zanussi@...ux.intel.com>,
	Namhyung Kim <namhyung@...nel.org>,
	David Ahern <dsahern@...il.com>, Jiri Olsa <jolsa@...hat.com>,
	"yrl.pp-manager.tt@...achi.com" <yrl.pp-manager.tt@...achi.com>
Subject: Re: Re: ktap inclusion in drivers/staging/?

(2013/10/25 19:15), Ingo Molnar wrote:
> 
> * Jovi Zhangwei <jovi.zhangwei@...il.com> wrote:
> 
>> Hi Ingo,
>>
>> On Thu, Oct 24, 2013 at 3:58 PM, Ingo Molnar <mingo@...nel.org> wrote:
>>>
>>> Greg,
>>>
>>> I was surprised to see 'ktap' appear in the staging tree silently,
>>> via these commits that are visible in today's staging-next:
>>>
>>>  2c856b9e3e06 staging: ktap: remove unused <asm/syscall.h> header file
>>>  687b63a3bfd5 staging: ktap: update email name in MAINTAINERS
>>>  c63a164271f8 staging: ktap: add to the kernel tree
>>>
>>> ktap is pretty fresh instrumentation code, announced on lkml a
>>> couple of months ago, and so far I haven't seen much technical
>>> discussion of integrating ktap upstream, mostly I suspect because
>>> not a _single_ patch was sent to linux-kernel for review. (!)
>>>
>> I accept Greg revert this in staging-next tree, It's entirely my fault, sorry.
> 
> Thanks!
> 
>>> An announcement of a Git tree was made (which Git tree is not very
>>> structured), and some very minimal discussion ensued, but no actual
>>> patches were sent with an intent to merge, no technical arguments
>>> were made in favor of merging and nothing conclusive was achieved.
>>>
>>> A couple of very quick (and incomplete) technical objections:
>>>
>>>  - The Git commits in staging an absolutely unstructured,
>>>    unreviewable mess, due to a single commit adding 16 KLOCs (!) of
>>>    code:
>>>
>>>       80 files changed, 16376 insertions(+)
>>>
>>>    (I looked at the ktap Git tree as well, it's not much better.)
>>>
>>>  - Most of the kernel code comes with near zero explanations in the
>>>    code itself. I looked at the kernel code in
>>>    drivers/staging/ktap/interpreter/.  I have not found a _single_
>>>    substantial in-code comment about design details and
>>>    implementational considerations. (!!)
>>>
>> I will add more comments for it, also will draft a design detail in
>> doc/ directory.
>>
>>>  - From the little I've been able to decode I get the impression
>>>    that the design should be much more integrated into the rest of
>>>    instrumentation: the in-kernel Lua bytecode interpreter looks
>>>    interesting, it could be an intelligent upgrade (or even outright
>>>    replacement) for the current 'filter' interpreter concept we have
>>>    for tracepoints - instead of putting a parallel interpreter
>>>    implementation into the kernel.

Hmm, IMHO, the current simple filter itself is not needed to be merged
at least ftrace side, since the ktap filter requires userspace compiler
on the other hand ftrace does it directly by debugfs.
Perhaps, after the bytecode generator and JIT compiler is introduced,
we can pass filter rules to the generator via debugfs.

>>>  - In a similar fashion, it would be nice to see it integrated with
>>>    'perf probe' or 'perf ktap', so that users can create probes from
>>>    a single place, with coherent syntax and integrated analysis
>>>    capabilities. I.e. there's no reason to not make this a
>>>    relatively pain-less yet very useful transition.
>>
>> Yes, I also mentioned this in my RFC email post before, that's the 
>> reason why I use perf-like interface in ktap as much as I can, 
>> like perf-tracepoints and perf-probe, also ktap can reuse perf 
>> debuginfo handling code in future, we are on the same page at this 
>> technical point.
> 
> Okay, cool! I've also Cc:-ed Masami, who was also very receptive in 
> person of the idea to merge this kind of scripting into perf probe.

Yeah, that is what I recommend him. If ktap uses directly perf
tools, it will simplify its design (compared with systemtap...)

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com


--
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/