[dtrace-discuss] DTrace in Perl: What probes should we have?

[Bryan Cantrill]

> >>     Again, for the tool we are building relying on signal trickery is
> >> not ideal, but
> >> we can survive. If, however, this approach of "transferring" control
> >> back and forth
> >> between userspace and kernel can be generalized -- I think everybody
> >> would
> >> benefit from such a mechanism.
> >
> > Again, this just isn't the way the world works -- when you are deep
> > in the context of the kernel, you cannot simply revector control to
> > user-land for arbitrary execution.
> 
>     I don't think you followed my example (the actual D code). If you
> did you would have seen that I specifically picked a kernel level
> probe (syscall::read) to illustrate how our crude but useful mechanism
> works. 

Yes, but you already have -- and have long had -- a mechanism to do exactly
this:  /proc.  If you would like to stop a process on every system call --
or more generally if you are more interested in stopping and controlling
processes than in observing their dynamic interactions with the system
at-large -- use /proc and be done with it.

> Nobody is suggesting immediately revectoring the control
> flow. As in my example a signal doesn't get delivered immediately.
> However it is guaranteed to be delivered before the process in question
> gets any chance to chug forward. I agree with the points you made later
> in your email, that instrumenting delicate places deep inside the kernel
> can not rely on such vectoring of the control flow. I agree with that.
> The same way these places can not rely on, lets say system(..)
> destructive action. Yet I can use system(...) in such a handler,  
> can't I?

Yes, but system() doesn't the work the way you appear to think that it
does:  system() merely records which command you wish to be executed --
the actual execution of that command does not occur until that datum
is processed (asynchronously) back in user-land.  The target process is
not stopped, and the command certainly does not execute synchronously
with respect to probe context (and nor could it).

> >>     Ok, let me try to be extra clear: what I need is a mechanism for
> >> passing the control flow back and forth between the kernel executing
> >> the action statements and a particular userspace process in the  
> >> system.
> >
> > You're asking for the operating system equivalent of a perpetual  
> > motion
> > machine.
> 
>     Analogies cut both ways. You of all people should know that. Trying
> to invent a perpetual motion machine is, perhaps unwise.  Talking about
> it and carrying out though experiments proved to be quite beneficial to
> physics.

I'm not sure how much grant money you could get to investigate perpetual
motion machines, but you'd like to spend your time and energy on the software
equivalent, don't let me get in your way...

> > It's not a "potentially good idea", but rather a traditional  
> > debugger-centric
> > notion that reflects a fundamental misunderstanding of the constraints
> > of DTrace.  Which is not to say that one couldn't implement a  
> > system around
> > these notions, but rather that such a system would be so different  
> > as to
> > longer be DTrace.  Indeed, it its features and limitations, it  
> > would look
> > much more like a conventional, process-oriented debugger -- which  
> > should be
> > no surprise given your background and bias...
> 
>    Sorry. For a minute there I forgot that DTrace was perfect. And it  
> is just
> silly me trying to do stupid things (like zeroing out struct elements  
> or even
> strings) and asking questions that don't even deserve an answer. Sorry.
> It won't happen again.

I was merely pointing out that we have different constraints on our
problem than you find on more traditional debuggers.  Those different
constraints convey both strength and weakness:  on the one hand, DTrace
is able to instrument contexts and answer system-level questions for which
traditional debuggers are useless, but on the other, DTrace has a much
more difficult time ascertaining information that is immediately useful
to the developer.  And if I was curt, it was out of frustration that the
misunderstanding of those constraints was coupled with an unyielding
assertion of a notion that completely violates them...

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems FishWorks.       http://blogs.sun.com/bmc