[Bug 1635] Refactor Priority bit map handling

[bugzilla-daemon at rtems.org]

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

--- Comment #7 from Gedare <giddyup44 at yahoo.com> 2010-07-28 08:43:42 CDT ---
(In reply to comment #6)
> Does this patch change anything substantial?  I see only various renames.  Why
> are these renames necessary?  I don't see the pattern.  In particular the
> change from _Priority_Handler_initialization() to
> _Priority_Handler_initialization_bit_map() is questionable since all handlers
> follow the previous name pattern.  Likewise for Priority_Information to
> Priority_Information_bit_map.
> 
Yes, this patch is simply renaming. This is necessary because I plan to
introduce a scheduler implementation without any priority management, and also
a scheduler that uses tree-based priority management.  The current
implementation of the Priority Handler assumes implicitly that bit-maps are
used to determine which priority levels have ready tasks available.  This patch
makes that assumption explicit.  I guess this patch isn't strictly necessary
right now, but I am trying to merge the code I have that has low impact.

Joel also pointed out the naming issue. I will be changing the function names
to better organize them, for example with
_Priority_Bit_map_Handler_initialization(), and Priority_Bit_map_Information.

> I am against to introduce new *.inl files.  I don't know why we have all these
> *.inl files.  I guess this is some relict of an old hack.
If a handler uses inline routines, the *.inl files are one-to-one with the
handler's *.h file.  The inline routines are not exported to the application
level, which I guess is why they are separated from the header files.  .

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