On 31/07/2018 04:03, Sebastian Huber wrote: > > rtems_status_code rtems_task_priority_posix_to_classic(rtems_id scheduler_id, > int posix_priority, rtems_task_priority *classic_priority) > rtems_status_code rtems_task_priority_classic_to_posix(rtems_id scheduler_id, > rtems_task_priority classic_priority, int *posix_priority)
What if this is: rtems_task_priority_mapping (scheduler_id, from_api, to_api, in_pri, &out_pri); And we enumerate the APIs that support mapping? I prefer less calls being added and smaller names. We also have the emerging "RTEMS-X", local-storage, no-object or what-ever it is called API. In relation to the internal or core priorities being exposed, I actually have no problem if those could be obtained. Dependence on them can documented as "free to change at any time" but an API to get such a value may help in tracing contexts where we need to see the trace in terms of the core priorities. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel