eCosTM Reference Manual
Prev | Chapter 2. A tour of the kernel sources | Next

# Kernel source files

The kernel source directory (`Cygnus/eCos/packages/kernel/v1_2_1/src`) is divided into a number of sub-directories each containing the source files for a particular kernel subsystem. These sources divide into two classes: those that are generic to all configurations, and those that are specific to a particular configuration.

## Sched subdirectory

`sched/sched.cxx`

  This contains the implementation of the base scheduler classes. The most important function here is `Cyg_Scheduler::unlock_inner()` which runs DSRs and performs any rescheduling and thread switching.

`sched/bitmap.cxx`

  This contains the bitmap scheduler implementation. It represents each runnable thread with a bit in a bitmap. Each thread must have a unique priority and there is a strict upper limit on the number of threads allowed.

`sched/mlqueue.cxx`

  This contains the multi-level queue scheduler implementation. It implements a number of thread priorities and is capable of timeslicing between threads at the same priority. This scheduler can also support priority inheritance.

`sched/lottery.cxx`

  This contains the lottery scheduler implementation. This implements a CPU share scheduler based on threads holding a number of lottery tickets. At the start of each time quantum, a random number is generated and the thread holding the matching ticket is scheduled. Compensation tickets and ticket donation allow fair sharing for I/O bound threads and an equivalent mechanism to priority inheritance.

  > Note: This scheduler is experimental, and is meant to test the behavior of other parts of the kernel with a non-orthodox scheduler. It is not meant to be used for real applications. It is currently under development and is incomplete.

## Common subdirectory

`common/thread.cxx`

  This implements the basic thread classes. The functions in this file implement the basic thread controls to sleep and wake threads, change priorities and delay and time-out. Also defined here is the idle thread that runs when there is nothing else to do.

`common/clock.cxx`

  This implements the counter, clock and alarm functions. Also defined here is the system real-time clock that is used to drive timeslicing, delays and time-outs.

`common/kapi.cxx`

  This implements a C API to the basic kernel functions.

`common/memcpy.c`, `common/memset.c`

  Standard ANSI memcpy and memset operations; these are here because the compiler may invoke them for structure operations regardless of the presence of a C library.

## Interrupt subdirectory

`intr/intr.cxx`

  This implements the Interrupt class. Most of this code is concerned with posting and calling DSRs. The remainder of the interrupt handling code is machine specific and is in `hal_intr.cxx` in the HAL directory.

## Synchronization subdirectory

`sync/mutex.cxx`

  This contains the implementation of mutexes and condition variables. Mutexes can optionally be configured to use a priority inheritance mechanism supplied by the scheduler.

`sync/cnt_sem.cxx`

  This contains the implementation of counting semaphores.

`sync/cnt_sem2.cxx`

  This contains the alternate implementation of counting semaphores which implements precise µITRON semantics.

`sync/bin_sem.cxx`

  This contains the implementation of binary semaphores.

`sync/mbox.cxx`

  This contains wrapper functions for a message box of (void *) values. The implementation is the template defined in `include/mboxt.hxx` which `include/mboxt.inl` implements in turn. Message boxes exist in the kernel specifically to support µITRON compatibility.

`sync/flag.cxx`

  This contains the implementation of flag objects. Flag objects exist in the kernel specifically to support µITRON compatibility.

## Memory management subdirectory

`mem/memfixed.cxx`

  This contains the wrapper functions for a fixed-block allocation memory manager. The actual implementation is in two parts: `include/mfiximpl.hxx` implements the fixed-block memory management algorithms, and template `include/mempoolt.hxx` implements thread safety and waiting for memory management classes. These are combined in `memfixed.cxx`. Memory pools exist in the kernel specifically to support µITRON compatibility.

`mem/memvar.cxx`

  This contains the wrapper functions for a variable-block allocation memory manager. The actual implementation is in two parts: `include/mvarimpl.hxx` implements the variable-block memory management algorithms, and template `include/mempoolt.hxx` implements thread safety and waiting for memory management classes. These are combined in `memvar.cxx`. Memory pools exist in the kernel specifically to support µITRON compatibility.

## Instrumentation subdirectory

`instrmnt/meminst.cxx`

  This contains an implementation of the instrumentation mechanism that stores instrumentation records in a circular buffer in memory. The size of this buffer is configurable. The instrumentation flags mechanism allows the generation of instrumentation records to be controlled on a per-record basis. The header file `cyg/kernel/instrmnt.h` contains macros to generate instrumentation records in various places, and may be configured to only generate instrumentation records where required.

`instrmnt/nullinst.cxx`

  This contains an implementation of the instrumentation mechanism that does nothing. By substituting its object file `nullinst.o` for `meminst.o` in a build, the instrumentation mechanism may be disabled without recompiling.

