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]
Date:	Sat, 26 Oct 2013 13:02:49 +0800
From:	Jovi Zhangwei <jovi.zhangwei@...il.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	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>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Subject: Re: ktap inclusion in drivers/staging/?

On Fri, Oct 25, 2013 at 6:15 PM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Jovi Zhangwei <jovi.zhangwei@...il.com> wrote:
>
>> >  - 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.
>
> (or perf ktap, whichever structure makes most sense from the end
> user POV.)
>
Thanks. An addition question I want to discuss in here is the ktap code
structure layout in first patch series, this don't need to dig out any ktap
design detail, so we can make agreement on this point, and ease for me
to prepare patch series.

Do I need to prepare patchset target on staging tree or "real" part of kernel?
If target on driver/staging/ktap, then kernel code and userspace code still
need to locate at same directory, that many people may don't like it.

Target on "real" part kernel?
- include/trace/ktap (header file common used by interpreter and
userspace compiler)
- kernel/trace/ktap (interpreter code, ktapvm, pure kernel module)
- tools/perf/ktap?(userspace compiler code)
  As I also agree integrating ktap and perf together, two subsystem can share
  many codes, so it's better putting ktap userspace into perf directory.

Whatever the name calling of perf and ktap integrating, ktap still would be
a single directory, and could be compile into a standalone binary ktap.

How about this sounds?

Thanks.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