[Ksummit-2008-discuss] DTrace

[Christoph Hellwig]

On Mon, Jun 30, 2008 at 10:40:34AM +0530, Ananth N Mavinakayanahalli wrote:
> > Actually the uprobes code that has been floating around for a while is
> > the completely wrong approach.
> 
> Hope you are referring to the uprobes code based on utrace.

The one that's in systemtap CVS, which is based on utrace, yes.

> Uprobes, in the current approach, hooks on to the per-task utrace event
> handlers. Utrace event handlers, by design run in the kernel (unless we
> want to go back to the ptrace model of context switches and intercepting
> signals). The current design enables running handlers in the context of
> the traced process. Also, the handler as such can do just minimal stuff
> in the kernel (dump data from the process address space - mostly
> restricted to what access_process_vm() gives you), and post processing is
> left to userspace.
> 
> If you have ideas for better ways of doing this, we are all ears.

This might be getting a little offtopic for the kernel summit discuss
list, but let's start anyway, we can move this to a better suited list,
although I can't think of one except for linux-kernel.  I'm not sure
if that's the current design, but I can't find any evidence in the code
that it allows running handlers in process context, all that's available
is a kernel callback.  Now as long as the probes are simple enough, e.g.
just a single stepping that pushes data to userspace when a trivial
condition is hit that's enough.  What's not enough is that the whole
handler is not implemented - the uprobes code as checked in there is
just a low-level building block that's not useful on it's own.  What
we really need is a userspace interface so that it actually can be used
by thing like frysk or an implementation of the userspace dtrace hooks.

The whole signal mess of ptrace is not a consequence of doing the
actual tracing / single stepping etc in userspace, but a historic
artefact.  If you look at e.g. the Plan 9 /proc based debugging
(similarly also in SysV based systems like Solaris) you can see that we
can have a debugger interface that doesn't need the signal mess,
or for a Linux implementation that doesn't do this (but has some other
issues) looks at the utracer module that plugs into utrace.  For complex
traces doing this in userspace is for sure a better idea.