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

[Srikar Dronamraju <srikar@linux.vnet.ibm.com>]

Hi Peter, 

> > > 
> > 
> > My reply in
> > http://lkml.indiana.edu/hypermail/linux/kernel/1001.1/02483.html
> > addresses this.
> 
> Right, so all that need be done is add the multiple probe stuff to UBP
> and its a sane interface to use on its own, at which point I'd be
> inclined to call that uprobes (UBP really is an crap name).

I am fine with renaming ubp to a suggested name. The reason for splitting
uprobes to two layers was to allow others (currently none) to reuse the
current ubp layer. It was felt that there could be multiple clients for
ubp who could co-exist. 

However ubp alone is not enough to provide the userspace tracing.
Currently it wouldn't understand synchronization between different
threads of a process, process life time issues, context in which the
handler has to be run. 

As pointed out by Jim earlier, we have segregrated that layer which
takes care of the above issues into the uprobes layer.

For example, while inserting a breakpoint, one of the threads of a
process could be running at the same place where we are trying to place
a breakpoint. Or there could be two threads that could be racing to
insert/delete a breakpoint. These synchronization issues are all handled
by the Uprobes layer.

Uprobes layer would need to be notified of process life-time events
like fork/clone/exec/exit. 
It also needs to know
	-  when a breakpoint is hit
	-  stop and resume a thread.

Uprobes layer uses utrace to be notified of the process life time events
and the signal handling part.

--
Thanks and Regards
Srikar

> 
> Then we can ditch the whole utrace muck as I see no reason to want to
> use that, whereas the ubp (given a sane name) looks interesting.
>