<div dir="ltr">Thank you for the clarification, I will proceed accordingly.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 9, 2020 at 10:36 PM Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 9, 2020 at 11:56 AM Utkarsh Rai <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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?</div></blockquote><div><br></div><div>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():</div><div><br></div><div><a href="https://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_nanosleep.html" target="_blank">https://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_nanosleep.html</a> </div><div><br></div><div>That's what psxhdr tests verify. It would make sense to add a second clock_nanosleep psxhdr test which uses the CLOCK_MONOTONIC enumeration.</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>--joel <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 9, 2020 at 6:43 PM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p><br>
</p>
<div>On 09/04/2020 15:04, Joel Sherrill
wrote:<br>
</div>
<blockquote type="cite">
<div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Apr 9, 2020, 7:43 AM
Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>On 09/04/2020 14:40, Joel Sherrill wrote:<br>
</p>
<blockquote type="cite">
<div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Apr 9,
2020, 7:28 AM Utkarsh Rai <<a href="mailto:utkarsh.rai60@gmail.com" rel="noreferrer" target="_blank">utkarsh.rai60@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Hi,
<div>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?</div>
</div>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Yes. That is the pattern.</div>
</blockquote>
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).<br>
</div>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">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. <br>
</div>
</blockquote>
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.<br>
<blockquote type="cite">
<div dir="auto"><br>
</div>
<div dir="auto">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 <br>
</div>
</blockquote>
<p>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.<br>
</p>
</div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>