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

[Peter Zijlstra <peterz@infradead.org>]

On Fri, 2010-01-15 at 08:10 -0500, Frank Ch. Eigler wrote:
> Hi -
> 
> > > > 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.
> > > 
> > > Assuming you meant what you write, perhaps you misunderstand the
> > > layering relationship of these pieces.  utrace underlies uprobes and
> > > other process manipulation functionality, present and future.
> > 
> > Why, utrace doesn't at all look to bring a fundamental contribution to
> > all that. If there's a proper kernel interface to install probes on
> > userspace code (ubp seems to be mostly that) then I can use perf/ftrace
> > to do the rest of the state management, no need to use utrace there.
> 
> > You can hardly force me to use utrace there, can you?
> 
> utrace is not a form of punishment inflicted upon the undeserving.  It
> is a service layer that uprobes et alii are built upon.  You as a
> potential uprobes client need not also talk directly to it, if you
> wish to reimplement task-finder-like services some other way.

I said I wanted to, I think the whole task orientation of user-space
probing is wrong, its about text mappings.

But yes, I think that for most purposes utrace is a punishment, its way
too heavy, I mean, trap, generate a signal, catch the signal, that's
like an insane amount of code to jump through in order to get that trap.

Furthermore it requires stopping and resuming tasks and nonsense like
that, that's unwanted in many cases, just run stuff from the trap site
and you're done.

Yes you can do this with utrace, and I'm not going to stop people from
using utrace for his, I'm just saying I'm not going to.