Re: DTrace for FreeBSD - Status Update

On Fri, May 26, 2006 at 09:01:12PM +0530, Joseph Koshy wrote:
> >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.

The problem with doing this is that DTrace is licensed under Sun's
CDDL. There is a software re-distribution requirement of the
CDDL, but it isn't viral and it only affects the files that Sun
provides. 

There are actually a handful of files in OpenSolaris that
originated in FreeBSD. One of those is sys/i386/i386/exception.s
which is where the FBT/SDT invalid opcode hooks are.

I've added a KDTRACE kernel option which compiles in the hooks that
DTrace uses and a bit of extra exception handling code. This
is only minimal bloat.

Apart from those hooks, the DTrace kernel functionality is in the
'dtrace' device which is also the 'dtrace' provider. The other
providers register themselves with the 'dtrace' device.

If the DTrace device modules aren't loaded, there is very little
code in the kernel to share.

--
John Birrell