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

[Ingo Molnar <mingo@elte.hu>]

* 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