<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 4, 2022 at 12:40 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 30/09/2022 23:39, Chris Johns wrote:<br>
> On 30/9/2022 7:21 pm, Sebastian Huber wrote:<br>
>> Update #4524.<br>
>> ---<br>
>> cpukit/doxygen/appl-config.h | 13 +++++<br>
>> cpukit/include/rtems/rtems/config.h | 29 +++++++++-<br>
>> cpukit/include/rtems/score/interr.h | 1 +<br>
>> cpukit/sapi/src/interrtext.c | 3 +-<br>
>> cpukit/sapi/src/malloctaskstackforidle.c | 59 +++++++++++++++++++++<br>
>> spec/build/cpukit/librtemscpu.yml | 1 +<br>
>> spec/build/testsuites/sptests/grp.yml | 2 +<br>
>> spec/build/testsuites/sptests/spfatal36.yml | 19 +++++++<br>
>> testsuites/sptests/spfatal36/init.c | 52 ++++++++++++++++++<br>
>> testsuites/sptests/spfatal36/spfatal36.doc | 11 ++++<br>
>> testsuites/sptests/spinternalerror02/init.c | 2 +-<br>
>> testsuites/sptests/sptls04/init.c | 2 +<br>
>> 12 files changed, 191 insertions(+), 3 deletions(-)<br>
>> create mode 100644 cpukit/sapi/src/malloctaskstackforidle.c<br>
>> create mode 100644 spec/build/testsuites/sptests/spfatal36.yml<br>
>> create mode 100644 testsuites/sptests/spfatal36/init.c<br>
>> create mode 100644 testsuites/sptests/spfatal36/spfatal36.doc<br>
>><br>
>> diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h<br>
>> index aa6dbae648..ee647dc961 100644<br>
>> --- a/cpukit/doxygen/appl-config.h<br>
>> +++ b/cpukit/doxygen/appl-config.h<br>
>> @@ -4842,6 +4842,19 @@<br>
>> * configuration options. It is assumed that any memory allocated for the<br>
>> * stack of an IDLE task will not be from the RTEMS Workspace or the memory<br>
>> * statically allocated by default.<br>
>> + *<br>
>> + * For applications with a thread-local storage size which is completely<br>
>> + * unknown at the time the application configuration is defined, RTEMS provides<br>
>> + * an IDLE task stack allocator which uses rtems_malloc().<br>
> <br>
> I thought the TLS size was static and set by the linker? Has this changed?<br>
<br>
No, this didn't change.<br>
<br>
> <br>
> I am confused about the relationship between an unknown TLS size and IDLE task?<br>
> And the relationship of the TLS size and stack size?<br>
<br>
Currently, the IDLE task storage area is statically allocated. The size <br>
of this area is defined by CONFIGURE_IDLE_TASK_STACK_SIZE. So, this <br>
configuration option doesn't directly specify the IDLE task stack size. <br>
This size covers also the TLS area.<br></blockquote><div><br></div><div>Thanks for speaking up Chris. I also don't like the idea that something that</div><div>has said and meant IDLE stack size was getting other items lumped into it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> <br>
>> * * The size of the<br>
>> + * allocated thread storage area is the sum of stack size defined by the<br>
>> + * #CONFIGURE_IDLE_TASK_STACK_SIZE configuration option and the actual<br>
>> + * thread-local storage size of the application.<br>
> <br>
> The label CONFIGURE_IDLE_TASK_STACK_SIZE provides no insight into it being<br>
> effected by the TLS size.<br>
> <br>
>> * * Define this configuration<br>
>> + * option to ``rtems_malloc_task_stack_for_idle`` to use this allocator. If<br>
>> + * the memory allocation fails, then the system terminates with the<br>
>> + * INTERNAL_ERROR_CORE fatal source and the<br>
>> + * INTERNAL_ERROR_NO_MEMORY_FOR_IDLE_TASK_STACK fatal code during system<br>
>> + * initialization.<br>
>> + * @endparblock<br>
> <br>
> I am confused about the how and why I would use this change?<br>
<br>
With the statically allocated storage area for the IDLE task you need at <br>
least an estimate of the size if you define the application <br>
configuration. If you can't estimate it, then one option is to simply <br>
allocate it dynamically.<br>
<br>
Maybe a better approach is to allocate the IDLE task storage from the <br>
workspace by default and use the CONFIGURE_IDLE_TASK_STACK_SIZE really <br>
for the stack size and not the complete storage area. We could add a new <br>
configuration option (for example CONFIGURE_IDLE_TASK_STORAGE_SIZE) to <br>
enable the static allocation.<br></blockquote><div><br></div><br class="gmail-Apple-interchange-newline"><div>CONFIGURE_IDLE_TASK_STORAGE_SIZE could default to the size of stack size</div><div>plus other items but it seems over complicated. Just have IDLE stack size and the other</div><div>area for other items.</div><div><br></div><div>I don't know when IDLE task storage size was introduced but it has been a long</div><div>time ago. Changing the semantics of it seems quite wrong.<br><br></div><div>--joel</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
embedded brains GmbH<br>
Herr Sebastian HUBER<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
phone: +49-89-18 94 741 - 16<br>
fax: +49-89-18 94 741 - 08<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>