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