Re: [RFC] [PATCH 4/7] Uprobes Implementation

2010-01-12 Thread Ananth N Mavinakayanahalli
On Tue, Jan 12, 2010 at 06:36:00AM +0100, Frederic Weisbecker wrote: On Mon, Jan 11, 2010 at 05:55:53PM +0530, Srikar Dronamraju wrote: +static const struct utrace_engine_ops uprobe_utrace_ops = { + .report_quiesce = uprobe_report_quiesce, + .report_signal = uprobe_report_signal, +

Re: [RFC] [PATCH 7/7] Ftrace plugin for Uprobes

2010-01-12 Thread Frank Ch. Eigler
Frederic Weisbecker fweis...@gmail.com writes: [...] This is much more tricky in the case of uprobes as I see two ways to work with it: - probing on an already running process - probing on a process we are about to run [...] As you might expect, in systemtap we've had to figure out this

Re: [RFC] [PATCH 7/7] Ftrace plugin for Uprobes

2010-01-12 Thread Frank Ch. Eigler
Hi - As you might expect, in systemtap we've had to figure out this area some time ago. We use another utrace consumer called task finder [...] So, could you tell us how the task-finder works and is implemented? The code may be found at runtime/task_finder* in the systemtap sources.

Re: [RFC] [PATCH 4/7] Uprobes Implementation

2010-01-12 Thread Jim Keniston
On Tue, 2010-01-12 at 13:44 +0530, Ananth N Mavinakayanahalli wrote: On Tue, Jan 12, 2010 at 06:36:00AM +0100, Frederic Weisbecker wrote: ... So, as stated before, uprobe seems to handle too much standalone policies such as freeing on exec, always inherit on clone and never on fork. Such