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

2022-10-06 Thread Chris Johns 
On 7/10/2022 3:25 pm, Sebastian Huber wrote:
> On 07.10.22 04:57, Chris Johns wrote:
>> On 6/10/2022 6:35 pm, Sebastian Huber wrote:
>>> On 06/10/2022 00:13, Chris Johns wrote:
 Will the IDLE TLS size be based on the
 CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE if it is not zero? This effects
 libdl once it supports loading TLS based code.
>>>
>>> Currently, only the actual TLS size is used. We would have to change
>>> _TLS_Get_allocation_size() to use the maximum if it is non-zero.
>>
>> It would be good to get this sorted and in before a push is made on libdl to
>> support TLS. I think the newlib change will make TLS a visible issue in 
>> libdl in
>> 6 so it needs to be fixed.
> 
> I checked _TLS_Get_allocation_size(). It already returns the maximum size if 
> it
> is configured:
> 
>     if ( _Thread_Maximum_TLS_size != 0 ) {
>   if ( allocation_size <= _Thread_Maximum_TLS_size ) {
>     _Assert( _Thread_Maximum_TLS_size % CPU_STACK_ALIGNMENT == 0 );
>     allocation_size = _Thread_Maximum_TLS_size;
>   } else {
>     _Internal_error( INTERNAL_ERROR_TOO_LARGE_TLS_SIZE );
>   }
>     }
> 

Thanks. I also checked and found this. It looks good to me.

Is the end of the TLS BSS area the start of the TSL space available for libdl to
use?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2022-10-06 Thread Sebastian Huber 



On 07.10.22 04:57, Chris Johns wrote:

On 6/10/2022 6:35 pm, Sebastian Huber wrote:

On 06/10/2022 00:13, Chris Johns wrote:

Will the IDLE TLS size be based on the
CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE if it is not zero? This effects
libdl once it supports loading TLS based code.


Currently, only the actual TLS size is used. We would have to change
_TLS_Get_allocation_size() to use the maximum if it is non-zero.


It would be good to get this sorted and in before a push is made on libdl to
support TLS. I think the newlib change will make TLS a visible issue in libdl in
6 so it needs to be fixed.


I checked _TLS_Get_allocation_size(). It already returns the maximum 
size if it is configured:


if ( _Thread_Maximum_TLS_size != 0 ) {
  if ( allocation_size <= _Thread_Maximum_TLS_size ) {
_Assert( _Thread_Maximum_TLS_size % CPU_STACK_ALIGNMENT == 0 );
allocation_size = _Thread_Maximum_TLS_size;
  } else {
_Internal_error( INTERNAL_ERROR_TOO_LARGE_TLS_SIZE );
  }
}

--
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

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

2022-10-06 Thread Chris Johns 
On 6/10/2022 6:35 pm, Sebastian Huber wrote:
> On 06/10/2022 00:13, Chris Johns wrote:
>> Will the IDLE TLS size be based on the
>> CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE if it is not zero? This effects
>> libdl once it supports loading TLS based code.
> 
> Currently, only the actual TLS size is used. We would have to change
> _TLS_Get_allocation_size() to use the maximum if it is non-zero.

It would be good to get this sorted and in before a push is made on libdl to
support TLS. I think the newlib change will make TLS a visible issue in libdl in
6 so it needs to be fixed.

Chris

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2022-10-06 Thread Sebastian Huber 

On 06/10/2022 00:13, Chris Johns wrote:

In this patch you discuss applications with "very dynamic thread-local storage
size"? I have no idea what this means and under what conditions such an app is
created. Could you please explain this?

A scenario is a bigger organization in which one department deals with the basic
RTEMS and platform support and another department develops the application
(without knowing much about RTEMS). The platform is a 64-bit processor with lots
of RAM. The application is a high performance SMP development using modern
software frameworks which use TLS.

If libdl is put aside, would the same mechanics used to size the TLS area for
any score thread be the same for IDLE?


The only other score thread is the MPCI thread. I haven't looked at this 
one yet.





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

Can you please provide a use case for these variables showing what is being
solved and when a user would need them?

With a statically allocated IDLE task storage area you need a lower bound for
the stack size. This is missing right now. Currently, if you have a TLS size
which is larger than CONFIGURE_IDLE_TASK_STACK_SIZE, then you have a memory
corruption during system initialization.

Ah OK. Does this mean the static allocation cannot take into account the size of
the static TLS area?


The static allocation needs to take the potential TLS area into account. 
However, the actual TLS area size could be larger than expected.





With the new CONFIGURE_IDLE_TASK_STORAGE_SIZE option we could also use
CONFIGURE_IDLE_TASK_STACK_SIZE to ensure this minimum stack size. I will adjust
the next patch to not introduce CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE.

OK


The IDLE stack size was used on architectures where the interrupt stack was on
the executing task's stack. We have been able to move away from that model to
having a separate interrupt stack. As a result the stack usage for IDLE is
deterministic because the code makes no calls and is little more than a loop. As
a result the default IDLE stack size should be OK for all users expect those
adding their own IDLE thread?

There are some calls to reach the loop, for example the thread begin extensions
and the thread switch extensions.

So this is a side effect of switching of newlib to TLS variables?


The use of TLS objects in Newlib makes this issue more visible.




Next proposal:


* Change 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.

* Add 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.

* Use CONFIGURE_IDLE_TASK_STACK_SIZE which ensures that the IDLE task stack size
has at least this size in case the statically allocated area is used.

With this change you don't have to worry about the TLS size in the default
configuration. If you enable the static allocation, then you don't get undefined
behaviour if your actual TLS size exceeds the configured limits.

Sounds good. Thanks for taking the time to explain the change.

Will the IDLE TLS size be based on the
CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE if it is not zero? This effects
libdl once it supports loading TLS based code.


Currently, only the actual TLS size is used. We would have to change 
_TLS_Get_allocation_size() to use the maximum if it is non-zero.




[ while looking at the doco ... ]

Should CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE be under General System
Configuration because it applies to all threads?


Makes sense, I moved the option.

--
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

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

2022-10-05 Thread Chris Johns 
On 5/10/2022 4:00 pm, Sebastian Huber wrote:
> On 04/10/2022 23:21, Chris Johns wrote:
>> On 5/10/2022 12:41 am, Sebastian Huber wrote:
>>> On 04/10/2022 15:21, Joel Sherrill wrote:
 On Tue, Oct 4, 2022 at 12:40 AM Sebastian Huber
 >>> > 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

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

2022-10-04 Thread Sebastian Huber 

On 04/10/2022 23:21, Chris Johns wrote:

On 5/10/2022 12:41 am, Sebastian Huber wrote:

On 04/10/2022 15:21, Joel Sherrill wrote:

On Tue, Oct 4, 2022 at 12:40 AM Sebastian Huber
mailto: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.


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


I suggest we get a clearer understand of what is happening first.


* Changes the default IDLE task storage allocation to the workspace.  It

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

2022-10-04 Thread Chris Johns 
On 5/10/2022 12:41 am, Sebastian Huber wrote:
> On 04/10/2022 15:21, Joel Sherrill wrote:
>> On Tue, Oct 4, 2022 at 12:40 AM Sebastian Huber
>> > > 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

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

2022-10-04 Thread Sebastian Huber 

On 04/10/2022 15:21, Joel Sherrill wrote:
On Tue, Oct 4, 2022 at 12:40 AM Sebastian Huber 
> 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

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

2022-10-04 Thread Joel Sherrill 
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

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

2022-10-03 Thread Sebastian Huber 

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.





* * 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.


--
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

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

2022-09-30 Thread Chris Johns 
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?

I am confused about the relationship between an unknown TLS size and IDLE task?
And the relationship of the TLS size and stack size?

> * * 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?

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2022-09-30 Thread Sebastian Huber 
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().  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.  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
  */
 #define CONFIGURE_TASK_STACK_ALLOCATOR_FOR_IDLE
 
diff --git a/cpukit/include/rtems/rtems/config.h 
b/cpukit/include/rtems/rtems/config.h
index 3d813c55b6..7c7f1e3aa3 100644
--- a/cpukit/include/rtems/rtems/config.h
+++ b/cpukit/include/rtems/rtems/config.h
@@ -10,7 +10,7 @@
  */
 
 /*
- * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ * Copyright (C) 2020, 2022 embedded brains GmbH 
(http://www.embedded-brains.de)
  * Copyright (C) 1989, 2008 On-Line Applications Research Corporation (OAR)
  *
  * Redistribution and use in source and binary forms, with or without
@@ -58,6 +58,7 @@
 #define _RTEMS_RTEMS_CONFIG_H
 
 #include 
+#include 
 #include 
 #include 
 
@@ -328,6 +329,32 @@ uint32_t rtems_configuration_get_maximum_tasks( void );
  */
 uint32_t rtems_configuration_get_maximum_timers( void );
 
+/* Generated from spec:/rtems/config/if/malloc-task-stack-for-idle */
+
+/**
+ * @ingroup RTEMSAPIConfig
+ *
+ * @brief Allocates a thread storage area for an IDLE task using
+ *   rtems_malloc().
+ *
+ * @param unused is an unused parameter.
+ *
+ * @param[in,out] size is the pointer to an size_t object.  At function entry,
+ *   the object contains the size of the thread storage area not accounting for
+ *   the thread-local storage size.  When the directive call is successful, the
+ *   size of the allocated thread storage area will be stored in this object.
+ *
+ * The thread storage size is determined by the #CONFIGURE_IDLE_TASK_STACK_SIZE
+ * application configuration option and the actual thread-local storage size of
+ * the application.  The memory is allocated using rtems_malloc().
+ *
+ * @return Returns the begin address of the allocated thread storage area.
+ *
+ * @par Notes
+ * See #CONFIGURE_TASK_STACK_ALLOCATOR_FOR_IDLE.
+ */
+void *rtems_malloc_task_stack_for_idle( uint32_t unused, size_t *size );
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/cpukit/include/rtems/score/interr.h 
b/cpukit/include/rtems/score/interr.h
index ae4966d6d8..6e6926ab61 100644
--- a/cpukit/include/rtems/score/interr.h
+++ b/cpukit/include/rtems/score/interr.h
@@ -229,6 +229,7 @@ typedef enum {
   INTERNAL_ERROR_NO_MEMORY_FOR_PER_CPU_DATA = 40,
   INTERNAL_ERROR_TOO_LARGE_TLS_SIZE = 41,
   INTERNAL_ERROR_RTEMS_INIT_TASK_CONSTRUCT_FAILED = 42,
+  INTERNAL_ERROR_NO_MEMORY_FOR_IDLE_TASK_STACK = 43
 } Internal_errors_Core_list;
 
 typedef CPU_Uint32ptr Internal_errors_t;
diff --git a/cpukit/sapi/src/interrtext.c b/cpukit/sapi/src/interrtext.c
index 383cc5bc0a..005cdc4508 100644
--- a/cpukit/sapi/src/interrtext.c
+++ b/cpukit/sapi/src/interrtext.c
@@ -83,7 +83,8 @@ static const char *const internal_error_text[] = {
   "INTERNAL_ERROR_ARC4RANDOM_GETENTROPY_FAIL",
   "INTERNAL_ERROR_NO_MEMORY_FOR_PER_CPU_DATA",
   "INTERNAL_ERROR_TOO_LARGE_TLS_SIZE",
-