On Tue, Oct 4, 2022 at 12:40 AM Sebastian Huber < sebastian.hu...@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. --joel > > -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@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/ > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel