#define delay(...)

[Sergei Organov]

Joel Sherrill <joel.sherrill at OARcorp.com> writes:
> Sergei Organov wrote:
> > 
> > Hello,
> > 
> > I've found that most of RTEMS 'bsp.h' files define macro 'delay', like this:
> > 
> > #define delay( _microseconds )\
> > ...
> > 
> > I believe 'delay' is too general to be a name of exported macro because it
> > likely to create conflicts with usage of the name in user code. In fact it did
> > create conflict in my case. Don't you think it's better to rename the macro
> > (e.g., to 'rtems_delay')?
> 
> Even better would be rtems_bsp_delay() to indicate that it is a BSP
> provided
> routine.   FWIW.. this routine is supposed to be a microsecond level
> spin
> delay.
> 
> 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 core
will check input stack size by comparing it to the latter constant.

The problem with current approach is that the constant is actually too large
(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 my
suggestion ABSOLUTE_MINIMUM will be somewhere around 1K for PowerPC thus
saving 7K for every light-weight task. Or did situation change in this area
since RTEMS-3.6?

BR,
Sergei Organov.