Re: ktrace -c behavior
On 08/25/2014 16:23, John Baldwin wrote: > 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: Okay, that would work. Minor note: You might avoid repeating "specified" in the -c description: Clear the specified trace points associated with the /given/ file or processes. Thanks, guys. Eric ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ktrace -c behavior
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. :) > 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. Eric ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ktrace -c behavior
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? :) or maybe selected? > >> ...I would expect the second command to clear the trace point for > >> context switches. It doesn't. I have to specify -tw with the -c to get > >> that behavior. This makes sense; it's just not what I was expecting. > >> > >> Assuming we want to keep this behavior, can we clarify the -c flag in > >> man page? I would suggest: > >> > >> If the -t flag is not specified, clear the default set of trace points. > > Maybe we should add a new trace point string that is a (for all).. so > > you can do ktrace -ta -c? > > That would be handy. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ktrace -c behavior
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? >> ...I would expect the second command to clear the trace point for >> context switches. It doesn't. I have to specify -tw with the -c to get >> that behavior. This makes sense; it's just not what I was expecting. >> >> Assuming we want to keep this behavior, can we clarify the -c flag in >> man page? I would suggest: >> >> If the -t flag is not specified, clear the default set of trace points. > Maybe we should add a new trace point string that is a (for all).. so > you can do ktrace -ta -c? That would be handy. Eric ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ktrace -c behavior
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 ... > ...I would expect the second command to clear the trace point for > context switches. It doesn't. I have to specify -tw with the -c to get > that behavior. This makes sense; it's just not what I was expecting. > > Assuming we want to keep this behavior, can we clarify the -c flag in > man page? I would suggest: > > If the -t flag is not specified, clear the default set of trace points. Maybe we should add a new trace point string that is a (for all).. so you can do ktrace -ta -c? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ktrace -c behavior
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. ...I would expect the second command to clear the trace point for context switches. It doesn't. I have to specify -tw with the -c to get that behavior. This makes sense; it's just not what I was expecting. Assuming we want to keep this behavior, can we clarify the -c flag in man page? I would suggest: If the -t flag is not specified, clear the default set of trace points. Thanks, Eric ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
