[Bug 1636] Refactor Rate Monotonic Manager into a generic Periodic Manager

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1636

--- Comment #10 from Gedare <giddyup44 at yahoo.com> 2010-08-12 10:38:45 CDT ---
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > + If I am right, I think you rename rate_monotonic_period_XXX
> > > to rate_periodic_XXX and I can't accept that part of the patch. This
> > > would break API compatibility and although it can be argued that
> > > the rate monotonic name obscures the fundamental nature of the periodic
> > > blocking service being implemented, it is really the theoretical reason
> > > this manager exists.  So can your periodicXXX be moved to ratemonXXX and
> > > fixed?
> > > 
> > Actually I copied rtems_rate_monotonic_XXX to rtems_periodic_XXX, and turned
> > the rtems_rate_monotonic_XXX into a wrapper that simply calls the
> > rtems_periodic_XXX routine.  This maintains the existing API, while enabling
> > new applications to use the more generic Periodic routines.  I guess if this is
> > OK then I should create user documentation for the rtems_periodic_XXX API
> > routines.
> 
> What does the rtems_periodic_XXX add over the rtems_rate_monotonic_XXX?
> Is it just a name change? Is there functionality? What is the reason?
> 
> I recall the code I reviewed still had lots of code in the
> rtems_rate_monotonic_XXX services. I think you are doing
> something like this:
> 
> rtems_rate_monotonic_xXX
>   rtems_periodic_XXX
>     SCORE Period
> 
> If that's the case, I would expect the rtems_periodic_XXX layer to
> be fairly thin and the rtems_rate_monotonic_XXX to be even thinner.
> 
> I am just confused and can't judge the value of the API level
> changes properly.
> 
In the patch, you can see there is no more implementation in
rtems_rate_monotonic_XXX, all of the classic Rate Monotonic Manager API calls
are simple wrappers to the new (classic) Periodic Manager API.

I took the classic Rate Monotonic Manager, renamed it to a Periodic Manager and
separated it in two parts, one part is 'classic' and one part is 'supercore'.
The classic part is a duplication of the public API of the rate monotonic
manager, but now it is intended to be useful for any periodic task model.  The
supercore part encapsulates all of the interactions with the Thread and
Scheduler.  The reason to create a supercore object for Periodic tasks is so
that the Scheduler can make call-outs to the Periodic Manager when a job is
released or completes.  This is a lot cleaner than hacking such support into
the classic API layer.

The bottom line is that the API for rtems_rate_monotonic is unchanged, but its
implementation is entirely provided by the API layer for rtems_periodic.  The
implementation for the API layer of rtems_periodic is split between the classic
Periodic Manager and the supercore Periodic object. 

The reason to provide the new periodic API is to have cleaner naming for future
periodic task schedulers.  It makes no sense to have an EDF scheduler that uses
rtems_rate_monotonic functions to control the periodic tasks.  I felt that it
makes the most sense to use the Periodic Manager as the 'master' so that new
functionality can be added more easily without having to hack the rate
monotonic manager.  So the Rate Monotonic Manager becomes a subset of the
Periodic Manger implementation, but with its own API layer for backward
compatibility and continued ease-of-use for RM applications.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.