Test for clock_nanosleep with CLOCK_MONOTONIC (# 3890)

[Utkarsh Rai]

Thank you for the clarification, I will proceed accordingly.

On Thu, Apr 9, 2020 at 10:36 PM Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Thu, Apr 9, 2020 at 11:56 AM Utkarsh Rai <utkarsh.rai60 at gmail.com>
> wrote:
>
>> Thank you, under psxtests/psxhdrs/time we have a test for clock_nanosleep
>> for CLOCK_REALTIME, would it be a good idea to add test for CLOCK_MONOTONIC
>> under the same test, or should I add a different test using RTEMS Test
>> framework?
>>
>
> psxhdr tests are NOT functionality tests. They only test that the method
> interface is prototyped as required by POSIX. For example, the following
> says you should only have to include <time.h> and then make any call to
> clock_nanosleep():
>
>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_nanosleep.html
>
>
> That's what psxhdr tests verify. It would make sense to add a second
> clock_nanosleep psxhdr test which uses the CLOCK_MONOTONIC enumeration.
>
> You will need to add a functional test which is focused on ensuring using
> clock_nanosleep() with CLOCK_MONOTONIC works as expected. For example, does
> it delay the correct minimum length of time based on
> clock_gettime(CLOCK_MONOTONIC)? If you change CLOCK_REALTIME, does it not
> have any impact on the delay period of a CLOCK_MONOTONIC nanosleep call?
>
> The functional test should cover the code in clock_nanosleep that is
> related to CLOCK_MONOTONIC and not tested when you delay using
> CLOCK_REALTIME.
>
> --joel
>
>>
>> On Thu, Apr 9, 2020 at 6:43 PM Sebastian Huber <
>> sebastian.huber at embedded-brains.de> wrote:
>>
>>>
>>> On 09/04/2020 15:04, Joel Sherrill wrote:
>>>
>>> On Thu, Apr 9, 2020, 7:43 AM Sebastian Huber <
>>> sebastian.huber at embedded-brains.de> wrote:
>>>
>>>> On 09/04/2020 14:40, Joel Sherrill wrote:
>>>>
>>>> On Thu, Apr 9, 2020, 7:28 AM Utkarsh Rai <utkarsh.rai60 at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>> I am willing to add tests for clock_nanosleep with CLOCK_MONOTONIC.
>>>>> What is the standard way of adding test for an already present  API but
>>>>> with different configuration? For eg. should I add  'psxtmclocknanosleep04/
>>>>> 05/ 06' in the testsuite?
>>>>>
>>>>
>>>> Yes. That is the pattern.
>>>>
>>>> We should try to reduce the count of test programs since on boards with
>>>> a long reboot time, more tests programs means much more test time (compared
>>>> to the new test cases alone).
>>>>
>>>
>>> And there is the competing factor that you end up with test executables
>>> that are overly complex, do not have clean environments for many of the
>>> test cases, and are too large to fit on many target boards.
>>>
>>> The RTEMS Test framework has checks to ensure that the environment is
>>> sane before a new test case is executed. It decouples the test cases from
>>> the runner. This could be used to group test cases to test suites depending
>>> on the target memory size.
>>>
>>>
>>> I know you have seen how long the list is of tests that you can't run on
>>> many boards.  That's a bad quality attribute
>>>
>>> I don't think that tests for clock_nanosleep() will result in big
>>> executables. The executable size is mostly defined by the feature to be
>>> tested.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200409/c72a34f9/attachment-0001.html>