Re: DTrace syscall provider - please test/comment

[christos%astron.com@localhost (Christos Zoulas)]

In article <51C8D0F5.9020302%NetBSD.org@localhost>, Jeff Rizzo  
<riz%NetBSD.org@localhost> wrote:
>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):
>
>http://www.tastylime.net/netbsd/systrace.diff
>
>To test it, make sure you're set up for dtrace:
>
>http://wiki.netbsd.org/how_to_enable_and_run_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 
>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?

Can't this be done as an addition/enhancement to the trace_enter()/
trace_exit() facility instead of having to enter each syscall entry?

christos