On Sun, Nov 01, 2009 at 11:58:10AM -0500, erik quanstrom wrote: > On Sun Nov 1 11:55:47 EST 2009, [email protected] wrote: > > Also, D is not compiled in kernel. The dtrace utility compiles the D > > script, and the script goes through some sanity checking in the D > > compiler. The bytecode is sent to the kernel to execute. There are > > some in-kernel safety guarantees -- for instance, a D script causing a > > nil ptr deref in kernel obviously shouldn't (and does not) cause the > > system to panic. > > that wasn't my main concern. > > there are many interrupt routines that depend on > the exact sequence of events and probing is likely > to wreck havoc.
D is not able (AFAIK, anyway... the design seems like it oughtn't be) to change the externally observable sequence of events to hardare. It may of course change the timing of those events, but that's often less of an issue. If you don't disable safety (as root, you can, AIUI) DTrace writes only to its own logs, even if it can read almost everything. > how do you prevent probes from reading read-to-clear > registers? DTrace has a notion of "toxic" regions of memory -- lists provided by drivers -- which D is not allowed to access. It is possible to get these wrong, and that's a bug, just like it would be possible to get the driver itself wrong. > how do you know a probe in an irq routine won't set > off a latent race? AIUI since D bytecode is loop-free (it permits only forward branches, making it trivially terminating), hooks run in non-preemptable context can safely inherit non-preemption from their hooked context. If you've got a race between CPUs that's tickled by DTrace, it could also be tickled by changing your compiler, or dynamic CPU clocking, or a higher priority IRQ, or ... take your pick. That's a bug and it's not DTrace's fault. All that said, DTrace is not perfect and probably has some corner cases that may cause trouble. I'm sure the Solaris developers would love to hear from you if you find one. --nwf;
pgpc3NZSDIM6B.pgp
Description: PGP signature
