Re: [RFC][PATCH] ftracetest: Add a couple of ftrace test cases

[Masami Hiramatsu]

(2014/09/25 0:42), Steven Rostedt wrote:
> On Wed, 24 Sep 2014 11:58:50 +0900
> Masami Hiramatsu <masami.hiramatsu.pt@xxxxxxxxxxx> wrote:
> 
>> (2014/09/24 6:38), Steven Rostedt wrote:
>  
>>>   to them and copied them pretty much unchanged into a ftrace directory
>>>   under test.d. Is this fine, or is there more massaging I need to do
>>>   to them?
>>
>> Yeah, ftrace has a double meaning :), so test.d/ftrace is fine to me.
> 
> I was thinking that more complex tests can go into ftrace, and simple
> tests can go into basic.

Hmm, what kind of "complex" test will be there?
I think unit tests are usually simple, selftests/ftrace/test.d/ftrace/
looks redundant if the first ftrace and the second one has same meaning.

>>>   I know the echos don't show up, but I kept them anyway. What should
>>>   happen with them?
>>
>> I think you'd better use exit_unsupported/exit_xfail to notify
>> that the test target is not configured, or expected to fail.
> 
> OK, that answers the exit codes (as you also stated below), but what
> about the echos themselves?

Again, ftracetest is for unit tests, exit code will return one
concrete result, but we can anything with echo (including typo)

> 
>> Then the user can reconfigure that. Maybe we should keep the
>> detailed log of such results. (you can do it with --keep option)
> 
> You mean keep the echos, as they are ignored anyway, but if we add
> --keep, then the echos will show?

No, --keep keeps all output logs of the test script. Since all scripts
run under set -x, all commands and outputs are logged to a logfile.

>  Maybe that option should be -v, like
> other tools use for "verbose".

OK, it will be easy, just turning "> $LOGFILE" into "| tee $LOGFILE" :)

>>> --- /dev/null
>>> +++ b/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter.tc
>>> @@ -0,0 +1,111 @@
>>> +#!/bin/sh
>>> +# description: ftrace - function graph filters
>>> +
>>> +# Make sure that function graph filtering works, and is not
>>> +# affected by other tracers enabled (like stack tracer)
>>> +
>>> +if ! grep -q function_graph available_tracers; then
>>> +    echo "no function graph tracer configured"
>>> +    exit 0;
>>
>> This should call exit_unsupported, because the test is not passed.
> 
> Will update this and others.
> 
> 
>>> +# Make sure we did find something
>>> +count=`cat trace | grep 'schedule()' | wc -l` 
>>> +if [ $count -eq 0 ]; then
>>> +    echo "No schedule traces found?"
>>> +    exit -1
>>> +fi
>>> +
>>> +echo "Graph filtering works by itself"
>>> +
>>
>> I think the following part should be a separated test for
>> stack trace.
> 
> Good point. A lot of my test scripts do multiple tests. I think for
> putting them into tools/testing/selftests/ftrace, I'll break them up
> and make them separate tests. For example, the simple graph filtering
> above is an example of something that can go into the basic directory,
> but the test against stack tracer should be in ftrace. What do you
> think?

Hm, I think only really basic operation tests go into the basic
directory, like reading and writing (no format checks).
And test.d/ftrace may be for more advanced tests, like checking
output, setting options, etc.

>>> +
>>> +echo "Now filter on just schedule"
>>> +echo '*schedule' > set_ftrace_filter
>>> +> trace
>>
>> echo > trace?
> 
> OK. Hmm, I wonder if we should make a bunch of functions that the tests
> can use. Like a "clear_trace" call that does this. Can we export
> functions that this shell will be able to use?

Yeah, it's a good idea :) We can use "." to include it.
I think test.d/functions will be good.

> When we see lots of
> duplicate code we may want to have something like that. Well, for this,
> it may not be that big of a deal, because "echo > trace" is rather
> simple. But I do have other operations that are a bit more intrusive.

Agreed.

Thank you!

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@xxxxxxxxxxx


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/