RTEMS and Object Orientation
Joel Sherrill
joel.sherrill at OARcorp.com
Wed Mar 26 13:33:44 UTC 2008
Hi,
I noticed this in multiple emails this morning
so decided to through it out as one post rather
than half answering it in each email.
I use OO terms to explain the design and if you know how to look
at the code, you will see it.
+ Each XXX*.c and XXX.h is a class with a structure usually
named something like XXX_Control.
+ You create instances of the "class"
+ You operate on them using relatively opaque methods which
encapsulate the functionality enough so you can replace the implementation
without impacting users.
+ There is often inheritance.
+ There is often aggregation.
But ... C is not an OO language so there is no directly visible OO
in the implementation except what our implementation patterns
reflect.
Most of the time we use terms like supercore handler, API manager, and
subsystem. But in general those are "classes" in the sense that class
equal data structure plus methods encapsulated.
For example:
+ SuperCore Chain Handler
- methods like _Chain_Initialize, _Chain_Append, etc.
+ Classic API Semaphore
- rtems_semaphore_create, rtems_semaphore_obtain
+ POSIX Threads
- pthread_create, etc.
When it comes to inheritance, consider this common case
which is used by EVERY API level "entity" or "class" with an
ID.
+ (base) SuperCore Chain_Node
+ SuperCore Object_Control
+ API "objects" with IDs ... Semaphore_Control,
POSIX_threads_Control
Another pattern is aggregation (this is inverted from above)
+ Classic API Semaphore and POSIX API Semaphore
- Aggregates the following:
+ SuperCore Object_Control (see above)
+ API unique fields
+ SuperCore Core Semaphore
Doxygen support is not done for all of the APIs but it is
done for the SuperCode. I think this picture of the
SuperCode Semaphore data structure might help:
http://www.rtems.org/doxygen/score/html/structCORE__semaphore__Control.html
And this is the "class" level documentation for Core Semaphore:
http://www.rtems.org/doxygen/score/html/group__ScoreSemaphore.html
So the terminology is a bit abused due to the language
used to implement it but the design patterns are there.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users
mailing list