Gedare Bloom gedare at rtems.org
Sat Sep 12 05:03:21 UTC 2020

On Fri, Sep 11, 2020 at 5:31 PM Chris Johns <chrisj at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

More information about the devel mailing list