An extension set is defined as a set of routines which are invoked at each of the critical system events at which user extension routines are invoked. Together a set of these routines typically perform a specific functionality such as performance monitoring or debugger support. RTEMS is informed of the entry points which constitute an extension set via the following record:
type Extensions_Table is record Task_Create : RTEMS.Task_Create_Extension; Task_Start : RTEMS.Task_Start_Extension; Task_Restart : RTEMS.Task_Restart_Extension; Task_Delete : RTEMS.Task_Delete_Extension; Task_Switch : RTEMS.Task_Switch_Extension; Task_Post_Switch : RTEMS.Task_Post_Switch_Extension; Task_Begin : RTEMS.Task_Begin_Extension; Task_Exitted : RTEMS.Task_Exitted_Extension; Fatal : RTEMS.Fatal_Error_Extension; end record;
RTEMS allows the user to have multiple extension sets active at the same time. First, a single static extension set may be defined as the application's User Extension Table which is included as part of the Configuration Table. This extension set is active for the entire life of the system and may not be deleted. This extension set is especially important because it is the only way the application can provided a FATAL error extension which is invoked if RTEMS fails during the initialize_executive directive. The static extension set is optional and may be configured as NULL if no static extension set is required.
Second, the user can install dynamic extensions using
the rtems.extension_create
directive. These extensions are RTEMS
objects in that they have a name, an ID, and can be dynamically
created and deleted. In contrast to the static extension set,
these extensions can only be created and installed after the
initialize_executive directive successfully completes execution.
Dynamic extensions are useful for encapsulating the
functionality of an extension set. For example, the application
could use extensions to manage a special coprocessor, do
performance monitoring, and to do stack bounds checking. Each
of these extension sets could be written and installed
independently of the others.
All user extensions are optional and RTEMS places no naming restrictions on the user. The user extension entry points are copied into an internal RTEMS structure. This means the user does not need to keep the table after creating it, and changing the handler entry points dynamically in a table once created has no effect. Creating a table local to a function can save space in space limited applications.
Extension switches do not effect the context switch overhead if no switch handler is installed.
Copyright © 1988-2007OAR Corporation