CONFIGURE_MINIMUM_TASK_STACK_SIZE

[Joel Sherrill]

On 12/07/2011 04:01 PM, Chris Johns wrote:
> On 8/12/11 8:52 AM, Joel Sherrill wrote:
>> On 12/07/2011 03:48 PM, Chris Johns wrote:
>>> On 8/12/11 5:39 AM, Gedare Bloom wrote:
>>>> CONFIGURE_MINIMUM_TASK_STACK_SIZE can be defined by an application to
>>>> increase the size of all of its task stacks (and implicitly the init
>>>> task and interrupt stacks). It seems wrong/wasteful to propagate the
>>>> user-defined CONFIGURE_MINIMUM_TASK_STACK_SIZE to both the idle and
>>>> interrupt stacks, perhaps these should be CPU_STACK_MINIMUM_SIZE
>>>> unless defined by the user explicitly?
>>>>
>>> What does a minimum stack size mean ?
>>>
>>> I have always assumed this setting provides enough stack so the tests
>>> could run across a number of platforms. I do not use it in any
>>> applications I develop.
>> It is more of a "enough to run hello" type of definition. If you
>> have less than this, then you are likely in trouble. Many tests
>> do 2-3 times minimum for their task stacks.
>>> Yes it would seem to be wasteful for idle. The init task is tricky
>>> because static constructors run on it.
>> Nope. Static constructors run in the first init task.
> Do you mean the BSP context before multi-tasking and after RTEMS has
> initialised ?
>
No. I really mean the first user task to execute. C++ constructors
can print, block etc and you can't do that before the first context
switch.
>>> If you use the BSP init code in
>>> bsp/shared where your entry point is main the network stack maybe
>>> started. There is also the implicit stack in the BSP context that starts
>>> RTEMS. These all require the user's involvement to make sure they are
>>> big enough.
>> The stack the BSP starts on is very special and has to be
>> established outside RTEMS. We can't do much about that
>> at this level.
> Is this the first init stack ?
I am missing the question...

BSP startup stack
   .. first context switch.. Init task stack


>
>> With that said, many BSPs specify where this stack is in
>> the linker script and have a variable like StackSize that
>> you can -D on the ld command to increase.
>>
> At the risk of polluting the thread ...
>
> I have to ask about using linker scripts this way. I tend to find they
> can get abused and over complicate things, eg some bsps has flags in
> bsp_spec files. What do we gain over just setting values in C code and
> using -D on the cc ?
>
It can be done either way.  Memory layout (to me) is easier to
read when the linker script has it.  It has no run-time overhead
and we would have to work this into the math of carving up
memory like we do for heap and work space.  BUT .. it would
have to match the assembly start code. Most of the time, the
linker script variables are just used by start.S anyway.

The linker script way is really clean and simple for this.

>> Your network example would impact the init task.
> Which one ?
An init task starting the network would likely need more
stack space.  That's all I meant.
>
> Chris


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985