lkml.org 
[lkml]   [2010]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHv7 2.6.35-rc3-tip 0/11] Uprobes Patches:
Ingo Molnar wrote:
> * Srikar Dronamraju <srikar@linux.vnet.ibm.com> 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/



\
 
 \ /
  Last update: 2010-07-01 11:21    [W:1.245 / U:3.432 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site