Sebastian Huber started a new discussion on spec/acfg/if/stack-checker-reporter.yml: https://gitlab.rtems.org/rtems/prequal/rtems-central/-/merge_requests/4#note_111292 > + ``CONFIGURE_STACK_CHECKER_REPORTER`` can be set to one of the follwoing > + reporters: > + > + * ``rtems_stack_checker_reporter_quiet``: The default quiet reporter that > + only calls the fatal error handler in case of stack overflow. > + > + * ``rtems_stack_checker_reporter_print_details``: The detiled reporter > that > + provides information about the task that caused the stack overflow. > + > + * Or a user-defined reporting function. > + > + A typical reporter should follow the signature below with these > parameters: > + > + ```c > + void rtems_stack_checker_reporter( > + const Thread_Control *running, The API should not expose implementation details such as Thread_Control. Is `running` the executing thread? If yes, is should be named `executing`. Using a function with two parameters makes it difficult to change/improve it in the future. Maybe we could extend the existing `rtems_stack_checker_info` structure to include also the pattern areas and their state. Then pass it as a single parameter. -- View it on GitLab: https://gitlab.rtems.org/rtems/prequal/rtems-central/-/merge_requests/4#note_111292 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs
