Date: Wed, 19 Jun 1996 21:56:43 GMT From: James Raynard <fcurrent@jraynard.demon.co.uk> To: wollman@lcs.mit.edu Cc: freebsd-current@freebsd.org Subject: Re: ktrace [Was: 2.2-960612-SNAP resolver problems] Message-ID: <199606192156.VAA29745@jraynard.demon.co.uk> In-Reply-To: <9606191554.AA19234@halloran-eldar.lcs.mit.edu> (message from Garrett Wollman on Wed, 19 Jun 1996 11:54:13 -0400)
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> Garrett Wollman <wollman@lcs.mit.edu> writes: > > <<On Tue, 18 Jun 1996 13:41:52 GMT, James Raynard <fcurrent@jraynard.demon.co.uk> said: > > 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). > > The original poster suggested sending it to standard output, which is > (generally speaking) not a useful place for binary trace data to go > because whatever is interpreting the real output of the program can't > deal with it. Hmm. That doesn't answer the question, which was why passing a file descriptor to the ktrace() system call could allegedly trash the debugged process's fd table. The original poster (that was me, BTW) actually wanted the data to be sent into a pipe, not ktrace's standard output! (which I agree is not a good idea). What I had in mind was something like using popen() to write into kdump's standard input, and pass the corresponding file descriptor to the ktrace() system call. (Or perhaps even get rid of kdump altogether and put its functionality into the ktrace program!) This would allow the user to get a "real-time" trace output, as is available on a number of other systems. Obviously that won't work as things stand, since ktrace() takes a pathname (which must apparently be that of a regular file) and I was curious as to why it was designed in such an apparently limited way. -- 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?199606192156.VAA29745>