Re: ktrace -c behavior

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