RTEMS source structure

[Joel Sherrill]

"Victor V. Vengerov" wrote:
> 
> 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.

If that is needed, it would be better as the rest of the
IDE/ATA code has been moved to libchip (see below).

> 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.

In merging the last IDE patch, I had to move some parts from
libblock/src
to libchip/ide.  They would not build in a pure-multilib/CPUkit setting.

This is what is currently in the two directories.

bash-2.05$ ls current/cpukit/libblock/src
bdbuf.c  blkdev.c  CVS  diskdevs.c  ide_part_table.c  ramdisk.c
bash-2.05$ ls current/c/src/libchip/ide/
ata.c  ata_internal.h  ide_controller.c  ide_ctrl.h     Makefile.am
ata.h  CVS             ide_ctrl_cfg.h    ide_ctrl_io.h  Makefile.in


> >c/src/libchip
> >
> >My impression of the following two are as follows.
> >cpukit/libcsupport - provides basic RTEMS and OS functionalities

Really your description matches cpukit/score.

cpukit/libcsupport is the OS system calls from a POSIX/UNIX perspective
(section 2 man pages) and required newlib glue.

> >cpukit/rtems - uses the above to provide RTEMS API
> >is that correct ?

Yep.  cpukit/rtems == RTEMS Classic API.

> >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 ???

It is at the same level logically as the RTEMS API but both are built
on top of score/

> >am I correct in saying cpukit/sapi is simply a set of "shared processor
> >modules" among all target CPUs ?

Yes that is a correct statement but it isn't the end all of the
explanation.
It is those API features which are well beyond any standardization
attempt
we have seen in the RTOS world.  How do you initialize and shutdown a
system.

> >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.

RTEMS API is based up RTEID (Real-Time Executive Interface Definition)
which morphed into ORKID (Open Real-time Kernel Interface Definition)
before folding into POSIX threads/real-time working groups.  RTEID
is essentially the pSOS+m API and was an effort by Motorola and Software
Components Group (original pSOS+ company) to standardize their API.

Very good description of the layering from there.  I just wanted to 
add history.

> 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.

Dead on the money correct.

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

ANd not definable based up compiler multilib settings.  Knowing you
are on a 68000 or CPU32 core is not enough to know the peripherals
on the CPU.

> 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.

Right.  It is largely non-threading ANSI C library and POSIX 
services as well as newlib glue.

FWIW a new version of the Development Environment Guide is in CVS.
It would be interesting to hear feedback on it.

> 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)

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985