Gedare Bloom gedare at
Wed Dec 7 22:01:54 UTC 2011

On Wed, Dec 7, 2011 at 4:52 PM, Joel Sherrill <joel.sherrill at> 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.
My concern is that this one configure macro propagates into other
macros that need not be so dependent.  The valid use of it is that it
gets assigned into rtems_minimum_stack_size which is used when a task
is created to ensure the requested stack size meets this minimum.

One problem I see is that when a user creates tasks if they specify
RTEMS_MINIMUM_STACK_SIZE as the stack size parameter, then they are
actually asking for the CPU_STACK_MINIMUM_SIZE and we currently ignore

I have used CONFIGURE_EXTRA_TASK_STACKS when I have tasks that need an
oversized stack, and then I will pass the stack size explicitly. All
this macro does is to ensure the workspace has enough space for what I
plan to request, and does not affect any other stack calculations
(like idle, init, or interrupt stack size).

>> 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.
Well, I don't see how the constructors are accounted for.

>> 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.
> 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.
Yes we can ignore the BSP boot stack.

> Your network example would impact the init task.
>> Chris
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at
> --
> Joel Sherrill, Ph.D.             Director of Research&  Development
> joel.sherrill at        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>   Support Available             (256) 722-9985

More information about the devel mailing list