BSP submitting requirements

[Chris Johns]

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.diaz at 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.huber at 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