diff options
| author | Chris Johns <chrisj@rtems.org> | 2016-02-04 10:19:13 +1300 |
|---|---|---|
| committer | Amar Takhar <verm@darkbeer.org> | 2016-05-02 20:51:26 -0400 |
| commit | c9aaf3145fc84b55191c460f645985b814994d70 (patch) | |
| tree | 8fb8388ed36ed695112330376654fd780d0fcd48 /c_user | |
| parent | Clean ups. (diff) | |
| download | rtems-docs-c9aaf3145fc84b55191c460f645985b814994d70.tar.bz2 | |
Clean up
Diffstat (limited to 'c_user')
| -rw-r--r-- | c_user/configuring_a_system.rst | 1954 | ||||
| -rw-r--r-- | c_user/initialization.rst | 14 | ||||
| -rw-r--r-- | c_user/key_concepts.rst | 4 | ||||
| -rw-r--r-- | c_user/multiprocessing.rst | 667 | ||||
| -rw-r--r-- | c_user/pci_library.rst | 279 | ||||
| -rw-r--r-- | c_user/symmetric_multiprocessing_services.rst | 601 |
6 files changed, 1781 insertions, 1738 deletions
diff --git a/c_user/configuring_a_system.rst b/c_user/configuring_a_system.rst index f33df6b..b55eea1 100644 --- a/c_user/configuring_a_system.rst +++ b/c_user/configuring_a_system.rst @@ -1,3 +1,7 @@ +.. COMMENT: COPYRIGHT (c) 1988-2008. +.. COMMENT: On-Line Applications Research Corporation (OAR). +.. COMMENT: All rights reserved. + Configuring a System #################### @@ -6,106 +10,111 @@ Configuring a System Introduction ============ -RTEMS must be configured for an application. This configuration -encompasses a variety of information including the length of each clock -tick, the maximum number of each information RTEMS object that can -be created, the application initialization tasks, the task scheduling -algorithm to be used, and the device drivers in the application. - -Although this information is contained in data structures that are used -by RTEMS at system initialization time, the data structures themselves -should only rarely to be generated by hand. RTEMS provides a set of -macros system which provides a simple standard mechanism to automate -the generation of these structures. +RTEMS must be configured for an application. This configuration encompasses a +variety of information including the length of each clock tick, the maximum +number of each information RTEMS object that can be created, the application +initialization tasks, the task scheduling algorithm to be used, and the device +drivers in the application. + +Although this information is contained in data structures that are used by +RTEMS at system initialization time, the data structures themselves should only +rarely to be generated by hand. RTEMS provides a set of macros system which +provides a simple standard mechanism to automate the generation of these +structures. + .. index:: confdefs.h .. index:: confdefs.h .. index:: <rtems/confdefs.h> .. index:: <rtems/confdefs.h> -The RTEMS header file ``<rtems/confdefs.h>`` is at the core of the -automatic generation of system configuration. It is based on the idea -of setting macros which define configuration parameters of interest to -the application and defaulting or calculating all others. This variety -of macros can automatically produce all of the configuration data -required for an RTEMS application. - -Trivia: ``confdefs`` is shorthand for a *Configuration Defaults*. - -As a general rule, application developers only specify values -for the configuration parameters of interest to them. They define what -resources or features they require. In most cases, when a parameter is -not specified, it defaults to zero (0) instances, a standards compliant -value, or disabled as appropriate. For example, by default there will be -256 task priority levels but this can be lowered by the application. This -number of priority levels is required to be compliant with the RTEID/ORKID -standards upon which the Classic API is based. There are similar cases -where the default is selected to be compliant with with the POSIX standard. +The RTEMS header file ``<rtems/confdefs.h>`` is at the core of the automatic +generation of system configuration. It is based on the idea of setting macros +which define configuration parameters of interest to the application and +defaulting or calculating all others. This variety of macros can automatically +produce all of the configuration data required for an RTEMS application. + +.. sidebar: Trivia: + + The term ``confdefs`` is shorthand for a *Configuration Defaults*. + +As a general rule, application developers only specify values for the +configuration parameters of interest to them. They define what resources or +features they require. In most cases, when a parameter is not specified, it +defaults to zero (0) instances, a standards compliant value, or disabled as +appropriate. For example, by default there will be 256 task priority levels but +this can be lowered by the application. This number of priority levels is +required to be compliant with the RTEID/ORKID standards upon which the Classic +API is based. There are similar cases where the default is selected to be +compliant with with the POSIX standard. For each configuration parameter in the configuration tables, the macro -corresponding to that field is discussed. The RTEMS Maintainers -expect that all systems can be easily configured using the``<rtems/confdefs.h>`` mechanism and that using this mechanism will -avoid internal RTEMS configuration changes impacting applications. +corresponding to that field is discussed. The RTEMS Maintainers expect that all +systems can be easily configured using the ``<rtems/confdefs.h>`` mechanism and +that using this mechanism will avoid internal RTEMS configuration changes +impacting applications. .. COMMENT: === Philosophy === Default Value Selection Philosophy ================================== -The user should be aware that the defaults are intentionally set as -low as possible. By default, no application resources are configured. -The ``<rtems/confdefs.h>`` file ensures that at least one application -task or thread is configured and that at least one of the initialization -task/thread tables is configured. +The user should be aware that the defaults are intentionally set as low as +possible. By default, no application resources are configured. The +``<rtems/confdefs.h>`` file ensures that at least one application task or +thread is configured and that at least one of the initialization task/thread +tables is configured. .. COMMENT: === Sizing the RTEMS Workspace === Sizing the RTEMS Workspace ========================== -The RTEMS Workspace is a user-specified block of memory reserved for -use by RTEMS. The application should NOT modify this memory. This area -consists primarily of the RTEMS data structures whose exact size depends -upon the values specified in the Configuration Table. In addition, -task stacks and floating point context areas are dynamically allocated -from the RTEMS Workspace. - -The ``<rtems/confdefs.h>`` mechanism calculates the size of the RTEMS -Workspace automatically. It assumes that all tasks are floating point and -that all will be allocated the minimum stack space. This calculation -includes the amount of memory that will be allocated for internal use -by RTEMS. The automatic calculation may underestimate the workspace -size truly needed by the application, in which case one can use the``CONFIGURE_MEMORY_OVERHEAD`` macro to add a value to the estimate. See `Specify Memory Overhead`_ for more details. +The RTEMS Workspace is a user-specified block of memory reserved for use by +RTEMS. The application should NOT modify this memory. This area consists +primarily of the RTEMS data structures whose exact size depends upon the values +specified in the Configuration Table. In addition, task stacks and floating +point context areas are dynamically allocated from the RTEMS Workspace. + +The ``<rtems/confdefs.h>`` mechanism calculates the size of the RTEMS Workspace +automatically. It assumes that all tasks are floating point and that all will +be allocated the minimum stack space. This calculation includes the amount of +memory that will be allocated for internal use by RTEMS. The automatic +calculation may underestimate the workspace size truly needed by the +application, in which case one can use the ``CONFIGURE_MEMORY_OVERHEAD`` macro +to add a value to the estimate. See :ref:`Specify Memory Overhead` for more +details. The memory area for the RTEMS Workspace is determined by the BSP. In case the RTEMS Workspace is too large for the available memory, then a fatal run-time error occurs and the system terminates. -The file ``<rtems/confdefs.h>`` will calculate the value of the``work_space_size`` parameter of the Configuration Table. There -are many parameters the application developer can specify to -help ``<rtems/confdefs.h>`` in its calculations. Correctly -specifying the application requirements via parameters such as``CONFIGURE_EXTRA_TASK_STACKS`` and ``CONFIGURE_MAXIMUM_TASKS`` -is critical for production software. - -For each class of objects, the allocation can operate in one of two ways. -The default way has an ceiling on the maximum number of object instances -which can concurrently exist in the system. Memory for all instances of -that object class is reserved at system initialization. The second -way allocates memory for an initial number of objects and increases the -current allocation by a fixed increment when required. Both ways allocate -space from inside the RTEMS Workspace. - -See `Unlimited Objects`_ for more details about -the second way, which allows for dynamic allocation of objects and -therefore does not provide determinism. This mode is useful mostly for -when the number of objects cannot be determined ahead of time or when -porting software for which you do not know the object requirements. - -The space needed for stacks and for RTEMS objects will vary from -one version of RTEMS and from one target processor to another. -Therefore it is safest to use ``<rtems/confdefs.h>`` and specify -your application's requirements in terms of the numbers of objects and -multiples of ``RTEMS_MINIMUM_STACK_SIZE``, as far as is possible. The -automatic estimates of space required will in general change when: +The file ``<rtems/confdefs.h>`` will calculate the value of +the``work_space_size`` parameter of the Configuration Table. There are many +parameters the application developer can specify to help ``<rtems/confdefs.h>`` +in its calculations. Correctly specifying the application requirements via +parameters such as ``CONFIGURE_EXTRA_TASK_STACKS`` and +``CONFIGURE_MAXIMUM_TASKS`` is critical for production software. + +For each class of objects, the allocation can operate in one of two ways. The +default way has an ceiling on the maximum number of object instances which can +concurrently exist in the system. Memory for all instances of that object class +is reserved at system initialization. The second way allocates memory for an +initial number of objects and increases the current allocation by a fixed +increment when required. Both ways allocate space from inside the RTEMS +Workspace. + +See :ref:`Unlimited Objects` for more details about the second way, which +allows for dynamic allocation of objects and therefore does not provide +determinism. This mode is useful mostly for when the number of objects cannot +be determined ahead of time or when porting software for which you do not know +the object requirements. + +The space needed for stacks and for RTEMS objects will vary from one version of +RTEMS and from one target processor to another. Therefore it is safest to use +``<rtems/confdefs.h>`` and specify your application's requirements in terms of +the numbers of objects and multiples of ``RTEMS_MINIMUM_STACK_SIZE``, as far as +is possible. The automatic estimates of space required will in general change +when: - a configuration parameter is changed, @@ -127,18 +136,19 @@ run-time errors terminating the system. Potential Issues with RTEMS Workspace Size Estimation ===================================================== -The ``<rtems/confdefs.h>`` file estimates the amount of memory -required for the RTEMS Workspace. This estimate is only as accurate -as the information given to ``<rtems/confdefs.h>`` and may be either -too high or too low for a variety of reasons. Some of the reasons that``<rtems/confdefs.h>`` may reserve too much memory for RTEMS are: +The ``<rtems/confdefs.h>`` file estimates the amount of memory required for the +RTEMS Workspace. This estimate is only as accurate as the information given to +``<rtems/confdefs.h>`` and may be either too high or too low for a variety of +reasons. Some of the reasons that ``<rtems/confdefs.h>`` may reserve too much +memory for RTEMS are: - All tasks/threads are assumed to be floating point. -Conversely, there are many more reasons that the resource estimate could be -too low: +Conversely, there are many more reasons that the resource estimate could be too +low: -- Task/thread stacks greater than minimum size must be - accounted for explicitly by developer. +- Task/thread stacks greater than minimum size must be accounted for explicitly + by developer. - Memory for messages is not included. @@ -149,53 +159,53 @@ too low: - Requirements for add-on libraries are not included. In general, ``<rtems/confdefs.h>`` is very accurate when given enough -information. However, it is quite easy to use a library and forget to -account for its resources. +information. However, it is quite easy to use a library and forget to account +for its resources. .. COMMENT: === Format to be followed for making changes in this file === Format to be followed for making changes in this file ===================================================== -- MACRO NAME +*MACRO NAME:*: Should be alphanumeric. Can have '_' (underscore). -- DATA TYPE +*DATA TYPE:* Please refer to all existing formats. -- RANGE: - +*RANGE:* The range depends on the Data Type of the macro. - - - If the data type is of type task priority, then its value should - be an integer in the range of 1 to 255. - - - If the data type is an integer, then it can have numbers, characters - (in case the value is defined using another macro) and arithmetic operations + - If the data type is of type task priority, then its value should be an + integer in the range of 1 to 255. + + - If the data type is an integer, then it can have numbers, characters (in + case the value is defined using another macro) and arithmetic operations (+, -, \*, /). - - - If the data type is a function pointer the first character - should be an alphabet or an underscore. The rest of the string - can be alphanumeric. - - - If the data type is RTEMS Attributes or RTEMS Mode then - the string should be alphanumeric. - - - If the data type is RTEMS NAME then the value should be - an integer>=0 or RTEMS_BUILD_NAME( 'U', 'I', '1', ' ' ) -- DEFAULT VALUE + - If the data type is a function pointer the first character should be an + alphabet or an underscore. The rest of the string can be alphanumeric. - The default value should be in the following formats- - Please note that the '.' (full stop) is necessary. + - If the data type is RTEMS Attributes or RTEMS Mode then the string should + be alphanumeric. - - - In case the value is not defined then: - This is not defined by default. - - - If we know the default value then: - The default value is XXX. - - - If the default value is BSP Specific then: - This option is BSP specific. + - If the data type is RTEMS NAME then the value should be an integer>=0 or + RTEMS_BUILD_NAME( 'U', 'I', '1', ' ' ) + +*DEFAULT VALUE:* + The default value should be in the following formats- Please note that the + '.' (full stop) is necessary. + + - In case the value is not defined then: This is not defined by default. -- DESCRIPTION + - If we know the default value then: The default value is XXX. + + - If the default value is BSP Specific then: This option is BSP specific. + +*DESCRIPTION:* The description of the macro. (No specific format) -- NOTES +*NOTES:* Any further notes. (No specific format) .. COMMENT: === Configuration Example === @@ -203,108 +213,108 @@ Format to be followed for making changes in this file Configuration Example ===================== -In the following example, the configuration information for a system -with a single message queue, four (4) tasks, and a timeslice of -fifty (50) milliseconds is as follows: +In the following example, the configuration information for a system with a +single message queue, four (4) tasks, and a timeslice of fifty (50) +milliseconds is as follows: + .. code:: c #include <bsp.h> #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER - #define CONFIGURE_MICROSECONDS_PER_TICK 1000 /* 1 millisecond \*/ - #define CONFIGURE_TICKS_PER_TIMESLICE 50 /* 50 milliseconds \*/ + #define CONFIGURE_MICROSECONDS_PER_TICK 1000 /* 1 millisecond */ + #define CONFIGURE_TICKS_PER_TIMESLICE 50 /* 50 milliseconds */ #define CONFIGURE_RTEMS_INIT_TASKS_TABLE #define CONFIGURE_MAXIMUM_TASKS 4 #define CONFIGURE_MAXIMUM_MESSAGE_QUEUES 1 - #define CONFIGURE_MESSAGE_BUFFER_MEMORY \\ - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE(20, sizeof(struct USER_MESSAGE)) + #define CONFIGURE_MESSAGE_BUFFER_MEMORY \ + CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE(20, sizeof(struct USER_MESSAGE)) #define CONFIGURE_INIT #include <rtems/confdefs.h> -In this example, only a few configuration parameters are specified. The -impact of these are as follows: - -- The example specified ``CONFIGURE_RTEMS_INIT_TASK_TABLE`` - but did not specify any additional parameters. This results in a - configuration of an application which will begin execution of a single - initialization task named ``Init`` which is non-preemptible and at - priority one (1). - -- By specifying ``CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER``, - this application is configured to have a clock tick device - driver. Without a clock tick device driver, RTEMS has no way to know - that time is passing and will be unable to support delays and wall - time. Further configuration details about time are - provided. Per ``CONFIGURE_MICROSECONDS_PER_TICK`` and``CONFIGURE_TICKS_PER_TIMESLICE``, the user specified they wanted a - clock tick to occur each millisecond, and that the length of a timeslice - would be fifty (50) milliseconds. - -- By specifying ``CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER``, - the application will include a console device driver. Although the - console device driver may support a combination of multiple serial - ports and display and keyboard combinations, it is only required to - provide a single device named ``/dev/console``. This device will - be used for Standard Input, Output and Error I/O Streams. Thus when``CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER`` is specified, implicitly - three (3) file descriptors are reserved for the Standard I/O Streams and - those file descriptors are associated with ``/dev/console`` during - initialization. All console devices are expected to support the POSIX*termios* interface. - -- The example above specifies via ``CONFIGURE_MAXIMUM_TASKS`` - that the application requires a maximum of four (4) - simultaneously existing Classic API tasks. Similarly, by specifying``CONFIGURE_MAXIMUM_MESSAGE_QUEUES``, there may be a maximum of only - one (1) concurrently existent Classic API message queues. - -- The most surprising configuration parameter in this example is the - use of ``CONFIGURE_MESSAGE_BUFFER_MEMORY``. Message buffer memory is - allocated from the RTEMS Workspace and must be accounted for. In this - example, the single message queue will have up to twenty (20) messages - of type ``struct USER_MESSAGE``. - -- The ``CONFIGURE_INIT`` constant must be defined in order to - make ``<rtems/confdefs.h>`` instantiate the configuration data - structures. This can only be defined in one source file per - application that includes ``<rtems/confdefs.h>`` or the symbol - table will be instantiated multiple times and linking errors - produced. - -This example illustrates that parameters have default values. Among -other things, the application implicitly used the following defaults: - -- All unspecified types of communications and synchronization objects - in the Classic and POSIX Threads API have maximums of zero (0). +In this example, only a few configuration parameters are specified. The impact +of these are as follows: + +- The example specified ``CONFIGURE_RTEMS_INIT_TASK_TABLE`` but did not specify + any additional parameters. This results in a configuration of an application + which will begin execution of a single initialization task named ``Init`` + which is non-preemptible and at priority one (1). + +- By specifying ``CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER``, this application + is configured to have a clock tick device driver. Without a clock tick device + driver, RTEMS has no way to know that time is passing and will be unable to + support delays and wall time. Further configuration details about time are + provided. Per ``CONFIGURE_MICROSECONDS_PER_TICK`` and + ``CONFIGURE_TICKS_PER_TIMESLICE``, the user specified they wanted a clock + tick to occur each millisecond, and that the length of a timeslice would be + fifty (50) milliseconds. + +- By specifying ``CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER``, the application + will include a console device driver. Although the console device driver may + support a combination of multiple serial ports and display and keyboard + combinations, it is only required to provide a single device named + ``/dev/console``. This device will be used for Standard Input, Output and + Error I/O Streams. Thus when ``CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER`` + is specified, implicitly three (3) file descriptors are reserved for the + Standard I/O Streams and those file descriptors are associated with + ``/dev/console`` during initialization. All console devices are expected to + support the POSIX*termios* interface. + +- The example above specifies via ``CONFIGURE_MAXIMUM_TASKS`` that the + application requires a maximum of four (4) simultaneously existing Classic + API tasks. Similarly, by specifying ``CONFIGURE_MAXIMUM_MESSAGE_QUEUES``, + there may be a maximum of only one (1) concurrently existent Classic API + message queues. + +- The most surprising configuration parameter in this example is the use of + ``CONFIGURE_MESSAGE_BUFFER_MEMORY``. Message buffer memory is allocated from + the RTEMS Workspace and must be accounted for. In this example, the single + message queue will have up to twenty (20) messages of type ``struct + USER_MESSAGE``. + +- The ``CONFIGURE_INIT`` constant must be defined in order to make + ``<rtems/confdefs.h>`` instantiate the configuration data structures. This + can only be defined in one source file per application that includes + ``<rtems/confdefs.h>`` or the symbol table will be instantiated multiple + times and linking errors produced. + +This example illustrates that parameters have default values. Among other +things, the application implicitly used the following defaults: + +- All unspecified types of communications and synchronization objects in the + Classic and POSIX Threads API have maximums of zero (0). - The filesystem will be the default filesystem which is the In-Memory File System (IMFS). - The application will have the default number of priority levels. -- The minimum task stack size will be that recommended by RTEMS for - the target architecture. +- The minimum task stack size will be that recommended by RTEMS for the target + architecture. .. COMMENT: === Unlimited Objects === - Unlimited Objects ----------------- -In real-time embedded systems the RAM is normally a limited, critical -resource and dynamic allocation is avoided as much as possible to -ensure predictable, deterministic execution times. For such cases, see `Sizing the RTEMS Workspace`_ for an overview -of how to tune the size of the workspace. Frequently when users are -porting software to RTEMS the precise resource requirements of the -software is unknown. In these situations users do not need to control -the size of the workspace very tightly because they just want to get +In real-time embedded systems the RAM is normally a limited, critical resource +and dynamic allocation is avoided as much as possible to ensure predictable, +deterministic execution times. For such cases, see :ref:`Sizing the RTEMS +Workspace` for an overview of how to tune the size of the workspace. +Frequently when users are porting software to RTEMS the precise resource +requirements of the software is unknown. In these situations users do not need +to control the size of the workspace very tightly because they just want to get the new software to run; later they can tune the workspace size as needed. -The following API-independent object classes can be configured in -unlimited mode: +The following API-independent object classes can be configured in unlimited +mode: - POSIX Keys - POSIX Key Value Pairs -The following object classes in the Classic API can be configured in -unlimited mode: +The following object classes in the Classic API can be configured in unlimited +mode: - Tasks @@ -324,8 +334,8 @@ unlimited mode: - Ports -Additionally, the following object classes from the POSIX API can be -configured in unlimited mode: +Additionally, the following object classes from the POSIX API can be configured +in unlimited mode: - Threads @@ -358,12 +368,13 @@ The following object classes can *not* be configured in unlimited mode: - POSIX Queued Signals Due to the memory requirements of unlimited objects it is strongly recommended -to use them only in combination with the unified work areas. See `Separate or Unified Work Areas`_ for more information -on unified work areas. +to use them only in combination with the unified work areas. See :ref:`Separate +or Unified Work Areas` for more information on unified work areas. The following example demonstrates how the two simple configuration defines for unlimited objects and unified works areas can replace many seperate configuration defines for supported object classes: + .. code:: c #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER @@ -375,10 +386,10 @@ configuration defines for supported object classes: #include <rtems/confdefs.h> Users are cautioned that using unlimited objects is not recommended for -production software unless the dynamic growth is absolutely required. It -is generally considered a safer embedded systems programming practice to -know the system limits rather than experience an out of memory error -at an arbitrary and largely unpredictable time in the field. +production software unless the dynamic growth is absolutely required. It is +generally considered a safer embedded systems programming practice to know the +system limits rather than experience an out of memory error at an arbitrary and +largely unpredictable time in the field. .. COMMENT: === Per Object Class Unlimited Object Instances === @@ -387,16 +398,17 @@ Per Object Class Unlimited Object Instances .. index:: rtems_resource_unlimited When the number of objects is not known ahead of time, RTEMS provides an -auto-extending mode that can be enabled individually for each object -type by using the macro ``rtems_resource_unlimited``. This takes a value -as a parameter, and is used to set the object maximum number field in -an API Configuration table. The value is an allocation unit size. When -RTEMS is required to grow the object table it is grown by this -size. The kernel will return the object memory back to the RTEMS Workspace -when an object is destroyed. The kernel will only return an allocated -block of objects to the RTEMS Workspace if at least half the allocation -size of free objects remain allocated. RTEMS always keeps one -allocation block of objects allocated. Here is an example of using``rtems_resource_unlimited``: +auto-extending mode that can be enabled individually for each object type by +using the macro ``rtems_resource_unlimited``. This takes a value as a +parameter, and is used to set the object maximum number field in an API +Configuration table. The value is an allocation unit size. When RTEMS is +required to grow the object table it is grown by this size. The kernel will +return the object memory back to the RTEMS Workspace when an object is +destroyed. The kernel will only return an allocated block of objects to the +RTEMS Workspace if at least half the allocation size of free objects remain +allocated. RTEMS always keeps one allocation block of objects allocated. Here +is an example of using ``rtems_resource_unlimited``: + .. code:: c #define CONFIGURE_MAXIMUM_TASKS rtems_resource_unlimited(5) @@ -404,18 +416,19 @@ allocation block of objects allocated. Here is an example of using``rtems_resour .. index:: rtems_resource_is_unlimited .. index:: rtems_resource_maximum_per_allocation -Object maximum specifications can be evaluated with the``rtems_resource_is_unlimited`` and``rtems_resource_maximum_per_allocation`` macros. +Object maximum specifications can be evaluated with the +``rtems_resource_is_unlimited`` and``rtems_resource_maximum_per_allocation`` +macros. .. COMMENT: === Unlimited Object Instances === Unlimited Object Instances -------------------------- -To ease the burden of developers who are porting new software RTEMS -also provides the capability to make all object classes listed above -operate in unlimited mode in a simple manner. The application developer -is only responsible for enabling unlimited objects and specifying the -allocation size. +To ease the burden of developers who are porting new software RTEMS also +provides the capability to make all object classes listed above operate in +unlimited mode in a simple manner. The application developer is only +responsible for enabling unlimited objects and specifying the allocation size. .. COMMENT: === CONFIGURE_UNLIMITED_OBJECTS === @@ -437,14 +450,15 @@ Enable Unlimited Object Instances **DESCRIPTION:** -``CONFIGURE_UNLIMITED_OBJECTS`` enables ``rtems_resource_unlimited`` -mode for Classic API and POSIX API objects that do not already have a -specific maximum limit defined. +``CONFIGURE_UNLIMITED_OBJECTS`` enables ``rtems_resource_unlimited`` mode for +Classic API and POSIX API objects that do not already have a specific maximum +limit defined. **NOTES:** -When using unlimited objects, it is common practice to also specify``CONFIGURE_UNIFIED_WORK_AREAS`` so the system operates with a single -pool of memory for both RTEMS and application memory allocations. +When using unlimited objects, it is common practice to also specify +``CONFIGURE_UNIFIED_WORK_AREAS`` so the system operates with a single pool of +memory for both RTEMS and application memory allocations. .. COMMENT: === CONFIGURE_UNLIMITED_ALLOCATION_SIZE === @@ -460,21 +474,22 @@ Specify Unlimited Objects Allocation Size *RANGE:* Positive. -*DEFAULT VALUE:* - If not defined and ``CONFIGURE_UNLIMITED_OBJECTS`` is defined, the - default value is eight (8). +*DEFAULT VALUE:* If not defined and ``CONFIGURE_UNLIMITED_OBJECTS`` is defined, + the default value is eight (8). **DESCRIPTION:** -``CONFIGURE_UNLIMITED_ALLOCATION_SIZE`` provides an -allocation size to use for ``rtems_resource_unlimited`` when using``CONFIGURE_UNLIMITED_OBJECTS``. +``CONFIGURE_UNLIMITED_ALLOCATION_SIZE`` provides an allocation size to use for +``rtems_resource_unlimited`` when using ``CONFIGURE_UNLIMITED_OBJECTS``. **NOTES:** -By allowing users to declare all resources as being unlimited -the user can avoid identifying and limiting the resources used.``CONFIGURE_UNLIMITED_OBJECTS`` does not support varying the allocation -sizes for different objects; users who want that much control can define -the ``rtems_resource_unlimited`` macros themselves. +By allowing users to declare all resources as being unlimited the user can +avoid identifying and limiting the resources +used. ``CONFIGURE_UNLIMITED_OBJECTS`` does not support varying the allocation +sizes for different objects; users who want that much control can define the +``rtems_resource_unlimited`` macros themselves. + .. code:: c #define CONFIGURE_UNLIMITED_OBJECTS @@ -485,8 +500,8 @@ the ``rtems_resource_unlimited`` macros themselves. Classic API Configuration ========================= -This section defines the Classic API related system configuration -parameters supported by ``<rtems/confdefs.h>``. +This section defines the Classic API related system configuration parameters +supported by ``<rtems/confdefs.h>``. .. COMMENT: === CONFIGURE_MAXIMUM_TASKS === @@ -508,27 +523,29 @@ Specify Maximum Classic API Tasks **DESCRIPTION:** -``CONFIGURE_MAXIMUM_TASKS`` is the maximum number of Classic API -Tasks that can be concurrently active. +``CONFIGURE_MAXIMUM_TASKS`` is the maximum number of Classic API Tasks that can +be concurrently active. **NOTES:** This object class can be configured in unlimited allocation mode. -The calculations for the required memory in the RTEMS Workspace -for tasks assume that each task has a minimum stack size and -has floating point support enabled. The configuration parameter``CONFIGURE_EXTRA_TASK_STACKS`` is used to specify task stack -requirements *ABOVE* the minimum size required. See `Reserve Task/Thread Stack Memory Above Minimum`_ -for more information about ``CONFIGURE_EXTRA_TASK_STACKS``. +The calculations for the required memory in the RTEMS Workspace for tasks +assume that each task has a minimum stack size and has floating point support +enabled. The configuration parameter ``CONFIGURE_EXTRA_TASK_STACKS`` is used +to specify task stack requirements *ABOVE* the minimum size required. See +:ref:`Reserve Task/Thread Stack Memory Above Minimum` for more information +about ``CONFIGURE_EXTRA_TASK_STACKS``. -The maximum number of POSIX threads is specified by``CONFIGURE_MAXIMUM_POSIX_THREADS``. +The maximum number of POSIX threads is specified by +``CONFIGURE_MAXIMUM_POSIX_THREADS``. .. COMMENT: XXX - Add xref to CONFIGURE_MAXIMUM_POSIX_THREADS. -A future enhancement to ``<rtems/confdefs.h>`` could be to eliminate -the assumption that all tasks have floating point enabled. This would -require the addition of a new configuration parameter to specify the -number of tasks which enable floating point support. +A future enhancement to ``<rtems/confdefs.h>`` could be to eliminate the +assumption that all tasks have floating point enabled. This would require the +addition of a new configuration parameter to specify the number of tasks which +enable floating point support. .. COMMENT: === CONFIGURE_MAXIMUM_TIMERS === @@ -550,8 +567,8 @@ Specify Maximum Classic API Timers **DESCRIPTION:** -``CONFIGURE_MAXIMUM_TIMERS`` is the maximum number of Classic API -Timers that can be concurrently active. +``CONFIGURE_MAXIMUM_TIMERS`` is the maximum number of Classic API Timers that +can be concurrently active. **NOTES:** @@ -577,8 +594,8 @@ Specify Maximum Classic API Semaphores **DESCRIPTION:** -``CONFIGURE_MAXIMUM_SEMAPHORES`` is the maximum number of Classic -API Semaphores that can be concurrently active. +``CONFIGURE_MAXIMUM_SEMAPHORES`` is the maximum number of Classic API +Semaphores that can be concurrently active. **NOTES:** @@ -604,9 +621,9 @@ Specify Maximum Classic API Semaphores usable with MrsP **DESCRIPTION:** -``CONFIGURE_MAXIMUM_MRSP_SEMAPHORES`` is the -maximum number of Classic API Semaphores using the Multiprocessor Resource -Sharing Protocol (MrsP) that can be concurrently active. +``CONFIGURE_MAXIMUM_MRSP_SEMAPHORES`` is the maximum number of Classic API +Semaphores using the Multiprocessor Resource Sharing Protocol (MrsP) that can +be concurrently active. **NOTES:** @@ -634,8 +651,8 @@ Specify Maximum Classic API Message Queues **DESCRIPTION:** -``CONFIGURE_MAXIMUM_MESSAGE_QUEUES`` is the maximum number of Classic -API Message Queues that can be concurrently active. +``CONFIGURE_MAXIMUM_MESSAGE_QUEUES`` is the maximum number of Classic API +Message Queues that can be concurrently active. **NOTES:** @@ -661,8 +678,8 @@ Specify Maximum Classic API Barriers **DESCRIPTION:** -``CONFIGURE_MAXIMUM_BARRIERS`` is the maximum number of Classic -API Barriers that can be concurrently active. +``CONFIGURE_MAXIMUM_BARRIERS`` is the maximum number of Classic API Barriers +that can be concurrently active. **NOTES:** @@ -688,8 +705,8 @@ Specify Maximum Classic API Periods **DESCRIPTION:** -``CONFIGURE_MAXIMUM_PERIODS`` is the maximum number of Classic -API Periods that can be concurrently active. +``CONFIGURE_MAXIMUM_PERIODS`` is the maximum number of Classic API Periods that +can be concurrently active. **NOTES:** @@ -715,8 +732,8 @@ Specify Maximum Classic API Partitions **DESCRIPTION:** -``CONFIGURE_MAXIMUM_PARTITIONS`` is the maximum number of Classic -API Partitions that can be concurrently active. +``CONFIGURE_MAXIMUM_PARTITIONS`` is the maximum number of Classic API +Partitions that can be concurrently active. **NOTES:** @@ -742,8 +759,8 @@ Specify Maximum Classic API Regions **DESCRIPTION:** -``CONFIGURE_MAXIMUM_REGIONS`` is the maximum number of Classic -API Regions that can be concurrently active. +``CONFIGURE_MAXIMUM_REGIONS`` is the maximum number of Classic API Regions that +can be concurrently active. **NOTES:** @@ -769,8 +786,8 @@ Specify Maximum Classic API Ports **DESCRIPTION:** -``CONFIGURE_MAXIMUM_PORTS`` is the maximum number of Classic -API Ports that can be concurrently active. +``CONFIGURE_MAXIMUM_PORTS`` is the maximum number of Classic API Ports that can +be concurrently active. **NOTES:** @@ -796,8 +813,8 @@ Specify Maximum Classic API User Extensions **DESCRIPTION:** -``CONFIGURE_MAXIMUM_USER_EXTENSIONS`` is the maximum number of Classic -API User Extensions that can be concurrently active. +``CONFIGURE_MAXIMUM_USER_EXTENSIONS`` is the maximum number of Classic API User +Extensions that can be concurrently active. **NOTES:** @@ -808,9 +825,9 @@ This object class can be configured in unlimited allocation mode. Classic API Initialization Tasks Table Configuration ==================================================== -The ``<rtems/confdefs.h>`` configuration system can automatically -generate an Initialization Tasks Table named``Initialization_tasks`` with a single entry. The following -parameters control the generation of that table. +The ``<rtems/confdefs.h>`` configuration system can automatically generate an +Initialization Tasks Table named ``Initialization_tasks`` with a single entry. +The following parameters control the generation of that table. .. COMMENT: === CONFIGURE_RTEMS_INIT_TASKS_TABLE === @@ -832,21 +849,21 @@ Instantiate Classic API Initialization Task Table **DESCRIPTION:** -``CONFIGURE_RTEMS_INIT_TASKS_TABLE`` is defined if the user wishes -to use a Classic RTEMS API Initialization Task Table. The table built by``<rtems/confdefs.h>`` specifies the parameters for a single task. This -is sufficient for applications which initialization the system from a -single task. +``CONFIGURE_RTEMS_INIT_TASKS_TABLE`` is defined if the user wishes to use a +Classic RTEMS API Initialization Task Table. The table built by +``<rtems/confdefs.h>`` specifies the parameters for a single task. This is +sufficient for applications which initialization the system from a single task. -By default, this field is not defined as the user MUST select their own -API for initialization tasks. +By default, this field is not defined as the user MUST select their own API for +initialization tasks. **NOTES:** -The application may choose to use the initialization tasks or threads -table from another API. +The application may choose to use the initialization tasks or threads table +from another API. -A compile time error will be generated if the user does not configure -any initialization tasks or threads. +A compile time error will be generated if the user does not configure any +initialization tasks or threads. .. COMMENT: === CONFIGURE_INIT_TASK_ENTRY_POINT === @@ -868,14 +885,14 @@ Specifying Classic API Initialization Task Entry Point **DESCRIPTION:** -``CONFIGURE_INIT_TASK_ENTRY_POINT`` is the entry point (a.k.a. function -name) of the single initialization task defined by the Classic API -Initialization Tasks Table. +``CONFIGURE_INIT_TASK_ENTRY_POINT`` is the entry point (a.k.a. function name) +of the single initialization task defined by the Classic API Initialization +Tasks Table. **NOTES:** -The user must implement the function ``Init`` or the function name provided -in this configuration parameter. +The user must implement the function ``Init`` or the function name provided in +this configuration parameter. .. COMMENT: === CONFIGURE_INIT_TASK_NAME === @@ -897,8 +914,8 @@ Specifying Classic API Initialization Task Name **DESCRIPTION:** -``CONFIGURE_INIT_TASK_NAME`` is the name of the single initialization -task defined by the Classic API Initialization Tasks Table. +``CONFIGURE_INIT_TASK_NAME`` is the name of the single initialization task +defined by the Classic API Initialization Tasks Table. **NOTES:** @@ -929,10 +946,10 @@ initialization task defined by the Classic API Initialization Tasks Table. **NOTES:** -If the stack size specified is greater than the configured minimum, -it must be accounted for in ``CONFIGURE_EXTRA_TASK_STACKS``. -See `Reserve Task/Thread Stack Memory Above Minimum`_ -for more information about ``CONFIGURE_EXTRA_TASK_STACKS``. +If the stack size specified is greater than the configured minimum, it must be +accounted for in ``CONFIGURE_EXTRA_TASK_STACKS``. See :ref:`Reserve +Task/Thread Stack Memory Above Minimum` for more information about +``CONFIGURE_EXTRA_TASK_STACKS``. .. COMMENT: === CONFIGURE_INIT_TASK_PRIORITY === @@ -1009,9 +1026,9 @@ Specifying Classic API Initialization Task Modes **DESCRIPTION:** -``CONFIGURE_INIT_TASK_INITIAL_MODES`` is the initial execution mode of -the single initialization task defined by the Classic API Initialization -Tasks Table. +``CONFIGURE_INIT_TASK_INITIAL_MODES`` is the initial execution mode of the +single initialization task defined by the Classic API Initialization Tasks +Table. **NOTES:** @@ -1064,23 +1081,23 @@ Not Using Generated Initialization Tasks Table **DESCRIPTION:** -``CONFIGURE_HAS_OWN_INIT_TASK_TABLE`` is defined if the user wishes -to define their own Classic API Initialization Tasks Table. This table -should be named ``Initialization_tasks``. +``CONFIGURE_HAS_OWN_INIT_TASK_TABLE`` is defined if the user wishes to define +their own Classic API Initialization Tasks Table. This table should be named +``Initialization_tasks``. **NOTES:** -This is a seldom used configuration parameter. The most likely use case -is when an application desires to have more than one initialization task. +This is a seldom used configuration parameter. The most likely use case is when +an application desires to have more than one initialization task. .. COMMENT: === POSIX API Configuration === POSIX API Configuration ======================= -The parameters in this section are used to configure resources -for the RTEMS POSIX API. They are only relevant if the POSIX API -is enabled at configure time using the ``--enable-posix`` option. +The parameters in this section are used to configure resources for the RTEMS +POSIX API. They are only relevant if the POSIX API is enabled at configure +time using the ``--enable-posix`` option. .. COMMENT: === CONFIGURE_MAXIMUM_POSIX_THREADS === @@ -1109,14 +1126,15 @@ Threads that can be concurrently active. This object class can be configured in unlimited allocation mode. -This calculations for the required memory in the RTEMS Workspace -for threads assume that each thread has a minimum stack size and -has floating point support enabled. The configuration parameter``CONFIGURE_EXTRA_TASK_STACKS`` is used to specify thread stack -requirements *ABOVE* the minimum size required. -See `Reserve Task/Thread Stack Memory Above Minimum`_ -for more information about ``CONFIGURE_EXTRA_TASK_STACKS``. +This calculations for the required memory in the RTEMS Workspace for threads +assume that each thread has a minimum stack size and has floating point support +enabled. The configuration parameter ``CONFIGURE_EXTRA_TASK_STACKS`` is used +to specify thread stack requirements *ABOVE* the minimum size required. See +:ref:`Reserve Task/Thread Stack Memory Above Minimum` for more information +about ``CONFIGURE_EXTRA_TASK_STACKS``. -The maximum number of Classic API Tasks is specified by``CONFIGURE_MAXIMUM_TASKS``. +The maximum number of Classic API Tasks is specified by +``CONFIGURE_MAXIMUM_TASKS``. All POSIX threads have floating point enabled. @@ -1142,8 +1160,8 @@ Specify Maximum POSIX API Mutexes **DESCRIPTION:** -``CONFIGURE_MAXIMUM_POSIX_MUTEXES`` is the maximum number of POSIX -API Mutexes that can be concurrently active. +``CONFIGURE_MAXIMUM_POSIX_MUTEXES`` is the maximum number of POSIX API Mutexes +that can be concurrently active. **NOTES:** @@ -1169,8 +1187,8 @@ Specify Maximum POSIX API Condition Variables **DESCRIPTION:** -``CONFIGURE_MAXIMUM_POSIX_CONDITION_VARIABLES`` is the maximum number -of POSIX API Condition Variables that can be concurrently active. +``CONFIGURE_MAXIMUM_POSIX_CONDITION_VARIABLES`` is the maximum number of POSIX +API Condition Variables that can be concurrently active. **NOTES:** @@ -1196,8 +1214,8 @@ Specify Maximum POSIX API Keys **DESCRIPTION:** -``CONFIGURE_MAXIMUM_POSIX_KEYS`` is the maximum number of POSIX -API Keys that can be concurrently active. +``CONFIGURE_MAXIMUM_POSIX_KEYS`` is the maximum number of POSIX API Keys that +can be concurrently active. **NOTES:** @@ -1225,8 +1243,8 @@ Specify Maximum POSIX API Timers **DESCRIPTION:** -``CONFIGURE_MAXIMUM_POSIX_TIMERS`` is the maximum number of POSIX -API Timers that can be concurrently active. +``CONFIGURE_MAXIMUM_POSIX_TIMERS`` is the maximum number of POSIX API Timers +that can be concurrently active. **NOTES:** @@ -1252,8 +1270,8 @@ Specify Maximum POSIX API Queued Signals **DESCRIPTION:** -``CONFIGURE_MAXIMUM_POSIX_QUEUED_SIGNALS`` is the maximum number of POSIX -API Queued Signals that can be concurrently active. +``CONFIGURE_MAXIMUM_POSIX_QUEUED_SIGNALS`` is the maximum number of POSIX API +Queued Signals that can be concurrently active. **NOTES:** @@ -1279,8 +1297,8 @@ Specify Maximum POSIX API Message Queues **DESCRIPTION:** -``CONFIGURE_MAXIMUM_POSIX_MESSAGE_QUEUES`` is the maximum number of POSIX -API Message Queues that can be concurrently active. +``CONFIGURE_MAXIMUM_POSIX_MESSAGE_QUEUES`` is the maximum number of POSIX API +Message Queues that can be concurrently active. **NOTES:** @@ -1308,16 +1326,15 @@ Specify Maximum POSIX API Message Queue Descriptors **DESCRIPTION:** -``CONFIGURE_MAXIMUM_POSIX_MESSAGE_QUEUE_DESCRIPTORS`` is the maximum -number of POSIX API Message Queue Descriptors that can be concurrently -active. +``CONFIGURE_MAXIMUM_POSIX_MESSAGE_QUEUE_DESCRIPTORS`` is the maximum number of +POSIX API Message Queue Descriptors that can be concurrently active. **NOTES:** This object class can be configured in unlimited allocation mode. -``CONFIGURE_MAXIMUM_POSIX_MESSAGE_QUEUE_DESCRIPTORS`` should be -greater than or equal to ``CONFIGURE_MAXIMUM_POSIX_MESSAGE_QUEUES``. +``CONFIGURE_MAXIMUM_POSIX_MESSAGE_QUEUE_DESCRIPTORS`` should be greater than or +equal to ``CONFIGURE_MAXIMUM_POSIX_MESSAGE_QUEUES``. .. COMMENT: === CONFIGURE_MAXIMUM_POSIX_SEMAPHORES === @@ -1339,8 +1356,8 @@ Specify Maximum POSIX API Semaphores **DESCRIPTION:** -``CONFIGURE_MAXIMUM_POSIX_SEMAPHORES`` is the maximum number of POSIX -API Semaphores that can be concurrently active. +``CONFIGURE_MAXIMUM_POSIX_SEMAPHORES`` is the maximum number of POSIX API +Semaphores that can be concurrently active. **NOTES:** @@ -1366,8 +1383,8 @@ Specify Maximum POSIX API Barriers **DESCRIPTION:** -``CONFIGURE_MAXIMUM_POSIX_BARRIERS`` is the maximum number of POSIX -API Barriers that can be concurrently active. +``CONFIGURE_MAXIMUM_POSIX_BARRIERS`` is the maximum number of POSIX API +Barriers that can be concurrently active. **NOTES:** @@ -1393,8 +1410,8 @@ Specify Maximum POSIX API Spinlocks **DESCRIPTION:** -``CONFIGURE_MAXIMUM_POSIX_SPINLOCKS`` is the maximum number of POSIX -API Spinlocks that can be concurrently active. +``CONFIGURE_MAXIMUM_POSIX_SPINLOCKS`` is the maximum number of POSIX API +Spinlocks that can be concurrently active. **NOTES:** @@ -1420,8 +1437,8 @@ Specify Maximum POSIX API Read/Write Locks **DESCRIPTION:** -``CONFIGURE_MAXIMUM_POSIX_RWLOCKS`` is the maximum number of POSIX -API Read/Write Locks that can be concurrently active. +``CONFIGURE_MAXIMUM_POSIX_RWLOCKS`` is the maximum number of POSIX API +Read/Write Locks that can be concurrently active. **NOTES:** @@ -1432,9 +1449,9 @@ This object class can be configured in unlimited allocation mode. POSIX Initialization Threads Table Configuration ================================================ -The ``<rtems/confdefs.h>`` configuration system can automatically -generate a POSIX Initialization Threads Table named``POSIX_Initialization_threads`` with a single entry. The following -parameters control the generation of that table. +The ``<rtems/confdefs.h>`` configuration system can automatically generate a +POSIX Initialization Threads Table named ``POSIX_Initialization_threads`` with +a single entry. The following parameters control the generation of that table. .. COMMENT: === CONFIGURE_POSIX_INIT_THREAD_TABLE === @@ -1452,28 +1469,26 @@ Instantiate POSIX API Initialization Thread Table Defined or undefined. *DEFAULT VALUE:* - This field is not defined by default, as the user MUST select their own - API for initialization tasks. + This field is not defined by default, as the user MUST select their own API + for initialization tasks. **DESCRIPTION:** -``CONFIGURE_POSIX_INIT_THREAD_TABLE`` is defined if the user wishes -to use a POSIX API Initialization Threads Table. The table built -by ``<rtems/confdefs.h>`` specifies the parameters for a single -thread. This is sufficient for applications which initialization the -system from a -single task. +``CONFIGURE_POSIX_INIT_THREAD_TABLE`` is defined if the user wishes to use a +POSIX API Initialization Threads Table. The table built by +``<rtems/confdefs.h>`` specifies the parameters for a single thread. This is +sufficient for applications which initialization the system from a single task. -By default, this field is not defined as the user MUST select their own -API for initialization tasks. +By default, this field is not defined as the user MUST select their own API for +initialization tasks. **NOTES:** -The application may choose to use the initialization tasks or threads -table from another API. +The application may choose to use the initialization tasks or threads table +from another API. -A compile time error will be generated if the user does not configure -any initialization tasks or threads. +A compile time error will be generated if the user does not configure any +initialization tasks or threads. .. COMMENT: === CONFIGURE_POSIX_INIT_THREAD_ENTRY_POINT === @@ -1495,9 +1510,9 @@ Specifying POSIX API Initialization Thread Entry Point **DESCRIPTION:** -``CONFIGURE_POSIX_INIT_THREAD_ENTRY_POINT`` is the entry point -(a.k.a. function name) of the single initialization thread defined by -the POSIX API Initialization Threads Table. +``CONFIGURE_POSIX_INIT_THREAD_ENTRY_POINT`` is the entry point (a.k.a. function +name) of the single initialization thread defined by the POSIX API +Initialization Threads Table. **NOTES:** @@ -1524,16 +1539,15 @@ Specifying POSIX API Initialization Thread Stack Size **DESCRIPTION:** -``CONFIGURE_POSIX_INIT_THREAD_STACK_SIZE`` is the stack size of the -single initialization thread defined by the POSIX API Initialization -Threads Table. +``CONFIGURE_POSIX_INIT_THREAD_STACK_SIZE`` is the stack size of the single +initialization thread defined by the POSIX API Initialization Threads Table. **NOTES:** -If the stack size specified is greater than the configured minimum, -it must be accounted for in ``CONFIGURE_EXTRA_TASK_STACKS``. -See `Reserve Task/Thread Stack Memory Above Minimum`_ -for more information about ``CONFIGURE_EXTRA_TASK_STACKS``. +If the stack size specified is greater than the configured minimum, it must be +accounted for in ``CONFIGURE_EXTRA_TASK_STACKS``. See `Reserve Task/Thread +Stack Memory Above Minimum`_ for more information about +``CONFIGURE_EXTRA_TASK_STACKS``. .. COMMENT: === CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE === @@ -1555,21 +1569,22 @@ Not Using Generated POSIX Initialization Threads Table **DESCRIPTION:** -``CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE`` is defined if the -user wishes to define their own POSIX API Initialization Threads Table. -This table should be named ``POSIX_Initialization_threads``. +``CONFIGURE_POSIX_HAS_OWN_INIT_THREAD_TABLE`` is defined if the user wishes to +define their own POSIX API Initialization Threads Table. This table should be +named ``POSIX_Initialization_threads``. **NOTES:** -This is a seldom used configuration parameter. The most likely use case -is when an application desires to have more than one initialization task. +This is a seldom used configuration parameter. The most likely use case is when +an application desires to have more than one initialization task. .. COMMENT: === Basic System Information === Basic System Information ======================== -This section defines the general system configuration parameters supported by``<rtems/confdefs.h>``. +This section defines the general system configuration parameters supported by +``<rtems/confdefs.h>``. .. COMMENT: === CONFIGURE_UNIFIED_WORK_AREAS === @@ -1592,28 +1607,28 @@ Separate or Unified Work Areas Defined or undefined. *DEFAULT VALUE:* - This is not defined by default, which specifies that the C Program Heap - and the RTEMS Workspace will be separate. + This is not defined by default, which specifies that the C Program Heap and + the RTEMS Workspace will be separate. **DESCRIPTION:** -When defined, the C Program Heap and the RTEMS Workspace will be one pool -of memory. +When defined, the C Program Heap and the RTEMS Workspace will be one pool of +memory. -When not defined, there will be separate memory pools for the RTEMS -Workspace and C Program Heap. +When not defined, there will be separate memory pools for the RTEMS Workspace +and C Program Heap. **NOTES:** -Having separate pools does have some advantages in the event a task blows -a stack or writes outside its memory area. However, in low memory systems -the overhead of the two pools plus the potential for unused memory in -either pool is very undesirable. +Having separate pools does have some advantages in the event a task blows a +stack or writes outside its memory area. However, in low memory systems the +overhead of the two pools plus the potential for unused memory in either pool +is very undesirable. -In high memory environments, this is desirable when you want to use the -RTEMS "unlimited" objects option. You will be able to create objects -until you run out of all available memory rather then just until you -run out of RTEMS Workspace. +In high memory environments, this is desirable when you want to use the RTEMS +"unlimited" objects option. You will be able to create objects until you run +out of all available memory rather then just until you run out of RTEMS +Workspace. .. COMMENT: === CONFIGURE_MICROSECONDS_PER_TICK === @@ -1632,36 +1647,33 @@ Length of Each Clock Tick Positive. *DEFAULT VALUE:* - This is not defined by default. When not defined, - the clock tick quantum is configured to be 10,000 - microseconds which is ten (10) milliseconds. + This is not defined by default. When not defined, the clock tick quantum is + configured to be 10,000 microseconds which is ten (10) milliseconds. **DESCRIPTION:** This constant is used to specify the length of time between clock ticks. -When the clock tick quantum value is too low, the system will spend so -much time processing clock ticks that it does not have processing time -available to perform application work. In this case, the system will -become unresponsive. +When the clock tick quantum value is too low, the system will spend so much +time processing clock ticks that it does not have processing time available to +perform application work. In this case, the system will become unresponsive. -The lowest practical time quantum varies widely based upon the speed -of the target hardware and the architectural overhead associated with -interrupts. In general terms, you do not want to configure it lower than -is needed for the application. - -The clock tick quantum should be selected such that it all blocking and -delay times in the application are evenly divisible by it. Otherwise, -rounding errors will be introduced which may negatively impact the +The lowest practical time quantum varies widely based upon the speed of the +target hardware and the architectural overhead associated with interrupts. In +general terms, you do not want to configure it lower than is needed for the application. +The clock tick quantum should be selected such that it all blocking and delay +times in the application are evenly divisible by it. Otherwise, rounding errors +will be introduced which may negatively impact the application. + **NOTES:** -This configuration parameter has no impact if the Clock Tick Device -driver is not configured. +This configuration parameter has no impact if the Clock Tick Device driver is +not configured. -There may be BSP specific limits on the resolution or maximum value of -a clock tick quantum. +There may be BSP specific limits on the resolution or maximum value of a clock +tick quantum. .. COMMENT: === CONFIGURE_TICKS_PER_TIMESLICE === @@ -1684,13 +1696,13 @@ Specifying Timeslicing Quantum **DESCRIPTION:** -This configuration parameter specifies the length of the timeslice -quantum in ticks for each task. +This configuration parameter specifies the length of the timeslice quantum in +ticks for each task. **NOTES:** -This configuration parameter has no impact if the Clock Tick Device -driver is not configured. +This configuration parameter has no impact if the Clock Tick Device driver is +not configured. .. COMMENT: === CONFIGURE_MAXIMUM_PRIORITY === @@ -1712,31 +1724,31 @@ Specifying the Number of Thread Priority Levels valid values are 3, 7, 31, 63, 127, and 255. *DEFAULT VALUE:* - The default value is 255, because RTEMS must support 256 priority levels to be - compliant with various standards. These priorities range from zero (0) to 255. + The default value is 255, because RTEMS must support 256 priority levels to + be compliant with various standards. These priorities range from zero (0) + to 255. **DESCRIPTION:** -This configuration parameter specified the maximum numeric priority -of any task in the system and one less that the number of priority levels -in the system. +This configuration parameter specified the maximum numeric priority of any task +in the system and one less that the number of priority levels in the system. -Reducing the number of priorities in the system reduces the amount of -memory allocated from the RTEMS Workspace. +Reducing the number of priorities in the system reduces the amount of memory +allocated from the RTEMS Workspace. **NOTES:** -The numerically greatest priority is the logically lowest priority in -the system and will thus be used by the IDLE task. +The numerically greatest priority is the logically lowest priority in the +system and will thus be used by the IDLE task. -Priority zero (0) is reserved for internal use by RTEMS and is not -available to applications. +Priority zero (0) is reserved for internal use by RTEMS and is not available to +applications. -With some schedulers, reducing the number of priorities can reduce the -amount of memory used by the scheduler. For example, the Deterministic -Priority Scheduler (DPS) used by default uses three pointers of storage -per priority level. Reducing the number of priorities from 256 levels -to sixteen (16) can reduce memory usage by about three (3) kilobytes. +With some schedulers, reducing the number of priorities can reduce the amount +of memory used by the scheduler. For example, the Deterministic Priority +Scheduler (DPS) used by default uses three pointers of storage per priority +level. Reducing the number of priorities from 256 levels to sixteen (16) can +reduce memory usage by about three (3) kilobytes. .. COMMENT: === CONFIGURE_MINIMUM_TASK_STACK_SIZE === @@ -1760,22 +1772,22 @@ Specifying the Minimum Task Size **DESCRIPTION:** -The configuration parameter is set to the number of bytes the application -wants the minimum stack size to be for every task or thread in the system. +The configuration parameter is set to the number of bytes the application wants +the minimum stack size to be for every task or thread in the system. Adjusting this parameter should be done with caution. Examining the actual usage using the Stack Checker Usage Reporting facility is recommended. **NOTES:** -This parameter can be used to lower the minimum from that -recommended. This can be used in low memory systems to reduce memory -consumption for stacks. However, this must be done with caution as it -could increase the possibility of a blown task stack. +This parameter can be used to lower the minimum from that recommended. This can +be used in low memory systems to reduce memory consumption for stacks. However, +this must be done with caution as it could increase the possibility of a blown +task stack. -This parameter can be used to increase the minimum from that -recommended. This can be used in higher memory systems to reduce the -risk of stack overflow without performing analysis on actual consumption. +This parameter can be used to increase the minimum from that recommended. This +can be used in higher memory systems to reduce the risk of stack overflow +without performing analysis on actual consumption. .. COMMENT: === CONFIGURE_INTERRUPT_STACK_SIZE === @@ -1794,25 +1806,23 @@ Configuring the Size of the Interrupt Stack Positive. *DEFAULT VALUE:* - The default value is CONFIGURE_MINIMUM_TASK_STACK_SIZE, which is the minimum - interrupt stack size. + The default value is CONFIGURE_MINIMUM_TASK_STACK_SIZE, which is the + minimum interrupt stack size. **DESCRIPTION:** -``CONFIGURE_INTERRUPT_STACK_SIZE`` is set to the size of the -interrupt stack. The interrupt stack size is often set by the BSP but -since this memory may be allocated from the RTEMS Workspace, it must be -accounted for. +``CONFIGURE_INTERRUPT_STACK_SIZE`` is set to the size of the interrupt stack. +The interrupt stack size is often set by the BSP but since this memory may be +allocated from the RTEMS Workspace, it must be accounted for. **NOTES:** -In some BSPs, changing this constant does NOT change the -size of the interrupt stack, only the amount of memory -reserved for it. +In some BSPs, changing this constant does NOT change the size of the interrupt +stack, only the amount of memory reserved for it. -Patches which result in this constant only being used in memory -calculations when the interrupt stack is intended to be allocated -from the RTEMS Workspace would be welcomed by the RTEMS Project. +Patches which result in this constant only being used in memory calculations +when the interrupt stack is intended to be allocated from the RTEMS Workspace +would be welcomed by the RTEMS Project. .. COMMENT: === CONFIGURE_EXTRA_TASK_STACKS === @@ -1836,15 +1846,15 @@ Reserve Task/Thread Stack Memory Above Minimum **DESCRIPTION:** -This configuration parameter is set to the number of bytes the -applications wishes to add to the task stack requirements calculated -by ``<rtems/confdefs.h>``. +This configuration parameter is set to the number of bytes the applications +wishes to add to the task stack requirements calculated by +``<rtems/confdefs.h>``. **NOTES:** -This parameter is very important. If the application creates tasks with -stacks larger then the minimum, then that memory is NOT accounted for -by ``<rtems/confdefs.h>``. +This parameter is very important. If the application creates tasks with stacks +larger then the minimum, then that memory is NOT accounted for by +``<rtems/confdefs.h>``. .. COMMENT: === CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY === @@ -1866,19 +1876,19 @@ Automatically Zeroing the RTEMS Workspace and C Program Heap Defined or undefined. *DEFAULT VALUE:* - This is not defined by default, unless overridden by the BSP. - The default is *NOT* to zero out the RTEMS Workspace or C Program Heap. + This is not defined by default, unless overridden by the BSP. The default + is *NOT* to zero out the RTEMS Workspace or C Program Heap. **DESCRIPTION:** -This macro indicates whether RTEMS should zero the RTEMS Workspace and -C Program Heap as part of its initialization. If defined, the memory -regions are zeroed. Otherwise, they are not. +This macro indicates whether RTEMS should zero the RTEMS Workspace and C +Program Heap as part of its initialization. If defined, the memory regions are +zeroed. Otherwise, they are not. **NOTES:** -Zeroing memory can add significantly to system boot time. It is not -necessary for RTEMS but is often assumed by support libraries. +Zeroing memory can add significantly to system boot time. It is not necessary +for RTEMS but is often assumed by support libraries. .. COMMENT: === CONFIGURE_STACK_CHECKER_ENABLED === @@ -1900,15 +1910,15 @@ Enable The Task Stack Usage Checker **DESCRIPTION:** -This configuration parameter is defined when the application wishes to -enable run-time stack bounds checking. +This configuration parameter is defined when the application wishes to enable +run-time stack bounds checking. **NOTES:** In 4.9 and older, this configuration parameter was named``STACK_CHECKER_ON``. -This increases the time required to create tasks as well as adding -overhead to each context switch. +This increases the time required to create tasks as well as adding overhead to +each context switch. .. COMMENT: === CONFIGURE_INITIAL_EXTENSIONS === @@ -1930,9 +1940,9 @@ Specify Application Specific User Extensions **DESCRIPTION:** -If ``CONFIGURE_INITIAL_EXTENSIONS`` is defined by the application, -then this application specific set of initial extensions will be placed -in the initial extension table. +If ``CONFIGURE_INITIAL_EXTENSIONS`` is defined by the application, then this +application specific set of initial extensions will be placed in the initial +extension table. **NOTES:** @@ -1944,9 +1954,9 @@ Configuring Custom Task Stack Allocation ======================================== RTEMS allows the application or BSP to define its own allocation and -deallocation methods for task stacks. This can be used to place task -stacks in special areas of memory or to utilize a Memory Management Unit -so that stack overflows are detected in hardware. +deallocation methods for task stacks. This can be used to place task stacks in +special areas of memory or to utilize a Memory Management Unit so that stack +overflows are detected in hardware. .. COMMENT: === CONFIGURE_TASK_STACK_ALLOCATOR_INIT === @@ -1964,14 +1974,13 @@ Custom Task Stack Allocator Initialization Undefined, NULL or valid function pointer. *DEFAULT VALUE:* - The default value is NULL, which indicates that - task stacks will be allocated from the RTEMS Workspace. + The default value is NULL, which indicates that task stacks will be + allocated from the RTEMS Workspace. **DESCRIPTION:** -``CONFIGURE_TASK_STACK_ALLOCATOR_INIT`` configures the initialization -method for an application or BSP specific task stack allocation -implementation. +``CONFIGURE_TASK_STACK_ALLOCATOR_INIT`` configures the initialization method +for an application or BSP specific task stack allocation implementation. **NOTES:** @@ -2001,13 +2010,13 @@ Custom Task Stack Allocator Undefined or valid function pointer. *DEFAULT VALUE:* - The default value is ``_Workspace_Allocate``, which indicates - that task stacks will be allocated from the RTEMS Workspace. + The default value is ``_Workspace_Allocate``, which indicates that task + stacks will be allocated from the RTEMS Workspace. **DESCRIPTION:** -``CONFIGURE_TASK_STACK_ALLOCATOR`` may point to a user provided -routine to allocate task stacks. +``CONFIGURE_TASK_STACK_ALLOCATOR`` may point to a user provided routine to +allocate task stacks. **NOTES:** @@ -2036,13 +2045,13 @@ Custom Task Stack Deallocator Undefined or valid function pointer. *DEFAULT VALUE:* - The default value is ``_Workspace_Free``, which indicates that - task stacks will be allocated from the RTEMS Workspace. + The default value is ``_Workspace_Free``, which indicates that task stacks + will be allocated from the RTEMS Workspace. **DESCRIPTION:** -``CONFIGURE_TASK_STACK_DEALLOCATOR`` may point to a user provided -routine to free task stacks. +``CONFIGURE_TASK_STACK_DEALLOCATOR`` may point to a user provided routine to +free task stacks. **NOTES:** @@ -2059,8 +2068,8 @@ A correctly configured system must configure the following to be consistent: Configuring Memory for Classic API Message Buffers ================================================== -This section describes the configuration parameters related to specifying -the amount of memory reserved for Classic API Message Buffers. +This section describes the configuration parameters related to specifying the +amount of memory reserved for Classic API Message Buffers. .. COMMENT: === CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE === @@ -2083,18 +2092,18 @@ Calculate Memory for a Single Classic Message API Message Queue **DESCRIPTION:** -This is a helper macro which is used to assist in computing the total -amount of memory required for message buffers. Each message queue will -have its own configuration with maximum message size and maximum number -of pending messages. +This is a helper macro which is used to assist in computing the total amount of +memory required for message buffers. Each message queue will have its own +configuration with maximum message size and maximum number of pending messages. The interface for this macro is as follows: + .. code:: c CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE(max_messages, size_per) -Where ``max_messages`` is the maximum number of pending messages -and ``size_per`` is the size in bytes of the user message. +Where ``max_messages`` is the maximum number of pending messages and +``size_per`` is the size in bytes of the user message. **NOTES:** @@ -2126,30 +2135,33 @@ reserved for pending Classic API Message Queue buffers. **NOTES:** -The following illustrates how the help macro``CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE`` can be used to assist in -calculating the message buffer memory required. In this example, there -are two message queues used in this application. The first message -queue has maximum of 24 pending messages with the message structure -defined by the type ``one_message_type``. The other message queue -has maximum of 500 pending messages with the message structure defined -by the type ``other_message_type``. +The following illustrates how the help macro +``CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE`` can be used to assist in calculating +the message buffer memory required. In this example, there are two message +queues used in this application. The first message queue has maximum of 24 +pending messages with the message structure defined by the type +``one_message_type``. The other message queue has maximum of 500 pending +messages with the message structure defined by the type ``other_message_type``. + .. code:: c - #define CONFIGURE_MESSAGE_BUFFER_MEMORY \\ - (CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( \\ - 24, sizeof(one_message_type) + \\ - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( \\ - 500, sizeof(other_message_type) \\ - ) + #define CONFIGURE_MESSAGE_BUFFER_MEMORY \ + (CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( \ + 24, sizeof(one_message_type) \ + ) + \ + CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( \ + 500, sizeof(other_message_type) \ + ) .. COMMENT: === Seldom Used Configuration Parameters === Seldom Used Configuration Parameters ==================================== -This section describes configuration parameters supported by``<rtems/confdefs.h>`` which are seldom used by applications. These -parameters tend to be oriented to debugging system configurations -and providing work-arounds when the memory estimated by``<rtems/confdefs.h>`` is incorrect. +This section describes configuration parameters supported by +``<rtems/confdefs.h>`` which are seldom used by applications. These parameters +tend to be oriented to debugging system configurations and providing +work-arounds when the memory estimated by ``<rtems/confdefs.h>`` is incorrect. .. COMMENT: === CONFIGURE_MEMORY_OVERHEAD === @@ -2172,15 +2184,15 @@ Specify Memory Overhead **DESCRIPTION:** -Thie parameter is set to the number of kilobytes the application wishes -to add to the requirements calculated by ``<rtems/confdefs.h>``. +Thie parameter is set to the number of kilobytes the application wishes to add +to the requirements calculated by ``<rtems/confdefs.h>``. **NOTES:** -This configuration parameter should only be used when it is suspected that -a bug in ``<rtems/confdefs.h>`` has resulted in an underestimation. -Typically the memory allocation will be too low when an application does -not account for all message queue buffers or task stacks. +This configuration parameter should only be used when it is suspected that a +bug in ``<rtems/confdefs.h>`` has resulted in an underestimation. Typically +the memory allocation will be too low when an application does not account for +all message queue buffers or task stacks. .. COMMENT: === CONFIGURE_HAS_OWN_CONFIGURATION_TABLE === @@ -2202,8 +2214,8 @@ Do Not Generate Configuration Information **DESCRIPTION:** -This configuration parameter should only be defined if the application -is providing their own complete set of configuration tables. +This configuration parameter should only be defined if the application is +providing their own complete set of configuration tables. **NOTES:** @@ -2214,8 +2226,8 @@ None. C Library Support Configuration =============================== -This section defines the file system and IO library -related configuration parameters supported by``<rtems/confdefs.h>``. +This section defines the file system and IO library related configuration +parameters supported by ``<rtems/confdefs.h>``. .. COMMENT: === CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS === @@ -2235,9 +2247,9 @@ Specify Maximum Number of File Descriptors *DEFAULT VALUE:* If ``CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER`` is defined, then the - default value is 3, otherwise the default value is 0. - Three file descriptors allows RTEMS to support standard input, output, and - error I/O streams on ``/dev/console``. + default value is 3, otherwise the default value is 0. Three file + descriptors allows RTEMS to support standard input, output, and error I/O + streams on ``/dev/console``. **DESCRIPTION:** @@ -2264,19 +2276,18 @@ Disable POSIX Termios Support Defined or undefined. *DEFAULT VALUE:* - This is not defined by default, and resources are reserved for the - termios functionality. + This is not defined by default, and resources are reserved for the termios + functionality. **DESCRIPTION:** -This configuration parameter is defined if the software implementing -POSIX termios functionality is not going to be used by this application. +This configuration parameter is defined if the software implementing POSIX +termios functionality is not going to be used by this application. **NOTES:** -The termios support library should not be included in an application -executable unless it is directly referenced by the application or a -device driver. +The termios support library should not be included in an application executable +unless it is directly referenced by the application or a device driver. .. COMMENT: === CONFIGURE_NUMBER_OF_TERMIOS_PORTS === @@ -2298,16 +2309,14 @@ Specify Maximum Termios Ports **DESCRIPTION:** -This configuration parameter is set to the number of ports using the -termios functionality. Each concurrently active termios port requires -resources. +This configuration parameter is set to the number of ports using the termios +functionality. Each concurrently active termios port requires resources. **NOTES:** -If the application will be using serial ports -including, but not limited to, the Console Device -(e.g. ``CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER``), then it is -highly likely that this configuration parameter should NOT be is defined. +If the application will be using serial ports including, but not limited to, +the Console Device (e.g. ``CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER``), then +it is highly likely that this configuration parameter should NOT be is defined. .. COMMENT: === File System Configuration Parameters === @@ -2336,11 +2345,11 @@ Providing Application Specific Mount Table **DESCRIPTION:** -This configuration parameter is defined when the application -provides their own filesystem mount table. The mount table is an -array of ``rtems_filesystem_mount_table_t`` entries pointed -to by the global variable ``rtems_filesystem_mount_table``. -The number of entries in this table is in an integer variable named``rtems_filesystem_mount_table_t``. +This configuration parameter is defined when the application provides their own +filesystem mount table. The mount table is an array of +``rtems_filesystem_mount_table_t`` entries pointed to by the global variable +``rtems_filesystem_mount_table``. The number of entries in this table is in an +integer variable named ``rtems_filesystem_mount_table_t``. .. COMMENT: XXX - is the variable name for the count right? @@ -2366,22 +2375,21 @@ Configure devFS as Root File System Defined or undefined. *DEFAULT VALUE:* - This is not defined by default. If no other root file system - configuration parameters are specified, the IMFS will be used as the - root file system. + This is not defined by default. If no other root file system configuration + parameters are specified, the IMFS will be used as the root file system. **DESCRIPTION:** -This configuration parameter is defined if the application wishes to -use the device-only filesytem as the root file system. +This configuration parameter is defined if the application wishes to use the +device-only filesytem as the root file system. **NOTES:** The device-only filesystem supports only device nodes and is smaller in executable code size than the full IMFS and miniIMFS. -The devFS is comparable in functionality to the pseudo-filesystem name -space provided before RTEMS release 4.5.0. +The devFS is comparable in functionality to the pseudo-filesystem name space +provided before RTEMS release 4.5.0. .. COMMENT: === CONFIGURE_MAXIMUM_DEVICES === @@ -2399,19 +2407,20 @@ Specifying Maximum Devices for devFS Positive. *DEFAULT VALUE:* - If ``BSP_MAXIMUM_DEVICES`` is defined, then the - default value is ``BSP_MAXIMUM_DEVICES``, otherwise the default value is 4. + If ``BSP_MAXIMUM_DEVICES`` is defined, then the default value is + ``BSP_MAXIMUM_DEVICES``, otherwise the default value is 4. **DESCRIPTION:** -``CONFIGURE_MAXIMUM_DEVICES`` is defined to the number of -individual devices that may be registered in the device file system (devFS). +``CONFIGURE_MAXIMUM_DEVICES`` is defined to the number of individual devices +that may be registered in the device file system (devFS). **NOTES:** This option is specific to the device file system (devFS) and should not be confused with the ``CONFIGURE_MAXIMUM_DRIVERS`` option. This parameter only -impacts the devFS and thus is only used by ``<rtems/confdefs.h>`` when``CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM`` is specified. +impacts the devFS and thus is only used by ``<rtems/confdefs.h>`` when +``CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM`` is specified. .. COMMENT: === CONFIGURE_APPLICATION_DISABLE_FILESYSTEM === @@ -2429,15 +2438,14 @@ Disable File System Support Defined or undefined. *DEFAULT VALUE:* - This is not defined by default. If no other root file system - configuration parameters are specified, the IMFS will be used as the - root file system. + This is not defined by default. If no other root file system configuration + parameters are specified, the IMFS will be used as the root file system. **DESCRIPTION:** -This configuration parameter is defined if the application dose not -intend to use any kind of filesystem support. This include the device -infrastructure necessary to support ``printf()``. +This configuration parameter is defined if the application dose not intend to +use any kind of filesystem support. This include the device infrastructure +necessary to support ``printf()``. **NOTES:** @@ -2496,8 +2504,8 @@ Specify Block Size for IMFS *RANGE:* Valid values for this configuration parameter are a power of two (2) - between 16 and 512 inclusive. In other words, valid values are 16, - 32, 64, 128, 256,and 512. + between 16 and 512 inclusive. In other words, valid values are 16, 32, 64, + 128, 256,and 512. *DEFAULT VALUE:* The default IMFS block size is 128 bytes. @@ -2505,36 +2513,31 @@ Specify Block Size for IMFS **DESCRIPTION:** This configuration parameter specifies the block size for in-memory files -managed by the IMFS. The configured block size has two impacts. The first -is the average amount of unused memory in the last block of each file. For -example, when the block size is 512, on average one-half of the last block -of each file will remain unused and the memory is wasted. In contrast, -when the block size is 16, the average unused memory per file is only -8 bytes. However, it requires more allocations for the same size file -and thus more overhead per block for the dynamic memory management. - -Second, the block size has an impact on the maximum size file that can -be stored in the IMFS. With smaller block size, the maximum file size -is correspondingly smaller. The following shows the maximum file size -possible based on the configured block size: - -- when the block size is 16 bytes, the maximum file size is 1,328 - bytes. +managed by the IMFS. The configured block size has two impacts. The first is +the average amount of unused memory in the last block of each file. For +example, when the block size is 512, on average one-half of the last block of +each file will remain unused and the memory is wasted. In contrast, when the +block size is 16, the average unused memory per file is only 8 bytes. However, +it requires more allocations for the same size file and thus more overhead per +block for the dynamic memory management. -- when the block size is 32 bytes, the maximum file size is 18,656 - bytes. +Second, the block size has an impact on the maximum size file that can be +stored in the IMFS. With smaller block size, the maximum file size is +correspondingly smaller. The following shows the maximum file size possible +based on the configured block size: -- when the block size is 64 bytes, the maximum file size is 279,488 - bytes. +- when the block size is 16 bytes, the maximum file size is 1,328 bytes. -- when the block size is 128 bytes, the maximum file size is - 4,329,344 bytes. +- when the block size is 32 bytes, the maximum file size is 18,656 bytes. -- when the block size is 256 bytes, the maximum file size is - 68,173,568 bytes. +- when the block size is 64 bytes, the maximum file size is 279,488 bytes. -- when the block size is 512 bytes, the maximum file size is - 1,082,195,456 bytes. +- when the block size is 128 bytes, the maximum file size is 4,329,344 bytes. + +- when the block size is 256 bytes, the maximum file size is 68,173,568 bytes. + +- when the block size is 512 bytes, the maximum file size is 1,082,195,456 + bytes. .. COMMENT: === CONFIGURE_IMFS_DISABLE_CHOWN === @@ -3191,8 +3194,9 @@ None. BSP Specific Settings ===================== -This section describes BSP specific configuration settings used by``<rtems/confdefs.h>``. The BSP specific configuration settings are -defined in ``<bsp.h>``. +This section describes BSP specific configuration settings used by +``<rtems/confdefs.h>``. The BSP specific configuration settings are defined in +``<bsp.h>``. .. COMMENT: === Disable BSP Settings === @@ -3214,8 +3218,8 @@ Disable BSP Configuration Settings **DESCRIPTION:** -All BSP specific configuration settings can be disabled by the application -with the ``CONFIGURE_DISABLE_BSP_SETTINGS`` option. +All BSP specific configuration settings can be disabled by the application with +the ``CONFIGURE_DISABLE_BSP_SETTINGS`` option. **NOTES:** @@ -3241,17 +3245,17 @@ Specify BSP Supports sbrk() **DESCRIPTION:** -This configuration parameter is defined by a BSP to indicate that it -does not allocate all available memory to the C Program Heap used by -the Malloc Family of routines. +This configuration parameter is defined by a BSP to indicate that it does not +allocate all available memory to the C Program Heap used by the Malloc Family +of routines. -If defined, when ``malloc()`` is unable to allocate memory, it will -call the BSP supplied ``sbrk()`` to obtain more memory. +If defined, when ``malloc()`` is unable to allocate memory, it will call the +BSP supplied ``sbrk()`` to obtain more memory. **NOTES:** -This parameter should not be defined by the application. Only the BSP -knows how it allocates memory to the C Program Heap. +This parameter should not be defined by the application. Only the BSP knows how +it allocates memory to the C Program Heap. .. COMMENT: === BSP_IDLE_TASK_BODY === @@ -3273,14 +3277,15 @@ Specify BSP Specific Idle Task **DESCRIPTION:** -If ``BSP_IDLE_TASK_BODY`` is defined by the BSP and``CONFIGURE_IDLE_TASK_BODY`` is not defined by the application, -then this BSP specific idle task body will be used. +If ``BSP_IDLE_TASK_BODY`` is defined by the BSP and +``CONFIGURE_IDLE_TASK_BODY`` is not defined by the application, then this BSP +specific idle task body will be used. **NOTES:** -As it has knowledge of the specific CPU model, system controller logic, -and peripheral buses, a BSP specific IDLE task may be capable of turning -components off to save power during extended periods of no task activity +As it has knowledge of the specific CPU model, system controller logic, and +peripheral buses, a BSP specific IDLE task may be capable of turning components +off to save power during extended periods of no task activity .. COMMENT: === BSP_IDLE_TASK_STACK_SIZE === @@ -3302,8 +3307,9 @@ Specify BSP Suggested Value for IDLE Task Stack Size **DESCRIPTION:** -If ``BSP_IDLE_TASK_STACK_SIZE`` is defined by the BSP and``CONFIGURE_IDLE_TASK_STACK_SIZE`` is not defined by the application, -then this BSP suggested idle task stack size will be used. +If ``BSP_IDLE_TASK_STACK_SIZE`` is defined by the BSP and +``CONFIGURE_IDLE_TASK_STACK_SIZE`` is not defined by the application, then this +BSP suggested idle task stack size will be used. **NOTES:** @@ -3339,9 +3345,9 @@ Specify BSP Specific User Extensions **DESCRIPTION:** -If ``BSP_INITIAL_EXTENSION`` is defined by the BSP, then this BSP -specific initial extension will be placed as the last entry in the initial -extension table. +If ``BSP_INITIAL_EXTENSION`` is defined by the BSP, then this BSP specific +initial extension will be placed as the last entry in the initial extension +table. **NOTES:** @@ -3367,8 +3373,9 @@ Specifying BSP Specific Interrupt Stack Size **DESCRIPTION:** -If ``BSP_INTERRUPT_STACK_SIZE`` is defined by the BSP and``CONFIGURE_INTERRUPT_STACK_SIZE`` is not defined by the application, -then this BSP specific interrupt stack size will be used. +If ``BSP_INTERRUPT_STACK_SIZE`` is defined by the BSP and +``CONFIGURE_INTERRUPT_STACK_SIZE`` is not defined by the application, then this +BSP specific interrupt stack size will be used. **NOTES:** @@ -3394,14 +3401,16 @@ Specifying BSP Specific Maximum Devices **DESCRIPTION:** -If ``BSP_MAXIMUM_DEVICES`` is defined by the BSP and``CONFIGURE_MAXIMUM_DEVICES`` is not defined by the application, -then this BSP specific maximum device count will be used. +If ``BSP_MAXIMUM_DEVICES`` is defined by the BSP and +``CONFIGURE_MAXIMUM_DEVICES`` is not defined by the application, then this BSP +specific maximum device count will be used. **NOTES:** This option is specific to the device file system (devFS) and should not be confused with the ``CONFIGURE_MAXIMUM_DRIVERS`` option. This parameter only -impacts the devFS and thus is only used by ``<rtems/confdefs.h>`` when``CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM`` is specified. +impacts the devFS and thus is only used by ``<rtems/confdefs.h>`` when +``CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM`` is specified. .. COMMENT: === BSP_ZERO_WORKSPACE_AUTOMATICALLY === @@ -3423,13 +3432,14 @@ BSP Recommends RTEMS Workspace be Cleared **DESCRIPTION:** -If ``BSP_ZERO_WORKSPACE_AUTOMATICALLY`` is defined by the BSP and``CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY`` is not defined by the -application, then the workspace will be zeroed automatically. +If ``BSP_ZERO_WORKSPACE_AUTOMATICALLY`` is defined by the BSP and +``CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY`` is not defined by the application, +then the workspace will be zeroed automatically. **NOTES:** -Zeroing memory can add significantly to system boot time. It is not -necessary for RTEMS but is often assumed by support libraries. +Zeroing memory can add significantly to system boot time. It is not necessary +for RTEMS but is often assumed by support libraries. .. COMMENT: === CONFIGURE_BSP_PREREQUISITE_DRIVERS === @@ -3451,25 +3461,24 @@ Specify BSP Prerequisite Drivers **DESCRIPTION:** -``CONFIGURE_BSP_PREREQUISITE_DRIVERS`` is defined if the BSP has device -drivers it needs to include in the Device Driver Table. This should be -defined to the set of device driver entries that will be placed in the -table at the *FRONT* of the Device Driver Table and initialized before -any other drivers *INCLUDING* any application prerequisite drivers. +``CONFIGURE_BSP_PREREQUISITE_DRIVERS`` is defined if the BSP has device drivers +it needs to include in the Device Driver Table. This should be defined to the +set of device driver entries that will be placed in the table at the *FRONT* of +the Device Driver Table and initialized before any other drivers *INCLUDING* +any application prerequisite drivers. **NOTES:** -``CONFIGURE_BSP_PREREQUISITE_DRIVERS`` is typically used by BSPs -to configure common infrastructure such as bus controllers or probe -for devices. +``CONFIGURE_BSP_PREREQUISITE_DRIVERS`` is typically used by BSPs to configure +common infrastructure such as bus controllers or probe for devices. .. COMMENT: === Idle Task Configuration === Idle Task Configuration ======================= -This section defines the IDLE task related configuration parameters -supported by ``<rtems/confdefs.h>``. +This section defines the IDLE task related configuration parameters supported +by ``<rtems/confdefs.h>``. .. COMMENT: === CONFIGURE_IDLE_TASK_BODY === @@ -3491,9 +3500,9 @@ Specify Application Specific Idle Task Body **DESCRIPTION:** -``CONFIGURE_IDLE_TASK_BODY`` is set to the function name corresponding -to the application specific IDLE thread body. If not specified, the -BSP or RTEMS default IDLE thread body will be used. +``CONFIGURE_IDLE_TASK_BODY`` is set to the function name corresponding to the +application specific IDLE thread body. If not specified, the BSP or RTEMS +default IDLE thread body will be used. **NOTES:** @@ -3547,17 +3556,16 @@ Specify Idle Task Performs Application Initialization **DESCRIPTION:** -``CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION`` is set to -indicate that the user has configured *NO* user initialization tasks -or threads and that the user provided IDLE task will perform application -initialization and then transform itself into an IDLE task. +``CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION`` is set to indicate that the +user has configured *NO* user initialization tasks or threads and that the user +provided IDLE task will perform application initialization and then transform +itself into an IDLE task. **NOTES:** -If you use this option be careful, the user IDLE task *CANNOT* block -at all during the initialization sequence. Further, once application -initialization is complete, it must make itself preemptible and enter -an IDLE body loop. +If you use this option be careful, the user IDLE task *CANNOT* block at all +during the initialization sequence. Further, once application initialization +is complete, it must make itself preemptible and enter an IDLE body loop. The IDLE task must run at the lowest priority of all tasks in the system. @@ -3567,14 +3575,14 @@ Scheduler Algorithm Configuration ================================= This section defines the configuration parameters related to selecting a -scheduling algorithm for an application. For the schedulers built into -RTEMS, the configuration is straightforward. All that is required is -to define the configuration macro which specifies which scheduler you -want for in your application. The currently available schedulers are: +scheduling algorithm for an application. For the schedulers built into RTEMS, +the configuration is straightforward. All that is required is to define the +configuration macro which specifies which scheduler you want for in your +application. The currently available schedulers are: -The pluggable scheduler interface also enables the user to provide their -own scheduling algorithm. If you choose to do this, you must define -multiple configuration macros. +The pluggable scheduler interface also enables the user to provide their own +scheduling algorithm. If you choose to do this, you must define multiple +configuration macros. .. COMMENT: === CONFIGURE_SCHEDULER_PRIORITY === @@ -3592,22 +3600,22 @@ Use Deterministic Priority Scheduler Defined or undefined. *DEFAULT VALUE:* - This is defined by default. - This is the default scheduler and specifying this - configuration parameter is redundant. + This is defined by default. This is the default scheduler and specifying + this configuration parameter is redundant. **DESCRIPTION:** -The Deterministic Priority Scheduler is the default scheduler in RTEMS -for uni-processor applications and is designed for predictable performance -under the highest loads. It can block or unblock a thread in a constant -amount of time. This scheduler requires a variable amount of memory -based upon the number of priorities configured in the system. +The Deterministic Priority Scheduler is the default scheduler in RTEMS for +uni-processor applications and is designed for predictable performance under +the highest loads. It can block or unblock a thread in a constant amount of +time. This scheduler requires a variable amount of memory based upon the +number of priorities configured in the system. **NOTES:** -This scheduler may be explicitly selected by defining``CONFIGURE_SCHEDULER_PRIORITY`` although this is equivalent to the -default behavior. +This scheduler may be explicitly selected by defining +``CONFIGURE_SCHEDULER_PRIORITY`` although this is equivalent to the default +behavior. .. COMMENT: === CONFIGURE_SCHEDULER_SIMPLE === @@ -3629,15 +3637,16 @@ Use Simple Priority Scheduler **DESCRIPTION:** -When defined, the Simple Priority Scheduler is used at the thread -scheduling algorithm. This is an alternative scheduler in RTEMS. -It is designed to provide the same task scheduling behaviour as the -Deterministic Priority Scheduler while being simpler in implementation -and uses less memory for data management. It maintains a single sorted -list of all ready threads. Thus blocking or unblocking a thread is not -a constant time operation with this scheduler. +When defined, the Simple Priority Scheduler is used at the thread scheduling +algorithm. This is an alternative scheduler in RTEMS. It is designed to +provide the same task scheduling behaviour as the Deterministic Priority +Scheduler while being simpler in implementation and uses less memory for data +management. It maintains a single sorted list of all ready threads. Thus +blocking or unblocking a thread is not a constant time operation with this +scheduler. -This scheduler may be explicitly selected by defining``CONFIGURE_SCHEDULER_SIMPLE``. +This scheduler may be explicitly selected by defining +``CONFIGURE_SCHEDULER_SIMPLE``. **NOTES:** @@ -3665,15 +3674,16 @@ Use Earliest Deadline First Scheduler The Earliest Deadline First Scheduler (EDF) is an alternative scheduler in RTEMS for uni-processor applications. The EDF schedules tasks with dynamic -priorities equal to deadlines. The deadlines are declared using only -Rate Monotonic manager which handles periodic behavior. Period is always -equal to deadline. If a task does not have any deadline declared or the -deadline is cancelled, the task is considered a background task which is -scheduled in case no deadline-driven tasks are ready to run. Moreover, -multiple background tasks are scheduled according their priority assigned -upon initialization. All ready tasks reside in a single ready queue. +priorities equal to deadlines. The deadlines are declared using only Rate +Monotonic manager which handles periodic behavior. Period is always equal to +deadline. If a task does not have any deadline declared or the deadline is +cancelled, the task is considered a background task which is scheduled in case +no deadline-driven tasks are ready to run. Moreover, multiple background tasks +are scheduled according their priority assigned upon initialization. All ready +tasks reside in a single ready queue. -This scheduler may be explicitly selected by defining``CONFIGURE_SCHEDULER_EDF``. +This scheduler may be explicitly selected by defining +``CONFIGURE_SCHEDULER_EDF``. **NOTES:** @@ -3699,13 +3709,14 @@ Use Constant Bandwidth Server Scheduler **DESCRIPTION:** -The Constant Bandwidth Server Scheduler (CBS) is an alternative scheduler -in RTEMS for uni-processor applications. The CBS is a budget aware extension -of EDF scheduler. The goal of this scheduler is to ensure temporal -isolation of tasks. The CBS is equipped with a set of additional rules -and provides with an extensive API. +The Constant Bandwidth Server Scheduler (CBS) is an alternative scheduler in +RTEMS for uni-processor applications. The CBS is a budget aware extension of +EDF scheduler. The goal of this scheduler is to ensure temporal isolation of +tasks. The CBS is equipped with a set of additional rules and provides with an +extensive API. -This scheduler may be explicitly selected by defining``CONFIGURE_SCHEDULER_CBS``. +This scheduler may be explicitly selected by defining +``CONFIGURE_SCHEDULER_CBS``. .. COMMENT: XXX - add cross reference to API chapter @@ -3737,16 +3748,16 @@ The Deterministic Priority SMP Scheduler is derived from the Deterministic Priority Scheduler but is capable of scheduling threads across multiple processors. -In a configuration with SMP enabled at configure time, it may be -explicitly selected by defining ``CONFIGURE_SCHEDULER_PRIORITY_SMP``. +In a configuration with SMP enabled at configure time, it may be explicitly +selected by defining ``CONFIGURE_SCHEDULER_PRIORITY_SMP``. **NOTES:** This scheduler is only available when RTEMS is configured with SMP support enabled. -This scheduler is currently the default in SMP configurations and is -only selected when ``CONFIGURE_SMP_APPLICATION`` is defined. +This scheduler is currently the default in SMP configurations and is only +selected when ``CONFIGURE_SMP_APPLICATION`` is defined. .. COMMENT: === CONFIGURE_SCHEDULER_SIMPLE_SMP === @@ -3768,26 +3779,26 @@ Use Simple SMP Priority Scheduler **DESCRIPTION:** -The Simple SMP Priority Scheduler is derived from the Simple Priority -Scheduler but is capable of scheduling threads across multiple processors. -It is designed to provide the same task scheduling behaviour as the -Deterministic Priority Scheduler while distributing threads across -multiple processors. Being based upon the Simple Priority Scheduler, it also -maintains a single sorted list of all ready threads. Thus blocking or -unblocking a thread is not a constant time operation with this scheduler. +The Simple SMP Priority Scheduler is derived from the Simple Priority Scheduler +but is capable of scheduling threads across multiple processors. It is +designed to provide the same task scheduling behaviour as the Deterministic +Priority Scheduler while distributing threads across multiple processors. +Being based upon the Simple Priority Scheduler, it also maintains a single +sorted list of all ready threads. Thus blocking or unblocking a thread is not +a constant time operation with this scheduler. In addition, when allocating threads to processors, the algorithm is not -constant time. This algorithm was not designed with efficiency as a -primary design goal. Its primary design goal was to provide an SMP-aware -scheduling algorithm that is simple to understand. +constant time. This algorithm was not designed with efficiency as a primary +design goal. Its primary design goal was to provide an SMP-aware scheduling +algorithm that is simple to understand. -In a configuration with SMP enabled at configure time, it may be -explicitly selected by defining ``CONFIGURE_SCHEDULER_SIMPLE_SMP``. +In a configuration with SMP enabled at configure time, it may be explicitly +selected by defining ``CONFIGURE_SCHEDULER_SIMPLE_SMP``. **NOTES:** -This scheduler is only available when RTEMS is configured with SMP -support enabled. +This scheduler is only available when RTEMS is configured with SMP support +enabled. .. COMMENT: === Configuring a Scheduler Name === @@ -3806,17 +3817,18 @@ Configuring a Scheduler Name *DEFAULT VALUE:* The default name is - - ``"UCBS"`` for the Uni-Processor CBS scheduler, - - ``"UEDF"`` for the Uni-Processor EDF scheduler, - - ``"UPD "`` for the Uni-Processor Deterministic Priority scheduler, - - ``"UPS "`` for the Uni-Processor Simple Priority scheduler, - - ``"MPA "`` for the Multi-Processor Priority Affinity scheduler, and - - ``"MPD "`` for the Multi-Processor Deterministic Priority scheduler, and - - ``"MPS "`` for the Multi-Processor Simple Priority scheduler. + - ``"UCBS"`` for the Uni-Processor CBS scheduler, + - ``"UEDF"`` for the Uni-Processor EDF scheduler, + - ``"UPD "`` for the Uni-Processor Deterministic Priority scheduler, + - ``"UPS "`` for the Uni-Processor Simple Priority scheduler, + - ``"MPA "`` for the Multi-Processor Priority Affinity scheduler, and + - ``"MPD "`` for the Multi-Processor Deterministic Priority scheduler, and + - ``"MPS "`` for the Multi-Processor Simple Priority scheduler. **DESCRIPTION:** -Schedulers can be identified via ``rtems_scheduler_ident``. The name of the scheduler is determined by the configuration. +Schedulers can be identified via ``rtems_scheduler_ident``. The name of the +scheduler is determined by the configuration. **NOTES:** @@ -3842,28 +3854,29 @@ Configuring a User Provided Scheduler **DESCRIPTION:** -RTEMS allows the application to provide its own task/thread -scheduling algorithm. In order to do this, one must define``CONFIGURE_SCHEDULER_USER`` to indicate the application provides its -own scheduling algorithm. If ``CONFIGURE_SCHEDULER_USER`` is defined -then the following additional macros must be defined: +RTEMS allows the application to provide its own task/thread scheduling +algorithm. In order to do this, one must define ``CONFIGURE_SCHEDULER_USER`` to +indicate the application provides its own scheduling algorithm. If +``CONFIGURE_SCHEDULER_USER`` is defined then the following additional macros +must be defined: -- ``CONFIGURE_SCHEDULER_CONTEXT`` must be defined to a static definition - of the scheduler context of the user scheduler. +- ``CONFIGURE_SCHEDULER_CONTEXT`` must be defined to a static definition of the + scheduler context of the user scheduler. -- ``CONFIGURE_SCHEDULER_CONTROLS`` must be defined to a scheduler - control initializer for the user scheduler. +- ``CONFIGURE_SCHEDULER_CONTROLS`` must be defined to a scheduler control + initializer for the user scheduler. -- ``CONFIGURE_SCHEDULER_USER_PER_THREAD`` must be defined to the type of - the per-thread information of the user scheduler. +- ``CONFIGURE_SCHEDULER_USER_PER_THREAD`` must be defined to the type of the + per-thread information of the user scheduler. **NOTES:** -At this time, the mechanics and requirements for writing a -new scheduler are evolving and not fully documented. It is -recommended that you look at the existing Deterministic Priority -Scheduler in ``cpukit/score/src/schedulerpriority*.c`` for -guidance. For guidance on the configuration macros, please examine``cpukit/sapi/include/confdefs.h`` for how these are defined for the -Deterministic Priority Scheduler. +At this time, the mechanics and requirements for writing a new scheduler are +evolving and not fully documented. It is recommended that you look at the +existing Deterministic Priority Scheduler in +``cpukit/score/src/schedulerpriority*.c`` for guidance. For guidance on the +configuration macros, please examine ``cpukit/sapi/include/confdefs.h`` for how +these are defined for the Deterministic Priority Scheduler. .. COMMENT: === Configuring Clustered Schedulers === @@ -3881,8 +3894,8 @@ and thus avoid expensive cache synchronization traffic. We have clustered scheduling in case the set of processors of a system is partitioned into non-empty pairwise-disjoint subsets. These subsets are called clusters. Clusters with a cardinality of one are partitions. Each cluster is -owned by exactly one scheduler instance. In order to use clustered -scheduling the application designer has to answer two questions. +owned by exactly one scheduler instance. In order to use clustered scheduling +the application designer has to answer two questions. # How is the set of processors partitioned into clusters? @@ -3902,9 +3915,9 @@ following defines This is necessary to calculate the per-thread overhead introduced by the schedulers. After these definitions the configuration file must ``#include -<rtems/scheduler.h>`` to have access to scheduler specific configuration macros. -Each scheduler needs a context to store state information at run-time. To -provide a context for each scheduler is the next step. Use the following +<rtems/scheduler.h>`` to have access to scheduler specific configuration +macros. Each scheduler needs a context to store state information at run-time. +To provide a context for each scheduler is the next step. Use the following macros to create scheduler contexts - ``RTEMS_SCHEDULER_CONTEXT_PRIORITY_SMP(name, prio_count)``, @@ -3913,11 +3926,11 @@ macros to create scheduler contexts - ``RTEMS_SCHEDULER_CONTEXT_PRIORITY_AFFINITY_SMP(name, prio_count)``. -The ``name`` parameter is used as part of a designator for a global -variable, so the usual C/C++ designator rules apply. Additional parameters are -scheduler specific. The schedulers are registered in the system via the -scheduler table. To create the scheduler table define``CONFIGURE_SCHEDULER_CONTROLS`` to a list of the following scheduler -control initializers +The ``name`` parameter is used as part of a designator for a global variable, +so the usual C/C++ designator rules apply. Additional parameters are scheduler +specific. The schedulers are registered in the system via the scheduler table. +To create the scheduler table define ``CONFIGURE_SCHEDULER_CONTROLS`` to a list +of the following scheduler control initializers - ``RTEMS_SCHEDULER_CONTROL_PRIORITY_SMP(name, obj_name)``, @@ -3925,23 +3938,24 @@ control initializers - ``RTEMS_SCHEDULER_CONTROL_PRIORITY_AFFINITY_SMP(name, obj_name)``. -The ``name`` parameter must correspond to the parameter defining the -scheduler context. The ``obj_name`` determines the scheduler object name -and can be used in ``rtems_scheduler_ident()`` to get the scheduler object -identifier. - -The last step is to define which processor uses which scheduler. -For this purpose a scheduler assignment table must be defined. The entry count -of this table must be equal to the configured maximum processors -(``CONFIGURE_SMP_MAXIMUM_PROCESSORS``). A processor assignment to a -scheduler can be optional or mandatory. The boot processor must have a -scheduler assigned. In case the system needs more mandatory processors than -available then a fatal run-time error will occur. To specify the scheduler -assignments define ``CONFIGURE_SMP_SCHEDULER_ASSIGNMENTS`` to a list of``RTEMS_SCHEDULER_ASSIGN(index, attr)`` and``RTEMS_SCHEDULER_ASSIGN_NO_SCHEDULER`` macros. The ``index`` parameter -must be a valid index into the scheduler table. The ``attr`` parameter -defines the scheduler assignment attributes. By default a scheduler assignment -to a processor is optional. For the scheduler assignment attribute use one of -the mutually exclusive variants +The ``name`` parameter must correspond to the parameter defining the scheduler +context. The ``obj_name`` determines the scheduler object name and can be used +in ``rtems_scheduler_ident()`` to get the scheduler object identifier. + +The last step is to define which processor uses which scheduler. For this +purpose a scheduler assignment table must be defined. The entry count of this +table must be equal to the configured maximum processors +(``CONFIGURE_SMP_MAXIMUM_PROCESSORS``). A processor assignment to a scheduler +can be optional or mandatory. The boot processor must have a scheduler +assigned. In case the system needs more mandatory processors than available +then a fatal run-time error will occur. To specify the scheduler assignments +define ``CONFIGURE_SMP_SCHEDULER_ASSIGNMENTS`` to a list of +``RTEMS_SCHEDULER_ASSIGN(index, attr)`` and +``RTEMS_SCHEDULER_ASSIGN_NO_SCHEDULER`` macros. The ``index`` parameter must +be a valid index into the scheduler table. The ``attr`` parameter defines the +scheduler assignment attributes. By default a scheduler assignment to a +processor is optional. For the scheduler assignment attribute use one of the +mutually exclusive variants - ``RTEMS_SCHEDULER_ASSIGN_DEFAULT``, @@ -3951,26 +3965,28 @@ the mutually exclusive variants **ERRORS:** -In case one of the scheduler indices in``CONFIGURE_SMP_SCHEDULER_ASSIGNMENTS`` is invalid a link-time error will -occur with an undefined reference to ``RTEMS_SCHEDULER_INVALID_INDEX``. +In case one of the scheduler indices in``CONFIGURE_SMP_SCHEDULER_ASSIGNMENTS`` +is invalid a link-time error will occur with an undefined reference to +``RTEMS_SCHEDULER_INVALID_INDEX``. -Some fatal errors may occur in case of scheduler configuration inconsistencies or a lack -of processors on the system. The fatal source is``RTEMS_FATAL_SOURCE_SMP``. None of the errors is internal. +Some fatal errors may occur in case of scheduler configuration inconsistencies +or a lack of processors on the system. The fatal source is +``RTEMS_FATAL_SOURCE_SMP``. None of the errors is internal. -- ``SMP_FATAL_BOOT_PROCESSOR_NOT_ASSIGNED_TO_SCHEDULER`` - the boot - processor must have a scheduler assigned. +- ``SMP_FATAL_BOOT_PROCESSOR_NOT_ASSIGNED_TO_SCHEDULER`` - the boot processor + must have a scheduler assigned. -- ``SMP_FATAL_MANDATORY_PROCESSOR_NOT_PRESENT`` - there exists a - mandatory processor beyond the range of physically or virtually available - processors. The processor demand must be reduced for this system. +- ``SMP_FATAL_MANDATORY_PROCESSOR_NOT_PRESENT`` - there exists a mandatory + processor beyond the range of physically or virtually available processors. + The processor demand must be reduced for this system. -- ``SMP_FATAL_START_OF_MANDATORY_PROCESSOR_FAILED`` - the start of a - mandatory processor failed during system initialization. The system may not - have this processor at all or it could be a problem with a boot loader for - example. Check the ``CONFIGURE_SMP_SCHEDULER_ASSIGNMENTS`` definition. +- ``SMP_FATAL_START_OF_MANDATORY_PROCESSOR_FAILED`` - the start of a mandatory + processor failed during system initialization. The system may not have this + processor at all or it could be a problem with a boot loader for example. + Check the ``CONFIGURE_SMP_SCHEDULER_ASSIGNMENTS`` definition. -- ``SMP_FATAL_MULTITASKING_START_ON_UNASSIGNED_PROCESSOR`` - it is not - allowed to start multitasking on a processor with no scheduler assigned. +- ``SMP_FATAL_MULTITASKING_START_ON_UNASSIGNED_PROCESSOR`` - it is not allowed + to start multitasking on a processor with no scheduler assigned. **EXAMPLE:** @@ -3985,20 +4001,20 @@ processing operations. The processors managed by RTEMS use two Deterministic Priority scheduler instances capable of dealing with 256 priority levels. The scheduler with -index zero has the name ``"IO "``. The scheduler with index one has the -name ``"WORK"``. The scheduler assignments of the first, third and fourth -processor are mandatory, so the system must have at least four processors, -otherwise a fatal run-time error will occur during system startup. The -processor assignments for the fifth up to the eighth processor are optional so -that the same application can be used for the normal and high-performance -product lines. The second processor has no scheduler assigned and runs Linux. -A hypervisor will ensure that the two systems cannot interfere in an -undesirable way. +index zero has the name ``"IO "``. The scheduler with index one has the name +``"WORK"``. The scheduler assignments of the first, third and fourth processor +are mandatory, so the system must have at least four processors, otherwise a +fatal run-time error will occur during system startup. The processor +assignments for the fifth up to the eighth processor are optional so that the +same application can be used for the normal and high-performance product lines. +The second processor has no scheduler assigned and runs Linux. A hypervisor +will ensure that the two systems cannot interfere in an undesirable way. + .. code:: c #define CONFIGURE_SMP_MAXIMUM_PROCESSORS 8 #define CONFIGURE_MAXIMUM_PRIORITY 255 - /* Make the scheduler algorithm available \*/ + /* Make the scheduler algorithm available */ #define CONFIGURE_SCHEDULER_PRIORITY_SMP #include <rtems/scheduler.h> /* Create contexts for the two scheduler instances \*/ @@ -4006,24 +4022,24 @@ undesirable way. RTEMS_SCHEDULER_CONTEXT_PRIORITY_SMP(work, CONFIGURE_MAXIMUM_PRIORITY + 1); /* Define the scheduler table \*/ #define CONFIGURE_SCHEDULER_CONTROLS \\ - RTEMS_SCHEDULER_CONTROL_PRIORITY_SMP( \\ - io, \\ - rtems_build_name('I', 'O', ' ', ' ') \\ - ), \\ - RTEMS_SCHEDULER_CONTROL_PRIORITY_SMP( \\ - work, \\ - rtems_build_name('W', 'O', 'R', 'K') \\ - ) - /* Define the processor to scheduler assignments \*/ - #define CONFIGURE_SMP_SCHEDULER_ASSIGNMENTS \\ - RTEMS_SCHEDULER_ASSIGN(0, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_MANDATORY), \\ - RTEMS_SCHEDULER_ASSIGN_NO_SCHEDULER, \\ - RTEMS_SCHEDULER_ASSIGN(1, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_MANDATORY), \\ - RTEMS_SCHEDULER_ASSIGN(1, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_MANDATORY), \\ - RTEMS_SCHEDULER_ASSIGN(1, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL), \\ - RTEMS_SCHEDULER_ASSIGN(1, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL), \\ - RTEMS_SCHEDULER_ASSIGN(1, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL), \\ - RTEMS_SCHEDULER_ASSIGN(1, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL) + RTEMS_SCHEDULER_CONTROL_PRIORITY_SMP( \ + io, \ + rtems_build_name('I', 'O', ' ', ' ') \ + ), \ + RTEMS_SCHEDULER_CONTROL_PRIORITY_SMP( \ + work, \ + rtems_build_name('W', 'O', 'R', 'K') \ + ) + /* Define the processor to scheduler assignments */ + #define CONFIGURE_SMP_SCHEDULER_ASSIGNMENTS \ + RTEMS_SCHEDULER_ASSIGN(0, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_MANDATORY), \ + RTEMS_SCHEDULER_ASSIGN_NO_SCHEDULER, \ + RTEMS_SCHEDULER_ASSIGN(1, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_MANDATORY), \ + RTEMS_SCHEDULER_ASSIGN(1, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_MANDATORY), \ + RTEMS_SCHEDULER_ASSIGN(1, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL), \ + RTEMS_SCHEDULER_ASSIGN(1, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL), \ + RTEMS_SCHEDULER_ASSIGN(1, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL), \ + RTEMS_SCHEDULER_ASSIGN(1, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL) .. COMMENT: === SMP Specific Configuration Parameters === @@ -4084,8 +4100,8 @@ Specify Maximum Processors in SMP System **DESCRIPTION:** -``CONFIGURE_SMP_MAXIMUM_PROCESSORS`` must be set to the number of -processors in the SMP configuration. +``CONFIGURE_SMP_MAXIMUM_PROCESSORS`` must be set to the number of processors in +the SMP configuration. **NOTES:** @@ -4097,11 +4113,10 @@ ignored. This configuration define is ignored on uni-processor configurations. Device Driver Table =================== -This section defines the configuration parameters related -to the automatic generation of a Device Driver Table. As``<rtems/confdefs.h>`` only is aware of a small set of -standard device drivers, the generated Device Driver -Table is suitable for simple applications with no -custom device drivers. +This section defines the configuration parameters related to the automatic +generation of a Device Driver Table. As ``<rtems/confdefs.h>`` only is aware +of a small set of standard device drivers, the generated Device Driver Table is +suitable for simple applications with no custom device drivers. Note that network device drivers are not configured in the Device Driver Table. @@ -4127,15 +4142,16 @@ Specifying the Maximum Number of Device Drivers **DESCRIPTION:** -``CONFIGURE_MAXIMUM_DRIVERS`` is defined as the number of device -drivers per node. +``CONFIGURE_MAXIMUM_DRIVERS`` is defined as the number of device drivers per +node. **NOTES:** If the application will dynamically install device drivers, then this -configuration parameter must be larger than the number of statically -configured device drivers. Drivers configured using the``CONFIGURE_APPLICATIONS_NEEDS_XXX_DRIVER`` configuration parameters -are statically installed. +configuration parameter must be larger than the number of statically configured +device drivers. Drivers configured using the +``CONFIGURE_APPLICATIONS_NEEDS_XXX_DRIVER`` configuration parameters are +statically installed. .. COMMENT: === CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER === @@ -4157,16 +4173,16 @@ Enable Console Device Driver **DESCRIPTION:** -``CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER`` is defined if the -application wishes to include the Console Device Driver. +``CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER`` is defined if the application +wishes to include the Console Device Driver. **NOTES:** -This device driver is responsible for providing standard input and output -using */dev/console*. +This device driver is responsible for providing standard input and output using +*/dev/console*. -BSPs should be constructed in a manner that allows ``printk()`` -to work properly without the need for the console driver to be configured. +BSPs should be constructed in a manner that allows ``printk()`` to work +properly without the need for the console driver to be configured. .. COMMENT: === CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER === @@ -4188,17 +4204,17 @@ Enable Clock Driver **DESCRIPTION:** -``CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER`` is defined if the -application wishes to include the Clock Device Driver. +``CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER`` is defined if the application +wishes to include the Clock Device Driver. **NOTES:** -This device driver is responsible for providing a regular -interrupt which invokes the ``rtems_clock_tick`` directive. +This device driver is responsible for providing a regular interrupt which +invokes the ``rtems_clock_tick`` directive. -If neither the Clock Driver not Benchmark Timer is enabled and -the configuration parameter``CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER`` is not defined, -then a compile time error will occur. +If neither the Clock Driver not Benchmark Timer is enabled and the +configuration parameter ``CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER`` is +not defined, then a compile time error will occur. .. COMMENT: === CONFIGURE_APPLICATION_NEEDS_TIMER_DRIVER === @@ -4226,9 +4242,9 @@ used to benchmark execution times by the RTEMS Timing Test Suites. **NOTES:** -If neither the Clock Driver not Benchmark Timer is enabled and -the configuration parameter``CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER`` is not defined, -then a compile time error will occur. +If neither the Clock Driver not Benchmark Timer is enabled and the +configuration parameter ``CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER`` is +not defined, then a compile time error will occur. .. COMMENT: === CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER === @@ -4250,16 +4266,16 @@ Specify Clock and Benchmark Timer Drivers Are Not Needed **DESCRIPTION:** -``CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER`` is defined when -the application does *NOT* want the Clock Device Driver and is *NOT* -using the Timer Driver. The inclusion or exclusion of the Clock Driver -must be explicit in user applications. +``CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER`` is defined when the +application does *NOT* want the Clock Device Driver and is *NOT* using the +Timer Driver. The inclusion or exclusion of the Clock Driver must be explicit +in user applications. **NOTES:** -This configuration parameter is intended to prevent the common user error -of using the Hello World example as the baseline for an application and -leaving out a clock tick source. +This configuration parameter is intended to prevent the common user error of +using the Hello World example as the baseline for an application and leaving +out a clock tick source. .. COMMENT: === CONFIGURE_APPLICATION_NEEDS_RTC_DRIVER === @@ -4281,16 +4297,16 @@ Enable Real-Time Clock Driver **DESCRIPTION:** -``CONFIGURE_APPLICATION_NEEDS_RTC_DRIVER`` is defined if the -application wishes to include the Real-Time Clock Driver. +``CONFIGURE_APPLICATION_NEEDS_RTC_DRIVER`` is defined if the application wishes +to include the Real-Time Clock Driver. **NOTES:** -Most BSPs do not include support for a real-time clock. This is because -many boards do not include the required hardware. +Most BSPs do not include support for a real-time clock. This is because many +boards do not include the required hardware. -If this is defined and the BSP does not have this device driver, then -the user will get a link time error for an undefined symbol. +If this is defined and the BSP does not have this device driver, then the user +will get a link time error for an undefined symbol. .. COMMENT: === CONFIGURE_APPLICATION_NEEDS_WATCHDOG_DRIVER === @@ -4312,16 +4328,16 @@ Enable the Watchdog Device Driver **DESCRIPTION:** -``CONFIGURE_APPLICATION_NEEDS_WATCHDOG_DRIVER`` -is defined if the application wishes to include the Watchdog Driver. +``CONFIGURE_APPLICATION_NEEDS_WATCHDOG_DRIVER`` is defined if the application +wishes to include the Watchdog Driver. **NOTES:** -Most BSPs do not include support for a watchdog device driver. This is -because many boards do not include the required hardware. +Most BSPs do not include support for a watchdog device driver. This is because +many boards do not include the required hardware. -If this is defined and the BSP does not have this device driver, then -the user will get a link time error for an undefined symbol. +If this is defined and the BSP does not have this device driver, then the user +will get a link time error for an undefined symbol. .. COMMENT: === CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER === @@ -4343,16 +4359,16 @@ Enable the Graphics Frame Buffer Device Driver **DESCRIPTION:** -``CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER`` is defined -if the application wishes to include the BSP's Frame Buffer Device Driver. +``CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER`` is defined if the +application wishes to include the BSP's Frame Buffer Device Driver. **NOTES:** Most BSPs do not include support for a Frame Buffer Device Driver. This is because many boards do not include the required hardware. -If this is defined and the BSP does not have this device driver, then -the user will get a link time error for an undefined symbol. +If this is defined and the BSP does not have this device driver, then the user +will get a link time error for an undefined symbol. .. COMMENT: === CONFIGURE_APPLICATION_NEEDS_STUB_DRIVER === @@ -4374,13 +4390,13 @@ Enable Stub Device Driver **DESCRIPTION:** -``CONFIGURE_APPLICATION_NEEDS_STUB_DRIVER`` is defined if the -application wishes to include the Stub Device Driver. +``CONFIGURE_APPLICATION_NEEDS_STUB_DRIVER`` is defined if the application +wishes to include the Stub Device Driver. **NOTES:** -This device driver simply provides entry points that return successful -and is primarily a test fixture. It is supported by all BSPs. +This device driver simply provides entry points that return successful and is +primarily a test fixture. It is supported by all BSPs. .. COMMENT: === CONFIGURE_APPLICATION_PREREQUISITE_DRIVERS === @@ -4402,20 +4418,19 @@ Specify Application Prerequisite Device Drivers **DESCRIPTION:** -``CONFIGURE_APPLICATION_PREREQUISITE_DRIVERS`` is defined if the -application has device drivers it needs to include in the Device Driver -Table. This should be defined to the set of device driver entries that -will be placed in the table at the *FRONT* of the Device Driver Table -and initialized before any other drivers *EXCEPT* any BSP prerequisite -drivers. +``CONFIGURE_APPLICATION_PREREQUISITE_DRIVERS`` is defined if the application +has device drivers it needs to include in the Device Driver Table. This should +be defined to the set of device driver entries that will be placed in the table +at the *FRONT* of the Device Driver Table and initialized before any other +drivers *EXCEPT* any BSP prerequisite drivers. **NOTES:** -In some cases, it is used by System On Chip BSPs to support peripheral -buses beyond those normally found on the System On Chip. For example, -this is used by one RTEMS system which has implemented a SPARC/ERC32 -based board with VMEBus. The VMEBus Controller initialization is performed -by a device driver configured via this configuration parameter. +In some cases, it is used by System On Chip BSPs to support peripheral buses +beyond those normally found on the System On Chip. For example, this is used by +one RTEMS system which has implemented a SPARC/ERC32 based board with +VMEBus. The VMEBus Controller initialization is performed by a device driver +configured via this configuration parameter. .. COMMENT: XXX Add example @@ -4439,10 +4454,10 @@ Specify Extra Application Device Drivers **DESCRIPTION:** -``CONFIGURE_APPLICATION_EXTRA_DRIVERS`` is defined if the -application has device drivers it needs to include in the Device Driver -Table. This should be defined to the set of device driver entries that -will be placed in the table at the *END* of the Device Driver Table. +``CONFIGURE_APPLICATION_EXTRA_DRIVERS`` is defined if the application has +device drivers it needs to include in the Device Driver Table. This should be +defined to the set of device driver entries that will be placed in the table at +the *END* of the Device Driver Table. **NOTES:** @@ -4469,8 +4484,7 @@ Enable /dev/null Device Driver **DESCRIPTION:** -This configuration variable is specified to enable */dev/null* -device driver. +This configuration variable is specified to enable ``/dev/null`` device driver. **NOTES:** @@ -4497,8 +4511,7 @@ Enable /dev/zero Device Driver **DESCRIPTION:** -This configuration variable is specified to enable */dev/zero* -device driver. +This configuration variable is specified to enable ``/dev/zero`` device driver. **NOTES:** @@ -4520,17 +4533,18 @@ Specifying Application Defined Device Driver Table Defined or undefined. *DEFAULT VALUE:* - This is not defined by default, indicating the ``<rtems/confdefs.h>`` - is providing the device driver table. + This is not defined by default, indicating the ``<rtems/confdefs.h>`` is + providing the device driver table. **DESCRIPTION:** -``CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE`` is defined if the application -wishes to provide their own Device Driver Table. +``CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE`` is defined if the application wishes +to provide their own Device Driver Table. -The table must be an array of ``rtems_driver_address_table`` entries named``_IO_Driver_address_table``. The application must also provide a const -variable ``_IO_Number_of_drivers`` of type ``size_t`` indicating the -number of entries in the ``_IO_Driver_address_table``. +The table must be an array of ``rtems_driver_address_table`` entries named`` +_IO_Driver_address_table``. The application must also provide a const variable +``_IO_Number_of_drivers`` of type ``size_t`` indicating the number of entries +in the ``_IO_Driver_address_table``. **NOTES:** @@ -4542,11 +4556,12 @@ Multiprocessing Configuration ============================= This section defines the multiprocessing related system configuration -parameters supported by ``<rtems/confdefs.h>``. They are only used -if the Multiprocessing Support (distinct from the SMP support) is enabled -at configure time using the ``--enable-multiprocessing`` option. +parameters supported by ``<rtems/confdefs.h>``. They are only used if the +Multiprocessing Support (distinct from the SMP support) is enabled at configure +time using the ``--enable-multiprocessing`` option. -Additionally, this class of Configuration Constants are only applicable if``CONFIGURE_MP_APPLICATION`` is defined. +Additionally, this class of Configuration Constants are only applicable if +``CONFIGURE_MP_APPLICATION`` is defined. .. COMMENT: === CONFIGURE_MP_APPLICATION === @@ -4568,14 +4583,14 @@ Specify Application Will Use Multiprocessing **DESCRIPTION:** -This configuration parameter must be defined to indicate -that the application intends to be part of a multiprocessing -configuration. Additional configuration parameters are assumed to be -provided. +This configuration parameter must be defined to indicate that the application +intends to be part of a multiprocessing configuration. Additional configuration +parameters are assumed to be provided. **NOTES:** -This has no impact unless RTEMS was configured and built using the``--enable-multiprocessing`` option. +This has no impact unless RTEMS was configured and built using the +``--enable-multiprocessing`` option. .. COMMENT: === CONFIGURE_MP_NODE_NUMBER === @@ -4593,20 +4608,20 @@ Configure Node Number in Multiprocessor Configuration Positive. *DEFAULT VALUE:* - The default value is ``NODE_NUMBER``, which is assumed to be - set by the compilation environment. + The default value is ``NODE_NUMBER``, which is assumed to be set by the + compilation environment. **DESCRIPTION:** -``CONFIGURE_MP_NODE_NUMBER`` is the node number of -this node in a multiprocessor system. +``CONFIGURE_MP_NODE_NUMBER`` is the node number of this node in a +multiprocessor system. **NOTES:** -In the RTEMS Multiprocessing Test Suite, the node number is derived from -the Makefile variable ``NODE_NUMBER``. The same code is compiled with -the ``NODE_NUMBER`` set to different values. The test programs behave -differently based upon their node number. +In the RTEMS Multiprocessing Test Suite, the node number is derived from the +Makefile variable ``NODE_NUMBER``. The same code is compiled with the +``NODE_NUMBER`` set to different values. The test programs behave differently +based upon their node number. .. COMMENT: === CONFIGURE_MP_MAXIMUM_NODES === @@ -4655,13 +4670,13 @@ Configure Maximum Global Objects in Multiprocessor Configuration **DESCRIPTION:** -``CONFIGURE_MP_MAXIMUM_GLOBAL_OBJECTS`` is the maximum number of -concurrently active global objects in a multiprocessor system. +``CONFIGURE_MP_MAXIMUM_GLOBAL_OBJECTS`` is the maximum number of concurrently +active global objects in a multiprocessor system. **NOTES:** -This value corresponds to the total number of objects which can be -created with the ``RTEMS_GLOBAL`` attribute. +This value corresponds to the total number of objects which can be created with +the ``RTEMS_GLOBAL`` attribute. .. COMMENT: === CONFIGURE_MP_MAXIMUM_PROXIES === @@ -4689,8 +4704,8 @@ active thread/task proxies on this node in a multiprocessor system. **NOTES:** Since a proxy is used to represent a remote task/thread which is blocking on -this node. This configuration parameter reflects the maximum number of -remote tasks/threads which can be blocked on objects on this node. +this node. This configuration parameter reflects the maximum number of remote +tasks/threads which can be blocked on objects on this node. .. COMMENT: XXX - add xref to proxy discussion in MP chapter @@ -4714,14 +4729,14 @@ Configure MPCI in Multiprocessor Configuration **DESCRIPTION:** -``CONFIGURE_MP_MPCI_TABLE_POINTER`` is the pointer to the -MPCI Configuration Table. The default value of this field is``&MPCI_table``. +``CONFIGURE_MP_MPCI_TABLE_POINTER`` is the pointer to the MPCI Configuration +Table. The default value of this field is``&MPCI_table``. **NOTES:** -RTEMS provides a Shared Memory MPCI Device Driver which can be used on -any Multiprocessor System assuming the BSP provides the proper set of -supporting methods. +RTEMS provides a Shared Memory MPCI Device Driver which can be used on any +Multiprocessor System assuming the BSP provides the proper set of supporting +methods. .. COMMENT: === CONFIGURE_HAS_OWN_MULTIPROCESSING_TABLE === @@ -4743,31 +4758,32 @@ Do Not Generate Multiprocessor Configuration Table **DESCRIPTION:** -``CONFIGURE_HAS_OWN_MULTIPROCESSING_TABLE`` is defined if the -application wishes to provide their own Multiprocessing Configuration -Table. The generated table is named ``Multiprocessing_configuration``. +``CONFIGURE_HAS_OWN_MULTIPROCESSING_TABLE`` is defined if the application +wishes to provide their own Multiprocessing Configuration Table. The generated +table is named ``Multiprocessing_configuration``. **NOTES:** -This is a configuration parameter which is very unlikely to be used by -an application. If you find yourself wanting to use it in an application, -please reconsider and discuss this on the RTEMS Users mailing list. +This is a configuration parameter which is very unlikely to be used by an +application. If you find yourself wanting to use it in an application, please +reconsider and discuss this on the RTEMS Users mailing list. .. COMMENT: === Ada Tasks === Ada Tasks ========= -This section defines the system configuration parameters supported -by ``<rtems/confdefs.h>`` related to configuring RTEMS to support -a task using Ada tasking with GNAT/RTEMS. +This section defines the system configuration parameters supported by +``<rtems/confdefs.h>`` related to configuring RTEMS to support a task using Ada +tasking with GNAT/RTEMS. -These configuration parameters are only available when RTEMS is built with -the ``--enable-ada`` configure option and the application specifies``CONFIGURE_GNAT_RTEMS``. +These configuration parameters are only available when RTEMS is built with the +``--enable-ada`` configure option and the application specifies +``CONFIGURE_GNAT_RTEMS``. -Additionally RTEMS includes an Ada language binding to the Classic -API which has a test suite. This test suite is enabled only when``--enable-tests`` and ``--enable-expada`` are specified on the -configure command. +Additionally RTEMS includes an Ada language binding to the Classic API which +has a test suite. This test suite is enabled only when``--enable-tests`` and +``--enable-expada`` are specified on the configure command. .. COMMENT: === CONFIGURE_GNAT_RTEMS === @@ -4789,14 +4805,14 @@ Specify Application Includes Ada Code **DESCRIPTION:** -``CONFIGURE_GNAT_RTEMS`` is defined to inform RTEMS that the GNAT -Ada run-time is to be used by the application. +``CONFIGURE_GNAT_RTEMS`` is defined to inform RTEMS that the GNAT Ada run-time +is to be used by the application. **NOTES:** -This configuration parameter is critical as it makes``<rtems/confdefs.h>`` configure the resources (POSIX API Threads, -Mutexes, Condition Variables, and Keys) used implicitly by the GNAT -run-time. +This configuration parameter is critical as it makes``<rtems/confdefs.h>`` +configure the resources (POSIX API Threads, Mutexes, Condition Variables, and +Keys) used implicitly by the GNAT run-time. .. COMMENT: === CONFIGURE_MAXIMUM_ADA_TASKS === @@ -4814,13 +4830,13 @@ Specify the Maximum Number of Ada Tasks. Undefined or positive. *DEFAULT VALUE:* - If ``CONFIGURE_GNAT_RTEMS`` is defined, then the - default value is 20, otherwise the default value is 0. + If ``CONFIGURE_GNAT_RTEMS`` is defined, then the default value is 20, + otherwise the default value is 0. **DESCRIPTION:** -``CONFIGURE_MAXIMUM_ADA_TASKS`` is the number of Ada tasks that can -be concurrently active in the system. +``CONFIGURE_MAXIMUM_ADA_TASKS`` is the number of Ada tasks that can be +concurrently active in the system. **NOTES:** @@ -4846,10 +4862,9 @@ Specify the Maximum Fake Ada Tasks **DESCRIPTION:** -``CONFIGURE_MAXIMUM_FAKE_ADA_TASKS`` is the number of *fake* Ada tasks -that can be concurrently active in the system. A *fake* Ada task is -a non-Ada task that makes calls back into Ada code and thus implicitly -uses the Ada run-time. +``CONFIGURE_MAXIMUM_FAKE_ADA_TASKS`` is the number of *fake* Ada tasks that can +be concurrently active in the system. A *fake* Ada task is a non-Ada task that +makes calls back into Ada code and thus implicitly uses the Ada run-time. **NOTES:** @@ -4860,51 +4875,53 @@ None. PCI Library =========== -This section defines the system configuration parameters supported -by ``rtems/confdefs.h`` related to configuring the PCI Library -for RTEMS. - -The PCI Library startup behaviour can be configured in four different -ways depending on how ``CONFIGURE_PCI_CONFIG_LIB`` is defined: - -- .. index:: PCI_LIB_AUTO - - ``PCI_LIB_AUTO`` is used to enable the PCI auto configuration - software. PCI will be automatically probed, PCI buses enumerated, all - devices and bridges will be initialized using Plug & Play software - routines. The PCI device tree will be populated based on the PCI devices - found in the system, PCI devices will be configured by allocating address - region resources automatically in PCI space according to the BSP or host - bridge driver set up. - -- .. index:: PCI_LIB_READ - - ``PCI_LIB_READ`` is used to enable the PCI read configuration - software. The current PCI configuration is read to create the RAM - representation (the PCI device tree) of the PCI devices present. PCI devices - are assumed to already have been initialized and PCI buses enumerated, it is - therefore required that a BIOS or a boot loader has set up configuration space - prior to booting into RTEMS. - -- .. index:: PCI_LIB_STATIC - - ``PCI_LIB_STATIC`` is used to enable the PCI static configuration - software. The user provides a PCI tree with information how all PCI devices - are to be configured at compile time by linking in a custom``struct pci_bus pci_hb`` tree. The static PCI library will not probe PCI - for devices, instead it will assume that all devices defined by the user are - present, it will enumerate the PCI buses and configure all PCI devices in - static configuration accordingly. Since probe and allocation software is not - needed the startup is faster, has smaller footprint and does not require - dynamic memory allocation. - -- .. index:: PCI_LIB_PERIPHERAL - - ``PCI_LIB_PERIPHERAL`` is used to enable the PCI peripheral - configuration. It is similar to ``PCI_LIB_STATIC``, but it will never write - the configuration to the PCI devices since PCI peripherals are not allowed to - access PCI configuration space. - -Note that selecting PCI_LIB_STATIC or PCI_LIB_PERIPHERAL but not defining``pci_hb`` will reuslt in link errors. Note also that in these modes +This section defines the system configuration parameters supported by +``rtems/confdefs.h`` related to configuring the PCI Library for RTEMS. + +The PCI Library startup behaviour can be configured in four different ways +depending on how ``CONFIGURE_PCI_CONFIG_LIB`` is defined: + +.. index:: PCI_LIB_AUTO + +``PCI_LIB_AUTO`` + Used to enable the PCI auto configuration software. PCI will be automatically + probed, PCI buses enumerated, all devices and bridges will be initialized + using Plug & Play software routines. The PCI device tree will be populated + based on the PCI devices found in the system, PCI devices will be configured + by allocating address region resources automatically in PCI space according + to the BSP or host bridge driver set up. + +.. index:: PCI_LIB_READ + +``PCI_LIB_READ`` + Used to enable the PCI read configuration software. The current PCI + configuration is read to create the RAM representation (the PCI device tree) + of the PCI devices present. PCI devices are assumed to already have been + initialized and PCI buses enumerated, it is therefore required that a BIOS or + a boot loader has set up configuration space prior to booting into RTEMS. + +.. index:: PCI_LIB_STATIC + +``PCI_LIB_STATIC`` + Used to enable the PCI static configuration software. The user provides a PCI + tree with information how all PCI devices are to be configured at compile + time by linking in a custom ``struct pci_bus pci_hb`` tree. The static PCI + library will not probe PCI for devices, instead it will assume that all + devices defined by the user are present, it will enumerate the PCI buses and + configure all PCI devices in static configuration accordingly. Since probe + and allocation software is not needed the startup is faster, has smaller + footprint and does not require dynamic memory allocation. + +.. index:: PCI_LIB_PERIPHERAL + +``PCI_LIB_PERIPHERAL`` + Used to enable the PCI peripheral configuration. It is similar to + ``PCI_LIB_STATIC``, but it will never write the configuration to the PCI + devices since PCI peripherals are not allowed to access PCI configuration + space. + +Note that selecting ``PCI_LIB_STATIC`` or ``PCI_LIB_PERIPHERAL`` but not +defining ``pci_hb`` will reuslt in link errors. Note also that in these modes Plug & Play is not performed. .. COMMENT: === Go Tasks === @@ -4932,8 +4949,8 @@ Specify Application Includes Go Code **DESCRIPTION:** -``CONFIGURE_ENABLE_GO`` is defined to inform RTEMS that the Go -run-time is to be used by the application. +``CONFIGURE_ENABLE_GO`` is defined to inform RTEMS that the Go run-time is to +be used by the application. **NOTES:** @@ -4959,8 +4976,8 @@ Specify the maximum number of Go routines **DESCRIPTION:** -``CONFIGURE_MAXIMUM_GOROUTINES`` is defined to specify the maximum number of -Go routines. +``CONFIGURE_MAXIMUM_GOROUTINES`` is defined to specify the maximum number of Go +routines. **NOTES:** @@ -4986,8 +5003,8 @@ Specify the maximum number of Go Channels **DESCRIPTION:** -``CONFIGURE_MAXIMUM_GO_CHANNELS`` is defined to specify the maximum number -of Go channels. +``CONFIGURE_MAXIMUM_GO_CHANNELS`` is defined to specify the maximum number of +Go channels. **NOTES:** @@ -4998,19 +5015,12 @@ The Go language support is experimental Configuration Data Structures ============================= -It is recommended that applications be configured using``<rtems/confdefs.h>`` as it is simpler and insulates applications -from changes in the underlying data structures. However, it is sometimes -important to understand the data structures that are automatically filled -in by the configuration parameters. This section describes the primary -configuration data structures. - -If the user wishes to see the details of a particular data structure, -they are are advised to look at the source code. After all, that is one -of the advantages of RTEMS. - -.. COMMENT: COPYRIGHT (c) 1988-2007. - -.. COMMENT: On-Line Applications Research Corporation (OAR). - -.. COMMENT: All rights reserved. +It is recommended that applications be configured using ``<rtems/confdefs.h>`` +as it is simpler and insulates applications from changes in the underlying data +structures. However, it is sometimes important to understand the data +structures that are automatically filled in by the configuration parameters. +This section describes the primary configuration data structures. +If the user wishes to see the details of a particular data structure, they are +are advised to look at the source code. After all, that is one of the +advantages of RTEMS. diff --git a/c_user/initialization.rst b/c_user/initialization.rst index 95c6e59..f071de9 100644 --- a/c_user/initialization.rst +++ b/c_user/initialization.rst @@ -15,9 +15,9 @@ user-supplied device driver. In a multiprocessor configuration, this manager also initializes the interprocessor communications layer. The directives provided by the Initialization Manager are: -- ``rtems_initialize_executive`` - Initialize RTEMS +- rtems_initialize_executive_ - Initialize RTEMS -- ``rtems_shutdown_executive`` - Shutdown RTEMS +- rtems_shutdown_executive_ - Shutdown RTEMS Background ========== @@ -104,7 +104,7 @@ The ``rtems_fatal_error_occurred`` directive will be invoked from successfully. A discussion of RTEMS actions when a fatal error occurs may be found -`Announcing a Fatal Error`_. +:ref:`Announcing a Fatal Error`. Operations ========== @@ -129,7 +129,7 @@ consists of The ``rtems_initialize_executive`` directive uses a system initialization linker set to initialize only those parts of the overall RTEMS feature set that -is necessary for a particular application. See `Linker Sets`_. Each RTEMS +is necessary for a particular application. See :ref:`Linker Sets`. Each RTEMS feature used the application may optionally register an initialization handler. The system initialization API is available via``#included <rtems/sysinit.h>``. @@ -184,7 +184,7 @@ initialization stack may be re-used for interrupt processing. Many of RTEMS actions during initialization are based upon the contents of the Configuration Table. For more information regarding the format and contents of -this table, please refer to the chapter `Configuring a System`_. +this table, please refer to the chapter :ref:`Configuring a System`. The final action in the initialization sequence is the initiation of multitasking. When the scheduler and dispatcher are enabled, the highest @@ -205,6 +205,8 @@ This section details the Initialization Manager's directives. A subsection is dedicated to each of this manager's directives and describes the calling sequence, related constants, usage, and status codes. +.. _rtems_initialize_executive: + INITIALIZE_EXECUTIVE - Initialize RTEMS --------------------------------------- .. index:: initialize RTEMS @@ -234,6 +236,8 @@ This directive should be called by ``boot_card`` only. This directive *does not return* to the caller. Errors in the initialization sequence are usually fatal and lead to a system termination. +.. _rtems_shutdown_executive: + SHUTDOWN_EXECUTIVE - Shutdown RTEMS ----------------------------------- .. index:: shutdown RTEMS diff --git a/c_user/key_concepts.rst b/c_user/key_concepts.rst index d69d715..16d1fe1 100644 --- a/c_user/key_concepts.rst +++ b/c_user/key_concepts.rst @@ -243,7 +243,9 @@ The development of responsive real-time applications requires an understanding of how RTEMS maintains and supports time-related operations. The basic unit of time in RTEMS is known as a tick. The frequency of clock ticks is completely application dependent and determines the granularity and accuracy of all -interval and calendar time operations... index:: rtems_interval +interval and calendar time operations. + +.. index:: rtems_interval By tracking time in units of ticks, RTEMS is capable of supporting interval timing functions such as task delays, timeouts, timeslicing, the delayed diff --git a/c_user/multiprocessing.rst b/c_user/multiprocessing.rst index 1c0ba04..6bb3f12 100644 --- a/c_user/multiprocessing.rst +++ b/c_user/multiprocessing.rst @@ -1,3 +1,7 @@ +.. COMMENT: COPYRIGHT (c) 1988-2008. +.. COMMENT: On-Line Applications Research Corporation (OAR). +.. COMMENT: All rights reserved. + Multiprocessing Manager ####################### @@ -6,255 +10,233 @@ Multiprocessing Manager Introduction ============ -In multiprocessor real-time systems, new -requirements, such as sharing data and global resources between -processors, are introduced. This requires an efficient and -reliable communications vehicle which allows all processors to -communicate with each other as necessary. In addition, the -ramifications of multiple processors affect each and every -characteristic of a real-time system, almost always making them -more complicated. - -RTEMS addresses these issues by providing simple and -flexible real-time multiprocessing capabilities. The executive -easily lends itself to both tightly-coupled and loosely-coupled -configurations of the target system hardware. In addition, -RTEMS supports systems composed of both homogeneous and +In multiprocessor real-time systems, new requirements, such as sharing data and +global resources between processors, are introduced. This requires an +efficient and reliable communications vehicle which allows all processors to +communicate with each other as necessary. In addition, the ramifications of +multiple processors affect each and every characteristic of a real-time system, +almost always making them more complicated. + +RTEMS addresses these issues by providing simple and flexible real-time +multiprocessing capabilities. The executive easily lends itself to both +tightly-coupled and loosely-coupled configurations of the target system +hardware. In addition, RTEMS supports systems composed of both homogeneous and heterogeneous mixtures of processors and target boards. -A major design goal of the RTEMS executive was to -transcend the physical boundaries of the target hardware -configuration. This goal is achieved by presenting the -application software with a logical view of the target system -where the boundaries between processor nodes are transparent. -As a result, the application developer may designate objects -such as tasks, queues, events, signals, semaphores, and memory -blocks as global objects. These global objects may then be -accessed by any task regardless of the physical location of the -object and the accessing task. RTEMS automatically determines -that the object being accessed resides on another processor and -performs the actions required to access the desired object. -Simply stated, RTEMS allows the entire system, both hardware and -software, to be viewed logically as a single system. +A major design goal of the RTEMS executive was to transcend the physical +boundaries of the target hardware configuration. This goal is achieved by +presenting the application software with a logical view of the target system +where the boundaries between processor nodes are transparent. As a result, the +application developer may designate objects such as tasks, queues, events, +signals, semaphores, and memory blocks as global objects. These global objects +may then be accessed by any task regardless of the physical location of the +object and the accessing task. RTEMS automatically determines that the object +being accessed resides on another processor and performs the actions required +to access the desired object. Simply stated, RTEMS allows the entire system, +both hardware and software, to be viewed logically as a single system. + +The directives provided by the Manager are: + +- rtems_multiprocessing_announce_ - A multiprocessing communications packet has + arrived Background ========== .. index:: multiprocessing topologies -RTEMS makes no assumptions regarding the connection -media or topology of a multiprocessor system. The tasks which -compose a particular application can be spread among as many -processors as needed to satisfy the application's timing -requirements. The application tasks can interact using a subset -of the RTEMS directives as if they were on the same processor. -These directives allow application tasks to exchange data, -communicate, and synchronize regardless of which processor they -reside upon. - -The RTEMS multiprocessor execution model is multiple -instruction streams with multiple data streams (MIMD). This -execution model has each of the processors executing code -independent of the other processors. Because of this -parallelism, the application designer can more easily guarantee -deterministic behavior. - -By supporting heterogeneous environments, RTEMS -allows the systems designer to select the most efficient -processor for each subsystem of the application. Configuring -RTEMS for a heterogeneous environment is no more difficult than -for a homogeneous one. In keeping with RTEMS philosophy of -providing transparent physical node boundaries, the minimal -heterogeneous processing required is isolated in the MPCI layer. +RTEMS makes no assumptions regarding the connection media or topology of a +multiprocessor system. The tasks which compose a particular application can be +spread among as many processors as needed to satisfy the application's timing +requirements. The application tasks can interact using a subset of the RTEMS +directives as if they were on the same processor. These directives allow +application tasks to exchange data, communicate, and synchronize regardless of +which processor they reside upon. + +The RTEMS multiprocessor execution model is multiple instruction streams with +multiple data streams (MIMD). This execution model has each of the processors +executing code independent of the other processors. Because of this +parallelism, the application designer can more easily guarantee deterministic +behavior. + +By supporting heterogeneous environments, RTEMS allows the systems designer to +select the most efficient processor for each subsystem of the application. +Configuring RTEMS for a heterogeneous environment is no more difficult than for +a homogeneous one. In keeping with RTEMS philosophy of providing transparent +physical node boundaries, the minimal heterogeneous processing required is +isolated in the MPCI layer. Nodes ----- .. index:: nodes, definition -A processor in a RTEMS system is referred to as a -node. Each node is assigned a unique non-zero node number by -the application designer. RTEMS assumes that node numbers are -assigned consecutively from one to the ``maximum_nodes`` -configuration parameter. The node -number, node, and the maximum number of nodes, maximum_nodes, in -a system are found in the Multiprocessor Configuration Table. -The maximum_nodes field and the number of global objects, -maximum_global_objects, is required to be the same on all nodes -in a system. - -The node number is used by RTEMS to identify each -node when performing remote operations. Thus, the -Multiprocessor Communications Interface Layer (MPCI) must be -able to route messages based on the node number. +A processor in a RTEMS system is referred to as a node. Each node is assigned +a unique non-zero node number by the application designer. RTEMS assumes that +node numbers are assigned consecutively from one to the ``maximum_nodes`` +configuration parameter. The node number, node, and the maximum number of +nodes, ``maximum_nodes``, in a system are found in the Multiprocessor +Configuration Table. The ``maximum_nodes`` field and the number of global +objects, ``maximum_global_objects``, is required to be the same on all nodes in +a system. + +The node number is used by RTEMS to identify each node when performing remote +operations. Thus, the Multiprocessor Communications Interface Layer (MPCI) +must be able to route messages based on the node number. Global Objects -------------- .. index:: global objects, definition -All RTEMS objects which are created with the GLOBAL -attribute will be known on all other nodes. Global objects can -be referenced from any node in the system, although certain -directive specific restrictions (e.g. one cannot delete a remote -object) may apply. A task does not have to be global to perform -operations involving remote objects. The maximum number of -global objects is the system is user configurable and can be -found in the maximum_global_objects field in the Multiprocessor -Configuration Table. The distribution of tasks to processors is -performed during the application design phase. Dynamic task +All RTEMS objects which are created with the GLOBAL attribute will be known on +all other nodes. Global objects can be referenced from any node in the system, +although certain directive specific restrictions (e.g. one cannot delete a +remote object) may apply. A task does not have to be global to perform +operations involving remote objects. The maximum number of global objects is +the system is user configurable and can be found in the maximum_global_objects +field in the Multiprocessor Configuration Table. The distribution of tasks to +processors is performed during the application design phase. Dynamic task relocation is not supported by RTEMS. Global Object Table ------------------- .. index:: global objects table -RTEMS maintains two tables containing object -information on every node in a multiprocessor system: a local -object table and a global object table. The local object table -on each node is unique and contains information for all objects -created on this node whether those objects are local or global. -The global object table contains information regarding all -global objects in the system and, consequently, is the same on -every node. - -Since each node must maintain an identical copy of -the global object table, the maximum number of entries in each -copy of the table must be the same. The maximum number of -entries in each copy is determined by the -maximum_global_objects parameter in the Multiprocessor -Configuration Table. This parameter, as well as the -maximum_nodes parameter, is required to be the same on all -nodes. To maintain consistency among the table copies, every -node in the system must be informed of the creation or deletion -of a global object. +RTEMS maintains two tables containing object information on every node in a +multiprocessor system: a local object table and a global object table. The +local object table on each node is unique and contains information for all +objects created on this node whether those objects are local or global. The +global object table contains information regarding all global objects in the +system and, consequently, is the same on every node. + +Since each node must maintain an identical copy of the global object table, the +maximum number of entries in each copy of the table must be the same. The +maximum number of entries in each copy is determined by the +maximum_global_objects parameter in the Multiprocessor Configuration Table. +This parameter, as well as the maximum_nodes parameter, is required to be the +same on all nodes. To maintain consistency among the table copies, every node +in the system must be informed of the creation or deletion of a global object. Remote Operations ----------------- .. index:: MPCI and remote operations -When an application performs an operation on a remote -global object, RTEMS must generate a Remote Request (RQ) message -and send it to the appropriate node. After completing the -requested operation, the remote node will build a Remote -Response (RR) message and send it to the originating node. -Messages generated as a side-effect of a directive (such as -deleting a global task) are known as Remote Processes (RP) and -do not require the receiving node to respond. - -Other than taking slightly longer to execute -directives on remote objects, the application is unaware of the -location of the objects it acts upon. The exact amount of -overhead required for a remote operation is dependent on the -media connecting the nodes and, to a lesser degree, on the -efficiency of the user-provided MPCI routines. - -The following shows the typical transaction sequence -during a remote application: - -# The application issues a directive accessing a - remote global object. - -# RTEMS determines the node on which the object - resides. - -# RTEMS calls the user-provided MPCI routine - GET_PACKET to obtain a packet in which to build a RQ message. - -# After building a message packet, RTEMS calls the - user-provided MPCI routine SEND_PACKET to transmit the packet to - the node on which the object resides (referred to as the - destination node). - -# The calling task is blocked until the RR message - arrives, and control of the processor is transferred to another - task. - -# The MPCI layer on the destination node senses the - arrival of a packet (commonly in an ISR), and calls the``rtems_multiprocessing_announce`` - directive. This directive readies the Multiprocessing Server. - -# The Multiprocessing Server calls the user-provided - MPCI routine RECEIVE_PACKET, performs the requested operation, - builds an RR message, and returns it to the originating node. - -# The MPCI layer on the originating node senses the - arrival of a packet (typically via an interrupt), and calls the RTEMS``rtems_multiprocessing_announce`` directive. This directive - readies the Multiprocessing Server. - -# The Multiprocessing Server calls the user-provided - MPCI routine RECEIVE_PACKET, readies the original requesting - task, and blocks until another packet arrives. Control is - transferred to the original task which then completes processing - of the directive. - -If an uncorrectable error occurs in the user-provided -MPCI layer, the fatal error handler should be invoked. RTEMS -assumes the reliable transmission and reception of messages by -the MPCI and makes no attempt to detect or correct errors. +When an application performs an operation on a remote global object, RTEMS must +generate a Remote Request (RQ) message and send it to the appropriate node. +After completing the requested operation, the remote node will build a Remote +Response (RR) message and send it to the originating node. Messages generated +as a side-effect of a directive (such as deleting a global task) are known as +Remote Processes (RP) and do not require the receiving node to respond. + +Other than taking slightly longer to execute directives on remote objects, the +application is unaware of the location of the objects it acts upon. The exact +amount of overhead required for a remote operation is dependent on the media +connecting the nodes and, to a lesser degree, on the efficiency of the +user-provided MPCI routines. + +The following shows the typical transaction sequence during a remote +application: + +#. The application issues a directive accessing a remote global object. + +#. RTEMS determines the node on which the object resides. + +#. RTEMS calls the user-provided MPCI routine ``GET_PACKET`` to obtain a packet + in which to build a RQ message. + +#. After building a message packet, RTEMS calls the user-provided MPCI routine + ``SEND_PACKET`` to transmit the packet to the node on which the object + resides (referred to as the destination node). + +#. The calling task is blocked until the RR message arrives, and control of the + processor is transferred to another task. + +#. The MPCI layer on the destination node senses the arrival of a packet + (commonly in an ISR), and calls the ``rtems_multiprocessing_announce`` + directive. This directive readies the Multiprocessing Server. + +#. The Multiprocessing Server calls the user-provided MPCI routine + ``RECEIVE_PACKET``, performs the requested operation, builds an RR message, + and returns it to the originating node. + +#. The MPCI layer on the originating node senses the arrival of a packet + (typically via an interrupt), and calls the + RTEMS``rtems_multiprocessing_announce`` directive. This directive readies + the Multiprocessing Server. + +#. The Multiprocessing Server calls the user-provided MPCI routine + ``RECEIVE_PACKET``, readies the original requesting task, and blocks until + another packet arrives. Control is transferred to the original task which + then completes processing of the directive. + +If an uncorrectable error occurs in the user-provided MPCI layer, the fatal +error handler should be invoked. RTEMS assumes the reliable transmission and +reception of messages by the MPCI and makes no attempt to detect or correct +errors. Proxies ------- .. index:: proxy, definition -A proxy is an RTEMS data structure which resides on a -remote node and is used to represent a task which must block as -part of a remote operation. This action can occur as part of the``rtems_semaphore_obtain`` and``rtems_message_queue_receive`` directives. If the -object were local, the task's control block would be available -for modification to indicate it was blocking on a message queue -or semaphore. However, the task's control block resides only on -the same node as the task. As a result, the remote node must +A proxy is an RTEMS data structure which resides on a remote node and is used +to represent a task which must block as part of a remote operation. This action +can occur as part of the ``rtems_semaphore_obtain`` and +``rtems_message_queue_receive`` directives. If the object were local, the +task's control block would be available for modification to indicate it was +blocking on a message queue or semaphore. However, the task's control block +resides only on the same node as the task. As a result, the remote node must allocate a proxy to represent the task until it can be readied. -The maximum number of proxies is defined in the -Multiprocessor Configuration Table. Each node in a -multiprocessor system may require a different number of proxies -to be configured. The distribution of proxy control blocks is -application dependent and is different from the distribution of -tasks. +The maximum number of proxies is defined in the Multiprocessor Configuration +Table. Each node in a multiprocessor system may require a different number of +proxies to be configured. The distribution of proxy control blocks is +application dependent and is different from the distribution of tasks. Multiprocessor Configuration Table ---------------------------------- -The Multiprocessor Configuration Table contains -information needed by RTEMS when used in a multiprocessor -system. This table is discussed in detail in the section -Multiprocessor Configuration Table of the Configuring a System -chapter. +The Multiprocessor Configuration Table contains information needed by RTEMS +when used in a multiprocessor system. This table is discussed in detail in the +section Multiprocessor Configuration Table of the Configuring a System chapter. Multiprocessor Communications Interface Layer ============================================= -The Multiprocessor Communications Interface Layer -(MPCI) is a set of user-provided procedures which enable the -nodes in a multiprocessor system to communicate with one -another. These routines are invoked by RTEMS at various times -in the preparation and processing of remote requests. -Interrupts are enabled when an MPCI procedure is invoked. It is -assumed that if the execution mode and/or interrupt level are -altered by the MPCI layer, that they will be restored prior to -returning to RTEMS... index:: MPCI, definition - -The MPCI layer is responsible for managing a pool of -buffers called packets and for sending these packets between -system nodes. Packet buffers contain the messages sent between -the nodes. Typically, the MPCI layer will encapsulate the -packet within an envelope which contains the information needed -by the MPCI layer. The number of packets available is dependent -on the MPCI layer implementation... index:: MPCI entry points - -The entry points to the routines in the user's MPCI -layer should be placed in the Multiprocessor Communications -Interface Table. The user must provide entry points for each of -the following table entries in a multiprocessor system: - -- initialization initialize the MPCI - -- get_packet obtain a packet buffer - -- return_packet return a packet buffer - -- send_packet send a packet to another node - -- receive_packet called to get an arrived packet +The Multiprocessor Communications Interface Layer (MPCI) is a set of +user-provided procedures which enable the nodes in a multiprocessor system to +communicate with one another. These routines are invoked by RTEMS at various +times in the preparation and processing of remote requests. Interrupts are +enabled when an MPCI procedure is invoked. It is assumed that if the execution +mode and/or interrupt level are altered by the MPCI layer, that they will be +restored prior to returning to RTEMS. + +.. index:: MPCI, definition + +The MPCI layer is responsible for managing a pool of buffers called packets and +for sending these packets between system nodes. Packet buffers contain the +messages sent between the nodes. Typically, the MPCI layer will encapsulate +the packet within an envelope which contains the information needed by the MPCI +layer. The number of packets available is dependent on the MPCI layer +implementation. + +.. index:: MPCI entry points + +The entry points to the routines in the user's MPCI layer should be placed in +the Multiprocessor Communications Interface Table. The user must provide entry +points for each of the following table entries in a multiprocessor system: + +.. list-table:: + :class: rtems-table + + * - initialization + - initialize the MPCI + * - get_packet + - obtain a packet buffer + * - return_packet + - return a packet buffer + * - send_packet + - send a packet to another node + * - receive_packet + - called to get an arrived packet A packet is sent by RTEMS in each of the following situations: @@ -270,153 +252,144 @@ A packet is sent by RTEMS in each of the following situations: - during system initialization to check for system consistency. -If the target hardware supports it, the arrival of a -packet at a node may generate an interrupt. Otherwise, the -real-time clock ISR can check for the arrival of a packet. In -any case, the``rtems_multiprocessing_announce`` directive must be called -to announce the arrival of a packet. After exiting the ISR, -control will be passed to the Multiprocessing Server to process -the packet. The Multiprocessing Server will call the get_packet -entry to obtain a packet buffer and the receive_entry entry to -copy the message into the buffer obtained. +If the target hardware supports it, the arrival of a packet at a node may +generate an interrupt. Otherwise, the real-time clock ISR can check for the +arrival of a packet. In any case, the ``rtems_multiprocessing_announce`` +directive must be called to announce the arrival of a packet. After exiting +the ISR, control will be passed to the Multiprocessing Server to process the +packet. The Multiprocessing Server will call the get_packet entry to obtain a +packet buffer and the receive_entry entry to copy the message into the buffer +obtained. INITIALIZATION -------------- -The INITIALIZATION component of the user-provided -MPCI layer is called as part of the ``rtems_initialize_executive`` -directive to initialize the MPCI layer and associated hardware. -It is invoked immediately after all of the device drivers have -been initialized. This component should be adhere to the -following prototype:.. index:: rtems_mpci_entry +The INITIALIZATION component of the user-provided MPCI layer is called as part +of the ``rtems_initialize_executive`` directive to initialize the MPCI layer +and associated hardware. It is invoked immediately after all of the device +drivers have been initialized. This component should be adhere to the +following prototype: + +.. index:: rtems_mpci_entry .. code:: c rtems_mpci_entry user_mpci_initialization( - rtems_configuration_table \*configuration + rtems_configuration_table *configuration ); -where configuration is the address of the user's -Configuration Table. Operations on global objects cannot be -performed until this component is invoked. The INITIALIZATION -component is invoked only once in the life of any system. If -the MPCI layer cannot be successfully initialized, the fatal -error manager should be invoked by this routine. - -One of the primary functions of the MPCI layer is to -provide the executive with packet buffers. The INITIALIZATION -routine must create and initialize a pool of packet buffers. -There must be enough packet buffers so RTEMS can obtain one +where configuration is the address of the user's Configuration Table. +Operations on global objects cannot be performed until this component is +invoked. The INITIALIZATION component is invoked only once in the life of any +system. If the MPCI layer cannot be successfully initialized, the fatal error +manager should be invoked by this routine. + +One of the primary functions of the MPCI layer is to provide the executive with +packet buffers. The INITIALIZATION routine must create and initialize a pool +of packet buffers. There must be enough packet buffers so RTEMS can obtain one whenever needed. GET_PACKET ---------- -The GET_PACKET component of the user-provided MPCI -layer is called when RTEMS must obtain a packet buffer to send -or broadcast a message. This component should be adhere to the -following prototype: +The GET_PACKET component of the user-provided MPCI layer is called when RTEMS +must obtain a packet buffer to send or broadcast a message. This component +should be adhere to the following prototype: + .. code:: c rtems_mpci_entry user_mpci_get_packet( - rtems_packet_prefix \**packet + rtems_packet_prefix **packet ); -where packet is the address of a pointer to a packet. -This routine always succeeds and, upon return, packet will -contain the address of a packet. If for any reason, a packet -cannot be successfully obtained, then the fatal error manager -should be invoked. +where packet is the address of a pointer to a packet. This routine always +succeeds and, upon return, packet will contain the address of a packet. If for +any reason, a packet cannot be successfully obtained, then the fatal error +manager should be invoked. -RTEMS has been optimized to avoid the need for -obtaining a packet each time a message is sent or broadcast. -For example, RTEMS sends response messages (RR) back to the -originator in the same packet in which the request message (RQ) +RTEMS has been optimized to avoid the need for obtaining a packet each time a +message is sent or broadcast. For example, RTEMS sends response messages (RR) +back to the originator in the same packet in which the request message (RQ) arrived. RETURN_PACKET ------------- -The RETURN_PACKET component of the user-provided MPCI -layer is called when RTEMS needs to release a packet to the free -packet buffer pool. This component should be adhere to the -following prototype: +The RETURN_PACKET component of the user-provided MPCI layer is called when +RTEMS needs to release a packet to the free packet buffer pool. This component +should be adhere to the following prototype: + .. code:: c rtems_mpci_entry user_mpci_return_packet( - rtems_packet_prefix \*packet + rtems_packet_prefix *packet ); -where packet is the address of a packet. If the -packet cannot be successfully returned, the fatal error manager -should be invoked. +where packet is the address of a packet. If the packet cannot be successfully +returned, the fatal error manager should be invoked. RECEIVE_PACKET -------------- -The RECEIVE_PACKET component of the user-provided -MPCI layer is called when RTEMS needs to obtain a packet which -has previously arrived. This component should be adhere to the -following prototype: +The RECEIVE_PACKET component of the user-provided MPCI layer is called when +RTEMS needs to obtain a packet which has previously arrived. This component +should be adhere to the following prototype: + .. code:: c rtems_mpci_entry user_mpci_receive_packet( - rtems_packet_prefix \**packet + rtems_packet_prefix **packet ); -where packet is a pointer to the address of a packet -to place the message from another node. If a message is -available, then packet will contain the address of the message -from another node. If no messages are available, this entry +where packet is a pointer to the address of a packet to place the message from +another node. If a message is available, then packet will contain the address +of the message from another node. If no messages are available, this entry packet should contain NULL. SEND_PACKET ----------- -The SEND_PACKET component of the user-provided MPCI -layer is called when RTEMS needs to send a packet containing a -message to another node. This component should be adhere to the -following prototype: +The SEND_PACKET component of the user-provided MPCI layer is called when RTEMS +needs to send a packet containing a message to another node. This component +should be adhere to the following prototype: + .. code:: c rtems_mpci_entry user_mpci_send_packet( - uint32_t node, - rtems_packet_prefix \**packet + uint32_t node, + rtems_packet_prefix **packet ); -where node is the node number of the destination and packet is the -address of a packet which containing a message. If the packet cannot -be successfully sent, the fatal error manager should be invoked. +where node is the node number of the destination and packet is the address of a +packet which containing a message. If the packet cannot be successfully sent, +the fatal error manager should be invoked. -If node is set to zero, the packet is to be -broadcasted to all other nodes in the system. Although some -MPCI layers will be built upon hardware which support a -broadcast mechanism, others may be required to generate a copy -of the packet for each node in the system. +If node is set to zero, the packet is to be broadcasted to all other nodes in +the system. Although some MPCI layers will be built upon hardware which +support a broadcast mechanism, others may be required to generate a copy of the +packet for each node in the system. .. COMMENT: XXX packet_prefix structure needs to be defined in this document -Many MPCI layers use the ``packet_length`` field of the``rtems_packet_prefix`` portion -of the packet to avoid sending unnecessary data. This is especially +Many MPCI layers use the ``packet_length`` field of the ``rtems_packet_prefix`` +portion of the packet to avoid sending unnecessary data. This is especially useful if the media connecting the nodes is relatively slow. -The ``to_convert`` field of the ``rtems_packet_prefix`` portion of the -packet indicates how much of the packet in 32-bit units may require conversion -in a heterogeneous system. +The ``to_convert`` field of the ``rtems_packet_prefix`` portion of the packet +indicates how much of the packet in 32-bit units may require conversion in a +heterogeneous system. Supporting Heterogeneous Environments ------------------------------------- .. index:: heterogeneous multiprocessing -Developing an MPCI layer for a heterogeneous system -requires a thorough understanding of the differences between the -processors which comprise the system. One difficult problem is -the varying data representation schemes used by different -processor types. The most pervasive data representation problem -is the order of the bytes which compose a data entity. -Processors which place the least significant byte at the -smallest address are classified as little endian processors. -Little endian byte-ordering is shown below: +Developing an MPCI layer for a heterogeneous system requires a thorough +understanding of the differences between the processors which comprise the +system. One difficult problem is the varying data representation schemes used +by different processor types. The most pervasive data representation problem +is the order of the bytes which compose a data entity. Processors which place +the least significant byte at the smallest address are classified as little +endian processors. Little endian byte-ordering is shown below: .. code:: c @@ -426,9 +399,10 @@ Little endian byte-ordering is shown below: | | | | | +---------------+----------------+---------------+----------------+ -Conversely, processors which place the most -significant byte at the smallest address are classified as big -endian processors. Big endian byte-ordering is shown below: +Conversely, processors which place the most significant byte at the smallest +address are classified as big endian processors. Big endian byte-ordering is +shown below: + .. code:: c +---------------+----------------+---------------+----------------+ @@ -437,47 +411,45 @@ endian processors. Big endian byte-ordering is shown below: | | | | | +---------------+----------------+---------------+----------------+ -Unfortunately, sharing a data structure between big -endian and little endian processors requires translation into a -common endian format. An application designer typically chooses -the common endian format to minimize conversion overhead. - -Another issue in the design of shared data structures -is the alignment of data structure elements. Alignment is both -processor and compiler implementation dependent. For example, -some processors allow data elements to begin on any address -boundary, while others impose restrictions. Common restrictions -are that data elements must begin on either an even address or -on a long word boundary. Violation of these restrictions may -cause an exception or impose a performance penalty. - -Other issues which commonly impact the design of -shared data structures include the representation of floating -point numbers, bit fields, decimal data, and character strings. -In addition, the representation method for negative integers -could be one's or two's complement. These factors combine to -increase the complexity of designing and manipulating data -structures shared between processors. - -RTEMS addressed these issues in the design of the -packets used to communicate between nodes. The RTEMS packet -format is designed to allow the MPCI layer to perform all -necessary conversion without burdening the developer with the -details of the RTEMS packet format. As a result, the MPCI layer -must be aware of the following: +Unfortunately, sharing a data structure between big endian and little endian +processors requires translation into a common endian format. An application +designer typically chooses the common endian format to minimize conversion +overhead. + +Another issue in the design of shared data structures is the alignment of data +structure elements. Alignment is both processor and compiler implementation +dependent. For example, some processors allow data elements to begin on any +address boundary, while others impose restrictions. Common restrictions are +that data elements must begin on either an even address or on a long word +boundary. Violation of these restrictions may cause an exception or impose a +performance penalty. + +Other issues which commonly impact the design of shared data structures include +the representation of floating point numbers, bit fields, decimal data, and +character strings. In addition, the representation method for negative +integers could be one's or two's complement. These factors combine to increase +the complexity of designing and manipulating data structures shared between +processors. + +RTEMS addressed these issues in the design of the packets used to communicate +between nodes. The RTEMS packet format is designed to allow the MPCI layer to +perform all necessary conversion without burdening the developer with the +details of the RTEMS packet format. As a result, the MPCI layer must be aware +of the following: - All packets must begin on a four byte boundary. -- Packets are composed of both RTEMS and application data. All RTEMS data - is treated as 32-bit unsigned quantities and is in the first ``to_convert`` - 32-bit quantities of the packet. The ``to_convert`` field is part of the``rtems_packet_prefix`` portion of the packet. +- Packets are composed of both RTEMS and application data. All RTEMS data is + treated as 32-bit unsigned quantities and is in the first ``to_convert`` + 32-bit quantities of the packet. The ``to_convert`` field is part of the + ``rtems_packet_prefix`` portion of the packet. -- The RTEMS data component of the packet must be in native - endian format. Endian conversion may be performed by either the - sending or receiving MPCI layer. +- The RTEMS data component of the packet must be in native endian format. + Endian conversion may be performed by either the sending or receiving MPCI + layer. -- RTEMS makes no assumptions regarding the application - data component of the packet. +- RTEMS makes no assumptions regarding the application data component of the + packet. Operations ========== @@ -485,19 +457,19 @@ Operations Announcing a Packet ------------------- -The ``rtems_multiprocessing_announce`` directive is called by -the MPCI layer to inform RTEMS that a packet has arrived from -another node. This directive can be called from an interrupt -service routine or from within a polling routine. +The ``rtems_multiprocessing_announce`` directive is called by the MPCI layer to +inform RTEMS that a packet has arrived from another node. This directive can +be called from an interrupt service routine or from within a polling routine. Directives ========== -This section details the additional directives -required to support RTEMS in a multiprocessor configuration. A -subsection is dedicated to each of this manager's directives and -describes the calling sequence, related constants, usage, and -status codes. +This section details the additional directives required to support RTEMS in a +multiprocessor configuration. A subsection is dedicated to each of this +manager's directives and describes the calling sequence, related constants, +usage, and status codes. + +.. _rtems_multiprocessing_announce: MULTIPROCESSING_ANNOUNCE - Announce the arrival of a packet ----------------------------------------------------------- @@ -517,23 +489,14 @@ NONE **DESCRIPTION:** -This directive informs RTEMS that a multiprocessing -communications packet has arrived from another node. This -directive is called by the user-provided MPCI, and is only used -in multiprocessor configurations. +This directive informs RTEMS that a multiprocessing communications packet has +arrived from another node. This directive is called by the user-provided MPCI, +and is only used in multiprocessor configurations. **NOTES:** This directive is typically called from an ISR. -This directive will almost certainly cause the -calling task to be preempted. +This directive will almost certainly cause the calling task to be preempted. This directive does not generate activity on remote nodes. - -.. COMMENT: COPYRIGHT (c) 2014. - -.. COMMENT: On-Line Applications Research Corporation (OAR). - -.. COMMENT: All rights reserved. - diff --git a/c_user/pci_library.rst b/c_user/pci_library.rst index 0512b45..6d97e3d 100644 --- a/c_user/pci_library.rst +++ b/c_user/pci_library.rst @@ -1,3 +1,7 @@ +.. COMMENT: COPYRIGHT (c) 1988-2008. +.. COMMENT: On-Line Applications Research Corporation (OAR). +.. COMMENT: All rights reserved. + PCI Library ########### @@ -6,19 +10,19 @@ PCI Library Introduction ============ -The Peripheral Component Interconnect (PCI) bus is a very common computer -bus architecture that is found in almost every PC today. The PCI bus is -normally located at the motherboard where some PCI devices are soldered -directly onto the PCB and expansion slots allows the user to add custom -devices easily. There is a wide range of PCI hardware available implementing -all sorts of interfaces and functions. +The Peripheral Component Interconnect (PCI) bus is a very common computer bus +architecture that is found in almost every PC today. The PCI bus is normally +located at the motherboard where some PCI devices are soldered directly onto +the PCB and expansion slots allows the user to add custom devices easily. There +is a wide range of PCI hardware available implementing all sorts of interfaces +and functions. This section describes the PCI Library available in RTEMS used to access the PCI bus in a portable way across computer architectures supported by RTEMS. The PCI Library aims to be compatible with PCI 2.3 with a couple of -limitations, for example there is no support for hot-plugging, 64-bit -memory space and cardbus bridges. +limitations, for example there is no support for hot-plugging, 64-bit memory +space and cardbus bridges. In order to support different architectures and with small foot-print embedded systems in mind the PCI Library offers four different configuration options @@ -26,7 +30,7 @@ listed below. It is selected during compile time by defining the appropriate macros in confdefs.h. It is also possible to enable PCI_LIB_NONE (No Configuration) which can be used for debuging PCI access functions. -- Auto Configuration (do Plug & Play) +- Auto Configuration (Plug & Play) - Read Configuration (read BIOS or boot loader configuration) @@ -37,24 +41,24 @@ Configuration) which can be used for debuging PCI access functions. Background ========== -The PCI bus is constructed in a way where on-board devices and devices -in expansion slots can be automatically found (probed) and configured -using Plug & Play completely implemented in software. The bus is set up once -during boot up. The Plug & Play information can be read and written from -PCI configuration space. A PCI device is identified in configuration space by -a unique bus, slot and function number. Each PCI slot can have up to 8 -functions and interface to another PCI sub-bus by implementing a PCI-to-PCI -bridge according to the PCI Bridge Architecture specification. - -Using the unique \[bus:slot:func] any device can be configured regardless of how -PCI is currently set up as long as all PCI buses are enumerated correctly. The -enumeration is done during probing, all bridges are given a bus number in -order for the bridges to respond to accesses from both directions. The PCI -library can assign address ranges to which a PCI device should respond using -Plug & Play technique or a static user defined configuration. After the -configuration has been performed the PCI device drivers can find devices by -the read-only PCI Class type, Vendor ID and Device ID information found in -configuration space for each device. +The PCI bus is constructed in a way where on-board devices and devices in +expansion slots can be automatically found (probed) and configured using Plug & +Play completely implemented in software. The bus is set up once during boot +up. The Plug & Play information can be read and written from PCI configuration +space. A PCI device is identified in configuration space by a unique bus, slot +and function number. Each PCI slot can have up to 8 functions and interface to +another PCI sub-bus by implementing a PCI-to-PCI bridge according to the PCI +Bridge Architecture specification. + +Using the unique \[bus:slot:func] any device can be configured regardless of +how PCI is currently set up as long as all PCI buses are enumerated +correctly. The enumeration is done during probing, all bridges are given a bus +number in order for the bridges to respond to accesses from both +directions. The PCI library can assign address ranges to which a PCI device +should respond using Plug & Play technique or a static user defined +configuration. After the configuration has been performed the PCI device +drivers can find devices by the read-only PCI Class type, Vendor ID and Device +ID information found in configuration space for each device. In some systems there is a boot loader or BIOS which have already configured all PCI devices, but on embedded targets it is quite common that there is no @@ -65,14 +69,13 @@ translate the \[bus:slot:func] into a valid PCI configuration space access. If the target is not a host, but a peripheral, configuration space can not be accessed, the peripheral is set up by the host during start up. In complex embedded PCI systems the peripheral may need to access other PCI boards than -the host. In such systems a custom (static) configuration of both the host -and peripheral may be a convenient solution. +the host. In such systems a custom (static) configuration of both the host and +peripheral may be a convenient solution. The PCI bus defines four interrupt signals INTA#..INTD#. The interrupt signals must be mapped into a system interrupt/vector, it is up to the BSP or host -driver to know the mapping, however the BIOS or boot loader may use the -8-bit read/write "Interrupt Line" register to pass the knowledge along to the -OS. +driver to know the mapping, however the BIOS or boot loader may use the 8-bit +read/write "Interrupt Line" register to pass the knowledge along to the OS. The PCI standard defines and recommends that the backplane route the interupt lines in a systematic way, however in standard there is no such requirement. @@ -105,8 +108,8 @@ PCI Configuration During start up the PCI bus must be configured in order for host and peripherals to access one another using Memory or I/O accesses and that -interrupts are properly handled. Three different spaces are defined and -mapped separately: +interrupts are properly handled. Three different spaces are defined and mapped +separately: # I/O space (IO) @@ -114,14 +117,14 @@ mapped separately: # prefetchable Memory space (MEM) -Regions of the same type (I/O or Memory) may not overlap which is guaranteed -by the software. MEM regions may be mapped into MEMIO regions, but MEMIO -regions can not be mapped into MEM, for that could lead to prefetching of -registers. The interrupt pin which a board is driving can be read out from -PCI configuration space, however it is up to software to know how interrupt -signals are routed between PCI-to-PCI bridges and how PCI INT[A..D]# pins are -mapped to system IRQ. In systems where previous software (boot loader or BIOS) -has already set up this the configuration is overwritten or simply read out. +Regions of the same type (I/O or Memory) may not overlap which is guaranteed by +the software. MEM regions may be mapped into MEMIO regions, but MEMIO regions +can not be mapped into MEM, for that could lead to prefetching of +registers. The interrupt pin which a board is driving can be read out from PCI +configuration space, however it is up to software to know how interrupt signals +are routed between PCI-to-PCI bridges and how PCI INT[A..D]# pins are mapped to +system IRQ. In systems where previous software (boot loader or BIOS) has +already set up this the configuration is overwritten or simply read out. In order to support different configuration methods the following configuration libraries are selectable by the user: @@ -138,7 +141,8 @@ libraries are selectable by the user: A host driver can be made to support all three configuration methods, or any combination. It may be defined by the BSP which approach is used. -The configuration software is called from the PCI driver (pci_config_init()). +The configuration software is called from the PCI driver +(``pci_config_init()``). Regardless of configuration method a PCI device tree is created in RAM during initialization, the tree can be accessed to find devices and resources without @@ -148,14 +152,14 @@ device tree at compile time when using the static/peripheral method. RTEMS Configuration selection ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The active configuration method can be selected at compile time in the same -way as other project parameters by including rtems/confdefs.h and setting +The active configuration method can be selected at compile time in the same way +as other project parameters by including rtems/confdefs.h and setting -- CONFIGURE_INIT +- ``CONFIGURE_INIT`` -- RTEMS_PCI_CONFIG_LIB +- ``RTEMS_PCI_CONFIG_LIB`` -- CONFIGURE_PCI_LIB = PCI_LIB_(AUTO,STATIC,READ,PERIPHERAL) +- ``CONFIGURE_PCI_LIB`` = PCI_LIB_(AUTO,STATIC,READ,PERIPHERAL) See the RTEMS configuration section how to setup the PCI library. @@ -163,17 +167,17 @@ Auto Configuration ~~~~~~~~~~~~~~~~~~ The auto configuration software enumerates PCI buses and initializes all PCI -devices found using Plug & Play. The auto configuration software requires -that a configuration setup has been registered by the driver or BSP in order -to setup the I/O and Memory regions at the correct address ranges. PCI -interrupt pins can optionally be routed over PCI-to-PCI bridges and mapped -to a system interrupt number. BAR resources are sorted by size and required -alignment, unused "dead" space may be created when PCI bridges are present -due to the PCI bridge window size does not equal the alignment. To cope with -that resources are reordered to fit smaller BARs into the dead space to minimize -the PCI space required. If a BAR or ROM register can not be allocated a PCI -address region (due to too few resources available) the register will be given -the value of pci_invalid_address which defaults to 0. +devices found using Plug & Play. The auto configuration software requires that +a configuration setup has been registered by the driver or BSP in order to +setup the I/O and Memory regions at the correct address ranges. PCI interrupt +pins can optionally be routed over PCI-to-PCI bridges and mapped to a system +interrupt number. BAR resources are sorted by size and required alignment, +unused "dead" space may be created when PCI bridges are present due to the PCI +bridge window size does not equal the alignment. To cope with that resources +are reordered to fit smaller BARs into the dead space to minimize the PCI space +required. If a BAR or ROM register can not be allocated a PCI address region +(due to too few resources available) the register will be given the value of +pci_invalid_address which defaults to 0. The auto configuration routines support: @@ -185,8 +189,7 @@ The auto configuration routines support: - memory space (MEMIO) -- prefetchable memory space (MEM), if not present MEM will be mapped into - MEMIO +- prefetchable memory space (MEM), if not present MEM will be mapped into MEMIO - multiple PCI buses - PCI-to-PCI bridges @@ -224,8 +227,8 @@ Static Configuration ~~~~~~~~~~~~~~~~~~~~ To support custom configurations and small-footprint PCI systems, the user may -provide the PCI device tree which contains the current configuration. The -PCI buses are enumerated and all resources are written to PCI devices during +provide the PCI device tree which contains the current configuration. The PCI +buses are enumerated and all resources are written to PCI devices during initialization. When this approach is selected PCI boards must be located at the same slots every time and devices can not be removed or added, Plug & Play is not performed. Boards of the same type may of course be exchanged. @@ -240,13 +243,13 @@ Peripheral Configuration On systems where a peripheral PCI device needs to access other PCI devices than the host the peripheral configuration approach may be handy. Most PCI devices -answers on the PCI host's requests and start DMA accesses into the Hosts memory, -however in some complex systems PCI devices may want to access other devices -on the same bus or at another PCI bus. +answers on the PCI host's requests and start DMA accesses into the Hosts +memory, however in some complex systems PCI devices may want to access other +devices on the same bus or at another PCI bus. -A PCI peripheral is not allowed to do PCI configuration cycles, which -means that it must either rely on the host to give it the addresses it -needs, or that the addresses are predefined. +A PCI peripheral is not allowed to do PCI configuration cycles, which means +that it must either rely on the host to give it the addresses it needs, or that +the addresses are predefined. This configuration approach is very similar to the static option, however the configuration is never written to PCI bus, instead it is only used for drivers @@ -256,8 +259,8 @@ PCI Access ---------- The PCI access routines are low-level routines provided for drivers, -configuration software, etc. in order to access different regions in a way -not dependent upon the host driver, BSP or platform. +configuration software, etc. in order to access different regions in a way not +dependent upon the host driver, BSP or platform. - PCI configuration space @@ -275,26 +278,28 @@ configuration space access. Some non-standard hardware may also define the PCI bus big-endian, for example the LEON2 AT697 PCI host bridge and some LEON3 systems may be configured that way. It is up to the BSP to set the appropriate PCI endianness on compile time -(BSP_PCI_BIG_ENDIAN) in order for inline macros to be correctly defined. -Another possibility is to use the function pointers defined by the access -layer to implement drivers that support "run-time endianness detection". +(``BSP_PCI_BIG_ENDIAN``) in order for inline macros to be correctly defined. +Another possibility is to use the function pointers defined by the access layer +to implement drivers that support "run-time endianness detection". Configuration space ~~~~~~~~~~~~~~~~~~~ -Configuration space is accessed using the routines listed below. The -pci_dev_t type is used to specify a specific PCI bus, device and function. It -is up to the host driver or BSP to create a valid access to the requested -PCI slot. Requests made to slots that are not supported by hardware should -result in PCISTS_MSTABRT and/or data must be ignored (writes) or 0xffffffff -is always returned (reads). +Configuration space is accessed using the routines listed below. The pci_dev_t +type is used to specify a specific PCI bus, device and function. It is up to +the host driver or BSP to create a valid access to the requested PCI +slot. Requests made to slots that are not supported by hardware should result +in ``PCISTS_MSTABRT`` and/or data must be ignored (writes) or ``0xFFFFFFFF`` is +always returned (reads). + .. code:: c - /* Configuration Space Access Read Routines \*/ - extern int pci_cfg_r8(pci_dev_t dev, int ofs, uint8_t \*data); - extern int pci_cfg_r16(pci_dev_t dev, int ofs, uint16_t \*data); - extern int pci_cfg_r32(pci_dev_t dev, int ofs, uint32_t \*data); - /* Configuration Space Access Write Routines \*/ + /* Configuration Space Access Read Routines */ + extern int pci_cfg_r8(pci_dev_t dev, int ofs, uint8_t *data); + extern int pci_cfg_r16(pci_dev_t dev, int ofs, uint16_t *data); + extern int pci_cfg_r32(pci_dev_t dev, int ofs, uint32_t *data); + + /* Configuration Space Access Write Routines */ extern int pci_cfg_w8(pci_dev_t dev, int ofs, uint8_t data); extern int pci_cfg_w16(pci_dev_t dev, int ofs, uint16_t data); extern int pci_cfg_w32(pci_dev_t dev, int ofs, uint32_t data); @@ -305,20 +310,20 @@ I/O space The BSP or driver provide special routines in order to access I/O space. Some architectures have a special instruction accessing I/O space, others have it mapped into a "PCI I/O window" in the standard address space accessed by the -CPU. The window size may vary and must be taken into consideration by the -host driver. The below routines must be used to access I/O space. The address -given to the functions is not the PCI I/O addresses, the caller must have -translated PCI I/O addresses (available in the PCI BARs) into a BSP or host -driver custom address, see `Access functions`_ for how -addresses are translated. +CPU. The window size may vary and must be taken into consideration by the host +driver. The below routines must be used to access I/O space. The address given +to the functions is not the PCI I/O addresses, the caller must have translated +PCI I/O addresses (available in the PCI BARs) into a BSP or host driver custom +address, see `Access functions`_ for how addresses are translated. .. code:: c - /* Read a register over PCI I/O Space \*/ + /* Read a register over PCI I/O Space */ extern uint8_t pci_io_r8(uint32_t adr); extern uint16_t pci_io_r16(uint32_t adr); extern uint32_t pci_io_r32(uint32_t adr); - /* Write a register over PCI I/O Space \*/ + + /* Write a register over PCI I/O Space */ extern void pci_io_w8(uint32_t adr, uint8_t data); extern void pci_io_w16(uint32_t adr, uint16_t data); extern void pci_io_w32(uint32_t adr, uint32_t data); @@ -334,52 +339,53 @@ memory space. This leads to register content being swapped, which must be swapped back. The below routines makes it possible to access registers over PCI memory space in a portable way on different architectures, the BSP or architecture must provide necessary functions in order to implement this. + .. code:: c - static inline uint16_t pci_ld_le16(volatile uint16_t \*addr); - static inline void pci_st_le16(volatile uint16_t \*addr, uint16_t val); - static inline uint32_t pci_ld_le32(volatile uint32_t \*addr); - static inline void pci_st_le32(volatile uint32_t \*addr, uint32_t val); - static inline uint16_t pci_ld_be16(volatile uint16_t \*addr); - static inline void pci_st_be16(volatile uint16_t \*addr, uint16_t val); - static inline uint32_t pci_ld_be32(volatile uint32_t \*addr); - static inline void pci_st_be32(volatile uint32_t \*addr, uint32_t val); + static inline uint16_t pci_ld_le16(volatile uint16_t *addr); + static inline void pci_st_le16(volatile uint16_t *addr, uint16_t val); + static inline uint32_t pci_ld_le32(volatile uint32_t *addr); + static inline void pci_st_le32(volatile uint32_t *addr, uint32_t val); + static inline uint16_t pci_ld_be16(volatile uint16_t *addr); + static inline void pci_st_be16(volatile uint16_t *addr, uint16_t val); + static inline uint32_t pci_ld_be32(volatile uint32_t *addr); + static inline void pci_st_be32(volatile uint32_t *addr, uint32_t val); -In order to support non-standard big-endian PCI bus the above pci_* functions -is required, pci_ld_le16 != ld_le16 on big endian PCI buses. +In order to support non-standard big-endian PCI bus the above ``pci_*`` +functions is required, ``pci_ld_le16 != ld_le16`` on big endian PCI buses. Access functions ~~~~~~~~~~~~~~~~ The PCI Access Library can provide device drivers with function pointers -executing the above Configuration, I/O and Memory space accesses. The -functions have the same arguments and return values as the above -functions. +executing the above Configuration, I/O and Memory space accesses. The functions +have the same arguments and return values as the above functions. The pci_access_func() function defined below can be used to get a function pointer of a specific access type. + .. code:: c /* Get Read/Write function for accessing a register over PCI Memory Space - * (non-inline functions). - * - * Arguments - * wr 0(Read), 1(Write) - * size 1(Byte), 2(Word), 4(Double Word) - * func Where function pointer will be stored - * endian PCI_LITTLE_ENDIAN or PCI_BIG_ENDIAN - * type 1(I/O), 3(REG over MEM), 4(CFG) - * - * Return - * 0 Found function - * others No such function defined by host driver or BSP - \*/ - int pci_access_func(int wr, int size, void \**func, int endian, int type); + * (non-inline functions). + * + * Arguments + * wr 0(Read), 1(Write) + * size 1(Byte), 2(Word), 4(Double Word) + * func Where function pointer will be stored + * endian PCI_LITTLE_ENDIAN or PCI_BIG_ENDIAN + * type 1(I/O), 3(REG over MEM), 4(CFG) + * + * Return + * 0 Found function + * others No such function defined by host driver or BSP + */ + int pci_access_func(int wr, int size, void **func, int endian, int type); PCI device drivers may be written to support run-time detection of endianess, this is mosly for debugging or for development systems. When the product is -finally deployed macros switch to using the inline functions instead which -have been configured for the correct endianness. +finally deployed macros switch to using the inline functions instead which have +been configured for the correct endianness. PCI address translation ~~~~~~~~~~~~~~~~~~~~~~~ @@ -390,23 +396,25 @@ using configuration space routines or in the device tree, the addresses given are PCI addresses. The below functions can be used to translate PCI addresses into CPU accessible addresses or vice versa, translation may be different for different PCI spaces/regions. + .. code:: c - /* Translate PCI address into CPU accessible address \*/ - static inline int pci_pci2cpu(uint32_t \*address, int type); - /* Translate CPU accessible address into PCI address (for DMA) \*/ - static inline int pci_cpu2pci(uint32_t \*address, int type); + /* Translate PCI address into CPU accessible address */ + static inline int pci_pci2cpu(uint32_t *address, int type); + + /* Translate CPU accessible address into PCI address (for DMA) */ + static inline int pci_cpu2pci(uint32_t *address, int type); PCI Interrupt ------------- -The PCI specification defines four different interrupt lines INTA#..INTD#, -the interrupts are low level sensitive which make it possible to support -multiple interrupt sources on the same interrupt line. Since the lines are -level sensitive the interrupt sources must be acknowledged before clearing the +The PCI specification defines four different interrupt lines INTA#..INTD#, the +interrupts are low level sensitive which make it possible to support multiple +interrupt sources on the same interrupt line. Since the lines are level +sensitive the interrupt sources must be acknowledged before clearing the interrupt contoller, or the interrupt controller must be masked. The BSP must -provide a routine for clearing/acknowledging the interrupt controller, it is -up to the interrupt service routine to acknowledge the interrupt source. +provide a routine for clearing/acknowledging the interrupt controller, it is up +to the interrupt service routine to acknowledge the interrupt source. The PCI Library relies on the BSP for implementing shared interrupt handling through the BSP_PCI_shared_interrupt_* functions/macros, they must be defined @@ -423,10 +431,3 @@ PCI Shell command The RTEMS shell has a PCI command 'pci' which makes it possible to read/write configuration space, print the current PCI configuration and print out a configuration C-file for the static or peripheral library. - -.. COMMENT: COPYRIGHT (c) 1988-2007. - -.. COMMENT: On-Line Applications Research Corporation (OAR). - -.. COMMENT: All rights reserved. - diff --git a/c_user/symmetric_multiprocessing_services.rst b/c_user/symmetric_multiprocessing_services.rst index 998a066..c45c3e1 100644 --- a/c_user/symmetric_multiprocessing_services.rst +++ b/c_user/symmetric_multiprocessing_services.rst @@ -1,11 +1,15 @@ +.. COMMENT: COPYRIGHT (c) 2011,2015 +.. COMMENT: Aeroflex Gaisler AB +.. COMMENT: All rights reserved. + Symmetric Multiprocessing Services ################################## Introduction ============ -The Symmetric Multiprocessing (SMP) support of the RTEMS 4.10.99.0 is -available on +The Symmetric Multiprocessing (SMP) support of the RTEMS 4.11.0 and later is available +on - ARM, @@ -13,34 +17,38 @@ available on - SPARC. -It must be explicitly enabled via the ``--enable-smp`` configure command -line option. To enable SMP in the application configuration see `Enable SMP Support for Applications`_. The default -scheduler for SMP applications supports up to 32 processors and is a global -fixed priority scheduler, see also `Configuring Clustered Schedulers`_. For example applications see:file:`testsuites/smptests`. +It must be explicitly enabled via the ``--enable-smp`` configure command line +option. To enable SMP in the application configuration see `Enable SMP Support +for Applications`_. The default scheduler for SMP applications supports up to +32 processors and is a global fixed priority scheduler, see also +:ref:`Configuring Clustered Schedulers`. For example applications +see:file:`testsuites/smptests`. -*WARNING: The SMP support in RTEMS is work in progress. Before you -start using this RTEMS version for SMP ask on the RTEMS mailing list.* +.. warning:: + + The SMP support in RTEMS is work in progress. Before you start using this + RTEMS version for SMP ask on the RTEMS mailing list. This chapter describes the services related to Symmetric Multiprocessing provided by RTEMS. The application level services currently provided are: -- ``rtems_get_processor_count`` - Get processor count +- rtems_get_processor_count_ - Get processor count -- ``rtems_get_current_processor`` - Get current processor index +- rtems_get_current_processor_ - Get current processor index -- ``rtems_scheduler_ident`` - Get ID of a scheduler +- rtems_scheduler_ident_ - Get ID of a scheduler -- ``rtems_scheduler_get_processor_set`` - Get processor set of a scheduler +- rtems_scheduler_get_processor_set_ - Get processor set of a scheduler -- ``rtems_task_get_scheduler`` - Get scheduler of a task +- rtems_task_get_scheduler_ - Get scheduler of a task -- ``rtems_task_set_scheduler`` - Set scheduler of a task +- rtems_task_set_scheduler_ - Set scheduler of a task -- ``rtems_task_get_affinity`` - Get task processor affinity +- rtems_task_get_affinity_ - Get task processor affinity -- ``rtems_task_set_affinity`` - Set task processor affinity +- rtems_task_set_affinity_ - Set task processor affinity Background ========== @@ -56,65 +64,62 @@ taken for granted: - hardware events result in interrupts -There is no true parallelism. Even when interrupts appear to occur -at the same time, they are processed in largely a serial fashion. -This is true even when the interupt service routines are allowed to -nest. From a tasking viewpoint, it is the responsibility of the real-time -operatimg system to simulate parallelism by switching between tasks. -These task switches occur in response to hardware interrupt events and explicit -application events such as blocking for a resource or delaying. - -With symmetric multiprocessing, the presence of multiple processors -allows for true concurrency and provides for cost-effective performance -improvements. Uniprocessors tend to increase performance by increasing -clock speed and complexity. This tends to lead to hot, power hungry -microprocessors which are poorly suited for many embedded applications. - -The true concurrency is in sharp contrast to the single task and -interrupt model of uniprocessor systems. This results in a fundamental -change to uniprocessor system characteristics listed above. Developers -are faced with a different set of characteristics which, in turn, break -some existing assumptions and result in new challenges. In an SMP system -with N processors, these are the new execution characteristics. +There is no true parallelism. Even when interrupts appear to occur at the same +time, they are processed in largely a serial fashion. This is true even when +the interupt service routines are allowed to nest. From a tasking viewpoint, +it is the responsibility of the real-time operatimg system to simulate +parallelism by switching between tasks. These task switches occur in response +to hardware interrupt events and explicit application events such as blocking +for a resource or delaying. + +With symmetric multiprocessing, the presence of multiple processors allows for +true concurrency and provides for cost-effective performance +improvements. Uniprocessors tend to increase performance by increasing clock +speed and complexity. This tends to lead to hot, power hungry microprocessors +which are poorly suited for many embedded applications. + +The true concurrency is in sharp contrast to the single task and interrupt +model of uniprocessor systems. This results in a fundamental change to +uniprocessor system characteristics listed above. Developers are faced with a +different set of characteristics which, in turn, break some existing +assumptions and result in new challenges. In an SMP system with N processors, +these are the new execution characteristics. - N tasks execute in parallel - hardware events result in interrupts -There is true parallelism with a task executing on each processor and -the possibility of interrupts occurring on each processor. Thus in contrast -to their being one task and one interrupt to consider on a uniprocessor, -there are N tasks and potentially N simultaneous interrupts to consider -on an SMP system. - -This increase in hardware complexity and presence of true parallelism -results in the application developer needing to be even more cautious -about mutual exclusion and shared data access than in a uniprocessor -embedded system. Race conditions that never or rarely happened when an -application executed on a uniprocessor system, become much more likely -due to multiple threads executing in parallel. On a uniprocessor system, -these race conditions would only happen when a task switch occurred at -just the wrong moment. Now there are N-1 tasks executing in parallel -all the time and this results in many more opportunities for small -windows in critical sections to be hit. +There is true parallelism with a task executing on each processor and the +possibility of interrupts occurring on each processor. Thus in contrast to +their being one task and one interrupt to consider on a uniprocessor, there are +N tasks and potentially N simultaneous interrupts to consider on an SMP system. + +This increase in hardware complexity and presence of true parallelism results +in the application developer needing to be even more cautious about mutual +exclusion and shared data access than in a uniprocessor embedded system. Race +conditions that never or rarely happened when an application executed on a +uniprocessor system, become much more likely due to multiple threads executing +in parallel. On a uniprocessor system, these race conditions would only happen +when a task switch occurred at just the wrong moment. Now there are N-1 tasks +executing in parallel all the time and this results in many more opportunities +for small windows in critical sections to be hit. Task Affinity ------------- .. index:: task affinity .. index:: thread affinity -RTEMS provides services to manipulate the affinity of a task. Affinity -is used to specify the subset of processors in an SMP system on which -a particular task can execute. +RTEMS provides services to manipulate the affinity of a task. Affinity is used +to specify the subset of processors in an SMP system on which a particular task +can execute. By default, tasks have an affinity which allows them to execute on any available processor. Task affinity is a possible feature to be supported by SMP-aware schedulers. However, only a subset of the available schedulers support -affinity. Although the behavior is scheduler specific, if the scheduler -does not support affinity, it is likely to ignore all attempts to set -affinity. +affinity. Although the behavior is scheduler specific, if the scheduler does +not support affinity, it is likely to ignore all attempts to set affinity. The scheduler with support for arbitary processor affinities uses a proof of concept implementation. See https://devel.rtems.org/ticket/2510. @@ -130,12 +135,13 @@ to another. There are three reasons why tasks migrate in RTEMS. - The scheduler changes explicitly via ``rtems_task_set_scheduler()`` or similar directives. -- The task resumes execution after a blocking operation. On a priority - based scheduler it will evict the lowest priority task currently assigned to a +- The task resumes execution after a blocking operation. On a priority based + scheduler it will evict the lowest priority task currently assigned to a processor in the processor set managed by the scheduler instance. - The task moves temporarily to another scheduler instance due to locking - protocols like *Migratory Priority Inheritance* or the*Multiprocessor Resource Sharing Protocol*. + protocols like *Migratory Priority Inheritance* or the *Multiprocessor + Resource Sharing Protocol*. Task migration should be avoided so that the working set of a task can stay on the most local cache level. @@ -173,8 +179,9 @@ clusters. Clusters with a cardinality of one are partitions. Each cluster is owned by exactly one scheduler instance. Clustered scheduling helps to control the worst-case latencies in -multi-processor systems, see *Brandenburg, Bjorn B.: Scheduling and -Locking in Multiprocessor Real-Time Operating Systems. PhD thesis, 2011.http://www.cs.unc.edu/~bbb/diss/brandenburg-diss.pdf*. The goal is to +multi-processor systems, see *Brandenburg, Bjorn B.: Scheduling and Locking in +Multiprocessor Real-Time Operating Systems. PhD thesis, +2011.http://www.cs.unc.edu/~bbb/diss/brandenburg-diss.pdf*. The goal is to reduce the amount of shared state in the system and thus prevention of lock contention. Modern multi-processor systems tend to have several layers of data and instruction caches. With clustered scheduling it is possible to honour the @@ -188,8 +195,8 @@ available - message queues, -- semaphores using the `Priority Inheritance`_ - protocol (priority boosting), and +- semaphores using the `Priority Inheritance`_ protocol (priority boosting), + and - semaphores using the `Multiprocessor Resource Sharing Protocol`_ (MrsP). @@ -198,9 +205,10 @@ real-time requirements and functions that profit from fairness and high throughput provided the scheduler instances are fully decoupled and adequate inter-cluster synchronization primitives are used. This is work in progress. -For the configuration of clustered schedulers see `Configuring Clustered Schedulers`_. +For the configuration of clustered schedulers see `Configuring Clustered +Schedulers`_. -To set the scheduler of a task see `SCHEDULER_IDENT - Get ID of a scheduler`_ +To set the scheduler of a task see `SCHEDULER_IDENT - Get ID of a scheduler`_ and `TASK_SET_SCHEDULER - Set scheduler of a task`_. Task Priority Queues @@ -220,9 +228,11 @@ appended to the FIFO. To dequeue a task the highest priority task of the first priority queue in the FIFO is selected. Then the first priority queue is removed from the FIFO. In case the previously first priority queue is not empty, then it is appended to the FIFO. So there is FIFO fairness with respect -to the highest priority task of each scheduler instances. See also *Brandenburg, Bjorn B.: A fully preemptive multiprocessor semaphore protocol for -latency-sensitive real-time applications. In Proceedings of the 25th Euromicro -Conference on Real-Time Systems (ECRTS 2013), pages 292-302, 2013.http://www.mpi-sws.org/~bbb/papers/pdf/ecrts13b.pdf*. +to the highest priority task of each scheduler instances. See also +*Brandenburg, Bjorn B.: A fully preemptive multiprocessor semaphore protocol +for latency-sensitive real-time applications. In Proceedings of the 25th +Euromicro Conference on Real-Time Systems (ECRTS 2013), pages 292-302, +2013.http://www.mpi-sws.org/~bbb/papers/pdf/ecrts13b.pdf*. Such a two level queue may need a considerable amount of memory if fast enqueue and dequeue operations are desired (depends on the scheduler instance count). @@ -242,11 +252,11 @@ for the task itself. In case a task needs to block, then there are two options In case the task is dequeued, then there are two options -- the task is the last task on the queue, then it removes this queue from - the object and reclaims it for its own purpose, or +- the task is the last task on the queue, then it removes this queue from the + object and reclaims it for its own purpose, or -- otherwise, then the task removes one queue from the free list of the - object and reclaims it for its own purpose. +- otherwise, then the task removes one queue from the free list of the object + and reclaims it for its own purpose. Since there are usually more objects than tasks, this actually reduces the memory demands. In addition the objects contain only a pointer to the task @@ -257,39 +267,40 @@ and OpenMP run-time support). Scheduler Helping Protocol -------------------------- -The scheduler provides a helping protocol to support locking protocols like*Migratory Priority Inheritance* or the *Multiprocessor Resource -Sharing Protocol*. Each ready task can use at least one scheduler node at a -time to gain access to a processor. Each scheduler node has an owner, a user -and an optional idle task. The owner of a scheduler node is determined a task +The scheduler provides a helping protocol to support locking protocols like +*Migratory Priority Inheritance* or the *Multiprocessor Resource Sharing +Protocol*. Each ready task can use at least one scheduler node at a time to +gain access to a processor. Each scheduler node has an owner, a user and an +optional idle task. The owner of a scheduler node is determined a task creation and never changes during the life time of a scheduler node. The user of a scheduler node may change due to the scheduler helping protocol. A scheduler node is in one of the four scheduler help states: :dfn:`help yourself` This scheduler node is solely used by the owner task. This task owns no - resources using a helping protocol and thus does not take part in the scheduler - helping protocol. No help will be provided for other tasks. + resources using a helping protocol and thus does not take part in the + scheduler helping protocol. No help will be provided for other tasks. :dfn:`help active owner` - This scheduler node is owned by a task actively owning a resource and can be - used to help out tasks. - In case this scheduler node changes its state from ready to scheduled and the - task executes using another node, then an idle task will be provided as a user - of this node to temporarily execute on behalf of the owner task. Thus lower - priority tasks are denied access to the processors of this scheduler instance. - In case a task actively owning a resource performs a blocking operation, then - an idle task will be used also in case this node is in the scheduled state. + This scheduler node is owned by a task actively owning a resource and can + be used to help out tasks. In case this scheduler node changes its state + from ready to scheduled and the task executes using another node, then an + idle task will be provided as a user of this node to temporarily execute on + behalf of the owner task. Thus lower priority tasks are denied access to + the processors of this scheduler instance. In case a task actively owning + a resource performs a blocking operation, then an idle task will be used + also in case this node is in the scheduled state. :dfn:`help active rival` - This scheduler node is owned by a task actively obtaining a resource currently - owned by another task and can be used to help out tasks. - The task owning this node is ready and will give away its processor in case the + This scheduler node is owned by a task actively obtaining a resource + currently owned by another task and can be used to help out tasks. The + task owning this node is ready and will give away its processor in case the task owning the resource asks for help. :dfn:`help passive` - This scheduler node is owned by a task obtaining a resource currently owned by - another task and can be used to help out tasks. - The task owning this node is blocked. + This scheduler node is owned by a task obtaining a resource currently owned + by another task and can be used to help out tasks. The task owning this + node is blocked. The following scheduler operations return a task in need for help @@ -324,15 +335,15 @@ the system depends on the maximum resource tree size of the application. Critical Section Techniques and SMP ----------------------------------- -As discussed earlier, SMP systems have opportunities for true parallelism -which was not possible on uniprocessor systems. Consequently, multiple -techniques that provided adequate critical sections on uniprocessor -systems are unsafe on SMP systems. In this section, some of these -unsafe techniques will be discussed. +As discussed earlier, SMP systems have opportunities for true parallelism which +was not possible on uniprocessor systems. Consequently, multiple techniques +that provided adequate critical sections on uniprocessor systems are unsafe on +SMP systems. In this section, some of these unsafe techniques will be +discussed. In general, applications must use proper operating system provided mutual -exclusion mechanisms to ensure correct behavior. This primarily means -the use of binary semaphores or mutexes to implement critical sections. +exclusion mechanisms to ensure correct behavior. This primarily means the use +of binary semaphores or mutexes to implement critical sections. Disable Interrupts and Interrupt Locks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -369,80 +380,85 @@ to simple interrupt disable/enable sequences. It is disallowed to acquire a single interrupt lock in a nested way. This will result in an infinite loop with interrupts disabled. While converting legacy code to interrupt locks care must be taken to avoid this situation. -.. code:: c + +.. code-block:: c + :linenos: void legacy_code_with_interrupt_disable_enable( void ) { - rtems_interrupt_level level; - rtems_interrupt_disable( level ); - /* Some critical stuff \*/ - rtems_interrupt_enable( level ); + rtems_interrupt_level level; + rtems_interrupt_disable( level ); + /* Some critical stuff */ + rtems_interrupt_enable( level ); } - RTEMS_INTERRUPT_LOCK_DEFINE( static, lock, "Name" ) + + RTEMS_INTERRUPT_LOCK_DEFINE( static, lock, "Name" ); + void smp_ready_code_with_interrupt_lock( void ) { - rtems_interrupt_lock_context lock_context; - rtems_interrupt_lock_acquire( &lock, &lock_context ); - /* Some critical stuff \*/ - rtems_interrupt_lock_release( &lock, &lock_context ); + rtems_interrupt_lock_context lock_context; + rtems_interrupt_lock_acquire( &lock, &lock_context ); + /* Some critical stuff */ + rtems_interrupt_lock_release( &lock, &lock_context ); } The ``rtems_interrupt_lock`` structure is empty on uni-processor configurations. Empty structures have a different size in C (implementation-defined, zero in case of GCC) and C++ (implementation-defined -non-zero value, one in case of GCC). Thus the``RTEMS_INTERRUPT_LOCK_DECLARE()``, ``RTEMS_INTERRUPT_LOCK_DEFINE()``,``RTEMS_INTERRUPT_LOCK_MEMBER()``, and``RTEMS_INTERRUPT_LOCK_REFERENCE()`` macros are provided to ensure ABI -compatibility. +non-zero value, one in case of GCC). Thus the +``RTEMS_INTERRUPT_LOCK_DECLARE()``, ``RTEMS_INTERRUPT_LOCK_DEFINE()``, +``RTEMS_INTERRUPT_LOCK_MEMBER()``, and ``RTEMS_INTERRUPT_LOCK_REFERENCE()`` +macros are provided to ensure ABI compatibility. Highest Priority Task Assumption ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -On a uniprocessor system, it is safe to assume that when the highest -priority task in an application executes, it will execute without being -preempted until it voluntarily blocks. Interrupts may occur while it is -executing, but there will be no context switch to another task unless -the highest priority task voluntarily initiates it. +On a uniprocessor system, it is safe to assume that when the highest priority +task in an application executes, it will execute without being preempted until +it voluntarily blocks. Interrupts may occur while it is executing, but there +will be no context switch to another task unless the highest priority task +voluntarily initiates it. -Given the assumption that no other tasks will have their execution -interleaved with the highest priority task, it is possible for this -task to be constructed such that it does not need to acquire a binary -semaphore or mutex for protected access to shared data. +Given the assumption that no other tasks will have their execution interleaved +with the highest priority task, it is possible for this task to be constructed +such that it does not need to acquire a binary semaphore or mutex for protected +access to shared data. In an SMP system, it cannot be assumed there will never be a single task executing. It should be assumed that every processor is executing another -application task. Further, those tasks will be ones which would not have -been executed in a uniprocessor configuration and should be assumed to -have data synchronization conflicts with what was formerly the highest -priority task which executed without conflict. +application task. Further, those tasks will be ones which would not have been +executed in a uniprocessor configuration and should be assumed to have data +synchronization conflicts with what was formerly the highest priority task +which executed without conflict. Disable Preemption ~~~~~~~~~~~~~~~~~~ -On a uniprocessor system, disabling preemption in a task is very similar -to making the highest priority task assumption. While preemption is -disabled, no task context switches will occur unless the task initiates -them voluntarily. And, just as with the highest priority task assumption, -there are N-1 processors also running tasks. Thus the assumption that no -other tasks will run while the task has preemption disabled is violated. +On a uniprocessor system, disabling preemption in a task is very similar to +making the highest priority task assumption. While preemption is disabled, no +task context switches will occur unless the task initiates them +voluntarily. And, just as with the highest priority task assumption, there are +N-1 processors also running tasks. Thus the assumption that no other tasks will +run while the task has preemption disabled is violated. Task Unique Data and SMP ------------------------ Per task variables are a service commonly provided by real-time operating -systems for application use. They work by allowing the application -to specify a location in memory (typically a ``void *``) which is -logically added to the context of a task. On each task switch, the -location in memory is stored and each task can have a unique value in -the same memory location. This memory location is directly accessed as a -variable in a program. +systems for application use. They work by allowing the application to specify a +location in memory (typically a ``void *``) which is logically added to the +context of a task. On each task switch, the location in memory is stored and +each task can have a unique value in the same memory location. This memory +location is directly accessed as a variable in a program. This works well in a uniprocessor environment because there is one task -executing and one memory location containing a task-specific value. But -it is fundamentally broken on an SMP system because there are always N -tasks executing. With only one location in memory, N-1 tasks will not -have the correct value. +executing and one memory location containing a task-specific value. But it is +fundamentally broken on an SMP system because there are always N tasks +executing. With only one location in memory, N-1 tasks will not have the +correct value. -This paradigm for providing task unique data values is fundamentally -broken on SMP systems. +This paradigm for providing task unique data values is fundamentally broken on +SMP systems. Classic API Per Task Variables ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -479,50 +495,54 @@ configuration of libgomp. In addition application configurable thread pools for each scheduler instance are available in GCC 6.1 or later. The run-time configuration of libgomp is done via environment variables -documented in the `libgomp -manual <https://gcc.gnu.org/onlinedocs/libgomp/>`_. The environment variables are evaluated in a constructor function -which executes in the context of the first initialization task before the -actual initialization task function is called (just like a global C++ -constructor). To set application specific values, a higher priority -constructor function must be used to set up the environment variables. +documented in the `libgomp manual <https://gcc.gnu.org/onlinedocs/libgomp/>`_. +The environment variables are evaluated in a constructor function which +executes in the context of the first initialization task before the actual +initialization task function is called (just like a global C++ constructor). +To set application specific values, a higher priority constructor function must +be used to set up the environment variables. + .. code:: c #include <stdlib.h> void __attribute__((constructor(1000))) config_libgomp( void ) { - setenv( "OMP_DISPLAY_ENV", "VERBOSE", 1 ); - setenv( "GOMP_SPINCOUNT", "30000", 1 ); - setenv( "GOMP_RTEMS_THREAD_POOLS", "1$2@SCHD", 1 ); + setenv( "OMP_DISPLAY_ENV", "VERBOSE", 1 ); + setenv( "GOMP_SPINCOUNT", "30000", 1 ); + setenv( "GOMP_RTEMS_THREAD_POOLS", "1$2@SCHD", 1 ); } The environment variable ``GOMP_RTEMS_THREAD_POOLS`` is RTEMS-specific. It -determines the thread pools for each scheduler instance. The format for``GOMP_RTEMS_THREAD_POOLS`` is a list of optional``<thread-pool-count>[$<priority>]@<scheduler-name>`` configurations -separated by ``:`` where: +determines the thread pools for each scheduler instance. The format for +``GOMP_RTEMS_THREAD_POOLS`` is a list of optional +``<thread-pool-count>[$<priority>]@<scheduler-name>`` configurations separated +by ``:`` where: -- ``<thread-pool-count>`` is the thread pool count for this scheduler - instance. +- ``<thread-pool-count>`` is the thread pool count for this scheduler instance. -- ``$<priority>`` is an optional priority for the worker threads of a - thread pool according to ``pthread_setschedparam``. In case a priority - value is omitted, then a worker thread will inherit the priority of the OpenMP - master thread that created it. The priority of the worker thread is not - changed by libgomp after creation, even if a new OpenMP master thread using the - worker has a different priority. +- ``$<priority>`` is an optional priority for the worker threads of a thread + pool according to ``pthread_setschedparam``. In case a priority value is + omitted, then a worker thread will inherit the priority of the OpenMP master + thread that created it. The priority of the worker thread is not changed by + libgomp after creation, even if a new OpenMP master thread using the worker + has a different priority. -- ``@<scheduler-name>`` is the scheduler instance name according to the - RTEMS application configuration. +- ``@<scheduler-name>`` is the scheduler instance name according to the RTEMS + application configuration. In case no thread pool configuration is specified for a scheduler instance, then each OpenMP master thread of this scheduler instance will use its own dynamically allocated thread pool. To limit the worker thread count of the thread pools, each OpenMP master thread must call ``omp_set_num_threads``. -Lets suppose we have three scheduler instances ``IO``, ``WRK0``, and``WRK1`` with ``GOMP_RTEMS_THREAD_POOLS`` set to``"1@WRK0:3$4@WRK1"``. Then there are no thread pool restrictions for -scheduler instance ``IO``. In the scheduler instance ``WRK0`` there is -one thread pool available. Since no priority is specified for this scheduler -instance, the worker thread inherits the priority of the OpenMP master thread -that created it. In the scheduler instance ``WRK1`` there are three thread -pools available and their worker threads run at priority four. +Lets suppose we have three scheduler instances ``IO``, ``WRK0``, and ``WRK1`` +with ``GOMP_RTEMS_THREAD_POOLS`` set to ``"1@WRK0:3$4@WRK1"``. Then there are +no thread pool restrictions for scheduler instance ``IO``. In the scheduler +instance ``WRK0`` there is one thread pool available. Since no priority is +specified for this scheduler instance, the worker thread inherits the priority +of the OpenMP master thread that created it. In the scheduler instance +``WRK1`` there are three thread pools available and their worker threads run at +priority four. Thread Dispatch Details ----------------------- @@ -548,10 +568,10 @@ variables, Updates of the heir thread and the thread dispatch necessary indicator are synchronized via explicit memory barriers without the use of locks. A thread -can be an heir thread on at most one processor in the system. The thread context -is protected by a TTAS lock embedded in the context to ensure that it is used -on at most one processor at a time. The thread post-switch actions use a -per-processor lock. This implementation turned out to be quite efficient and +can be an heir thread on at most one processor in the system. The thread +context is protected by a TTAS lock embedded in the context to ensure that it +is used on at most one processor at a time. The thread post-switch actions use +a per-processor lock. This implementation turned out to be quite efficient and no lock contention was observed in the test suite. The current implementation of thread dispatching has some implications with @@ -607,31 +627,34 @@ lock individual tasks to specific processors. In this way, one can designate a processor for I/O tasks, another for computation, etc.. The following illustrates the code sequence necessary to assign a task an affinity for processor with index ``processor_index``. + .. code:: c #include <rtems.h> #include <assert.h> + void pin_to_processor(rtems_id task_id, int processor_index) { - rtems_status_code sc; - cpu_set_t cpuset; - CPU_ZERO(&cpuset); - CPU_SET(processor_index, &cpuset); - sc = rtems_task_set_affinity(task_id, sizeof(cpuset), &cpuset); - assert(sc == RTEMS_SUCCESSFUL); + rtems_status_code sc; + cpu_set_t cpuset; + CPU_ZERO(&cpuset); + CPU_SET(processor_index, &cpuset); + sc = rtems_task_set_affinity(task_id, sizeof(cpuset), &cpuset); + assert(sc == RTEMS_SUCCESSFUL); } -It is important to note that the ``cpuset`` is not validated until the``rtems_task_set_affinity`` call is made. At that point, -it is validated against the current system configuration. +It is important to note that the ``cpuset`` is not validated until the +``rtems_task_set_affinity`` call is made. At that point, it is validated +against the current system configuration. Directives ========== -This section details the symmetric multiprocessing services. A subsection -is dedicated to each of these services and describes the calling sequence, -related constants, usage, and status codes. +This section details the symmetric multiprocessing services. A subsection is +dedicated to each of these services and describes the calling sequence, related +constants, usage, and status codes. -.. COMMENT: rtems_get_processor_count +.. _rtems_get_processor_count: GET_PROCESSOR_COUNT - Get processor count ----------------------------------------- @@ -660,7 +683,7 @@ maximum count of application configured processors. None. -.. COMMENT: rtems_get_current_processor +.. _rtems_get_current_processor: GET_CURRENT_PROCESSOR - Get current processor index --------------------------------------------------- @@ -692,8 +715,7 @@ thread dispatching disabled. None. -.. COMMENT: rtems_scheduler_ident - +.. _rtems_scheduler_ident: SCHEDULER_IDENT - Get ID of a scheduler --------------------------------------- @@ -703,17 +725,24 @@ SCHEDULER_IDENT - Get ID of a scheduler .. code:: c rtems_status_code rtems_scheduler_ident( - rtems_name name, - rtems_id \*id + rtems_name name, + rtems_id *id ); **DIRECTIVE STATUS CODES:** -``RTEMS_SUCCESSFUL`` - successful operation -``RTEMS_INVALID_ADDRESS`` - ``id`` is NULL -``RTEMS_INVALID_NAME`` - invalid scheduler name -``RTEMS_UNSATISFIED`` - - a scheduler with this name exists, but -the processor set of this scheduler is empty +.. list-table:: + :class: rtems-table + + * - ``RTEMS_SUCCESSFUL`` + - successful operation + * - ``RTEMS_INVALID_ADDRESS`` + - ``id`` is NULL + * - ``RTEMS_INVALID_NAME`` + - invalid scheduler name + * - ``RTEMS_UNSATISFIED`` + - a scheduler with this name exists, but the processor set of this scheduler + is empty **DESCRIPTION:** @@ -724,7 +753,7 @@ scheduler configuration. See `Configuring a System`_. None. -.. COMMENT: rtems_scheduler_get_processor_set +.. _rtems_scheduler_get_processor_set: SCHEDULER_GET_PROCESSOR_SET - Get processor set of a scheduler -------------------------------------------------------------- @@ -734,30 +763,37 @@ SCHEDULER_GET_PROCESSOR_SET - Get processor set of a scheduler .. code:: c rtems_status_code rtems_scheduler_get_processor_set( - rtems_id scheduler_id, - size_t cpusetsize, - cpu_set_t \*cpuset + rtems_id scheduler_id, + size_t cpusetsize, + cpu_set_t *cpuset ); **DIRECTIVE STATUS CODES:** -``RTEMS_SUCCESSFUL`` - successful operation -``RTEMS_INVALID_ADDRESS`` - ``cpuset`` is NULL -``RTEMS_INVALID_ID`` - invalid scheduler id -``RTEMS_INVALID_NUMBER`` - the affinity set buffer is too small for -set of processors owned by the scheduler +.. list-table:: + :class: rtems-table + + * - ``RTEMS_SUCCESSFUL`` + - successful operation + * - ``RTEMS_INVALID_ADDRESS`` + - ``cpuset`` is NULL + * - ``RTEMS_INVALID_ID`` + - invalid scheduler id + * - ``RTEMS_INVALID_NUMBER`` + - the affinity set buffer is too small for set of processors owned by the + scheduler **DESCRIPTION:** -Returns the processor set owned by the scheduler in ``cpuset``. A set bit -in the processor set means that this processor is owned by the scheduler and a +Returns the processor set owned by the scheduler in ``cpuset``. A set bit in +the processor set means that this processor is owned by the scheduler and a cleared bit means the opposite. **NOTES:** None. -.. COMMENT: rtems_task_get_scheduler +.. _rtems_task_get_scheduler: TASK_GET_SCHEDULER - Get scheduler of a task -------------------------------------------- @@ -767,26 +803,32 @@ TASK_GET_SCHEDULER - Get scheduler of a task .. code:: c rtems_status_code rtems_task_get_scheduler( - rtems_id task_id, - rtems_id \*scheduler_id + rtems_id task_id, + rtems_id *scheduler_id ); **DIRECTIVE STATUS CODES:** -``RTEMS_SUCCESSFUL`` - successful operation -``RTEMS_INVALID_ADDRESS`` - ``scheduler_id`` is NULL -``RTEMS_INVALID_ID`` - invalid task id +.. list-table:: + :class: rtems-table + + * - ``RTEMS_SUCCESSFUL`` + - successful operation + * - ``RTEMS_INVALID_ADDRESS`` + - ``scheduler_id`` is NULL + * - ``RTEMS_INVALID_ID`` + - invalid task id **DESCRIPTION:** -Returns the scheduler identifier of a task identified by ``task_id`` in``scheduler_id``. +Returns the scheduler identifier of a task identified by ``task_id`` in +``scheduler_id``. **NOTES:** None. -.. COMMENT: rtems_task_set_scheduler - +.. _rtems_task_set_scheduler: TASK_SET_SCHEDULER - Set scheduler of a task -------------------------------------------- @@ -796,22 +838,27 @@ TASK_SET_SCHEDULER - Set scheduler of a task .. code:: c rtems_status_code rtems_task_set_scheduler( - rtems_id task_id, - rtems_id scheduler_id + rtems_id task_id, + rtems_id scheduler_id ); **DIRECTIVE STATUS CODES:** -``RTEMS_SUCCESSFUL`` - successful operation -``RTEMS_INVALID_ID`` - invalid task or scheduler id -``RTEMS_INCORRECT_STATE`` - the task is in the wrong state to -perform a scheduler change +.. list-table:: + :class: rtems-table + + * - ``RTEMS_SUCCESSFUL`` + - successful operation + * - ``RTEMS_INVALID_ID`` + - invalid task or scheduler id + * - ``RTEMS_INCORRECT_STATE`` + - the task is in the wrong state to perform a scheduler change **DESCRIPTION:** Sets the scheduler of a task identified by ``task_id`` to the scheduler -identified by ``scheduler_id``. The scheduler of a task is initialized to -the scheduler of the task that created it. +identified by ``scheduler_id``. The scheduler of a task is initialized to the +scheduler of the task that created it. **NOTES:** @@ -819,36 +866,44 @@ None. **EXAMPLE:** -.. code:: c +.. code-block:: c + :linenos: #include <rtems.h> #include <assert.h> + void task(rtems_task_argument arg); + void example(void) { - rtems_status_code sc; - rtems_id task_id; - rtems_id scheduler_id; - rtems_name scheduler_name; - scheduler_name = rtems_build_name('W', 'O', 'R', 'K'); - sc = rtems_scheduler_ident(scheduler_name, &scheduler_id); - assert(sc == RTEMS_SUCCESSFUL); - sc = rtems_task_create( - rtems_build_name('T', 'A', 'S', 'K'), - 1, - RTEMS_MINIMUM_STACK_SIZE, - RTEMS_DEFAULT_MODES, - RTEMS_DEFAULT_ATTRIBUTES, - &task_id - ); - assert(sc == RTEMS_SUCCESSFUL); - sc = rtems_task_set_scheduler(task_id, scheduler_id); - assert(sc == RTEMS_SUCCESSFUL); - sc = rtems_task_start(task_id, task, 0); - assert(sc == RTEMS_SUCCESSFUL); + rtems_status_code sc; + rtems_id task_id; + rtems_id scheduler_id; + rtems_name scheduler_name; + + scheduler_name = rtems_build_name('W', 'O', 'R', 'K'); + + sc = rtems_scheduler_ident(scheduler_name, &scheduler_id); + assert(sc == RTEMS_SUCCESSFUL); + + sc = rtems_task_create( + rtems_build_name('T', 'A', 'S', 'K'), + 1, + RTEMS_MINIMUM_STACK_SIZE, + RTEMS_DEFAULT_MODES, + RTEMS_DEFAULT_ATTRIBUTES, + &task_id + ); + assert(sc == RTEMS_SUCCESSFUL); + + sc = rtems_task_set_scheduler(task_id, scheduler_id); + assert(sc == RTEMS_SUCCESSFUL); + + sc = rtems_task_start(task_id, task, 0); + assert(sc == RTEMS_SUCCESSFUL); } -.. COMMENT: rtems_task_get_affinity +.. _rtems_task_get_affinity: TASK_GET_AFFINITY - Get task processor affinity ----------------------------------------------- @@ -858,18 +913,25 @@ TASK_GET_AFFINITY - Get task processor affinity .. code:: c rtems_status_code rtems_task_get_affinity( - rtems_id id, - size_t cpusetsize, - cpu_set_t \*cpuset + rtems_id id, + size_t cpusetsize, + cpu_set_t *cpuset ); **DIRECTIVE STATUS CODES:** -``RTEMS_SUCCESSFUL`` - successful operation -``RTEMS_INVALID_ADDRESS`` - ``cpuset`` is NULL -``RTEMS_INVALID_ID`` - invalid task id -``RTEMS_INVALID_NUMBER`` - the affinity set buffer is too small for -the current processor affinity set of the task +.. list-table:: + :class: rtems-table + + * - ``RTEMS_SUCCESSFUL`` + - successful operation + * - ``RTEMS_INVALID_ADDRESS`` + - ``cpuset`` is NULL + * - ``RTEMS_INVALID_ID`` + - invalid task id + * - ``RTEMS_INVALID_NUMBER`` + - the affinity set buffer is too small for the current processor affinity + set of the task **DESCRIPTION:** @@ -881,7 +943,7 @@ cleared bit means the opposite. None. -.. COMMENT: rtems_task_set_affinity +.. _rtems_task_set_affinity: TASK_SET_AFFINITY - Set task processor affinity ----------------------------------------------- @@ -891,17 +953,24 @@ TASK_SET_AFFINITY - Set task processor affinity .. code:: c rtems_status_code rtems_task_set_affinity( - rtems_id id, - size_t cpusetsize, - const cpu_set_t \*cpuset + rtems_id id, + size_t cpusetsize, + const cpu_set_t *cpuset ); **DIRECTIVE STATUS CODES:** -``RTEMS_SUCCESSFUL`` - successful operation -``RTEMS_INVALID_ADDRESS`` - ``cpuset`` is NULL -``RTEMS_INVALID_ID`` - invalid task id -``RTEMS_INVALID_NUMBER`` - invalid processor affinity set +.. list-table:: + :class: rtems-table + + * - ``RTEMS_SUCCESSFUL`` + - successful operation + * - ``RTEMS_INVALID_ADDRESS`` + - ``cpuset`` is NULL + * - ``RTEMS_INVALID_ID`` + - invalid task id + * - ``RTEMS_INVALID_NUMBER`` + - invalid processor affinity set **DESCRIPTION:** @@ -921,9 +990,3 @@ locking protocols may temporarily use processors that are not included in the processor affinity set of the task. It is also not an error if the processor affinity set contains processors that are not part of the system. -.. COMMENT: COPYRIGHT (c) 2011,2015 - -.. COMMENT: Aeroflex Gaisler AB - -.. COMMENT: All rights reserved. - |