## Trace subdirectory

`trace/simple.cxx`

  This contains an implementation of the trace and assert mechanisms that output textual messages via a set of externally defined functions. These are currently supplied by the code in `trace/diag.c` but may be supplied by a device driver in the future.

`trace/fancy.cxx`

  This contains a (fancier) implementation of the trace and assert mechanisms that output textual messages via a set of externally defined functions. These are currently supplied by the code in `trace/diag.c` but may be supplied by a device driver in the future.

  This more elaborate view was introduced mainly to validate the trace and assertion macros during development.

`trace/null.cxx`

  This contains an implementation of the trace and assert mechanisms that do nothing. By substituting its object file `null.o` for `simple.o` in a build, the trace mechanisms may be disabled without recompiling.

`trace/diag.c`

  This contains a number of diagnostic routines that use the HAL supplied diagnostic output mechanism to format and print strings and numbers. There is currently no formatted output.

`trace/tcdiag.c`

  This contains an implementation of the testing internal API which uses the kernel"s diagnostic routines to perform output.

## Sload subdirectory

This contains the sources of a simple S-Record loader that may be used in a ROM for various microprocessor development boards to download code via a serial port.

## HAL source files

The HAL is divided into architecture- and platform-specific files. For each architecture supported, there is an `arch` directory, containing files generic to that architecture, and a `platform` directory, containing files specific to each platform supported.

Amongst the architectures supported are: the PowerPC, the Tx39 and the MN10300. To find the code corresponding to each architecture, substitute “powerpc”, “mips” and “mn10300”, respectively, for “ARCH” in the following file descriptions. Similarly substitute the appropriate platform name representing your development board for “PLATFORM”.

## Architecture files

`ARCH/arch/v1_2_1/include/basetype.h`

  This file is used to define the base architecture configuration such as endianness and word size.

`ARCH/arch/v1_2_1/include/hal_arch.h`

  This file contains macros that implement various architecture-specific functions. The most important macros here are the thread context initialization and switch macros that are used to implement multithreading.

`ARCH/arch/v1_2_1/include/hal_intr.h`

  This file contains the HAL support for interrupt management and clock support.

`ARCH/arch/v1_2_1/include/hal_io.h`

  This file contains the HAL support for accessing hardware registers. It provides a portable API that allows more generic device drivers to be written.

`ARCH/arch/v1_2_1/include/hal_cache.h`

  This file contains macros to control any caches that may be present.

`ARCH/arch/v1_2_1/include/ARCH_stub.h`

  This file contains architectural information for a GDB stub, such as the register layout in a GDB packet.

`ARCH/arch/v1_2_1/src/vectors.S`

  This is an assembly code file that contains the code to handle interrupt and exception vectors. Since system reset can also be considered an exception, this is handled here also. Interrupts are currently handled by placing a stub routine in the hardware vector which calls a Vector Service Routine via an indirection table. There is a API to allow user-defined VSRs to be installed. The default VSR reads the interrupt controller registers and decodes the interrupt source into an offset into a further table of interrupt service routines. It also handles interrupt cleanup, which may result in the execution of deferred service routines (DSRs) and the preemption of the current thread.

`ARCH/arch/v1_2_1/src/context.S`

  If present, this is an assembly code file that contains the code to support thread contexts. The routines to switch between various contexts, as well as initialize a thread context may be present in this file.

`ARCH/arch/v1_2_1/src/hal_misc.c`

  This file contains the implementation of various miscellaneous HAL routines that are needed by the kernel or C++ runtime.

`ARCH/arch/v1_2_1/src/ARCH_stub.c`

  This file contains the architectural part of a GDB stub. This deals with CPU-specific details of the stub, such as the setting of breakpoints and translating exception data into signals that GDB understands.

`ARCH/arch/v1_2_1/src/ARCH.ld`

  This file is the linker script. During preprocessing it includes linker script fragments that define the memory layout.

## Platform files

`ARCH/PLATFORM/v1_2_1/include/hal_diag.h`

  This file contains the definitions of macros that support the HAL diagnostic output mechanism.

`ARCH/PLATFORM/v1_2_1/include/plf_stub.h`

  This file contains a set of macros that allow the common GDB stub code to access the platform-specific minimal serial driver functions.

`ARCH/PLATFORM/v1_2_1/src/hal_diag.c`

  This file contain the implementation of the HAL diagnostic output mechanism.

`ARCH/PLATFORM/v1_2_1/src/plf_stub.c`

  This file contains a minimal serial driver for the target platform that is used by the GDB stub.

`ARCH/PLATFORM/v1_2_1/src/PLATFORM.S`

  This is an assembler file that contains any platform-specific code. It often contains platform initialization code called from vectors.S.

Prev | Home | Next
A tour of the kernel sources | Up | Kernel APIs