A couple of providers have been proposed here, and I know that Apple has added providers for Python and Ruby. So, I wonder what kind(s) of plugin APIs may exist for DTrace. Is there, for example, something like a REST-based interface that some arbitrary script could feed? -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm at cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development
On Thu, 2007-11-15 at 21:11 -0800, Rich Morin wrote:> A couple of providers have been proposed here, and I know that > Apple has added providers for Python and Ruby. So, I wonder > what kind(s) of plugin APIs may exist for DTrace. Is there, > for example, something like a REST-based interface that some > arbitrary script could feed?I''m not sure I understand what kind of "plug-ins" you are talking about. Care to elaborate? Thanks, Roman.
At 12:04 -0800 11/19/07, Roman Shaposhnik wrote:> On Thu, 2007-11-15 at 21:11 -0800, Rich Morin wrote: >> A couple of providers have been proposed here, and I know that >> Apple has added providers for Python and Ruby. So, I wonder >> what kind(s) of plugin APIs may exist for DTrace. Is there, >> for example, something like a REST-based interface that some >> arbitrary script could feed? > > I''m not sure I understand what kind of "plug-ins" you are > talking about. Care to elaborate?The fact that both Sun and Apple have added providers tells us that there are ways to do so. The question is whether these ways are open to (say) a Perl scripter or the fellow who wants to instrument Erlang programs. 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. -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm at cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development
On Nov 20, 2007, at 8:10 AM, Rich Morin wrote:> At 12:04 -0800 11/19/07, Roman Shaposhnik wrote: >> On Thu, 2007-11-15 at 21:11 -0800, Rich Morin wrote: >>> A couple of providers have been proposed here, and I know that >>> Apple has added providers for Python and Ruby. So, I wonder >>> what kind(s) of plugin APIs may exist for DTrace. Is there, >>> for example, something like a REST-based interface that some >>> arbitrary script could feed? >> >> I''m not sure I understand what kind of "plug-ins" you are >> talking about. Care to elaborate? > > The fact that both Sun and Apple have added providers tells us > that there are ways to do so. The question is whether these > ways are open to (say) a Perl scripter or the fellow who wants > to instrument Erlang programs. > > 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. The patch Apple ultimately included in Ruby is at http:// www.opensource.apple.com/darwinsource/10.5/ruby-67/patches/ dtrace.diff if you''d like to see how it was done with the Ruby provider. -Scott
> > 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
Bryan Cantrill writes:> 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...I like "DTracer," because it fits in well with the rest of the Mac environment -- Chooser, Launcher, Installer, Finder -- and this makes it look like a first-class citizen in the Mac world. I agree with avoiding gratuitous renaming, but if a slight alteration helps support an existing design pattern, I don''t think it''s necessarily a bad thing. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677