RTEMS source structure

[Victor V. Vengerov]

Salman,

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?
>cpukit/libblock
>
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.

>c/src/libchip
>
>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.
>cpukit/score
>c/src/lib/libcpu
>
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.

Regards,
Victor

>
>  
>


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