From owner-freebsd-current@FreeBSD.ORG Fri May 26 19:50:25 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4061816A4EB for ; Fri, 26 May 2006 19:50:25 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id B069543D6E for ; Fri, 26 May 2006 19:50:20 +0000 (GMT) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id BF0B378C1D; Fri, 26 May 2006 19:50:18 +0000 (GMT) Date: Fri, 26 May 2006 19:50:18 +0000 From: John Birrell To: Joseph Koshy Message-ID: <20060526195018.GA34554@what-creek.com> References: <20060525065510.GA20475@what-creek.com> <20060525082633.GA724@turion.vk2pj.dyndns.org> <20060525195346.GA25270@what-creek.com> <84dead720605260831n65cecbc2r7c6a2a7b45416379@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84dead720605260831n65cecbc2r7c6a2a7b45416379@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: DTrace for FreeBSD - Status Update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 19:50:37 -0000 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