RTEMS source structure

Victor V. Vengerov vvv at oktet.ru
Wed Apr 9 18:42:30 UTC 2003


Salman wrote:

>I'm a bit confused regarding some areas of the RTEMS source structure.
>Could someone give me a hand on this?
>I cant understand cpukit/libblock properly,
>IDE seems to be split between the following two,
>what modules/functionalities are supported by each section?
This directory, in my understanding, should contains
device-independent part of disk I/O sub-system.
Basically, it should contain hardware-independent
code. It may be good to rename file ide_part_table.c to
part_table.c (and header + some identifiers) because it is
actually contains no IDE-specific code.

File ide.c implements hardware-independent IDE driver.
Hardware details hidden in libchip-style controller driver
(located in c/src/libchip/ide or in specific BSP). Logically,
it may be reasonable to move it to c/src/libchip/ide,
although I'm not sure.

>My impression of the following two are as follows.
>cpukit/libcsupport - provides basic RTEMS and OS functionalities
>cpukit/rtems - uses the above to provide RTEMS API
>is that correct ?
>Is the POSIX API considered as an additional layer (sitting on top of
>RTEMS API) or does it directly interact with libcsupport, making it at
>the same level as RTEMS API ???
>am I correct in saying cpukit/sapi is simply a set of "shared processor
>modules" among all target CPUs ?
>finally, I am unable to distinguish between the following two !
>could someone explain this as well.
RTEMS implements several APIs, particulary RTEMS API (RTEAI? based),
posix, itron. In general, other APIs may be implemented in future. All these
APIs centered around score - Super Core(?). APIs is like wrappers
for  score (although actually it's more than just wrappers). score
is RTEMS internals, it is not intended for using in application code.
cpukit/rtems, cpukit/itron, cpukit/posix contains the implementation
of appropiate APIs.

In my understanding, sapi directory contains the code which implements
the system services related to initialisation, I/O, error processing which
couldn't be addressed as part of specific API. Please correct me if
I'm wrong.

c/src/lib/libcpu contains the CPU-specific code (not board specific!).

ANSI C library is not part of RTEMS. newlib (portable ANSI C
library implementation intended specifically for embedded systems)
used for this. newlib requires several hooks which should be provided
externally (it is like newlib BSP when newlib used standalone,
without RTOS; in case when newlib integrated with RTEMS, it
provides appropriate services to newlib). I beleive, libcsupport
get his name from this. Nowadays,  libcsupport includes also
implementation of posix interface related to file I/O, file system
infrastructure, termios implementation for RTEMS and so on.



Victor V. Vengerov
Ulianovskaya st., 1, office 533, St.-Petersburg 198504 Russia
phone: +7 812 4284384 (work), +7 812 9389372 (mobile), +7 812 4281653 (home)

More information about the users mailing list