[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: DTrace syscall provider - please test/comment
In article <51C8D0F5.9020302%NetBSD.org@localhost>, Jeff Rizzo
>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?
Can't this be done as an addition/enhancement to the trace_enter()/
trace_exit() facility instead of having to enter each syscall entry?
Main Index |
Thread Index |