On 2014-06-13 17:29, Joel Sherrill wrote:
On 6/12/2014 8:06 AM, Sebastian Huber wrote:
On 2014-06-11 21:18, jennifer wrote:
+++ b/testsuites/smptests/smpschedsem01/smpschedsem01.doc
@@ -0,0 +1,11 @@
+This file describes the directives and concepts tested by this test set.
+
+test set name: smpschedaffinity01
+
+directives:
+
+ - XXX
+
+concepts:
+
+ - Ensure that affinity is honored at task start.
This file doesn't match with the subject. What is the purpose of this test?
If you want to test the change priority operation, then you may have a look at:
http://git.rtems.org/rtems/tree/testsuites/smptests/smpscheduler03/init.c
Why are you testing at the Score API level?
Tests should not be written which violate the public APIs unless there
is a VERY VERY good reason.
It is very difficult to test these state changes with a test using only the
public API. For the ready to scheduled state changes you need interrupts.
Only one state change is impossible in a real system, that is ready to
scheduled with prepend.
Again, this is another one of those unwritten rules but when you do
that, there is no proof that the method, argument combination,
or mode is needed by any API. For example, if you have code in the
Score which can only be accessed from POSIX and you test directly,
there is no way from the coverage data to tell that the method
is not needed when POSIX is disabled. Or that the method isn't
needed at all.
The only normal paths to _Thread_Change_priority with
prepend_it set to FALSE is through the core mutex. Which means
you need to either initialize a mutex the correct way or
surrender one restoring your priority.
Code is either needed in support of an API or serves no purpose.
Unit testing at the Score level makes unnecessary code harder to
find and violates the API boundary.
For the code coverage metric this test is worthless, but for a correctness test
of the implementation it is valuable. I think we need at least two sets of
tests, one that targets code coverage and one that simply test the correctness
of the basic implementation.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
