[GSOC]Progress Report of MMU support project
Gedare Bloom
gedare at gwmail.gwu.edu
Tue Jul 12 13:58:09 UTC 2011
On Tue, Jul 12, 2011 at 6:55 AM, Peter Dufault <dufault at hda.com> wrote:
>
> On Jul 12, 2011, at 6:11 , Sebastian Huber wrote:
>
>> What is the difference between memp and mprot? RTEMS in general uses no
>> abbreviations in its API.
>
> Since I work mostly at the POSIX interface I hadn't noticed this, but looking through cpukit/rtems/src I see there are some really long-winded names (e.g., _Message_queue_Manager_initialization()).
>
> What's the convention on CamelCase versus underscores (versus mixed Camel_Case_and_Underscores)?
>
In the supercore code (cpukit/score), the convention is
Package_name_Method_name. So the first letter of the first word of the
package (handler) is capitalized, and similarly the first letter of
the first word of the method. For example, the Message Queue handler
has a function for Manager Initialization that is named
_Message_queue_Manager_initialization. A similar convention exists for
data structures, types, and visible variables.
For code that resides in the classic API (cpukit/rtems), the
convention is all lower-case and each function is something like
rtems_package_method.
I would probably name the package Memory Protect, so in the classic
API functions would be rtems_memory_protect_xxx. If code goes in
supercore, it would be _Memory_protect_Xxx.
Also, I question about including the word "alut" in the API. If all of
the functions use an alut as argument, then it is redundant.
Differentiating with alut is useful if there are other mechanisms for
tracking access rights. But since the alut is opaque to applications,
then why should the application ever care?
> Quanming and I should have had more discussions on the mailing list to get these issues brought up earlier, I take the blame for not pushing that.
>
> Peter
> -----------------
> Peter Dufault
> HD Associates, Inc. Software and System Engineering
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>
More information about the users
mailing list