Re: DTrace for FreeBSD - Status Update

> The place were DTrace is really, really machine dependent is
> in the trap handling code. DTrace has what it calls 'safe'
> loads where it goes to read from a memory address which a
> flag set to stop a panic if a trap occurs during the
> message access.

Is there any way we can do some code refactoring when
DTrace is brought in?

For example, Dtrace has a 'stack()' primitive that walks
the kernel stack and a 'ustack()' primitive that walks
userland stacks.

Both of these are useful for hwpmc, and are useful in
other contexts (e.g., recording stack traces for userland
processes that dump core).

Similarly, alq(9), ktrace(2) and hwpmc(4) all implement
kernel->userland logging in some form or the other.
DTrace's logging requirements are probably a superset of
all of these so having a common logging layer could help
reduce code bloat in the kernel.

-- 
FreeBSD Developer,     http://people.freebsd.org/~jkoshy