jMax IRCAM - Centre Georges Pompidou

System Services



Hardware related services

This module provide a number of abstraction to access low level hardware related functionalities in a platform independent way; note that this do no include I/O, that is covered by the device architecture, in the runtime layer.

The area covered by this module include:

Scheduling and memory locking

Setting high priority for FTS when running in real time mode, locking virtual memory in physical memory to avoid swapping, possibly interaction with the SMP programming model of the underlaying OS; the work is usually done during system startup.

Floating Point Exception Handling

Abstractions to access floating point enabling/disabling and handling in an hardware/OS independent way.

Configuration

The platform.h include a few constant defined to help configure the system, at compile time, for different platforms.

The module include a file for each supported platform.

Related Files:

  • hw.h
  • gnuhw.c
  • sgihw.c
  • solaris2hw.c
  • platform.h

Memory Allocation

This module provide a basic set of memory allocation functions; standard system malloc/free functions are substituted by equivalent ones (fts_malloc/fts_free) to give a way to intercept and trace memory allocation in debug.
To reduce the space and time overhead of the standard malloc for small blocks, fts provide the heap and the block mechanism. See the Kernel Reference Manual for details and the API.

The block mechanism is based on the use of a set of heaps of different sizes; all the heap of the same size share the free block list, to reduce memory fragmentation; note that anyway this method is not optimal in term of memory locality.

In order to debug memory corruption problems with heap analysis tools, like Purify, you may want to remap all the FTS memory allocation functions to the standard system malloc/free; this can be done by uncommenting the #define HELP_PURIFY line of code that you will find at the beginning of the mem.c file.

This module provide also a very primitive memory check functionality, trying to detect simple case of memory corruption; this can enabled by uncommenting the #include "smem.h" at the beginning of the mem.c file; enabling memory check will radically slow down the system, expecially during patch loading, so it is usefull only in debug situations; if a memory corruption problem is found, a segmentation fault is immediately generated, so that the situation can be analized using a debugger.

Related Files:

  • mem.c
  • mem.h
  • smem.c
  • smem.h

Modules

A module, in the fts meaning, is a code organizational unit; a module have a start up function, a restart function and a shutdown functions; the rest of the FTS code, i.e. all the code that do not belong to the sys layer, is organized as a set of modules, including all the FST object libraries.

Modules can either be statically linked and initialized during system startup (like all the kernel modules) or dynamically linked; the sys layer can use the system dynamic loader to load modules at run time.

The module init function is called either at system startup, for statically linked time, or at loading time; the shutdown function is called just before system shutdown; the restart function should clean up the module, and bring it in the same state as after the loading; currently, is never called, but a system reset functionality (warm boot) is planned.

All the user libraries must be organized as modules, provide a fts_module_t structure which respect the module naming convention: the structure should be a non static variable named name_module, where name is the name of the module.

This layer provide a C API to access module loading and installing; module loading is then exported to the user environment by means of an UCS command (see the tiles layer).

Related Files:

  • modules.c
  • modules.h

Status

The sys layer provide a simple type to represent functions return status; the type is just a structure including a string description of the error; this type is used in the FTS kernel and in some object related function to return error values.

Related Files:

  • status.h

Version

Provide one or more set of #defines that define the current FTS version; it is automatically generated by the release handling script.

Related Files:

  • version.h

Welcome

Since statically linked modules are initialized before the connection with the user interface exists, modules init functions cannot call any kind of print/post function; in order to allow a module to print a startup message to the console, the sys layer define the welcome abstraction; a welcome is a message a module can register, and that will be shown when the user interface is ready to accept console messages.

Related Files:

  • welcome.c
  • welcome.h