RTEMS | aarch64/arm: Make _CPU_Fatal_halt() BSP-specific (!28)

[Gedare Bloom (@gedare)]

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20240710/fd171063/attachment.htm>