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 <ged...@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 <j...@rtems.org> wrote: > > > > > > On Mon, Jul 30, 2018 at 1:03 PM, Sebastian Huber > > <sebastian.hu...@embedded-brains.de> wrote: > >> > >> ----- Am 30. Jul 2018 um 18:29 schrieb Gedare Bloom ged...@rtems.org: > >> > >> > On Mon, Jul 30, 2018 at 11:23 AM, Joel Sherrill <j...@rtems.org> > wrote: > >> >> > >> >> > >> >> On Mon, Jul 30, 2018 at 7:43 AM, Sebastian Huber > >> >> <sebastian.hu...@embedded-brains.de> wrote: > >> >>> > >> >>> On 30/07/18 14:25, Joel Sherrill wrote: > >> >>>> > >> >>>> > >> >>>> > >> >>>> On Mon, Jul 30, 2018, 6:26 AM Sebastian Huber > >> >>>> <sebastian.hu...@embedded-brains.de > >> >>>> <mailto:sebastian.hu...@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. > > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
