All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH V6 01/17] syscalls/timer_gettime: Add support for time64 tests
Date: Thu, 25 Jun 2020 13:07:51 +0200	[thread overview]
Message-ID: <20200625110751.GB23637@yuki.lan> (raw)
In-Reply-To: <20200625095006.d6ndameqblecadp4@vireshk-i7>

Hi!
> > > +static void verify(void)
> > > +{
> > > +	struct test_variants *tv = &variants[tst_variant];
> > > +	struct tst_its spec = {.type = tv->type, };
> > > +
> > > +	TEST(tv->func(timer, tst_its_get(&spec)));
> > > +	if (TST_RET == 0) {
> > > +		tst_res(TPASS, "timer_gettime() Passed");
> > > +	} else {
> > > +		tst_res(TFAIL | TTERRNO, "timer_gettime() Failed");
> > >  	}
> > 
> > Looking at manuals it seems that:
> > 
> > * Newly created timer is disarmed
> > 
> > * For disarmed timers the clock_gettime() should get itimer with zeroes
> > 
> > So we check here that the returned itimer has zeroes for both oneshoot
> > and interval timers here.
> 
> I am not sure what oneshoot/interval timers you are talking about :)

These are the two timerspec structures inside of the itimerspec, one of
them is for oneshoot timer/alarm and the second one is for reocurring
timer/alarm and called interval.

> This is what I came to, is this sufficient ?
> 
> diff --git a/testcases/kernel/syscalls/timer_gettime/timer_gettime01.c b/testcases/kernel/syscalls/timer_gettime/timer_gettime01.c
> index ea7cc6b59f7e..4a949486a920 100644
> --- a/testcases/kernel/syscalls/timer_gettime/timer_gettime01.c
> +++ b/testcases/kernel/syscalls/timer_gettime/timer_gettime01.c
> @@ -55,7 +55,19 @@ static void verify(void)
>  
>         TEST(tv->func(timer, tst_its_get(&spec)));
>         if (TST_RET == 0) {
> -               tst_res(TPASS, "timer_gettime() Passed");
> +               if ((spec.type == TST_KERN_OLD_TIMESPEC &&
> +                       (spec.ts.kern_old_its.it_interval.tv_sec ||
> +                        spec.ts.kern_old_its.it_interval.tv_nsec ||
> +                        spec.ts.kern_old_its.it_value.tv_sec ||
> +                        spec.ts.kern_old_its.it_value.tv_nsec)) ||
> +                   (spec.type == TST_KERN_TIMESPEC &&
> +                       (spec.ts.kern_its.it_interval.tv_sec ||
> +                        spec.ts.kern_its.it_interval.tv_nsec ||
> +                        spec.ts.kern_its.it_value.tv_sec ||
> +                        spec.ts.kern_its.it_value.tv_nsec)))
> +                       tst_res(TFAIL, "timespec should have been zeroed");

Indeed that's what I had in mind, can we please abstract this properly
as well? I guess that we can add helpers such as tst_its_interval_sec()
tst_its_inverval_nsec, etc.

> +               else
> +                       tst_res(TPASS, "timer_gettime() Passed");
>         } else {
>                 tst_res(TFAIL | TTERRNO, "timer_gettime() Failed");
>         }
> 
> -- 
> viresh

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2020-06-25 11:07 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-22 10:51 [LTP] [PATCH V4 00/17] Syscalls: Add support for time64 variants Viresh Kumar
2020-05-22 10:51 ` [LTP] [PATCH V4 01/17] syscalls/timer_gettime: Add support for time64 tests Viresh Kumar
2020-06-09 12:32   ` Li Wang
2020-06-10  3:26     ` Viresh Kumar
2020-06-10  3:34   ` [LTP] [PATCH V5 " Viresh Kumar
2020-06-10  3:38   ` [LTP] [PATCH V6 " Viresh Kumar
2020-06-24 14:23     ` Cyril Hrubis
2020-06-25  9:50       ` Viresh Kumar
2020-06-25 11:07         ` Cyril Hrubis [this message]
2020-06-25 11:10           ` Viresh Kumar
2020-06-25 11:13             ` Cyril Hrubis
2020-05-22 10:51 ` [LTP] [PATCH V4 02/17] syscalls/timer_settime: " Viresh Kumar
2020-06-24 14:30   ` Cyril Hrubis
2020-06-25  9:56     ` Viresh Kumar
2020-06-25 11:12       ` Cyril Hrubis
2020-05-22 10:51 ` [LTP] [PATCH V4 03/17] syscalls/timerfd: " Viresh Kumar
2020-05-22 10:51 ` [LTP] [PATCH V4 04/17] syscalls/sched_rr_get_interval: " Viresh Kumar
2020-05-22 10:51 ` [LTP] [PATCH V4 05/17] syscalls/futex: Merge futex_wait_bitset tests Viresh Kumar
2020-05-22 10:51 ` [LTP] [PATCH V4 06/17] syscalls/futex: Add support for time64 tests Viresh Kumar
2020-06-09 12:55   ` Li Wang
2020-06-10  3:35   ` [LTP] [PATCH V5 " Viresh Kumar
2020-05-22 10:51 ` [LTP] [PATCH V4 07/17] syscalls/io_pgetevents: " Viresh Kumar
2020-05-22 10:51 ` [LTP] [PATCH V4 08/17] syscalls/sigwaitinfo: Migrate to new test framework Viresh Kumar
2020-05-22 10:51 ` [LTP] [PATCH V4 09/17] syscalls/rt_sigtimedwait: Add support for time64 tests Viresh Kumar
2020-05-22 10:51 ` [LTP] [PATCH V4 10/17] syscalls/mq_timed{send|receive}: " Viresh Kumar
2020-05-22 10:51 ` [LTP] [PATCH V4 11/17] syscalls/recvmmsg: " Viresh Kumar
2020-05-22 10:51 ` [LTP] [PATCH V4 12/17] syscalls/ppoll: " Viresh Kumar
2020-05-22 10:51 ` [LTP] [PATCH V4 13/17] syscalls/select6: " Viresh Kumar
2020-05-22 10:51 ` [LTP] [PATCH V4 14/17] syscalls/semop: Migrate to new test framework Viresh Kumar
2020-05-22 10:51 ` [LTP] [PATCH V4 15/17] syscalls/semtimedop: Add support for semtimedop and its time64 version Viresh Kumar
2020-05-22 10:51 ` [LTP] [PATCH V4 16/17] syscalls/utimensat: Migrate to new test framework Viresh Kumar
2020-05-22 10:51 ` [LTP] [PATCH V4 17/17] syscalls/utimensat: Add support for time64 tests Viresh Kumar

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=20200625110751.GB23637@yuki.lan \
    --to=chrubis@suse.cz \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.