Date: Mon, 24 Apr 2006 22:04:05 +0000 From: John Birrell <jb@what-creek.com> To: John Baldwin <jhb@freebsd.org> Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 96007 for review Message-ID: <20060424220405.GA62694@what-creek.com> In-Reply-To: <200604241748.59461.jhb@freebsd.org> References: <200604241913.k3OJDEAq055317@repoman.freebsd.org> <200604241637.08322.jhb@freebsd.org> <20060424213134.GA62456@what-creek.com> <200604241748.59461.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 24, 2006 at 05:48:58PM -0400, John Baldwin wrote: > 1) I've already completely redone all of the locking in the > kernel linker to use a big sx lock around the whole kernel > linker. I have to tidy up some issues with ndis still. > > 2) Tell me what dtrace is trying to do and let's see if we > can provide an API hook in the kernel linker for it instead > of having DTrace grovel around in the linker's internals. > Then DTrace doesn't need to be aware of any locking for the > kernel linker. What I would like to do is have DTrace call a kern_linker function specifying a callback function that the linker would call for each module. The function needs to pass back an opaque argument, plus a pointer to the linker file structure. DTrace wants the module info not to change while it looks at the contents of the linker file structure. DTrace doesn't need to know how the modules are listed or locked, but it definitely needs to be able to allocate memory with wait while it is looking at the module data. > 3) Generally speaking it is better (if possible) to preallocate > resources before acquiring a lock so that you don't hold the > lock as long. I agree, but the structure of Sun's code does all it's allocations except the buffers with VM_SLEEP. It's a major rewrite of their code to fall back gracefully if memory isn't available. -- John Birrell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060424220405.GA62694>