Message-ID: <CAGdX0WHh3UqiCLbz+18_fj5s4PMpTfy638HA=LHpgLfVc2JpOg@mail.gmail.com>
Date:	Wed, 2 Apr 2014 16:49:11 +0800
From:	Jovi Zhangwei <jovi.zhangwei@...il.com>
To:	Ingo Molnar <mingo@...nel.org>
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

On Wed, Apr 2, 2014 at 3:43 PM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * 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:
>
There is no fundamental design concerns outlined about ktap, that
'loop' in ktap design is not fundamental, others review feedback
is focus on patch, not fundamental design, and those "safety"
concerns raised by Alexei is just bound checking.
I don't see any others.

>      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.
>
I don't see any suggestion about integrating BPF before this review cycle.

> Many months have passed since the
> previous ktap submission, still I see no progress on the 'design'
> front. That really needs to change.
>

I think the change need both in ktap and ebpf, not ktap one side,
if you really want integrate ktap and BPF is a way.

There have no proven that current ebpf low level bytecode design is suit
for generic dynamic tracing use, I also raised some design concern
about ebpf in previous mail but got no clear answer, like exposed too
much low level stuff to end user, that would be a problem because
script engine need to validate more memory references which should
not need to; and also there may be expose table lock into user inf future,
that would be more complex IMO.

The efforts need all related people participation, not only ktap,
ktap and bpf maybe need to close with each other, but not means
bpf stay and let ktap move close.

That's why I think the things would be more faster and effective if in
public place(like staging tree), otherwise the change may be hard to
happen.

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