Date: Tue, 18 Jun 1996 13:41:52 GMT From: James Raynard <fcurrent@jraynard.demon.co.uk> To: wollman@lcs.mit.edu Cc: bde@zeta.org.au, freebsd-current@FreeBSD.ORG Subject: Re: ktrace [Was: 2.2-960612-SNAP resolver problems] Message-ID: <199606181341.NAA00521@jraynard.demon.co.uk> In-Reply-To: <9606171557.AA01047@halloran-eldar.lcs.mit.edu> (message from Garrett Wollman on Mon, 17 Jun 1996 11:57:56 -0400)
next in thread | previous in thread | raw e-mail | index | archive | help
> > Indeed. Apart from volume of output, is there any particular reason > > why ktrace writes to a file which kdump reads in, as opposed to using > > a pipe? Particularly as the first thing kdump does is > > freopen(tracefile, "r", stdin)! > 2) The present approach has the advantage of not disturbing the file > descriptor table of the process being debugged, so that heisenbug > effects are less likely to occur. I don't follow. If the ktrace() system call took a file descriptor allocated by the ktrace program as its first argument, and used that to find the vnode to write the trace information to, how would that involve disturbing the file descriptor table of the process being debugged? (Except perhaps for pathological cases like trying to get a running ktrace process to debug itself). -- James Raynard, Edinburgh, Scotland james@jraynard.demon.co.uk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606181341.NAA00521>