Re: [PATCHv7 2.6.35-rc3-tip 0/11] Uprobes Patches:

[Masami Hiramatsu]

Ingo Molnar wrote:
> * Srikar Dronamraju <srikar@xxxxxxxxxxxxxxxxxx> wrote:
> 
>> Hi Ingo,
>>
>> I have addressed all comments to the uprobes patchset.  We have few todos 
>> (most of them are features over the current code) which I plan to work in 
>> the immediate future.
>>
>> So would it be possible for this patchset to be picked into the tip tree. 
>> Getting these patches merged into the tip tree would help in getting more 
>> comments/feedback and testing.
> 
> If Masami-san, PeterZ and Arnaldo is happy with it being tried in its current 
> form then we could try it.

At least ftrace/perf side, it's almost good for me. (but I need time to test it)

> Assuming everyone is reasonably happy about the code, here are some open areas 
> as i see them, before we can think about pushing things from -tip towards 
> upstream:
> 
> - One thing i havent seen is the ability to 'list' potential probe points:
>   i.e. function names. Often the user will not know precisely where to look 
>   and what to type. This leaves our probe capability under-utilized in 
>   practice.

It will be the next step for perf-(u)probe, debuginfo support. Since
the perf-(k)probe already support in which function the probe is put,
I think if perf-(u)probe support debuginfo, it's easy to be implemented.

> - On a similar note, it might also make sense to extend the Newt interface to 
>   perf report to integrate probes: if a function looks high-overhead, then a 
>   probe point could be inserted and the app could be traced straight away. We 
>   already allow per function actions in the Newt interface, such as assembly 
>   annotation - the adding of a probe point would be quite useful.

Hmm, does that mean that user puts a new probe point from Newt interface?
That's a good idea:)

> - [ Optional: Another interesting area to look at would be the scripting 
>     engine: allow trace scripts to insert probes if they are not present yet. ]

Sure, that's what I hope. :)

> - Plus the security model is an open question as well. Right now it's
>   root-only, but it would make sense to allow users to insert probes into 
>   their own apps. This brings up the next point:

Hmm, put a probe in user-space(by owner) may be good. But
inside the kernel, there are more sensitive informations...

> - Proper syscall integration and more unification with kprobes and with the 
>   TRACE_EVENT() universe. As far as API design goes, 
>   /sys/kernel/debug/tracing/uprobe_events is quite sucky as a concept.

Yeah, we can extend the interface and merge it. But removing all
debugfs interfaces should be discussed.

Thank you,

> 
> Thanks,
> 
> 	Ingo
> --
> 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/

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