tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

DTrace syscall provider - please test/comment

I've been looking at our DTrace code in my spare time recently, and I'd like to get us closer to the point where generally available D scripts "just work" on NetBSD. One of the big missing pieces right now (by no means the *only* missing piece) is the "syscall" provider for tracing system calls.

Here's the latest patch, meant to be applied with "patch -p0" in /usr/src (or whereever):

To test it, make sure you're set up for dtrace:

You'll need to rebuild both the kernel and all the dtrace kmods with these patches. Something like this to rebuild the whole system:

./ -U -O /dtracetest/obj -T /dtracetest/tools -m amd64 -j8 -V MKDTRACE=yes release

The kernel config I'm using is:

# Kernel with dtrace enabled.

include "arch/amd64/conf/GENERIC"

options         KDTRACE_HOOKS
options         DDB_ONPANIC=1
makeoptions     DEBUG="-g"

Some notes:

- I've only tested this on amd64.  It *should* work on i386 as well.

- Only native syscalls will be traced. I could use some help figuring out the best way to implement tracing of emulated syscalls (netbsd32, linux, linux32, etc) given the fact that those are meant to be loadable modules

- The name "systrace" was not chosen by me; it's from the original Solaris code. Yes, it conflicts with the removed "systrace" feature. No, it doesn't have anything to do with that systrace. I would like to rename all the dtrace providers (fbt, sdt, profile, systrace) to "dtrace_*" names at some point, but not until after these changes are in.

- at some point, I would like to make "MKDTRACE=yes" the default on systems that support DTrace (amd64 and i386 at the moment), without including KDTRACE_HOOKS in the kernel config necessarily. Thoughts?

Please let me know what you think.  Constructive suggestions welcome.


Home | Main Index | Thread Index | Old Index