Date: Fri, 26 May 2006 21:01:12 +0530 From: "Joseph Koshy" <joseph.koshy@gmail.com> To: "John Birrell" <jb@what-creek.com> Cc: Peter Jeremy <peterjeremy@optushome.com.au>, current@freebsd.org Subject: Re: DTrace for FreeBSD - Status Update Message-ID: <84dead720605260831n65cecbc2r7c6a2a7b45416379@mail.gmail.com> In-Reply-To: <20060525195346.GA25270@what-creek.com> References: <20060525065510.GA20475@what-creek.com> <20060525082633.GA724@turion.vk2pj.dyndns.org> <20060525195346.GA25270@what-creek.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. -- FreeBSD Developer, http://people.freebsd.org/~jkoshy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?84dead720605260831n65cecbc2r7c6a2a7b45416379>