CONFIGURE_MINIMUM_TASK_STACK_SIZE

[Chris Johns]

On 8/12/11 9:37 AM, Joel Sherrill wrote:
> 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.

Ah ok I think are talking about the same thing. I was referring to the 
same one. I do not create any more init tasks.

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

Agreed. I suspect we are talking at cross purposes about the same thing.

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

Ok. I was more interested in a technical reason I may have been missing. 
I have been looking over the bsp_specs files thinking about how to 
remove them. They have all sorts of little differences and I was 
wondering if a more standard approach would be a good thing.

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