On Fri, Sep 11, 2020 at 5:31 PM Chris Johns <chr...@rtems.org> 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 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. > > > 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 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. > There might be something interesting there to solve from an academic perspective. I should circle back to this thought when it's not almost midnight on Friday. This seems like a good problem since it's hard to know for sure the user intent vs what they configured. Some kind of machine learning / anomaly detection might be useful here.
> Chris > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
