minimum stack size was Re: #define delay(...)
osv at javad.ru
Mon Nov 13 09:55:16 UTC 2000
Gerke Kok <gerke.kok at tpa-nl.com> writes:
> Should not the stacksize be given at the start of the task in the
> create_task call? This is used in many systems and is very flexible.
> (Althoug I do know it taks more admin. for the kernel)
AFAIK, the stack size is passed to the task creation routine (at least in
native RTEMS API, don't know about POSIX one). The problem is that RTEMS task
creation routine doesn't allow to create tasks with stack smaller than
specified by the RTEMS_MINIMUM_STACK_SIZE define.
> -----Oorspronkelijk bericht-----
> Van: Joel Sherrill [mailto:joel.sherrill at OARcorp.com]
> Verzonden: Friday, November 10, 2000 18:59
> Aan: Sergei Organov
> CC: rtems-users at OARcorp.com
> Onderwerp: minimum stack size was Re: #define delay(...)
> Sergei Organov wrote:
> > > This name is a relic from the very EARLIEST days of RTEMS.
> > "EARLIEST days of RTEMS" recalled me that I've had another suggestion for
> > RTEMS. What if in addition to one lower stack size limit
> > RTEMS_MINIMUM_STACK_SIZE we introduce another constant,
> > let's say, RTEMS_ABSOLUTE_MINIMUM_STACK_SIZE that will be indeed close to
> > absolute minimum for given architecture. All the test programs (as well as
> > applications) then will continue to use the former constant, but RTEMS
> > will check input stack size by comparing it to the latter constant.
> > The problem with current approach is that the constant is actually too
> > (e.g., 8K on PowerPC) and as RTEMS core doesn't allow to create tasks with
> > smaller stacks, light-weight tasks take too much memory for stack. Using
> > suggestion ABSOLUTE_MINIMUM will be somewhere around 1K for PowerPC thus
> > saving 7K for every light-weight task. Or did situation change in this
> > since RTEMS-3.6?
> Hasn't changed but it has irritated me and I have something in mind.
> What about minimum stack size defaulting to the current
> value and the user being able to specify their own default size as an
> override. What do you think of this?
> I have also toyed with the idea of moving the fields in CPU table
> that are shared by all ports to the regular configuration table.
> > BR,
> > Sergei Organov.
> Joel Sherrill, Ph.D. Director of Research & Development
> joel at OARcorp.com On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available (256) 722-9985
More information about the users