Hi! > PROCESS_CPUTIME_ID and THREAD_CPUTIME_ID are not supported before > kernel 2.6.12, and changed back since 2.6.38. And they are > thought improper supported on Linux, so we just remove them > from the test of clock_settime and remain them be untested. > > Signed-off-by: Wanlong Gao <[email protected]> > --- > testcases/kernel/timers/clock_settime/clock_settime03.c | 15 --------------- > 1 file changed, 15 deletions(-) > > diff --git a/testcases/kernel/timers/clock_settime/clock_settime03.c > b/testcases/kernel/timers/clock_settime/clock_settime03.c > index a949303..3693395 100644 > --- a/testcases/kernel/timers/clock_settime/clock_settime03.c > +++ b/testcases/kernel/timers/clock_settime/clock_settime03.c > @@ -37,8 +37,6 @@ clockid_t clocks[] = { > CLOCK_REALTIME, > CLOCK_REALTIME, > CLOCK_REALTIME, > - CLOCK_PROCESS_CPUTIME_ID, > - CLOCK_THREAD_CPUTIME_ID > }; > > int testcases[] = { > @@ -49,8 +47,6 @@ int testcases[] = { > EINVAL, /* Invalid timespec */ > EINVAL, /* NSEC_PER_SEC + 1 */ > EPERM, /* non-root user */ > - 0, > - 0, > };
What is the exact issue here? I suspect that the problem is that the errno values are not stable between kernel versions but AFAIK the PROCESS_CPUTIME clocks were never setable but that shouldn't stop us from trying to set them and expect failure. So what about we change the code to expect failure with unspecified errno or add a list of expected errnos broad enough to cover all kernel versions? And btw, the Linux implementation is POSIXly correct as the ability to set these clocks is left open to implementation. -- Cyril Hrubis [email protected] ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
