Messages in this thread | | | Date | Thu, 1 Jul 2010 10:19:42 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCHv7 2.6.35-rc3-tip 0/11] Uprobes Patches: |
| |
* 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.
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.
- 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.
- [ Optional: Another interesting area to look at would be the scripting engine: allow trace scripts to insert probes if they are not present yet. ]
- 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:
- 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.
Thanks,
Ingo
| |