Re: [9fans] dtrace for plan 9

[Roman Shaposhnik <roman@shaposhnik.org>]

On Sun, Nov 1, 2009 at 11:26 AM, ron minnich <rminnich@gmail.com> wrote:
> On Sat, Oct 31, 2009 at 8:01 PM,  <dave.l@mac.com> wrote:
>
>> but wouldn't be slightly nicer to have something like a set of dynamic
>> probes
>> which queue up blobs of data up for userland code to do the hairy lifting
>> on?
>
> yeah. You are right. Is there any reason that D couldn't always run in
> user mode, having read from a device which delivers events to it?
>
> I'm not really that familiar with dtrace, as you can tell; I've just
> read the papers, not really used it.

The whole point of D is to be able to execute scripts in kernel mode (and
sometime in tricky places like interrupt handlers, etc). The main reason of
doing that is to be able to filter in place what is it that you want to send
to userland /dev/dtrace and what you just want to discard. That gives you
a huge reduction in event traffic at a price of restricting D. Lack of looping
is the prime example of such a restriction.

As for your question -- I have to ask you back: why would you want to? IOW,
why would you still want to restrict yourself in user mode? If you simply want
to pipe all events to an aggregation engine won't:
   # dtrace -n 'whatever spec' | awk 'do postprocessing here'
be what you really want?

Thanks,
Roman.