From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 03:07:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6ED4FB68 for ; Tue, 26 Aug 2014 03:07:39 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 414593C17 for ; Tue, 26 Aug 2014 03:07:39 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0A0A1B93B; Mon, 25 Aug 2014 23:07:38 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: ktrace -c behavior Date: Mon, 25 Aug 2014 16:23:27 -0400 Message-ID: <9285902.gXIcESz31I@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: <53FB386C.9030800@vangyzen.net> References: <53F79710.6090700@vangyzen.net> <20140824235336.GR71691@funkthat.com> <53FB386C.9030800@vangyzen.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 25 Aug 2014 23:07:38 -0400 (EDT) Cc: Eric van Gyzen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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: Tue, 26 Aug 2014 03:07:39 -0000 On Monday, August 25, 2014 09:21:48 AM Eric van Gyzen wrote: > On 08/24/2014 19:53, John-Mark Gurney wrote: > > Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:26 -0400: > >> On 08/22/2014 15:20, John-Mark Gurney wrote: > >>> Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:16 -0400: > >>>> What behavior would you expect from this sequence of commands? > >>>> > >>>> ktrace -tw -p 1234 > >>>> ktrace -c -p 1234 > >>>> > >>>> Based on this... > >>>> > >>>> -c Clear the trace points associated with the specified file > >>>> > >>>> or processes. > >>> > >>> and/or just add specified: > >>> Clear the specified trace points ... > >> > >> But what if I didn't specify them? > > > > You specified the default by not specificly specifing any different > > ones.. :) Confused? :) > > Amused. :) Adding "specified" is the first thing that came to my mind as well. > > or maybe selected? > > Perhaps, but I didn't select them, either. My original suggestion is > more--dare I use this word again--specific. It explains exactly how the > command behaves. But then do we need to annotate every place that uses "trace points" to add this language? Note that the 'command' description uses the language John- mark suggested: command Execute command with the specified trace flags. My vote would be to add "specified" to the description of "-c", but to improve the the description of "-t" itself from: -t trstr The string argument represents the kernel trace points, one per letter. The following table equates the letters with the trace- points: to: -t trstr Specify the list of trace points to enable or disable, one per letter. If an explicit list is not specified, the default set of trace points is used. The following trace points are supported: -- John Baldwin