linux-kernel - Re: Re: [RFC PATCH v3 4/4] ftracetest: Add XFAIL/XPASS and POSIX.3 std. result codes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5407ED17.5060000@hitachi.com>
Date:	Thu, 04 Sep 2014 13:39:51 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Namhyung Kim <namhyung@...nel.org>
Cc:	Shuah Khan <shuah.kh@...sung.com>,
	Tom Zanussi <tom.zanussi@...ux.intel.com>,
	Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@...achi.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Re: [RFC PATCH v3 4/4] ftracetest: Add XFAIL/XPASS and POSIX.3
 std. result codes

(2014/09/04 11:29), Namhyung Kim wrote:
>> diff --git a/tools/testing/ftrace/test.d/basic3.tc b/tools/testing/ftrace/test.d/basic3.tc
>> index 0c1a3a2..7bc5a53 100644
>> --- a/tools/testing/ftrace/test.d/basic3.tc
>> +++ b/tools/testing/ftrace/test.d/basic3.tc
>> @@ -1,8 +1,9 @@
>>  #!/bin/sh
>>  # description: Basic trace clock test
>> -[ -f trace_clock ] || exit 1
>> +[ -f trace_clock ] || exit $FAIL # this is basic feature, must be there
>>  for c in `cat trace_clock | tr  -d \[\]`; do
>> -  echo $c > trace_clock || exit 1
>> -  grep '\['$c'\]' trace_clock || exit 1
>> +  echo $c > trace_clock || exit $FAIL
>> +  grep '\['$c'\]' trace_clock || exit $FAIL
>>  done
>> -echo local > trace_clock
>> +echo local > trace_clock || exit $FAIL
>> +exit $PASS
> 
> IMHO it's a bit sad that we need to write every test in this way -
> adding '|| exit $FAIL' for every command.  It'd be better if only
> exceptional cases require that explicitly and normal cases live in
> simple.
> 
> Can we do better - like using trap or something?

Hmm, no, trap is only for the signal trapping, and using signal
means run "kill" command for special errors. That may not be what
you want... :(

Perhaps, "set -e" may help you to simplify the script. But
since it also returns various exit code, you can not control it.
(I hope to have the "atexit" for dash...)

Anyway, IMHO, the test cases should express what happened clearly
since the test is a kind of verification process.

Thank you,

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


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