Messages in this thread | | | Subject | Re: [PATCH] tracing: Fix the outmost stupidity of tracing_off() | From | Steven Rostedt <> | Date | Fri, 15 Jun 2012 00:18:39 -0400 |
| |
On Thu, 2012-06-14 at 19:48 -0400, Steven Rostedt wrote:
> I have several branches that I work on and when they are ready, I rebase > them on top of tip, run a bunch of tests, and then push them out.
One more thing. I do run specific tests during development aimed at the changes I make. I may rebase on top of tip afterward, run generic tests, and then push out. These activities are not always done right after each other. I probably screwed up by either cherry-picking or rebasing a separate branch, noticing the bug (I remember fixing it before) but then get side-tracked, and use the original branch that didn't have the fix. Or it could have simply gotten reverted with a git reset --hard, where I forgot to do the --amend. For testing something like this, I would have added tracing_off() in the code, and I do reset --hard to remove my testing code. If I made the fix and forgot to --amend it, the fix was lost.
Anyway, I added to my generic tests: testing 'echo schedule:traceon > set_ftrace_filter' as well as 'echo schedule:traceoff > set_ftrace_filter' and make sure that they do enable and disable tracing.
The traceon and traceoff triggers use tracing_on() and tracing_off() underneath the covers. If they break, the test will fail (I tested the broken patch and it does fail). This regression wont appear again.
Since the last time you've yelled at me, I've added a lot of stress tests to ftrace. I test the tracing_on file to make sure it enables and disables. But my generic tests did not include the internal tracing_off() testing. My mistake, and yes I screwed up.
-- Steve
| |