On Thu, Apr 9, 2020 at 11:56 AM Utkarsh Rai <utkarsh.ra...@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.hu...@embedded-brains.de> wrote: > >> >> On 09/04/2020 15:04, Joel Sherrill wrote: >> >> On Thu, Apr 9, 2020, 7:43 AM Sebastian Huber < >> sebastian.hu...@embedded-brains.de> wrote: >> >>> On 09/04/2020 14:40, Joel Sherrill wrote: >>> >>> On Thu, Apr 9, 2020, 7:28 AM Utkarsh Rai <utkarsh.ra...@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. >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
