From owner-freebsd-current Wed Jun 19 02:54:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA01756 for current-outgoing; Wed, 19 Jun 1996 02:54:07 -0700 (PDT) Received: from jraynard.demon.co.uk (jraynard.demon.co.uk [158.152.42.77]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA01707 for ; Wed, 19 Jun 1996 02:52:29 -0700 (PDT) Received: (from fcurrent@localhost) by jraynard.demon.co.uk (8.7.5/8.6.12) id NAA00521; Tue, 18 Jun 1996 13:41:52 GMT Date: Tue, 18 Jun 1996 13:41:52 GMT Message-Id: <199606181341.NAA00521@jraynard.demon.co.uk> From: James Raynard To: wollman@lcs.mit.edu CC: bde@zeta.org.au, freebsd-current@FreeBSD.ORG In-reply-to: <9606171557.AA01047@halloran-eldar.lcs.mit.edu> (message from Garrett Wollman on Mon, 17 Jun 1996 11:57:56 -0400) Subject: Re: ktrace [Was: 2.2-960612-SNAP resolver problems] Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > 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