[PATCH 06/13] config: Add rtems_malloc_task_stack_for_idle()

Tue Oct 4 13:41:15 UTC 2022

On 04/10/2022 15:21, Joel Sherrill wrote:
> On Tue, Oct 4, 2022 at 12:40 AM Sebastian Huber 
> <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at embedded-brains.de>> wrote:
> 
>     On 30/09/2022 23:39, Chris Johns wrote:
>      > On 30/9/2022 7:21 pm, Sebastian Huber wrote:
>      >> Update #4524.
>      >> ---
>      >>   cpukit/doxygen/appl-config.h                | 13 +++++
>      >>   cpukit/include/rtems/rtems/config.h         | 29 +++++++++-
>      >>   cpukit/include/rtems/score/interr.h         |  1 +
>      >>   cpukit/sapi/src/interrtext.c                |  3 +-
>      >>   cpukit/sapi/src/malloctaskstackforidle.c    | 59
>     +++++++++++++++++++++
>      >>   spec/build/cpukit/librtemscpu.yml           |  1 +
>      >>   spec/build/testsuites/sptests/grp.yml       |  2 +
>      >>   spec/build/testsuites/sptests/spfatal36.yml | 19 +++++++
>      >>   testsuites/sptests/spfatal36/init.c         | 52
>     ++++++++++++++++++
>      >>   testsuites/sptests/spfatal36/spfatal36.doc  | 11 ++++
>      >>   testsuites/sptests/spinternalerror02/init.c |  2 +-
>      >>   testsuites/sptests/sptls04/init.c           |  2 +
>      >>   12 files changed, 191 insertions(+), 3 deletions(-)
>      >>   create mode 100644 cpukit/sapi/src/malloctaskstackforidle.c
>      >>   create mode 100644 spec/build/testsuites/sptests/spfatal36.yml
>      >>   create mode 100644 testsuites/sptests/spfatal36/init.c
>      >>   create mode 100644 testsuites/sptests/spfatal36/spfatal36.doc
>      >>
>      >> diff --git a/cpukit/doxygen/appl-config.h
>     b/cpukit/doxygen/appl-config.h
>      >> index aa6dbae648..ee647dc961 100644
>      >> --- a/cpukit/doxygen/appl-config.h
>      >> +++ b/cpukit/doxygen/appl-config.h
>      >> @@ -4842,6 +4842,19 @@
>      >>    * configuration options.  It is assumed that any memory
>     allocated for the
>      >>    * stack of an IDLE task will not be from the RTEMS Workspace
>     or the memory
>      >>    * statically allocated by default.
>      >> + *
>      >> + * For applications with a thread-local storage size which is
>     completely
>      >> + * unknown at the time the application configuration is
>     defined, RTEMS provides
>      >> + * an IDLE task stack allocator which uses rtems_malloc().
>      >
>      > I thought the TLS size was static and set by the linker? Has this
>     changed?
> 
>     No, this didn't change.
> 
>      >
>      > I am confused about the relationship between an unknown TLS size
>     and IDLE task?
>      > And the relationship of the TLS size and stack size?
> 
>     Currently, the IDLE task storage area is statically allocated. The size
>     of this area is defined by CONFIGURE_IDLE_TASK_STACK_SIZE. So, this
>     configuration option doesn't directly specify the IDLE task stack size.
>     This size covers also the TLS area.
> 
> 
> Thanks for speaking up Chris. I also don't like the idea that something that
> has said and meant IDLE stack size was getting other items lumped into it.
> 
> 
>      >
>      >> * * The size of the
>      >> + * allocated thread storage area is the sum of stack size
>     defined by the
>      >> + * #CONFIGURE_IDLE_TASK_STACK_SIZE configuration option and the
>     actual
>      >> + * thread-local storage size of the application.
>      >
>      > The label CONFIGURE_IDLE_TASK_STACK_SIZE provides no insight into
>     it being
>      > effected by the TLS size.
>      >
>      >> * * Define this configuration
>      >> + * option to ``rtems_malloc_task_stack_for_idle`` to use this
>     allocator.  If
>      >> + * the memory allocation fails, then the system terminates with the
>      >> + * INTERNAL_ERROR_CORE fatal source and the
>      >> + * INTERNAL_ERROR_NO_MEMORY_FOR_IDLE_TASK_STACK fatal code
>     during system
>      >> + * initialization.
>      >> + * @endparblock
>      >
>      > I am confused about the how and why I would use this change?
> 
>     With the statically allocated storage area for the IDLE task you
>     need at
>     least an estimate of the size if you define the application
>     configuration. If you can't estimate it, then one option is to simply
>     allocate it dynamically.
> 
>     Maybe a better approach is to allocate the IDLE task storage from the
>     workspace by default and use the CONFIGURE_IDLE_TASK_STACK_SIZE really
>     for the stack size and not the complete storage area. We could add a
>     new
>     configuration option (for example CONFIGURE_IDLE_TASK_STORAGE_SIZE) to
>     enable the static allocation.
> 
> 
> 
> CONFIGURE_IDLE_TASK_STORAGE_SIZE could default to the size of stack size
> plus other items but it seems over complicated. Just have IDLE stack 
> size and the other
> area for other items.
> 
> I don't know when IDLE task storage size was introduced but it has been 
> a long
> time ago. Changing the semantics of it seems quite wrong.

Ok, I will send a v2 of the patch which:

* Changes the default IDLE task storage allocation to the workspace.  It 
will use CONFIGURE_IDLE_TASK_STACK_SIZE and this size will define the 
stack size.

* Adds a new option CONFIGURE_IDLE_TASK_STORAGE_SIZE which will change 
the IDLE task storage allocation to a statically allocated area which 
will contain the task stack and the thread-local storage area.

* Adds a new option CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE which ensures 
that the IDLE task stack size has at least this size.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/