From: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 1/4] memcg/functional: rewrite
Date: Fri, 19 Aug 2016 17:11:20 +0300 [thread overview]
Message-ID: <57B71388.9090106@oracle.com> (raw)
In-Reply-To: <20160622133444.GD13962@rei.lan>
Hi!
On 06/22/2016 04:34 PM, Cyril Hrubis wrote:
> Hi!
>> # Record the test result of a test case
>> # $1 - The result of the test case, $PASS or $FAIL
>> @@ -55,7 +82,6 @@ result()
>> tst_resm TPASS "$info"
>> else
>> tst_resm TFAIL "$info"
>> - : $(( failed += 1 ))
>> fi
>
> Can we get rid of the result() function?
>
> Since the failures are now counted in the test.sh library it does not
> make a sense to define special result reporting function.
Yes, we can.
One thing to notice that in the current code there are many places like
this:
echo 1.0 > memory.limit_in_bytes 2> /dev/null
result $(( !($? != 0) )) "return value is $?"
I don't think it will be a good idea to transform them all to:
echo 1.0 > memory.limit_in_bytes 2> /dev/null
if [ $? -ne 0 ]; then
tst_resm TPASS "return value is $?"
else
tst_resm TFAIL "return value is 0"
fi
A possible solution could be using help functions similar to ROD():
SHOULD_FAIL echo 1.0 \> memory.limit_in_bytes
which will output:
TPASS: echo 1.0 > memory.limit_in_bytes failed as expected
I have an RFC patch for that. I'll send it shortly.
>
>> @@ -83,7 +109,7 @@ warmup()
>> {
>> pid=$1
>>
>> - echo "Warming up for test: $cur_id, pid: $pid"
>> + tst_resm TINFO "Warming up pid: $pid"
>> kill -s USR1 $pid 2> /dev/null
>> sleep 1
>> kill -s USR1 $pid 2> /dev/null
>> @@ -91,10 +117,10 @@ warmup()
>>
>> kill -0 $pid
>> if [ $? -ne 0 ]; then
>> - result $FAIL "cur_id=$cur_id"
>> + result $FAIL ""
> ^
> Shouldn't we print here something as:
>
> "process died after warmup"
>
> Or even better wait the pid and print the exit value as well.
Ok. Will do.
>
>
> Otherwise this looks fine.
>
prev parent reply other threads:[~2016-08-19 14:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-14 15:24 [LTP] [PATCH 1/4] memcg/functional: rewrite Stanislav Kholmanskikh
2016-06-14 15:24 ` [LTP] [PATCH 2/4] memcg/functional/memcg_process: cleanup Stanislav Kholmanskikh
2016-06-14 15:24 ` [LTP] [PATCH 3/4] memcg/functional: use checkpoints Stanislav Kholmanskikh
2016-06-14 15:24 ` [LTP] [PATCH V3 4/4] memcg/functional: check several times if the process is killed Stanislav Kholmanskikh
2016-06-22 13:51 ` Cyril Hrubis
2016-06-22 13:38 ` [LTP] [PATCH 3/4] memcg/functional: use checkpoints Cyril Hrubis
2016-06-22 13:40 ` Cyril Hrubis
2016-06-22 13:35 ` [LTP] [PATCH 2/4] memcg/functional/memcg_process: cleanup Cyril Hrubis
2016-06-22 13:34 ` [LTP] [PATCH 1/4] memcg/functional: rewrite Cyril Hrubis
2016-08-19 14:11 ` Stanislav Kholmanskikh [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57B71388.9090106@oracle.com \
--to=stanislav.kholmanskikh@oracle.com \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox