Date: Fri, 26 May 2006 19:50:18 +0000 From: John Birrell <jb@what-creek.com> To: Joseph Koshy <joseph.koshy@gmail.com> Cc: current@freebsd.org Subject: Re: DTrace for FreeBSD - Status Update Message-ID: <20060526195018.GA34554@what-creek.com> In-Reply-To: <84dead720605260831n65cecbc2r7c6a2a7b45416379@mail.gmail.com> References: <20060525065510.GA20475@what-creek.com> <20060525082633.GA724@turion.vk2pj.dyndns.org> <20060525195346.GA25270@what-creek.com> <84dead720605260831n65cecbc2r7c6a2a7b45416379@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060526195018.GA34554>