[PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

[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 a user to make a very conscious
decision to allow it.

There does need to be documentation on the allocation
strategies, when to use, limitations, and particularly the
use of rtems-exeinfo to get the TLS size. This is one case
for sure where an RTEMS Tool needs explicit mention in
both the API and configure option sections.

I have had flashbacks to how often we got used to get questions
about why adding a sleep(1) in the middle of hello world locked
up. Then we added an option to say "does not need clock
driver" and the user questions stopped.  I would rather be a
bit aggressive on setup and avoid this for tasks with statically
allocated resources.

--joel

On Fri, Sep 11, 2020 at 2:08 AM Chris Johns <chrisj at rtems.org> wrote:

> 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 then
> inspect
> >> and check their system.
> >
> > We don't need a flag for this. We can just use:
> >
> > the_thread->Start.stack_free == _Stack_Free
>
> Nice.
>
> > Adding this information to the task command could be helpful if we find
> a way to
> > display it without needing to much space on the line.
>
> They are making wider screens these days ... ;)
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200911/6df5430f/attachment-0001.html>