On 06/28/2013 08:58 AM, Wanlong Gao wrote:
> On 06/27/2013 08:20 PM, [email protected] wrote:
>> 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?
> 
> OK, if we want to keep it here, I think add a list of expected errnos
> is better. Any other ideas?

Disagree myself, since the errnos here is useless for testing, so expect 
failure with
unspecified errno will be better.

Thanks,
Wanlong Gao


> 
> Thanks,
> Wanlong Gao
> 
>>
>> And btw, the Linux implementation is POSIXly correct as the ability to
>> set these clocks is left open to implementation.
>>
> 
> 
> ------------------------------------------------------------------------------
> 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
> 


------------------------------------------------------------------------------
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

Reply via email to