Re: ktap inclusion in drivers/staging/?

[Jovi Zhangwei]

On Fri, Oct 25, 2013 at 6:15 PM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
> * Jovi Zhangwei <jovi.zhangwei@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/