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