On 6/06/2014 12:24 am, Marcos Díaz wrote:
From tmtests folder the following tests used more than 3 tasks: tm02,
tm03, tm04, tm05, tm06, tm07, tm10, tm11, tm12, tm13, tm14, tm15, tm
16, tm17, tm18, tm19, tm21, tm22, tm23, tm24, tm 25, tm26, tm29.
Although we reduced the count of tasks for those tests (with the
OPERATION_COUNT macro) with stacks of 4kb there isn't room for more
than 2 or 3 tasks. With this change we could run 17 of 33 tests of
tmtests. (see times_tests file).
An interesting and welcome side effect of the change to map the
testsuite to a specific BSP's capabilities. Thanks for raising it. It
highlights a new issue that a CPU default does not meet the needs of all
users of a CPU including our own testsuite.
On Thu, Jun 5, 2014 at 10:57 AM, Marcos Díaz
<marcos.d...@tallertechnologies.com> wrote:
Not all the tests run but we achieved many more tests working with this change.
On Thu, Jun 5, 2014 at 10:54 AM, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
On 2014-06-05 15:04, Marcos Díaz wrote:
Yes, we made this patch in order to the testsuites work correctly. So
you think we should change the macro value in cpu.h and arm.h as i
proposed before?
So you can run the complete test suite with a default stack size of 1024?
I wouldn't change the default for ARM, since this can break existing
applications that rely on the 4k.
I think this new BSP specific setting makes it harder for users to know what
is going on.
The previous method of setting a default size based on the CPU is
showing its age and the patch highlights this. I agree this patch is
something new for existing users so could be seen as confusing however
is a per BSP setting any more confusing for a new user than the existing
per CPU setting ? I doubt it is as both are kind of confusing.
Since I don't have a better alternative, your patch is fine.
I agree the patch is needed. My only comment relates to the name
'BSP_MINIMUM_TASK_STACK_SIZE'. Should this be
'BSP_TESTSUITE_MAXIMUM_TASK_STACK_SIZE' to highlight this is a setting
so the BSP can execute all tests and nothing more ?
Is a better long term solution to have this setting become something
maintained as a part of the testsuite and to remove all defaults to
there and have confdefs.h raise an error if the user does not provide a
default ? I understand this adds a number of per arch settings to the
testsuite.
I consider all aspects of stack usage a system level design constraint
each user needs to carefully consider. Many variables effect stack usage
including optimisation and having a global default depend on an
arbitrary setting based on our testsuite is convenient but misleading.
For example should the CPU_STACK_MINIMUM_SIZE be the amount of stack
needed to start a task or should it include the ability to make any API
call or should it include any API call ith the maximum possible nesting
level of interrupts if task stacks are used with interrupt ? I am sure
you get the idea a CPU_STACK_MINIMUM_SIZE is always going to be ambiguous.
Chris
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
