> > At this point, I suspect that the answer is no, but it doesn't
> > hurt to speculate. So, here's a bit of Science Fiction:
> >
> > Sitting in a Perl script, I make calls to dtrace_event(),
> > handing it some data structures and flags. If a probe has
> > been set for this event (i.e., for the flags I've enclosed),
> > the information is passed on to dtrace to trigger the probe.
> >
> > In the probe's associated D code, I reach into the data
> > structures, pull out the information I want to log, store
> > to control other logging activities, etc.
> >
> > The idea here is to allow arbitrary programs to voluntarily
> > submit information to dtrace. I realize that there would be
> > performance limitations to any such scheme, but the ability to
> > mix in volunteered information could still be useful.
> >
>
> Sure - anyone could write such a thing. I wrote something similar in
> the Ruby DTrace probes (which Apple has included). In the original
> patch up on the Joyent site the added Ruby module was called Tracer
> but Apple changed it to DTracer because Ruby already has a Tracer
> module. Firing an event from Ruby code fires a probe called 'ruby-
> probe', so it works like this:
>
> def foo
> DTracer.fire('foo-start', 'some arbitrary string')
> # do work
> DTracer.fire('foo-end', 'some arbitrary string')
> end
>
> And the D would look something like:
>
> ruby*:::ruby-probe
> /copyinstr(arg0) == "foo-start"/
> {
> printf("%s\n", copyinstr(arg1));
> }
>
> And so forth. Passing simple strings back is all I needed so
> anything more complex is left as an exercise, but you get the idea.
We on the DTrace team really liked Scott's approach here, and we would
encourage other environments to follow the model that Scott set forth in
his Ruby provider -- name your native statically defined probes (NSDT?)
as "environment-probe", and have two strings as arguments: one which
denotes some connection to the program text (either statically or
dynamically determined), and a second which is a single string parameter.
On the one hand, it would be nice to have a richer type support, but on
the other, these dynamic environments all support string conversion, and
with is-enabled probes it seems much wiser to do this in the native
environment than to try to struggle with a zillion different native
representations on the DTrace side. Also, this allows many environments
to leverage any enhancements that we add to string handling on the DTrace
side. To that end, I would encourage environments that wish to support
richer arguments (i.e., objects) to use JSON -- it would be very reasonable
to add DTrace subroutines to perform simple JSON parsing, should we need
to go there.
Now that said, the one thing that I confess does grate a bit is Apple's
choice of "DTracer" for the module name. Personally, I would prefer
that the name "DTrace" be used, if only because "DTracer" is not used
anywhere else in DTrace (to me, "DTracer" sounds more like a license plate
that Jarod might get than it does an actual piece of the technology). So
unless there's a compelling reason not to, we would encourage environments
to adopt simply "DTrace" as the module name...
- Bryan
--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems FishWorks. http://blogs.sun.com/bmc
_______________________________________________
dtrace-discuss mailing list
[email protected]
