Gedare Bloom commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/28#note_109006 I'm not that happy with the user experience that they can configure `BSP_FATAL_RESET` as disabled and still have the CPU port/BSP cause a reset. It would be a surprising bug. A "Fatal_Halt" that results in a board reset by default is also surprising. Overall, this change increases the number of surprises that a user will face. I understand that it is desirable to improve coverage, but I'm not convinced the cost is worth it here. Honestly, I don't see how to provide a "Fatal Halt" condition that is testable, while using a "Reset" to handle fatal errors. Maybe this patch should go the other way around, and `#ifdef` out the `_CPU_Fatal_halt()` functionality if a BSP reset is defined? I am generally not in favor about the placement of `_CPU_Xxx` inside of BSP, but would be willing to overlook it. I do appreciate the documentation update. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/28#note_109006 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
