Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

2020-09-14 Thread Joel Sherrill
On Sun, Sep 13, 2020 at 6:05 PM Chris Johns wrote: > On 13/9/20 6:31 pm, Sebastian Huber wrote: > > On 12/09/2020 01:31, Chris Johns wrote: > >> On 12/9/20 12:10 am, Joel Sherrill wrote: > >> [...] > >>> Did we decide if there had to be an explicit configure > >>> option to even use this API? Chr

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

2020-09-13 Thread Chris Johns
On 13/9/20 6:31 pm, Sebastian Huber wrote: > On 12/09/2020 01:31, Chris Johns wrote: >> On 12/9/20 12:10 am, Joel Sherrill wrote: >> [...] >>> Did we decide if there had to be an explicit configure >>> option to even use this API? Chris and I discussed this >>> as an idea to force a user to make a

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

2020-09-13 Thread Sebastian Huber
On 12/09/2020 01:31, Chris Johns wrote: On 12/9/20 12:10 am, Joel Sherrill wrote: [...] Did we decide if there had to be an explicit configure option to even use this API? Chris and I discussed this as an idea to force a user to make a very conscious decision to allow it. Sebastian did not lik

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

2020-09-11 Thread Gedare Bloom
On Fri, Sep 11, 2020 at 5:31 PM Chris Johns wrote: > > On 12/9/20 12:10 am, Joel Sherrill wrote: > > This thread has wandered a lot but I just wanted to say > > I am OK with the direction this is going. I think we have > > made this about as safe and easy to use as possible. > > Yes. > > > Did we

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

2020-09-11 Thread Chris Johns
On 12/9/20 12:10 am, Joel Sherrill wrote: > This thread has wandered a lot but I just wanted to say  > I am OK with the direction this is going.  I think we have > made this about as safe and easy to use as possible. Yes. > Did we decide if there had to be an explicit configure  > option to even

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

2020-09-11 Thread Joel Sherrill
This thread has wandered a lot but I just wanted to say I am OK with the direction this is going. I think we have made this about as safe and easy to use as possible. Did we decide if there had to be an explicit configure option to even use this API? Chris and I discussed this as an idea to force

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

2020-09-11 Thread Chris Johns
On 11/9/20 5:07 pm, Sebastian Huber wrote: > On 11/09/2020 09:00, Chris Johns wrote: > >> Considering this some more I wonder if the TCB >> should have a flag set to say the allocator was "static". This could be >> reported >> by the `task` command and may be even via an API call. Users could the

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

2020-09-11 Thread Sebastian Huber
On 11/09/2020 09:00, Chris Johns wrote: Considering this some more I wonder if the TCB should have a flag set to say the allocator was "static". This could be reported by the `task` command and may be even via an API call. Users could then inspect and check their system. We don't need a flag f

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

2020-09-11 Thread Chris Johns
On 11/9/20 12:40 am, Joel Sherrill wrote: > How is the user/system integrator supposed to figure out the size of the TLS? > It > is not known until the application is linked and thus varies based on the > total > set of code linked. Yes the user links the application and inspects the executable

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

2020-09-10 Thread Sebastian Huber
Hello Joel, this configuration option is a by product of the discussions related to the proposed rtems_task_create_from_config() directive. I addresses an issue with thread-local storage in dynamically linked objects. Since I work currently in the same code area, it is easier if I try to imple

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

2020-09-10 Thread Joel Sherrill
How is the user/system integrator supposed to figure out the size of the TLS? It is not known until the application is linked and thus varies based on the total set of code linked. As far as I can tell, this makes this type of task creation unsuitable for use in libraries where the end system is u