[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
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:
./build.sh -U -O /dtracetest/obj -T /dtracetest/tools -m amd64 -j8 -V
The kernel config I'm using is:
# Kernel with dtrace enabled.
- 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
- 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.
Main Index |
Thread Index |