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

[Frank Ch. Eigler]

Hi -

On Fri, Jan 15, 2010 at 02:25:30PM +0100, Peter Zijlstra wrote:
> [...]
> > 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.
> 
> [...]
> 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.

At the bottom, there will be an int3 in the userspace text page.
There will be a trap taken, no matter what.  Code must figure out
whether this trap came from an in-kernel client such as uprobes, or
whether it is to be passed through to a userspace debugger via ptrace
(or the gdbstub).  This part is unavoidable if you wish to be
compatible.

I'm not sure, but it sounds like the part you're complaining about is
how utrace ultimately reports the trap to uprobes: i.e.,
utrace_get_signal()?  Is that the "insane amount of code"?


> 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.

I don't know what you mean exactly.  A trap already stopped task.
utrace merely allows various clients to inspect/manipulate the state
of the task at that moment.  It does not add any context switches or
spurious stop/resumue operations.


- FChE
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/