API to convert priorities to/from POSIX from/to Classic?

[Joel Sherrill]

Solves the easiest part of the problem.

Full mapping for scheduling attributes between the two APIs is a different
matter.

--joel

On Mon, Jul 30, 2018 at 1:58 PM, Gedare Bloom <gedare at rtems.org> wrote:

> I can get on board with extending the classic API to include
> converters to/from posix priorities directly.. this makes good enough
> sense to me.
>
> On Mon, Jul 30, 2018 at 2:30 PM, Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> > On Mon, Jul 30, 2018 at 1:03 PM, Sebastian Huber
> > <sebastian.huber at embedded-brains.de> wrote:
> >>
> >> ----- Am 30. Jul 2018 um 18:29 schrieb Gedare Bloom gedare at rtems.org:
> >>
> >> > On Mon, Jul 30, 2018 at 11:23 AM, Joel Sherrill <joel at rtems.org>
> wrote:
> >> >>
> >> >>
> >> >> On Mon, Jul 30, 2018 at 7:43 AM, Sebastian Huber
> >> >> <sebastian.huber at embedded-brains.de> wrote:
> >> >>>
> >> >>> On 30/07/18 14:25, Joel Sherrill wrote:
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> On Mon, Jul 30, 2018, 6:26 AM Sebastian Huber
> >> >>>> <sebastian.huber at embedded-brains.de
> >> >>>> <mailto:sebastian.huber at embedded-brains.de>> wrote:
> >> >>>>
> >> >>>>     Hello,
> >> >>>>
> >> >>>>     is there a standard API to convert priorities to/from POSIX
> >> >>>> from/to
> >> >>>>     Classic? If not, I think we should add something.
> >> >>>>
> >> >>>>
> >> >>>> There is not a public API for this.  There are some internal
> helpers
> >> >>>
> >> >>>
> >> >>> Do you know the name of the helpers?
> >> >>
> >> >>
> >> >> I was thinking of the _RTEMS_Priority_To_Core,
> >> >> _RTEMS_Priority_From_core, and the similar
> >> >> POSIX helper.
> >> >>
> >> >> These are probably useful to some users. No real
> >> >> cost to applications that don't use them.
> >> >>
> >> >
> >> > These convert between the core kernel notion of priority and the api.
> >> > I see no problem to add some wrappers like
> >> >
> >> > rtems_posix_priority_to_core() and from_core(), and
> >> > rtems_priority_to_core(), and from_core().
> >> >
> >> > A user then could convert between the two APIs themselves if they
> need,
> >> > like
> >> > rtems_priority_from_core( rtems_posix_priority_to_core(p) );
> >> >
> >> > I would not introduce any conversion between classic and posix
> >> > priorities directly. It is violation of the API independence.
> >>
> >> I don't like the idea to expose an internal priority thing to the user.
> We
> >> would have to create an API representation of something
> scheduler-specific.
> >>
> >> I propose:
> >>
> >> scheduler_id == RTEMS_SELF == scheduler of executing thread
> >>
> >> 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)
> >
> >
> >
> > For the simplest case of current scheduler, what does a call look like?
> >
> > And honestly, I wouldn't be opposed to something like this if it has a
> use
> > case:
> >
> > rtems_task_priority rtems_get_self_priority(void)
> >
> > The Classic API (e.g. RTEID/ORKID) reflects a period in API programming
> > where
> > you wanted a small API set. Accessors were not separated out. Methods to
> > simply get some information or state of an object were not included.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180730/202a790f/attachment-0002.html>