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 very conscious >>> decision to allow it. >> Sebastian did not like the idea and accepted that so not at the moment. The >> solution is better config management and we will monitor how this goes. > My point is that an API enable and the now implemented > maximum_thread_local_storage_size both lead to run-time errors of the new > directive. However, the maximum_thread_local_storage_size ensures that you > don't > have an unexpected task storage configuration, for example a too small thread > stack size which could be difficult to debug. >> >>> 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 agree. This one needs a little more than the others. > > I updated the ticket description: > > https://devel.rtems.org/ticket/3959
I have added some updates for you to review. >>> 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. >> I am concerned we have really difficult to debug issues that appear to be >> bugs >> but are weakness in the configuration. > I think it is now quite safe. If something is wrongly configured, then you get > an error status (RTEMS_INVALID_SIZE). You don't get problems like a suddenly > too > small thread stack with a potential overflow. Yes I think we have suitable balance. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
