Naming of Fixed-Priority Scheduler (Now is Rate-Monotonic Scheduler)

[Kuan Hsun Chen]

Hello all,

One question about the naming of rate-monotonic scheduler.
I believe is not the serious problem in the past most likely.
However, when RTEMS becomes more powerful and popular, I guess this
question will emerge.

We all know that Rate-monotonic (RM) is a well-known optimal scheduling
under fixed-priority assignment when the task model is based on implicit
deadline (I guess in the past most of real-time applications using RTEMS
follow this design rationale).
When we further consider constrained-deadline task model,
Deadline-monotonic (DM) is the optimal rather than RM. In fact the users
can decide the priorites of tasks themselves, and our kernel does not
provide any standard scheduling to automatically help the user sort/assign
the priorities of tasks even RM that using the periods of tasks to
determine the priorities.

This rate_monotonic "prefix" so far takes place everywhere in the manual,
source code, or user applications. However, since RTEMS does not really
provide the service about the automatic priority assignment yet, this will
confuse the following users when they start to implement their applications
or follow the manual. In my opinion, we should *rename* this prefix to
fixed-priority or something else neutral.

Furthermore, we can *really* integrate some well-known priority assignments
and scheduling policy into the kernel to provide automatic priority
assignment but also keep the flexibility of scheduler (like add one more
parameter to enable/disable the flexibility). This kind of design can be
found in LitmusRT as well.

I know it must be a long-term perspective, but I believe it is good to
achieve it for future usage.

Cheers,
Kuan-Hsun

-- 
M.Sc. Kuan-Hsun Chen

TU Dortmund
Department of Computer Science 12
Design Automation of Embedded Systems
Otto-Hahn-Strasse 16, Room 102

44227 Dortmund
Germany

Phone:  *+49 231 755 6124 <%2B49%20231%20755%206124>*
Mail:   kuan-hsun.chen at tu-dortmund.de <kuan-hsun.chen at tu-dortmund.de>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20160922/503f6138/attachment.html>