Thank you for the clarification, I will proceed accordingly. On Thu, Apr 9, 2020 at 10:36 PM Joel Sherrill <j...@rtems.org> wrote:
> > > 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
