On Thu, Jan 14, 2010 at 12:43:01PM +0100, Peter Zijlstra wrote: > On Thu, 2010-01-14 at 12:35 +0100, Frederic Weisbecker wrote: > > On Thu, Jan 14, 2010 at 12:23:11PM +0100, Peter Zijlstra wrote: > > > On Mon, 2010-01-11 at 17:56 +0530, Srikar Dronamraju wrote: > > > > This patch implements ftrace plugin for uprobes. > > > > > > Right, like others have said, trace events is a much saner interface. > > > > > > So the easiest way I can see that working is to register uprobes against > > > a file (not a pid). Then on creation it uses rmap to find all current > > > maps of that file and install the probe if there is a consumer for that > > > map. > > > > > > Then for each new mmap() of that file, we also need to check if there's > > > a consumer ready and install the probe. > > > > > > > > That looks racy. > > > > Say you first create a probe on /bin/ls: > > > > perf probe p addr_in_ls /bin/ls > > > > then something else launches /bin/ls behind you, probe > > is set on it > > > > then you launch: > > > > perf record -e "probe:...." /bin/ls > > > > Then it goes recording the previous instance. > > Uhm, why? Only the perf /bin/ls instance has a consumer and will thus > have a probe installed. > > (Or if you want to use ftrace you need to always have all instances > probed anyway)
I see, so what you suggest is to have the probe set up as generic first. Then the process that activates it becomes a consumer, right? Would work, yeah.
