> >> > One can dtrace dtrace as in use the kernel framework + command to debug > >> > the command and library. We do this often. One cannot debug DTrace > >the > >> > kernel software, though, since you can't instrument the kernel portion > >of > >> > the instrumentation framework. This would violate the s/w laws of > >physics. > >> > >> I was thinking about this part. Why is this a violation of physics? A > >> perfect emulator can run itself like the Russian dolls, over and over > >> and over and over again in a nested nested nested fashion
The in-kernel component of DTrace is quite a bit more than an emulator; if you're curious I recommend you peruse it (the comments will guide you as to the major in-kernel components): http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/dtrace_impl.h http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/dtrace/dtrace.c > >The emulator would be a separate process, loading itself, with the nested > >instance having its own resources. In an arbitrary-context instrumentation > >framework, you've got one instance of this thing in the one kernel, with > >finite resources and you can't arbitrarily allocate more as you go. > You can allocate from the stack and say 'no stack left for probing' if > you are out of stack. What's the stupid problem with that? Um, what would you do with the data? Even leaving aside the essentially insurmountable obstacles of getting the DTrace data space to live within a kernel stack, where would you then store the resulting data? If you want to instrument the instrumentation framework arbitrarily, any global space to which you can store data must be entirely transactional down to the unit of a single instruction -- and it's not even sufficient for it to be lock-free; it would have to be wait-free to avoid starvation. Any system that satisfies these constraints would be (in my opinion) too small to do anything interesting. Allowing the instrumentation framework to not instrument itself allows for much more powerful facilities, because the unit of atomic transaction can become much larger and more complicated -- which is why it was such a conscious design decision in DTrace... - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
