RTEMS | Draft: confdefs: Improve CONFIGURE_MAXIMUM_PRIORITY (!436)

[Chris Johns (@chris)]

Chris Johns commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/436#note_120299


Yes I could add `CONFIGURE_MAXIMUM_PRIORITY` with `255` to resolve the problem in my application. Why should I? The code base that brought this problem to my attention was originally developed on RTEMS 4 on a Zynq and the user wants to use SMP?

My investigation to understand the problem has raised a number of concerns and I do not think this MR is the place to discuss them. The MR may in the end be a suitable resolution however we need to first have a wider discussion.

I believe the changing of the priority range is a **_regression_** with respect to the historical user interfaces until we decide otherwise. I do not remember a specific discussion about the range changing in regards to this context, the effects, other possible options or how we convey this to users? I believe a number of separate changes over a period of time have come together to bring about my concerns. Each piece on its own makes sense and seems reasonable however together there are issues. We need to respect our users, existing code and the need to make things as simple as possible simple configurations.

I am also using this specific example to bring about a policy change. API changes needs to be announced and a specific discussion happen for the change to accepted. Approval and merging of changes in isolation does not mean an acceptable of change. If this happens we need to discuss the impact, look at solutions I have labelled this MR API however I wonder if we need an `api-change` label as well?

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/436#note_120299
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/20250227/8a1c1f54/attachment.htm>