Test for clock_nanosleep with CLOCK_MONOTONIC (# 3890)

[Utkarsh Rai]

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?

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/d316b79c/attachment-0001.html>