From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 04:22:25 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3F2516A41B; Mon, 18 Feb 2008 04:22:24 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from mx-out-05.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by mx1.freebsd.org (Postfix) with ESMTP id 5B42213C43E; Mon, 18 Feb 2008 04:22:24 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from mx-av-02.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.13.8/8.13.8) with ESMTP id m1I4BbE7022063; Mon, 18 Feb 2008 06:11:37 +0200 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-02.forthnet.gr (8.14.1/8.14.1) with ESMTP id m1I4BbO3007953; Mon, 18 Feb 2008 06:11:37 +0200 Received: from kobe.laptop (adsl78-170.kln.forthnet.gr [77.49.125.170]) by MX-IN-04.forthnet.gr (8.14.2/8.14.2) with ESMTP id m1I46TjV031628; Mon, 18 Feb 2008 06:06:32 +0200 Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=keramida@freebsd.org; spf=permerror Authentication-Results: MX-IN-04.forthnet.gr header.from=keramida@freebsd.org; sender-id=permerror Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m1I46TmN008294; Mon, 18 Feb 2008 06:06:29 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m1I46Qe3008293; Mon, 18 Feb 2008 06:06:26 +0200 (EET) (envelope-from keramida@freebsd.org) Date: Mon, 18 Feb 2008 06:06:25 +0200 From: Giorgos Keramidas To: "Daniel O'Connor" Message-ID: <20080218040625.GA8141@kobe.laptop> References: <200802122009.m1CK94Y8026959@repoman.freebsd.org> <200802161153.34513.doconnor@gsoft.com.au> <200802160843.11766.jhb@freebsd.org> <200802181004.21379.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802181004.21379.doconnor@gsoft.com.au> Cc: Kostik Belousov , Dag-Erling Smorgrav , freebsd-current@freebsd.org Subject: Re: [src] cvs commit: src/include unistd.h src/lib/libc/sys readlink.2 src/sys/compat/freebsd32 syscalls.master src/sys/kern syscalls.master vfs_syscalls.c src/sys/sys syscallsubr.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 04:22:25 -0000 On 2008-02-18 10:04, Daniel O'Connor wrote: >On Sun, 17 Feb 2008, John Baldwin wrote: >>On Friday 15 February 2008 08:23:33 pm Daniel O'Connor wrote: >>>On Sat, 16 Feb 2008, John Baldwin wrote: >>>>> That's a pretty big advantage :) >>>>> >>>>> Also, ktrace can't write to a pipe which means you need to >>>>> run/process rather than 'stream'. >>>> >>>> kdump -l. >>> >>> Ahh nice! >>> >>> However, you still keep the file around which can be rather space >>> consuming :( >> >> Yes, but it also means you can do offline analysis later. :) >> Tradeoffs either way. > > Yes, but being able to specify stdout to ktrace would be really, really > nice.. Hi Daniel, Specifying stdout may be a bit tricky, since the traced application may be using the same stream to print output. The same is possible with stderr, but may be a tiny bit less likely. It is probably easy to add an -F flag to ktrace/kdump which would inhibit the check for a `regular' file, so you could then write: ( ktrace -aF -f /dev/stdout ls ) | \ kdump -F -f /dev/stdin ( ktrace -aF -f /dev/stderr ls >/dev/null ) 2>&1 | \ kdump -F -f /dev/stdin But the first will probably fail when kdump tries to parse the output of ls(1), and the second may fail in a similar manner when kdump tries to parse an error message like a ktrace record. This sort of difficulty in separating the output of the traced process and the ktrace records themselves is probably at least part of the reason why nobody has done it yet. - Giorgos