diff options
Diffstat (limited to '')
121 files changed, 705 insertions, 705 deletions
diff --git a/bsp_howto/analog.rst b/bsp_howto/analog.rst index 84b8221..dbccb59 100644 --- a/bsp_howto/analog.rst +++ b/bsp_howto/analog.rst @@ -71,7 +71,7 @@ to configure an analog board: Initialize an Analog Board ========================== -At system initialization, the analog driver’s initialization entry point +At system initialization, the analog driver's initialization entry point will be invoked. As part of initialization, the driver will perform whatever board initialization is required and then set all outputs to their configured initial state. diff --git a/bsp_howto/ata.rst b/bsp_howto/ata.rst index dbf9f72..6101b4b 100644 --- a/bsp_howto/ata.rst +++ b/bsp_howto/ata.rst @@ -101,7 +101,7 @@ following structure: ATA driver supports separate ATA requests queues for each IDE controller (one queue per controller). The following structure contains -information about controller’s queue and devices attached to the controller: +information about controller's queue and devices attached to the controller: .. code:: c /* @@ -153,7 +153,7 @@ implementation supports only two ioctls: BLKIO_REQUEST and ATAIO_SET_MULTIPLE_MODE. Each ATA driver ioctl() call generates an ATA request which is appended to the appropriate controller queue depending on ATA device the request belongs to. If appended request is single request in -the controller’s queue then ATA driver event is generated. +the controller's queue then ATA driver event is generated. ATA driver task which manages queue of ATA driver events is core of ATA driver. In current driver version queue of ATA driver events implemented diff --git a/bsp_howto/clock.rst b/bsp_howto/clock.rst index d8c454b..870eebf 100644 --- a/bsp_howto/clock.rst +++ b/bsp_howto/clock.rst @@ -8,7 +8,7 @@ The purpose of the clock driver is to provide two services for the operating system. - A steady time basis to the kernel, so that the RTEMS primitives that need - a clock tick work properly. See the *Clock Manager* chapter of the*RTEMS Application C User’s Guide* for more details. + a clock tick work properly. See the *Clock Manager* chapter of the*RTEMS Application C User's Guide* for more details. - An optional time counter to generate timestamps of the uptime and wall clock time. diff --git a/bsp_howto/console.rst b/bsp_howto/console.rst index 13f7a6c..5436bfb 100644 --- a/bsp_howto/console.rst +++ b/bsp_howto/console.rst @@ -36,11 +36,11 @@ and are at http://opengroup.org/onlinepubs/007908775/xsh/termios.h.html. Having RTEMS support for Termios is beneficial because: -- from the user’s side because it provides standard primitive operations +- from the user's side because it provides standard primitive operations to access the terminal and change configuration settings. These operations are the same under UNIX and RTEMS. -- from the BSP developer’s side because it frees the +- from the BSP developer's side because it frees the developer from dealing with buffer states and mutual exclusions on them. Early RTEMS console device drivers also did their own special character processing. diff --git a/bsp_howto/discrete.rst b/bsp_howto/discrete.rst index c5ce450..c358ee1 100644 --- a/bsp_howto/discrete.rst +++ b/bsp_howto/discrete.rst @@ -76,12 +76,12 @@ to configure an discrete I/O board: *relay_initial_values* is an array of the values that should be written to each output word on the board during initialization. This allows the driver - to start with the board’s output in a known state. + to start with the board's output in a known state. Initialize a Discrete I/O Board =============================== -At system initialization, the discrete I/O driver’s initialization entry point +At system initialization, the discrete I/O driver's initialization entry point will be invoked. As part of initialization, the driver will perform whatever board initializatin is required and then set all outputs to their configured initial state. diff --git a/bsp_howto/index.rst b/bsp_howto/index.rst index 0f279aa..d422251 100644 --- a/bsp_howto/index.rst +++ b/bsp_howto/index.rst @@ -2,7 +2,7 @@ BSP and Device Driver Development Guide ======================================= -COPYRIGHT © 1988 - 2015. +COPYRIGHT (c) 1988 - 2015. On-Line Applications Research Corporation (OAR). diff --git a/bsp_howto/initilization_code.rst b/bsp_howto/initilization_code.rst index d6ce46b..4657602 100644 --- a/bsp_howto/initilization_code.rst +++ b/bsp_howto/initilization_code.rst @@ -4,7 +4,7 @@ Initialization Code Introduction ============ -The initialization code is the first piece of code executed when there’s a +The initialization code is the first piece of code executed when there's a reset/reboot. Its purpose is to initialize the board for the application. This chapter contains a narrative description of the initialization process followed by a description of each of the files and routines @@ -178,7 +178,7 @@ The ``boot_card()`` routine performs the following functions: When in the context of the first task but before its body has been entered, any C++ Global Constructors will be invoked. -That’s it. We just went through the entire sequence. +That's it. We just went through the entire sequence. bsp_work_area_initialize() - BSP Specific Work Area Initialization ------------------------------------------------------------------ @@ -227,7 +227,7 @@ in the order they appear in the Device Driver Table. The Driver Address Table is part of the RTEMS Configuration Table. It defines device drivers entry points (initialization, open, close, read, write, and control). For more information about this table, please -refer to the *Configuring a System* chapter in the*RTEMS Application C User’s Guide*. +refer to the *Configuring a System* chapter in the*RTEMS Application C User's Guide*. The RTEMS initialization procedure calls the initialization function for every driver defined in the RTEMS Configuration Table (this allows @@ -289,7 +289,7 @@ of ``__uhoh`` in the ``gen68340`` BSP. At ``__uhoh`` label is the default interrupt handler routine. This routine is only called when an unexpected interrupts is raised. One can -add their own routine there (in that case there’s a call to a routine - +add their own routine there (in that case there's a call to a routine - $BSP_ROOT/startup/dumpanic.c - that prints which address caused the interrupt and the contents of the registers, stack, etc.), but this should not return. @@ -325,7 +325,7 @@ Integrated Processor Registers Initialization The CPUs used in many embedded systems are highly complex devices with multiple peripherals on the CPU itself. For these devices, there are always some specific integrated processor registers -that must be initialized. Refer to the processors’ manuals for +that must be initialized. Refer to the processors' manuals for details on these registers and be VERY careful programming them. Data Section Recopy @@ -348,7 +348,7 @@ The RTEMS Configuration Table The RTEMS configuration table contains the maximum number of objects RTEMS can handle during the application (e.g. maximum number of tasks, -semaphores, etc.). It’s used to allocate the size for the RTEMS inner data +semaphores, etc.). It's used to allocate the size for the RTEMS inner data structures. The RTEMS configuration table is application dependent, which means that @@ -367,7 +367,7 @@ application. In 4.9 and newer, we have eliminated the BSP copies of the configuration tables and are making efforts to make the configuration information generated by ``<rtems/confdefs.h>`` constant and read only. -For more information on the RTEMS Configuration Table, refer to the*RTEMS Application C User’s Guide*. +For more information on the RTEMS Configuration Table, refer to the*RTEMS Application C User's Guide*. .. COMMENT: COPYRIGHT (c) 1988-2008. diff --git a/bsp_howto/linker_script.rst b/bsp_howto/linker_script.rst index 684e2db..a9f1c98 100644 --- a/bsp_howto/linker_script.rst +++ b/bsp_howto/linker_script.rst @@ -34,7 +34,7 @@ Two types of memories have to be distinguished: - ROM - non-volatile but read only Even though RAM and ROM can be found in every personal computer, -one generally doesn’t care about them. In a personal computer, +one generally doesn't care about them. In a personal computer, a program is nearly always stored on disk and executed in RAM. Things are a bit different for embedded targets: the target will execute the program each time it is rebooted or switched on. The application @@ -49,7 +49,7 @@ object file format on the Motorola m68k family of microprocessors, the following sections will be present: - *code (``.text``) section*: - is the program’s code and it should not be modified. + is the program's code and it should not be modified. This section may be placed in ROM. - *non-initialized data (``.bss``) section*: @@ -57,7 +57,7 @@ the following sections will be present: - *initialized data (``.data``) section*: holds the initialized program data which may be modified during the - program’s life. This means they have to be in RAM. + program's life. This means they have to be in RAM. On the other hand, these variables must be set to predefined values, and those predefined values have to be stored in ROM. @@ -300,7 +300,7 @@ $BSP340_ROOT/startup/linkcmds. Initialized Data ================ -Now there’s a problem with the initialized data: the ``.data`` section +Now there's a problem with the initialized data: the ``.data`` section has to be in RAM as this data may be modified during the program execution. But how will the values be initialized at boot time? @@ -354,7 +354,7 @@ section with an ``awk`` script. The details of how this is done are not relevant. Step 3 shows the final executable image as it logically appears in -the target’s non-volatile program memory. The board initialization +the target's non-volatile program memory. The board initialization code will copy the ""copy of ``.data`` section" (which are stored in ROM) to their reserved location in RAM. diff --git a/bsp_howto/makefiles.rst b/bsp_howto/makefiles.rst index 528617e..77e7186 100644 --- a/bsp_howto/makefiles.rst +++ b/bsp_howto/makefiles.rst @@ -147,10 +147,10 @@ with the toolset, this same information must be used when building the application. So a BSP must include a build configuration file. The configuration file is ``make/custom/BSP.cfg``. -The configuration file is taken into account when building one’s +The configuration file is taken into account when building one's application using the RTEMS template Makefiles (``make/templates``). These application template Makefiles have been included with the -RTEMS source distribution since the early 1990’s. However there is +RTEMS source distribution since the early 1990's. However there is a desire in the RTEMS user community to move all provided examples to GNU autoconf. They are included in the 4.9 release series and used for all examples provided with RTEMS. There is no definite time table for diff --git a/bsp_howto/miscellanous_support.rst b/bsp_howto/miscellanous_support.rst index 4c6bb25..735ebd8 100644 --- a/bsp_howto/miscellanous_support.rst +++ b/bsp_howto/miscellanous_support.rst @@ -114,7 +114,7 @@ The ``tm27`` test from the RTEMS Timing Test Suite is designed to measure the le All members of the Timing Test Suite are designed to run *WITHOUT* the Clock Device Driver installed. This increases the predictability -of the tests’ execution as well as avoids occassionally including the +of the tests' execution as well as avoids occassionally including the overhead of a clock tick interrupt in the time reported. Because of this it is sometimes possible to use the clock tick interrupt source as the source of this test interrupt. On other architectures, it is diff --git a/bsp_howto/networking.rst b/bsp_howto/networking.rst index 40ae5b6..123b52c 100644 --- a/bsp_howto/networking.rst +++ b/bsp_howto/networking.rst @@ -6,7 +6,7 @@ Introduction This chapter is intended to provide an introduction to the procedure for writing RTEMS network device drivers. -The example code is taken from the ‘Generic 68360’ network device +The example code is taken from the 'Generic 68360' network device driver. The source code for this driver is located in the``c/src/lib/libbsp/m68k/gen68360/network`` directory in the RTEMS source code distribution. Having a copy of this driver at hand when reading the following notes will help significantly. @@ -15,7 +15,7 @@ Learn about the network device ============================== Before starting to write the network driver become completely -familiar with the programmer’s view of the device. +familiar with the programmer's view of the device. The following points list some of the details of the device that must be understood before a driver can be written. @@ -70,7 +70,7 @@ data structures and resources. To ensure the consistency of these structures the tasks execute only when they hold the network semaphore (``rtems_bsdnet_semaphore``). The transmit and receive tasks must abide by this protocol. Be very -careful to avoid ‘deadly embraces’ with the other network tasks. +careful to avoid 'deadly embraces' with the other network tasks. A number of routines are provided to make it easier for the network driver code to conform to the network task scheduling conventions. @@ -161,9 +161,9 @@ in the device-dependent data structure supplied and maintained by the driver: ``ifp->if_unit`` The device number. The network stack uses this number and the - device name for device name lookups. For example, if``ifp->if_name`` is ‘``scc``’ and ``ifp->if_unit`` is ‘``1``’, - the full device name would be ‘``scc1``’. The unit number should be - obtained from the ‘name’ entry in the configuration structure. + device name for device name lookups. For example, if``ifp->if_name`` is '``scc``' and ``ifp->if_unit`` is '``1``', + the full device name would be '``scc1``'. The unit number should be + obtained from the 'name' entry in the configuration structure. ``ifp->if_mtu`` The maximum transmission unit for the device. For Ethernet @@ -212,7 +212,7 @@ Once the attach function has set up the above entries it must link the driver data structure onto the list of devices by calling ``if_attach``. Ethernet devices should then call ``ether_ifattach``. Both functions take a pointer to the -device’s ``ifnet`` structure as their only argument. +device's ``ifnet`` structure as their only argument. The attach function should return a non-zero value to indicate that the driver has been successfully configured and attached. @@ -222,8 +222,8 @@ Write the Driver Start Function. This function is called each time the network stack wants to start the transmitter. This occures whenever the network stack adds a packet -to a device’s send queue and the ``IFF_OACTIVE`` bit in the -device’s ``if_flags`` is not set. +to a device's send queue and the ``IFF_OACTIVE`` bit in the +device's ``if_flags`` is not set. For many devices this function need only set the ``IFF_OACTIVE`` bit in the``if_flags`` and send an event to the transmit task indicating that a packet is in the driver transmit queue. diff --git a/bsp_howto/non_volatile_memory.rst b/bsp_howto/non_volatile_memory.rst index b85f6ae..1015320 100644 --- a/bsp_howto/non_volatile_memory.rst +++ b/bsp_howto/non_volatile_memory.rst @@ -127,7 +127,7 @@ to easily divide the non-volatile memory for different purposes. Initialize the Non-Volatile Memory Driver ========================================= -At system initialization, the non-volatile memory driver’s +At system initialization, the non-volatile memory driver's initialization entry point will be invoked. As part of initialization, the driver will perform whatever initializatin is required on each non-volatile memory area. @@ -140,7 +140,7 @@ the entire device driver. Disable Read and Write Handlers =============================== -Depending on the target’s non-volatile memory configuration, it may be +Depending on the target's non-volatile memory configuration, it may be possible to write to a status register and make the memory area completely inaccessible. This is target dependent and beyond the standard capabilities of any memory type. The user has the optional capability to provide diff --git a/bsp_howto/real_time_clock.rst b/bsp_howto/real_time_clock.rst index c8e0424..7637b9d 100644 --- a/bsp_howto/real_time_clock.rst +++ b/bsp_howto/real_time_clock.rst @@ -33,7 +33,7 @@ driver. There were no DMV177 specific configuration routines. A BSP could use configuration routines to dynamically determine what type of real-time clock is on a particular board. This would be useful for a BSP supporting multiple board models. The relevant ports of -the DMV177’s ``RTC_Table`` configuration table is below: +the DMV177's ``RTC_Table`` configuration table is below: .. code:: c #include <bsp.h> @@ -104,10 +104,10 @@ The ``deviceProbe`` routine returns TRUE if the device configured by this entry in the ``RTC_Table`` is present. This configuration scheme allows one to support multiple versions of the same board with a single BSP. For example, if the first -generation of a board had Vendor A’s RTC chip and the second -generation had Vendor B’s RTC chip, RTC_Table could contain +generation of a board had Vendor A's RTC chip and the second +generation had Vendor B's RTC chip, RTC_Table could contain information for both. The ``deviceProbe`` configured -for Vendor A’s RTC chip would need to return TRUE if the +for Vendor A's RTC chip would need to return TRUE if the board was a first generation one. The ``deviceProbe`` routines are very board dependent and must be provided by the BSP. diff --git a/bsp_howto/shared_memory_support.rst b/bsp_howto/shared_memory_support.rst index 9165de4..93246c6 100644 --- a/bsp_howto/shared_memory_support.rst +++ b/bsp_howto/shared_memory_support.rst @@ -11,7 +11,7 @@ This driver is only required in shared memory multiprocessing systems that use the RTEMS mulitprocessing support. For more information on RTEMS multiprocessing capabilities and the MPCI, refer to the *Multiprocessing Manager* chapter -of the *RTEMS Application C User’s Guide*. +of the *RTEMS Application C User's Guide*. Shared Memory Configuration Table ================================= @@ -95,7 +95,7 @@ used from this node. Most targets will simply return the address passed to this routine. However, some target boards will have a special window onto the shared memory. For example, some VMEbus boards have special address windows to access addresses that are normally reserved -in the CPU’s address space. +in the CPU's address space. .. code:: c void \*Shm_Convert_address( void \*address ) diff --git a/bsp_howto/target_dependant_files.rst b/bsp_howto/target_dependant_files.rst index 77a78f1..d154841 100644 --- a/bsp_howto/target_dependant_files.rst +++ b/bsp_howto/target_dependant_files.rst @@ -31,10 +31,10 @@ differences between these CPU models which RTEMS must take into account. The source code found in the ``cpukit/score/cpu`` is required to only depend upon the CPU model variations that GCC distinguishes -for the purposes of multilib’ing. Multilib is the term the GNU +for the purposes of multilib'ing. Multilib is the term the GNU community uses to refer to building a single library source multiple times with different compiler options so the binary code generated -is compatible. As an example, from GCC’s perspective, many PowerPC +is compatible. As an example, from GCC's perspective, many PowerPC CPU models are just a PPC603e. Remember that GCC only cares about the CPU code itself and need not be aware of any peripherals. In the embedded community, we are exposed to thousands of CPU models @@ -86,16 +86,16 @@ a particular target board, the following questions should be asked: - Does a BSP for a similar board exists? -- Is the board’s CPU supported? +- Is the board's CPU supported? If there is already a BSP for the board, then things may already be ready to start developing application software. All that remains is to verify that the existing BSP provides device drivers for all the peripherals on the board that the application will be using. For example, the application -in question may require that the board’s Ethernet controller be used and +in question may require that the board's Ethernet controller be used and the existing BSP may not support this. -If the BSP does not exist and the board’s CPU model is supported, then +If the BSP does not exist and the board's CPU model is supported, then examine the reusable chip library and existing BSPs for a close match. Other BSPs and libchip provide starting points for the development of a new BSP. It is often possible to copy existing components in @@ -103,7 +103,7 @@ the reusable chip library or device drivers from BSPs from different CPU families as the starting point for a new device driver. This will help reduce the development effort required. -If the board’s CPU family is supported but the particular CPU model on +If the board's CPU family is supported but the particular CPU model on that board is not, then the RTEMS port to that CPU family will have to be augmented. After this is done, development of the new BSP can proceed. @@ -179,7 +179,7 @@ describes the commonly found subdirectories under each BSP. UARTs (i.e. serial devices). - *clock*: - support for the clock tick – a regular time basis to the kernel. + support for the clock tick - a regular time basis to the kernel. - *timer*: support of timer devices. diff --git a/bsp_howto/timer.rst b/bsp_howto/timer.rst index 46bdf0c..88a4589 100644 --- a/bsp_howto/timer.rst +++ b/bsp_howto/timer.rst @@ -83,11 +83,11 @@ gen68340 UART FIFO Full Mode The gen68340 BSP is an example of the use of the timer to support the UART input FIFO full mode (FIFO means First In First Out and roughly means buffer). This mode consists in the UART raising an interrupt when n -characters have been received (*n* is the UART’s FIFO length). It results +characters have been received (*n* is the UART's FIFO length). It results in a lower interrupt processing time, but the problem is that a scanf primitive will block on a receipt of less than *n* characters. The solution is to set a timer that will check whether there are some characters -waiting in the UART’s input FIFO. The delay time has to be set carefully +waiting in the UART's input FIFO. The delay time has to be set carefully otherwise high rates will be broken: - if no character was received last time the interrupt subroutine was diff --git a/c_user/barrier_manager.rst b/c_user/barrier_manager.rst index f2dfcf8..188b563 100644 --- a/c_user/barrier_manager.rst +++ b/c_user/barrier_manager.rst @@ -126,7 +126,7 @@ unblock all tasks waiting at the barrier and the caller will return immediately. When the task does wait to acquire the barrier, then it -is placed in the barrier’s task wait queue in FIFO order. +is placed in the barrier's task wait queue in FIFO order. All tasks waiting on a barrier are returned an error code when the barrier is deleted. @@ -143,17 +143,17 @@ Deleting a Barrier The ``rtems_barrier_delete`` directive removes a barrier from the system and frees its control block. A barrier can be -deleted by any local task that knows the barrier’s ID. As a +deleted by any local task that knows the barrier's ID. As a result of this directive, all tasks blocked waiting for the barrier to be released, will be readied and returned a status code which indicates that the barrier was deleted. Any subsequent -references to the barrier’s name and ID are invalid. +references to the barrier's name and ID are invalid. Directives ========== -This section details the barrier manager’s -directives. A subsection is dedicated to each of this manager’s +This section details the barrier 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. @@ -179,7 +179,7 @@ BARRIER_CREATE - Create a barrier ``RTEMS_SUCCESSFUL`` - barrier created successfully ``RTEMS_INVALID_NAME`` - invalid barrier name ``RTEMS_INVALID_ADDRESS`` - ``id`` is NULL -``RTEMS_TOO_MANY`` - too many barriers created +``RTEMS_TOO_MANY`` - too many barriers created **DESCRIPTION:** @@ -268,7 +268,7 @@ BARRIER_DELETE - Delete a barrier **DIRECTIVE STATUS CODES:** ``RTEMS_SUCCESSFUL`` - barrier deleted successfully -``RTEMS_INVALID_ID`` - invalid barrier id +``RTEMS_INVALID_ID`` -c invalid barrier id **DESCRIPTION:** @@ -281,7 +281,7 @@ by RTEMS. **NOTES:** The calling task will be preempted if it is enabled -by the task’s execution mode and a higher priority local task is +by the task's execution mode and a higher priority local task is waiting on the deleted barrier. The calling task will NOT be preempted if all of the tasks that are waiting on the barrier are remote tasks. @@ -378,7 +378,7 @@ BARRIER_RELEASE - Release a barrier This directive releases the barrier specified by id. All tasks waiting at the barrier will be unblocked. -If the running task’s preemption mode is enabled and one of +If the running task's preemption mode is enabled and one of the unblocked tasks has a higher priority than the running task. **NOTES:** diff --git a/c_user/board_support_packages.rst b/c_user/board_support_packages.rst index 9e8449e..9b5b932 100644 --- a/c_user/board_support_packages.rst +++ b/c_user/board_support_packages.rst @@ -40,15 +40,15 @@ application. Some of the hardware components may be initialized in this code as well as any application initialization that does not involve calls to RTEMS directives. -The processor’s Interrupt Vector Table which will be used by the +The processor's Interrupt Vector Table which will be used by the application may need to be set to the required value by the reset application initialization code. Because interrupts are enabled automatically by RTEMS as part of the context switch to the first task, the Interrupt Vector Table MUST be set before this directive is invoked -to ensure correct interrupt vectoring. The processor’s Interrupt Vector +to ensure correct interrupt vectoring. The processor's Interrupt Vector Table must be accessible by RTEMS as it will be modified by the when installing user Interrupt Service Routines (ISRs) On some CPUs, RTEMS -installs it’s own Interrupt Vector Table as part of initialization and +installs it's own Interrupt Vector Table as part of initialization and thus these requirements are met automatically. The reset code which is executed before the call to any RTEMS initialization routines has the following requirements: @@ -66,7 +66,7 @@ following requirements: - Must initialize the stack pointer for the initialization process to that allocated. -- Must initialize the processor’s Interrupt Vector Table. +- Must initialize the processor's Interrupt Vector Table. - Must disable all maskable interrupts. @@ -91,9 +91,9 @@ application. If the processor supports interrupt nesting, the stack usage must include the deepest nest level. The worst-case stack usage must account for the following requirements: -- Processor’s interrupt stack frame +- Processor's interrupt stack frame -- Processor’s subroutine call stack frame +- Processor's subroutine call stack frame - RTEMS system calls @@ -115,7 +115,7 @@ interrupt service routines. The dedicated interrupt stack for the entire application on some architectures is supplied and initialized by the reset and initialization -code of the user’s Board Support Package. Whether allocated and +code of the user's Board Support Package. Whether allocated and initialized by the BSP or RTEMS, since all ISRs use this stack, the stack size must take into account the worst case stack usage by any combination of nested ISRs. @@ -124,8 +124,8 @@ Processors Without a Separate Interrupt Stack --------------------------------------------- Some processors do not support a separate stack for interrupts. In this -case, without special assistance every task’s stack must include -enough space to handle the task’s worst-case stack usage as well as +case, without special assistance every task's stack must include +enough space to handle the task's worst-case stack usage as well as the worst-case interrupt stack usage. This is necessary because the worst-case interrupt nesting could occur while any task is executing. diff --git a/c_user/chains.rst b/c_user/chains.rst index 770fd5f..490d2b2 100644 --- a/c_user/chains.rst +++ b/c_user/chains.rst @@ -23,11 +23,11 @@ provided by RTEMS is: - ``rtems_chain_is_null_node`` - Is the node NULL ? -- ``rtems_chain_head`` - Return the chain’s head +- ``rtems_chain_head`` - Return the chain's head -- ``rtems_chain_tail`` - Return the chain’s tail +- ``rtems_chain_tail`` - Return the chain's tail -- ``rtems_chain_are_nodes_equal`` - Are the node’s equal ? +- ``rtems_chain_are_nodes_equal`` - Are the node's equal ? - ``rtems_chain_is_empty`` - Is the chain empty ? @@ -106,8 +106,8 @@ foo structure from the list you perform the following: return (foo*) rtems_chain_get(control); } -The node is placed at the start of the user’s structure to allow the -node address on the chain to be easly cast to the user’s structure +The node is placed at the start of the user's structure to allow the +node address on the chain to be easly cast to the user's structure address. Controls diff --git a/c_user/clock_manager.rst b/c_user/clock_manager.rst index 900ddd0..5ea889f 100644 --- a/c_user/clock_manager.rst +++ b/c_user/clock_manager.rst @@ -103,15 +103,15 @@ also sometimes referred to as the automatic round-robin scheduling algorithm. The length of time allocated to each task is known as the quantum or timeslice. -The system’s timeslice is defined as an integral +The system's timeslice is defined as an integral number of ticks, and is specified in the Configuration Table. The timeslice is defined for the entire system of tasks, but timeslicing is enabled and disabled on a per task basis. The ``rtems_clock_tick`` directive implements timeslicing by -decrementing the running task’s time-remaining counter when both -timeslicing and preemption are enabled. If the task’s timeslice +decrementing the running task's time-remaining counter when both +timeslicing and preemption are enabled. If the task's timeslice has expired, then that task will be preempted if there exists a ready task of equal priority. @@ -143,7 +143,7 @@ Announcing a Tick ----------------- RTEMS provides the ``rtems_clock_tick`` directive which is -called from the user’s real-time clock ISR to inform RTEMS that +called from the user's real-time clock ISR to inform RTEMS that a tick has elapsed. The tick frequency value, defined in microseconds, is a configuration parameter found in the Configuration Table. RTEMS divides one million microseconds @@ -203,8 +203,8 @@ invoked before the date and time have been set. Directives ========== -This section details the clock manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the clock 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. diff --git a/c_user/configuring_a_system.rst b/c_user/configuring_a_system.rst index b4d4066..f33df6b 100644 --- a/c_user/configuring_a_system.rst +++ b/c_user/configuring_a_system.rst @@ -103,7 +103,7 @@ 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 +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: @@ -158,7 +158,7 @@ Format to be followed for making changes in this file ===================================================== - MACRO NAME - Should be alphanumeric. Can have ’_’ (underscore). + Should be alphanumeric. Can have '_' (underscore). - DATA TYPE Please refer to all existing formats. @@ -167,29 +167,29 @@ Format to be followed for making changes in this file The range depends on the Data Type of the macro. - - − If the data type is of type task priority, then its value should + - - 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 + - - 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 + - - 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 + - - 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’, ’ ’ ) + - - 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. + Please note that the '.' (full stop) is necessary. - - − In case the value is not defined then: + - - In case the value is not defined then: This is not defined by default. - - − If we know the default value then: + - - If we know the default value then: The default value is XXX. - - − If the default value is BSP Specific then: + - - If the default value is BSP Specific then: This option is BSP specific. - DESCRIPTION @@ -2067,7 +2067,7 @@ the amount of memory reserved for Classic API Message Buffers. Calculate Memory for a Single Classic Message API Message Queue --------------------------------------------------------------- .. index:: CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE -.. index:: memory for a single message queue’s buffers +.. index:: memory for a single message queue's buffers *CONSTANT:* ``CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE(max_messages, size_per)`` @@ -4344,7 +4344,7 @@ 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. +if the application wishes to include the BSP's Frame Buffer Device Driver. **NOTES:** diff --git a/c_user/constant_bandwidth_server.rst b/c_user/constant_bandwidth_server.rst index 6616623..69e2db9 100644 --- a/c_user/constant_bandwidth_server.rst +++ b/c_user/constant_bandwidth_server.rst @@ -72,7 +72,7 @@ Handling Periodic Tasks ----------------------- .. index:: CBS periodic tasks -Each task’s execution begins with a default background priority +Each task's execution begins with a default background priority (see the chapter Scheduling Concepts to understand the concept of priorities in EDF). Once you decide the tasks should start periodic execution, you have two possibilities. Either you use only the Rate @@ -146,10 +146,10 @@ Attaching Task to a Server -------------------------- If a task is attached to a server using ``rtems_cbs_attach_thread``, -the task’s computation time per period is limited by the server and +the task's computation time per period is limited by the server and the deadline (period) of task is equal to deadline of the server which means if you conclude a period using ``rate_monotonic_period``, -the length of next period is always determined by the server’s property. +the length of next period is always determined by the server's property. The task has a guaranteed bandwidth given by the server but should not exceed it, otherwise the priority is pulled to background until the @@ -220,8 +220,8 @@ to avoid overrun. Directives ========== -This section details the Constant Bandwidth Server’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the Constant Bandwidth Server's directives. +A subsection is dedicated to each of this manager's directives and describes the calling sequence, related constants, usage, and status codes. @@ -308,7 +308,7 @@ This routine prepares an instance of a constant bandwidth server. The input parameter ``rtems_cbs_parameters`` specifies scheduling parameters of the server (period and budget). If these are not valid,``RTEMS_CBS_ERROR_INVALID_PARAMETER`` is returned. The ``budget_overrun_callback`` is an optional callback function, which is -invoked in case the server’s budget within one period is exceeded. +invoked in case the server's budget within one period is exceeded. Output parameter ``server_id`` becomes an id of the newly created server. If there is not enough memory, the ``RTEMS_CBS_ERROR_NO_MEMORY`` is returned. If the maximum server count in the system is exceeded,``RTEMS_CBS_ERROR_FULL`` is returned. @@ -583,7 +583,7 @@ CBS_GET_APPROVED_BUDGET - Get scheduler approved execution time **DESCRIPTION:** -This directive returns server’s approved budget for subsequent periods. +This directive returns server's approved budget for subsequent periods. .. COMMENT: COPYRIGHT (c) 1989-2011. diff --git a/c_user/cpu_usage_statistics.rst b/c_user/cpu_usage_statistics.rst index bc057c3..743a859 100644 --- a/c_user/cpu_usage_statistics.rst +++ b/c_user/cpu_usage_statistics.rst @@ -83,7 +83,7 @@ successive clock ticks, there would be no way to tell that it executed at all. Another thing to keep in mind when looking at idle time, is that -many systems – especially during debug – have a task providing +many systems - especially during debug - have a task providing some type of debug interface. It is usually fine to think of the total idle time as being the sum of the IDLE task and a debug task that will not be included in a production build of an application. @@ -97,8 +97,8 @@ the CPU usage statistics for all tasks in the system. Directives ========== -This section details the CPU usage statistics manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the CPU usage statistics 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. diff --git a/c_user/dual_ports_memory_manager.rst b/c_user/dual_ports_memory_manager.rst index 471cefc..5dd59a5 100644 --- a/c_user/dual_ports_memory_manager.rst +++ b/c_user/dual_ports_memory_manager.rst @@ -94,8 +94,8 @@ its control block is returned to the DPCB free list. Directives ========== -This section details the dual-ported memory manager’s -directives. A subsection is dedicated to each of this manager’s +This section details the dual-ported memory 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. diff --git a/c_user/event_manager.rst b/c_user/event_manager.rst index cfe3cc5..740d127 100644 --- a/c_user/event_manager.rst +++ b/c_user/event_manager.rst @@ -116,10 +116,10 @@ the target task, one of the following situations applies: - Target Task is Blocked Waiting for Events - - If the waiting task’s input event condition is + - If the waiting task's input event condition is satisfied, then the task is made ready for execution. - - If the waiting task’s input event condition is not + - If the waiting task's input event condition is not satisfied, then the event set is posted but left pending and the task remains blocked. @@ -170,8 +170,8 @@ pending then the ``RTEMS_UNSATISFIED`` status code will be returned. Directives ========== -This section details the event manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the event 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. @@ -198,7 +198,7 @@ EVENT_SEND - Send event set to a task **DESCRIPTION:** This directive sends an event set, event_in, to the -task specified by id. If a blocked task’s input event condition +task specified by id. If a blocked task's input event condition is satisfied by this directive, then it will be made ready. If its input event condition is not satisfied, then the events satisfied are updated and the events not satisfied are left diff --git a/c_user/fatal_error.rst b/c_user/fatal_error.rst index 2c540f1..b4c221a 100644 --- a/c_user/fatal_error.rst +++ b/c_user/fatal_error.rst @@ -81,7 +81,7 @@ contains three pieces of information: The error type indicator is dependent on the source of the error and whether or not the error was internally generated by the executive. If the error was generated -from an API, then the error code will be of that API’s +from an API, then the error code will be of that API's error or status codes. The status codes for the RTEMS API are in cpukit/rtems/include/rtems/rtems/status.h. Those for the POSIX API can be found in <errno.h>. @@ -106,8 +106,8 @@ occurred. Directives ========== -This section details the fatal error manager’s -directives. A subsection is dedicated to each of this manager’s +This section details the fatal error 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. @@ -137,7 +137,7 @@ error extension is defined in the configuration table, then the user-defined error extension is called. If configured and the provided FATAL error extension returns, then the RTEMS default error handler is invoked. This directive can be invoked by -RTEMS or by the user’s application code including initialization +RTEMS or by the user's application code including initialization tasks, other tasks, and ISRs. **NOTES:** diff --git a/c_user/glossary.rst b/c_user/glossary.rst index b9d9c7d..5464bf4 100644 --- a/c_user/glossary.rst +++ b/c_user/glossary.rst @@ -142,11 +142,11 @@ Glossary peripheral devices used by the application. :dfn:`directives` - RTEMS’ provided routines that provide + RTEMS' provided routines that provide support mechanisms for real-time applications. :dfn:`dispatch` - The act of loading a task’s context onto + The act of loading a task's context onto the CPU and transferring control of the CPU to that task. :dfn:`dormant` @@ -177,7 +177,7 @@ Glossary :dfn:`entry point` The address at which a function or task begins to execute. In C, the entry point of a function is the - function’s name. + function's name. :dfn:`events` A method for task communication and @@ -339,7 +339,7 @@ Glossary Device Driver Table. :dfn:`manager` - A group of related RTEMS’ directives which + A group of related RTEMS' directives which provide access and control over resources. :dfn:`memory pool` @@ -368,7 +368,7 @@ Glossary driver, the exact usage of which is driver dependent. :dfn:`mode` - An entry in a task’s control block that is + An entry in a task's control block that is used to determine if the task allows preemption, timeslicing, processing of signals, and the interrupt disable level used by the task. @@ -435,7 +435,7 @@ Glossary :dfn:`operating system` The software which controls all - the computer’s resources and provides the base upon which + the computer's resources and provides the base upon which application programs can be written. :dfn:`overhead` @@ -595,7 +595,7 @@ Glossary :dfn:`resume` Removing a task from the suspend state. If - the task’s state is ready following a call to the ``rtems_task_resume`` + the task's state is ready following a call to the ``rtems_task_resume`` directive, then the task is available for scheduling. :dfn:`return code` @@ -671,7 +671,7 @@ Glossary :dfn:`signal set` A thirty-two bit entity which is used to - represent a task’s collection of pending signals and the signals + represent a task's collection of pending signals and the signals sent to a task. :dfn:`SMCB` diff --git a/c_user/index.rst b/c_user/index.rst index 0b24f90..bef9f30 100644 --- a/c_user/index.rst +++ b/c_user/index.rst @@ -1,8 +1,8 @@ ==================== -RTEMS C User’s Guide +RTEMS C User's Guide ==================== -COPYRIGHT © 1988 - 2015. +COPYRIGHT (c) 1988 - 2015. On-Line Applications Research Corporation (OAR). diff --git a/c_user/initialization.rst b/c_user/initialization.rst index d57ffac..e2a823b 100644 --- a/c_user/initialization.rst +++ b/c_user/initialization.rst @@ -24,7 +24,7 @@ Initialization Tasks .. index:: initialization tasks Initialization task(s) are the mechanism by which -RTEMS transfers initial control to the user’s application. +RTEMS transfers initial control to the user's application. Initialization tasks differ from other application tasks in that they are defined in the User Initialization Tasks Table and automatically created and started by RTEMS as part of its @@ -211,8 +211,8 @@ application to end multitasking and terminate the system. Directives ========== -This section details the Initialization Manager’s -directives. A subsection is dedicated to each of this manager’s +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. diff --git a/c_user/interrupt_manager.rst b/c_user/interrupt_manager.rst index 5b9d6c3..52f4339 100644 --- a/c_user/interrupt_manager.rst +++ b/c_user/interrupt_manager.rst @@ -50,7 +50,7 @@ interrupt occurs, the processor will automatically vector to RTEMS. RTEMS saves and restores all registers which are not preserved by the normal C calling convention for the target -processor and invokes the user’s ISR. The user’s ISR is +processor and invokes the user's ISR. The user's ISR is responsible for processing the interrupt, clearing the interrupt if necessary, and device specific manipulation... index:: rtems_vector_number @@ -80,7 +80,7 @@ servicing. To minimize the masking of lower or equal priority level interrupts, the ISR should perform the minimum actions required to service the interrupt. Other non-essential actions -should be handled by application tasks. Once the user’s ISR has +should be handled by application tasks. Once the user's ISR has completed, it returns control to the RTEMS interrupt manager which will perform task dispatching and restore the registers saved before the ISR was invoked. @@ -119,9 +119,9 @@ RTEMS Interrupt Levels Many processors support multiple interrupt levels or priorities. The exact number of interrupt levels is processor dependent. RTEMS internally supports 256 interrupt levels which -are mapped to the processor’s interrupt levels. For specific +are mapped to the processor's interrupt levels. For specific information on the mapping between RTEMS and the target -processor’s interrupt levels, refer to the Interrupt Processing +processor's interrupt levels, refer to the Interrupt Processing chapter of the Applications Supplement document for a specific target processor. @@ -157,10 +157,10 @@ The ``rtems_interrupt_catch`` directive establishes an ISR for the system. The address of the ISR and its associated CPU vector number are specified to this directive. This directive -installs the RTEMS interrupt wrapper in the processor’s -Interrupt Vector Table and the address of the user’s ISR in the -RTEMS’ Vector Table. This directive returns the previous -contents of the specified vector in the RTEMS’ Vector Table. +installs the RTEMS interrupt wrapper in the processor's +Interrupt Vector Table and the address of the user's ISR in the +RTEMS' Vector Table. This directive returns the previous +contents of the specified vector in the RTEMS' Vector Table. Directives Allowed from an ISR ------------------------------ @@ -253,8 +253,8 @@ made from an ISR: Directives ========== -This section details the interrupt manager’s -directives. A subsection is dedicated to each of this manager’s +This section details the interrupt 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. @@ -288,7 +288,7 @@ routine (ISR) for the specified interrupt vector number. The``new_isr_handler`` The entry point of the previous ISR for the specified vector is returned in ``old_isr_handler``. -To release an interrupt vector, pass the old handler’s address obtained +To release an interrupt vector, pass the old handler's address obtained when the vector was first capture. **NOTES:** diff --git a/c_user/io_manager.rst b/c_user/io_manager.rst index f870580..cf24310 100644 --- a/c_user/io_manager.rst +++ b/c_user/io_manager.rst @@ -41,7 +41,7 @@ Device Driver Table Each application utilizing the RTEMS I/O manager must specify the address of a Device Driver Table in its Configuration Table. This table -contains each device driver’s entry points that is to be initialised by +contains each device driver's entry points that is to be initialised by RTEMS during initialization. Each device driver may contain the following entry points: @@ -59,8 +59,8 @@ following entry points: If the device driver does not support a particular entry point, then that entry in the Configuration Table should -be NULL. RTEMS will return``RTEMS_SUCCESSFUL`` as the executive’s and -zero (0) as the device driver’s return code for these device +be NULL. RTEMS will return``RTEMS_SUCCESSFUL`` as the executive's and +zero (0) as the device driver's return code for these device driver entry points. Applications can register and unregister drivers with the RTEMS I/O @@ -75,9 +75,9 @@ Major and Minor Device Numbers .. index:: major device number .. index:: minor device number -Each call to the I/O manager must provide a device’s +Each call to the I/O manager must provide a device's major and minor numbers as arguments. The major number is the -index of the requested driver’s entry points in the Device +index of the requested driver's entry points in the Device Driver Table, and is used to select a specific device driver. The exact usage of the minor number is driver specific, but is commonly used to distinguish between a number of devices @@ -224,8 +224,8 @@ and the underlying device driver entry points. Directives ========== -This section details the I/O manager’s directives. A -subsection is dedicated to each of this manager’s directives and +This section details the I/O 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. @@ -258,7 +258,7 @@ IO_REGISTER_DRIVER - Register a device driver This directive attempts to add a new device driver to the Device Driver Table. The user can specify a specific major device number via the -directive’s ``major`` parameter, or let the registration routine find +directive's ``major`` parameter, or let the registration routine find the next available major device number by specifing a major number of``0``. The selected major device number is returned via the``registered_major`` directive parameter. The directive automatically allocation major device numbers from the highest value down. diff --git a/c_user/key_concepts.rst b/c_user/key_concepts.rst index c5ee56f..9f4c5ea 100644 --- a/c_user/key_concepts.rst +++ b/c_user/key_concepts.rst @@ -26,10 +26,10 @@ re-usable "building block" routines. All objects are created on the local node as required by the application and have an RTEMS assigned ID. All objects have a user-assigned name. Although a relationship exists -between an object’s name and its RTEMS assigned ID, the name and +between an object's name and its RTEMS assigned ID, the name and ID are not identical. Object names are completely arbitrary and selected by the user as a meaningful "tag" which may commonly -reflect the object’s use in the application. Conversely, object +reflect the object's use in the application. Conversely, object IDs are designed to facilitate efficient object manipulation by the executive. @@ -149,7 +149,7 @@ Object ID Description The components of an object ID make it possible to quickly locate any object in even the most complicated -multiprocessor system. Object ID’s are associated with an +multiprocessor system. Object ID's are associated with an object by RTEMS when the object is created and the corresponding ID is returned by the appropriate object create directive. The object ID is required as input to all directives involving @@ -157,7 +157,7 @@ objects, except those which create an object or obtain the ID of an object. The object identification directives can be used to -dynamically obtain a particular object’s ID given its name. +dynamically obtain a particular object's ID given its name. This mapping is accomplished by searching the name table associated with this object type. If the name is non-unique, then the ID associated with the first occurrence of the name @@ -190,10 +190,10 @@ as follows:.. index:: obtaining class from object ID An object control block is a data structure defined by RTEMS which contains the information necessary to manage a particular object type. For efficiency reasons, the format of -each object type’s control block is different. However, many of +each object type's control block is different. However, many of the fields are similar in function. The number of each type of control block is application dependent and determined by the -values specified in the user’s Configuration Table. An object +values specified in the user's Configuration Table. An object control block is allocated at object create time and freed when the object is deleted. With the exception of user extension routines, object control blocks are not directly manipulated by @@ -220,7 +220,7 @@ Most RTEMS managers can be used to provide some form of communication and/or synchronization. However, managers dedicated specifically to communication and synchronization provide well established mechanisms which directly map to the -application’s varying needs. This level of flexibility allows +application's varying needs. This level of flexibility allows the application designer to match the features of a particular manager with the complexity of communication and synchronization required. The following managers were specifically designed for @@ -276,9 +276,9 @@ the clock granularity is large. The rate monotonic scheduling algorithm is a hard real-time scheduling methodology. This methodology provides rules which allows one to guarantee that a set of independent -periodic tasks will always meet their deadlines – even under +periodic tasks will always meet their deadlines - even under transient overload conditions. The rate monotonic manager -provides directives built upon the Clock Manager’s interval +provides directives built upon the Clock Manager's interval timer support routines. Interval timing is not sufficient for the many @@ -286,7 +286,7 @@ applications which require that time be kept in wall time or true calendar form. Consequently, RTEMS maintains the current date and time. This allows selected time operations to be scheduled at an actual calendar date and time. For example, a -task could request to delay until midnight on New Year’s Eve +task could request to delay until midnight on New Year's Eve before lowering the ball at Times Square. The data type ``rtems_time_of_day`` is used to specify calendar time in RTEMS services. @@ -307,7 +307,7 @@ RTEMS memory management facilities can be grouped into two classes: dynamic memory allocation and address translation. Dynamic memory allocation is required by applications whose memory requirements vary through the -application’s course of execution. Address translation is +application's course of execution. Address translation is needed by applications which share memory with another CPU or an intelligent Input/Output processor. The following RTEMS managers provide facilities to manage memory: diff --git a/c_user/message_manager.rst b/c_user/message_manager.rst index 42211e1..57401bc 100644 --- a/c_user/message_manager.rst +++ b/c_user/message_manager.rst @@ -152,7 +152,7 @@ Receiving a Message The ``rtems_message_queue_receive`` directive attempts to retrieve a message from the specified message queue. If at least one message is in the queue, then the message is removed -from the queue, copied to the caller’s message buffer, and +from the queue, copied to the caller's message buffer, and returned immediately along with the length of the message. When messages are unavailable, one of the following situations applies: @@ -167,7 +167,7 @@ applies: wait before returning with an error status. If the task waits for a message, then it is placed in -the message queue’s task wait queue in either FIFO or task +the message queue's task wait queue in either FIFO or task priority order. All tasks waiting on a message queue are returned an error code when the message queue is deleted. @@ -177,13 +177,13 @@ Sending a Message Messages can be sent to a queue with the``rtems_message_queue_send`` and``rtems_message_queue_urgent`` directives. These directives work identically when tasks are waiting to receive a message. A task is removed from the task waiting queue, -unblocked, and the message is copied to a waiting task’s +unblocked, and the message is copied to a waiting task's message buffer. When no tasks are waiting at the queue,``rtems_message_queue_send`` places the message at the rear of the message queue, while``rtems_message_queue_urgent`` places the message at the front of the queue. The message is copied to a message buffer -from this message queue’s buffer pool and then placed in the +from this message queue's buffer pool and then placed in the message queue. Neither directive can successfully send a message to a message queue which has a full queue of pending messages. @@ -194,7 +194,7 @@ Broadcasting a Message The ``rtems_message_queue_broadcast`` directive sends the same message to every task waiting on the specified message queue as an atomic operation. The message is copied to each waiting -task’s message buffer and each task is unblocked. The number of +task's message buffer and each task is unblocked. The number of tasks which were unblocked is returned to the caller. Deleting a Message Queue @@ -202,20 +202,20 @@ Deleting a Message Queue The ``rtems_message_queue_delete`` directive removes a message queue from the system and frees its control block as well as the -memory associated with this message queue’s message buffer pool. +memory associated with this message queue's message buffer pool. A message queue can be deleted by any local task that knows the -message queue’s ID. As a result of this directive, all tasks +message queue's ID. As a result of this directive, all tasks blocked waiting to receive a message from the message queue will be readied and returned a status code which indicates that the message queue was deleted. Any subsequent references to the -message queue’s name and ID are invalid. Any messages waiting +message queue's name and ID are invalid. Any messages waiting at the message queue are also deleted and deallocated. Directives ========== -This section details the message manager’s -directives. A subsection is dedicated to each of this manager’s +This section details the message 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. @@ -284,7 +284,7 @@ Message queues should not be made global unless remote tasks must interact with the created message queue. This is to avoid the system overhead incurred by the creation of a global message queue. When a global message queue is created, -the message queue’s name and id must be transmitted to every +the message queue's name and id must be transmitted to every node in the system for insertion in the local copy of the global object table. @@ -422,16 +422,16 @@ MESSAGE_QUEUE_SEND - Put message at rear of a queue ``RTEMS_INVALID_SIZE`` - invalid message size ``RTEMS_INVALID_ADDRESS`` - ``buffer`` is NULL ``RTEMS_UNSATISFIED`` - out of message buffers -``RTEMS_TOO_MANY`` - queue’s limit has been reached +``RTEMS_TOO_MANY`` - queue's limit has been reached **DESCRIPTION:** This directive sends the message buffer of size bytes in length to the queue specified by id. If a task is waiting at -the queue, then the message is copied to the waiting task’s +the queue, then the message is copied to the waiting task's buffer and the task is unblocked. If no tasks are waiting at the queue, then the message is copied to a message buffer which is -obtained from this message queue’s message buffer pool. The +obtained from this message queue's message buffer pool. The message buffer is then placed at the rear of the queue. **NOTES:** @@ -472,16 +472,16 @@ MESSAGE_QUEUE_URGENT - Put message at front of a queue ``RTEMS_INVALID_SIZE`` - invalid message size ``RTEMS_INVALID_ADDRESS`` - ``buffer`` is NULL ``RTEMS_UNSATISFIED`` - out of message buffers -``RTEMS_TOO_MANY`` - queue’s limit has been reached +``RTEMS_TOO_MANY`` - queue's limit has been reached **DESCRIPTION:** This directive sends the message buffer of size bytes in length to the queue specified by id. If a task is waiting on -the queue, then the message is copied to the task’s buffer and +the queue, then the message is copied to the task's buffer and the task is unblocked. If no tasks are waiting on the queue, then the message is copied to a message buffer which is obtained -from this message queue’s message buffer pool. The message +from this message queue's message buffer pool. The message buffer is then placed at the front of the queue. **NOTES:** @@ -530,7 +530,7 @@ MESSAGE_QUEUE_BROADCAST - Broadcast N messages to a queue This directive causes all tasks that are waiting at the queue specified by id to be unblocked and sent the message contained in buffer. Before a task is unblocked, the message -buffer of size byes in length is copied to that task’s message +buffer of size byes in length is copied to that task's message buffer. The number of tasks that were unblocked is returned in count. diff --git a/c_user/multiprocessing.rst b/c_user/multiprocessing.rst index dfd3324..1c0ba04 100644 --- a/c_user/multiprocessing.rst +++ b/c_user/multiprocessing.rst @@ -45,7 +45,7 @@ Background 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 +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, @@ -198,9 +198,9 @@ Proxies 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 +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 +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. @@ -241,7 +241,7 @@ 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 +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: @@ -296,7 +296,7 @@ following prototype:.. index:: rtems_mpci_entry rtems_configuration_table \*configuration ); -where configuration is the address of the user’s +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 @@ -455,7 +455,7 @@ 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 +could be one's or two's complement. These factors combine to increase the complexity of designing and manipulating data structures shared between processors. @@ -495,7 +495,7 @@ 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 +subsection is dedicated to each of this manager's directives and describes the calling sequence, related constants, usage, and status codes. diff --git a/c_user/overview.rst b/c_user/overview.rst index 6b4d125..80ad8da 100644 --- a/c_user/overview.rst +++ b/c_user/overview.rst @@ -270,7 +270,7 @@ that is created. Thus the more RTEMS objects an application needs, the more memory that must be reserved. See `Configuring a System`_. RTEMS utilizes memory for both code and data space. -Although RTEMS’ data space must be in RAM, its code space can be +Although RTEMS' data space must be in RAM, its code space can be located in either ROM or RAM. Audience @@ -288,9 +288,9 @@ understand the material presented. However, because of the similarity of the Ada and C RTEMS implementations, users will find that the use and behavior of the two implementations is very similar. A working knowledge of the target processor is -helpful in understanding some of RTEMS’ features. A thorough +helpful in understanding some of RTEMS' features. A thorough understanding of the executive cannot be obtained without -studying the entire manual because many of RTEMS’ concepts and +studying the entire manual because many of RTEMS' concepts and features are interrelated. Experienced RTEMS users will find that the manual organization facilitates its use as a reference document. @@ -450,7 +450,7 @@ Chapter 26: Chapter 27: Object Services: presents a collection of helper services useful when manipulating RTEMS objects. These include methods to assist - in obtaining an object’s name in printable form. Additional services + in obtaining an object's name in printable form. Additional services are provided to decompose an object Id and determine which API and object class it belongs to. diff --git a/c_user/partition_manager.rst b/c_user/partition_manager.rst index c411a13..8ea18d3 100644 --- a/c_user/partition_manager.rst +++ b/c_user/partition_manager.rst @@ -32,7 +32,7 @@ divided into fixed-size buffers that can be dynamically allocated and deallocated... index:: buffers, definition Partitions are managed and maintained as a list of -buffers. Buffers are obtained from the front of the partition’s +buffers. Buffers are obtained from the front of the partition's free buffer chain and returned to the rear of the same chain. When a buffer is on the free buffer chain, RTEMS uses two pointers of memory from each buffer as the free buffer chain. @@ -70,7 +70,7 @@ Creating a Partition -------------------- The ``rtems_partition_create`` directive creates a partition -with a user-specified name. The partition’s name, starting +with a user-specified name. The partition's name, starting address, length and buffer size are all specified to the``rtems_partition_create`` directive. RTEMS allocates a Partition Control Block (PTCB) from the PTCB free list. This data structure is @@ -104,7 +104,7 @@ become available. Releasing a Buffer ------------------ -Buffers are returned to a partition’s free buffer +Buffers are returned to a partition's free buffer chain with the ``rtems_partition_return_buffer`` directive. This directive returns an error status code if the returned buffer was not previously allocated from this partition. @@ -121,8 +121,8 @@ task attempting to do so will be returned an error status code. Directives ========== -This section details the partition manager’s -directives. A subsection is dedicated to each of this manager’s +This section details the partition 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. @@ -199,7 +199,7 @@ local node. The memory space used for the partition must reside in shared memory. Partitions should not be made global unless remote tasks must interact with the partition. This is to avoid the overhead incurred by the creation of a global partition. -When a global partition is created, the partition’s name and id +When a global partition is created, the partition's name and id must be transmitted to every node in the system for insertion in the local copy of the global object table. diff --git a/c_user/pci_library.rst b/c_user/pci_library.rst index 12acfd4..0512b45 100644 --- a/c_user/pci_library.rst +++ b/c_user/pci_library.rst @@ -240,7 +240,7 @@ 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, +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. @@ -420,7 +420,7 @@ use the standard RTEMS interrupt functions directly. PCI Shell command ----------------- -The RTEMS shell has a PCI command ’pci’ which makes it possible to read/write +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. diff --git a/c_user/preface.rst b/c_user/preface.rst index 97bd805..ce828b0 100644 --- a/c_user/preface.rst +++ b/c_user/preface.rst @@ -45,7 +45,7 @@ multiple real-time executive implementations. This interface includes both the source code interfaces and run-time behavior as seen by a real-time application. It does not include the details of how a kernel implements these functions. The -standard’s goal is to serve as a complete definition of external +standard's goal is to serve as a complete definition of external interfaces so that application code that conforms to these interfaces will execute properly in all real-time executive environments. With the use of a standards compliant executive, @@ -68,8 +68,8 @@ of which processor the object and the accessing task reside. The acceptance of a standard for real-time executives will produce the same advantages enjoyed from the push for UNIX -standardization by AT&T’s System V Interface Definition and -IEEE’s POSIX efforts. A compliant multiprocessing executive +standardization by AT&T's System V Interface Definition and +IEEE's POSIX efforts. A compliant multiprocessing executive will allow close coupling between UNIX systems and real-time executives to provide the many benefits of the UNIX development environment to be applied to real-time software development. diff --git a/c_user/rate_monotonic_manager.rst b/c_user/rate_monotonic_manager.rst index c22cd00..5bd3b1b 100644 --- a/c_user/rate_monotonic_manager.rst +++ b/c_user/rate_monotonic_manager.rst @@ -115,11 +115,11 @@ and it averaged 11 milliseconds, then application requirements are not being met. The information reported can be used to determine the "hot spots" -in the application. Given a period’s id, the user can determine +in the application. Given a period's id, the user can determine the length of that period. From that information and the CPU usage, the user can calculate the percentage of CPU time consumed by that periodic task. For example, a task executing for 20 milliseconds -every 200 milliseconds is consuming 10 percent of the processor’s +every 200 milliseconds is consuming 10 percent of the processor's execution time. This is usually enough to make it a good candidate for optimization. @@ -142,9 +142,9 @@ characterized by the length of their period and execution time. The period and execution time of a task can be used to determine the processor utilization for that task. Processor utilization is the percentage of processor time used and can be calculated -on a per-task or system-wide basis. Typically, the task’s +on a per-task or system-wide basis. Typically, the task's worst-case execution time will be less than its period. For -example, a periodic task’s requirements may state that it should +example, a periodic task's requirements may state that it should execute for 10 milliseconds every 100 milliseconds. Although the execution time may be the average, worst, or best case, the worst-case execution time is more appropriate for use when @@ -178,7 +178,7 @@ deadlines. RMS provides a set of rules which can be used to perform a guaranteed schedulability analysis for a task set. This analysis determines whether a task set is schedulable under worst-case conditions and emphasizes the predictability of the -system’s behavior. It has been proven that: +system's behavior. It has been proven that: - *RMS is an optimal static priority algorithm for scheduling independent, preemptible, periodic tasks @@ -191,13 +191,13 @@ analysis on the processor utilization level below which all deadlines can be met. RMS calls for the static assignment of task -priorities based upon their period. The shorter a task’s +priorities based upon their period. The shorter a task's period, the higher its priority. For example, a task with a 1 millisecond period has higher priority than a task with a 100 millisecond period. If two tasks have the same period, then RMS does not distinguish between the tasks. However, RTEMS specifies that when given tasks of equal priority, the task -which has been ready longest will execute first. RMS’s priority +which has been ready longest will execute first. RMS's priority assignment scheme does not provide one with exact numeric values for task priorities. For example, consider the following task set and priority assignments: @@ -345,7 +345,7 @@ quite easy to ensure. By having a non-preemptible user initialization task, all application tasks, regardless of priority, can be created and started before the initialization deletes itself. This technique ensures that all tasks begin to -compete for execution time at the same instant – when the user +compete for execution time at the same instant - when the user initialization task deletes itself. First Deadline Rule Example @@ -426,7 +426,7 @@ Another assumption is that the tasks are independent. This means that the tasks do not wait for one another or contend for resources. This assumption can be relaxed by accounting for the amount of time a task spends waiting to -acquire resources. Similarly, each task’s execution time must +acquire resources. Similarly, each task's execution time must account for any I/O performed and any RTEMS directive calls. In addition, the assumptions did not account for the @@ -517,7 +517,7 @@ Obtaining the Status of a Period If the ``rtems_rate_monotonic_period`` directive is invoked with a period of ``RTEMS_PERIOD_STATUS`` ticks, the current state of the specified rate monotonic period will be returned. The following -table details the relationship between the period’s status and +table details the relationship between the period's status and the directive status code returned by the``rtems_rate_monotonic_period`` directive: @@ -544,7 +544,7 @@ Deleting a Rate Monotonic Period The ``rtems_rate_monotonic_delete`` directive is used to delete a rate monotonic period. If the period is running and has not expired, the period is automatically canceled. The rate -monotonic period’s control block is returned to the PCB free +monotonic period's control block is returned to the PCB free list when it is deleted. A rate monotonic period can be deleted by a task other than the task which created the period. @@ -674,8 +674,8 @@ will delete the rate monotonic periods and itself. Directives ========== -This section details the rate monotonic manager’s -directives. A subsection is dedicated to each of this manager’s +This section details the rate monotonic 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. @@ -899,7 +899,7 @@ the rate monotonic period id in the following data structure:.. index:: rtems_ra A configure time option can be used to select whether the time information is given in ticks or seconds and nanoseconds. The default is seconds and -nanoseconds. If the period’s state is ``RATE_MONOTONIC_INACTIVE``, both +nanoseconds. If the period's state is ``RATE_MONOTONIC_INACTIVE``, both time values will be set to 0. Otherwise, both time values will contain time information since the last invocation of the``rtems_rate_monotonic_period`` directive. More specifically, the ticks_since_last_period value contains the elapsed time diff --git a/c_user/red_black_trees.rst b/c_user/red_black_trees.rst index c4cfc12..35c8db9 100644 --- a/c_user/red_black_trees.rst +++ b/c_user/red_black_trees.rst @@ -21,21 +21,21 @@ heap memory. The Red-Black Tree API provided by RTEMS is: - ``rtems_rtems_rbtree_initialize_empty`` - initialize the red-black tree as empty -- ``rtems_rtems_rbtree_set_off_tree`` - Clear a node’s links +- ``rtems_rtems_rbtree_set_off_tree`` - Clear a node's links -- ``rtems_rtems_rbtree_root`` - Return the red-black tree’s root node +- ``rtems_rtems_rbtree_root`` - Return the red-black tree's root node -- ``rtems_rtems_rbtree_min`` - Return the red-black tree’s minimum node +- ``rtems_rtems_rbtree_min`` - Return the red-black tree's minimum node -- ``rtems_rtems_rbtree_max`` - Return the red-black tree’s maximum node +- ``rtems_rtems_rbtree_max`` - Return the red-black tree's maximum node -- ``rtems_rtems_rbtree_left`` - Return a node’s left child node +- ``rtems_rtems_rbtree_left`` - Return a node's left child node -- ``rtems_rtems_rbtree_right`` - Return a node’s right child node +- ``rtems_rtems_rbtree_right`` - Return a node's right child node -- ``rtems_rtems_rbtree_parent`` - Return a node’s parent node +- ``rtems_rtems_rbtree_parent`` - Return a node's parent node -- ``rtems_rtems_rbtree_are_nodes_equal`` - Are the node’s equal ? +- ``rtems_rtems_rbtree_are_nodes_equal`` - Are the node's equal ? - ``rtems_rtems_rbtree_is_empty`` - Is the red-black tree empty ? @@ -85,8 +85,8 @@ A red-black tree is made up from nodes that orginate from a red-black tree contr object. A node is of type ``rtems_rtems_rbtree_node``. The node is designed to be part of a user data structure. To obtain the encapsulating structure users can use the ``RTEMS_CONTAINER_OF`` macro. -The node can be placed anywhere within the user’s structure and the macro will -calculate the structure’s address from the node’s address. +The node can be placed anywhere within the user's structure and the macro will +calculate the structure's address from the node's address. Controls -------- diff --git a/c_user/region_manager.rst b/c_user/region_manager.rst index 1c9bbc0..0b4b939 100644 --- a/c_user/region_manager.rst +++ b/c_user/region_manager.rst @@ -47,12 +47,12 @@ Regions are organized as doubly linked chains of variable sized memory blocks. Memory requests are allocated using a first-fit algorithm. If available, the requester receives the number of bytes requested (rounded up to the next -page size). RTEMS requires some overhead from the region’s +page size). RTEMS requires some overhead from the region's memory for each segment that is allocated. Therefore, an application should only modify the memory of a segment that has been obtained from the region. The application should NOT modify the memory outside of any obtained segments and within -the region’s boundaries while the region is currently active in +the region's boundaries while the region is currently active in the system. Upon return to the region, the free block is @@ -178,7 +178,7 @@ following situations applies: wait before returning with an error status code. If the task waits for the segment, then it is placed -in the region’s task wait queue in either FIFO or task priority +in the region's task wait queue in either FIFO or task priority order. All tasks waiting on a region are returned an error when the message queue is deleted. @@ -190,7 +190,7 @@ unallocated neighbors to form the largest possible segment. The first task on the wait queue is examined to determine if its segment request can now be satisfied. If so, it is given a segment and unblocked. This process is repeated until the first -task’s segment request cannot be satisfied. +task's segment request cannot be satisfied. Obtaining the Size of a Segment ------------------------------- @@ -226,8 +226,8 @@ a status code which indicates that the region was deleted. Directives ========== -This section details the region manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the region 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. @@ -448,7 +448,7 @@ If the calling task chooses to return immediately and a segment large enough is not available, then an error code indicating this fact is returned. If the calling task chooses to wait for the segment and a segment large enough is not -available, then the calling task is placed on the region’s +available, then the calling task is placed on the region's segment wait queue and blocked. If the region was created with the ``RTEMS_PRIORITY`` option, then the calling task is inserted into the @@ -465,7 +465,7 @@ calling task will wait forever. The actual length of the allocated segment may be larger than the requested size because a segment size is always -a multiple of the region’s page size. +a multiple of the region's page size. The following segment acquisition option constants are defined by RTEMS: @@ -507,7 +507,7 @@ merged with its neighbors to form the largest possible segment. The first task on the wait queue is examined to determine if its segment request can now be satisfied. If so, it is given a segment and unblocked. This process is repeated until the first -task’s segment request cannot be satisfied. +task's segment request cannot be satisfied. **NOTES:** @@ -552,7 +552,7 @@ This directive obtains the size in bytes of the specified segment. The actual length of the allocated segment may be larger than the requested size because a segment size is always -a multiple of the region’s page size. +a multiple of the region's page size. REGION_RESIZE_SEGMENT - Change size of a segment ------------------------------------------------ diff --git a/c_user/rtems_data_types.rst b/c_user/rtems_data_types.rst index 9d3a51f..83e9fe2 100644 --- a/c_user/rtems_data_types.rst +++ b/c_user/rtems_data_types.rst @@ -49,13 +49,13 @@ data types in alphabetical order: ``rtems_context`` is the CPU dependent data structure used to manage the integer and system - register portion of each task’s context. + register portion of each task's context. - .. index:: rtems_context_fp ``rtems_context_fp`` is the CPU dependent data structure used to manage the floating point portion of - each task’s context. + each task's context. - .. index:: rtems_device_driver diff --git a/c_user/scheduling_concepts.rst b/c_user/scheduling_concepts.rst index 56ddc46..d5b261e 100644 --- a/c_user/scheduling_concepts.rst +++ b/c_user/scheduling_concepts.rst @@ -12,10 +12,10 @@ provide immediate response to specific external events, particularly the necessity of scheduling tasks to run within a specified time limit after the occurrence of an event. For example, software embedded in life-support systems used to monitor hospital patients must take instant -action if a change in the patient’s status is detected. +action if a change in the patient's status is detected. The component of RTEMS responsible for providing this capability is -appropriately called the scheduler. The scheduler’s sole purpose is +appropriately called the scheduler. The scheduler's sole purpose is to allocate the all important resource of processor time to the various tasks competing for attention. @@ -175,7 +175,7 @@ Constant Bandwidth Server Scheduling (CBS) This is an alternative scheduler in RTEMS for single core applications. The CBS is a budget aware extension of EDF scheduler. The main goal of this -scheduler is to ensure temporal isolation of tasks meaning that a task’s +scheduler is to ensure temporal isolation of tasks meaning that a task's execution in terms of meeting deadlines must not be influenced by other tasks as if they were run on multiple independent processors. @@ -232,7 +232,7 @@ Task Priority and Scheduling The most significant task scheduling modification mechanism is the ability for the user to assign a priority level to each individual task when it -is created and to alter a task’s priority at run-time. RTEMS supports +is created and to alter a task's priority at run-time. RTEMS supports up to 255 priority levels. Level 255 is the lowest priority and level 1 is the highest. @@ -260,7 +260,7 @@ mode flag (``RTEMS_TIMESLICE_MASK``). If timeslicing is enabled for a task (``RTEMS_TIMESLICE``), then RTEMS will limit the amount of time the task can execute before the processor is allocated to another task. Each tick of the real-time clock reduces -the currently running task’s timeslice. When the execution time equals +the currently running task's timeslice. When the execution time equals the timeslice, RTEMS will dispatch another task of the same priority to execute. If there are no other tasks of the same priority ready to execute, then the current task is allocated an additional timeslice and @@ -288,14 +288,14 @@ from the task currently using it. This involves a concept called a context switch. To perform a context switch, the dispatcher saves the context of the current task and restores the context of the task which has been allocated to the -processor. Saving and restoring a task’s context is the +processor. Saving and restoring a task's context is the storing/loading of all the essential information about a task to enable it to continue execution without any effects of the -interruption. For example, the contents of a task’s register +interruption. For example, the contents of a task's register set must be the same when it is given the processor as they were when it was taken away. All of the information that must be saved or restored for a context switch is located either in the -TCB or on the task’s stacks. +TCB or on the task's stacks. Tasks that utilize a numeric coprocessor and are created with the``RTEMS_FLOATING_POINT`` attribute require additional operations during a context switch. These additional operations @@ -394,7 +394,7 @@ A task enters the blocked state due to any of the following conditions: - The running task issues a ``rtems_region_get_segment`` directive with the wait option and there is not an available segment large - enough to satisfy the task’s request. + enough to satisfy the task's request. A blocked task may also be suspended. Therefore, both the suspension and the blocking condition must be removed before the task becomes ready @@ -432,7 +432,7 @@ to any of the following conditions: - A running task issues a ``rtems_region_return_segment`` directive which releases a segment to the region on which the blocked task is waiting and a resulting segment is large enough to satisfy - the task’s request. + the task's request. - A rate monotonic period expires for a task which blocked by a call to the ``rtems_rate_monotonic_period`` directive. diff --git a/c_user/semaphore_manager.rst b/c_user/semaphore_manager.rst index 38f1a60..4997bf3 100644 --- a/c_user/semaphore_manager.rst +++ b/c_user/semaphore_manager.rst @@ -125,7 +125,7 @@ discipline. When a task of higher priority than the task holding the semaphore blocks, the priority of the task holding the semaphore is increased to that of the blocking task. When the task holding the task completely releases the binary -semaphore (i.e. not for a nested release), the holder’s priority +semaphore (i.e. not for a nested release), the holder's priority is restored to the value it had before any higher priority was inherited. @@ -159,7 +159,7 @@ discipline. When a task of lower priority than the ceiling priority successfully obtains the semaphore, its priority is raised to the ceiling priority. When the task holding the task completely releases the binary semaphore (i.e. not for a nested -release), the holder’s priority is restored to the value it had +release), the holder's priority is restored to the value it had before any higher priority was put into effect. The need to identify the highest priority task which @@ -298,7 +298,7 @@ initial count. If a binary semaphore is created with a count of zero (0) to indicate that it has been allocated, then the task creating the semaphore is considered the current holder of the semaphore. At create time the method for ordering waiting tasks -in the semaphore’s task wait queue (by FIFO or task priority) is +in the semaphore's task wait queue (by FIFO or task priority) is specified. Additionally, the priority inheritance or priority ceiling algorithm may be selected for local, binary semaphores that use the priority task wait queue blocking discipline. If @@ -346,9 +346,9 @@ one of the following situations applies: wait before returning with an error status code. If the task waits to acquire the semaphore, then it -is placed in the semaphore’s task wait queue in either FIFO or +is placed in the semaphore's task wait queue in either FIFO or task priority order. If the task blocked waiting for a binary -semaphore using priority inheritance and the task’s priority is +semaphore using priority inheritance and the task's priority is greater than that of the task currently holding the semaphore, then the holding task will inherit the priority of the blocking task. All tasks waiting on a semaphore are returned an error @@ -356,7 +356,7 @@ code when the semaphore is deleted. When a task successfully obtains a semaphore using priority ceiling and the priority ceiling for this semaphore is -greater than that of the holder, then the holder’s priority will +greater than that of the holder, then the holder's priority will be elevated. Releasing a Semaphore @@ -383,17 +383,17 @@ Deleting a Semaphore The ``rtems_semaphore_delete`` directive removes a semaphore from the system and frees its control block. A semaphore can be -deleted by any local task that knows the semaphore’s ID. As a +deleted by any local task that knows the semaphore's ID. As a result of this directive, all tasks blocked waiting to acquire the semaphore will be readied and returned a status code which indicates that the semaphore was deleted. Any subsequent -references to the semaphore’s name and ID are invalid. +references to the semaphore's name and ID are invalid. Directives ========== -This section details the semaphore manager’s -directives. A subsection is dedicated to each of this manager’s +This section details the semaphore 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. @@ -489,7 +489,7 @@ defined by RTEMS: Semaphores should not be made global unless remote tasks must interact with the created semaphore. This is to avoid the system overhead incurred by the creation of a global -semaphore. When a global semaphore is created, the semaphore’s +semaphore. When a global semaphore is created, the semaphore's name and id must be transmitted to every node in the system for insertion in the local copy of the global object table. @@ -584,7 +584,7 @@ by RTEMS. **NOTES:** The calling task will be preempted if it is enabled -by the task’s execution mode and a higher priority local task is +by the task's execution mode and a higher priority local task is waiting on the deleted semaphore. The calling task will NOT be preempted if all of the tasks that are waiting on the semaphore are remote tasks. @@ -643,7 +643,7 @@ semaphore count is zero or negative, then a status code is returned indicating that the semaphore is not available. If the calling task chooses to wait for a semaphore and the current semaphore count is zero or negative, then it is decremented by one and the calling task is placed on -the semaphore’s wait queue and blocked. If the semaphore was created with +the semaphore's wait queue and blocked. If the semaphore was created with the ``RTEMS_PRIORITY`` attribute, then the calling task is inserted into the queue according to its priority. However, if the semaphore was created with the ``RTEMS_FIFO`` attribute, then @@ -713,9 +713,9 @@ SEMAPHORE_RELEASE - Release a semaphore This directive releases the semaphore specified by id. The semaphore count is incremented by one. If the count is -zero or negative, then the first task on this semaphore’s wait +zero or negative, then the first task on this semaphore's wait queue is removed and unblocked. The unblocked task may preempt -the running task if the running task’s preemption mode is +the running task if the running task's preemption mode is enabled and the unblocked task has a higher priority than the running task. @@ -769,7 +769,7 @@ the semaphore **DESCRIPTION:** This directive unblocks all tasks waiting on the semaphore specified by -id. Since there are tasks blocked on the semaphore, the semaphore’s +id. Since there are tasks blocked on the semaphore, the semaphore's count is not changed by this directive and thus is zero before and after this directive is executed. Tasks which are unblocked as the result of this directive will return from the``rtems_semaphore_obtain`` directive with a @@ -777,7 +777,7 @@ status code of ``RTEMS_UNSATISFIED`` to indicate that the semaphore was not obtained. This directive may unblock any number of tasks. Any of the unblocked -tasks may preempt the running task if the running task’s preemption mode is +tasks may preempt the running task if the running task's preemption mode is enabled and an unblocked task has a higher priority than the running task. diff --git a/c_user/signal_manager.rst b/c_user/signal_manager.rst index 2b671b1..b11bf89 100644 --- a/c_user/signal_manager.rst +++ b/c_user/signal_manager.rst @@ -24,12 +24,12 @@ Signal Manager Definitions The signal manager allows a task to optionally define an asynchronous signal routine (ASR). An ASR is to a task what -an ISR is to an application’s set of tasks. When the processor +an ISR is to an application's set of tasks. When the processor is interrupted, the execution of an application is also interrupted and an ISR is given control. Similarly, when a -signal is sent to a task, that task’s execution path will be +signal is sent to a task, that task's execution path will be "interrupted" by the ASR. Sending a signal to a task has no -effect on the receiving task’s current execution state... index:: rtems_signal_set +effect on the receiving task's current execution state... index:: rtems_signal_set A signal flag is used by a task (or ISR) to inform another task of the occurrence of a significant situation. @@ -40,7 +40,7 @@ is used to manipulate signal sets. A signal set is posted when it is directed (or sent) to a task. A pending signal is a signal that has been sent to a task -with a valid ASR, but has not been processed by that task’s ASR. +with a valid ASR, but has not been processed by that task's ASR. A Comparison of ASRs and ISRs ----------------------------- @@ -85,7 +85,7 @@ Building an ASR Mode -------------------- .. index:: ASR mode, building -In general, an ASR’s mode is built by a bitwise OR of +In general, an ASR's mode is built by a bitwise OR of the desired mode components. The set of valid mode components is the same as those allowed with the task_create and task_mode directives. A complete list of mode options is provided in the @@ -132,19 +132,19 @@ Establishing an ASR The ``rtems_signal_catch`` directive establishes an ASR for the calling task. The address of the ASR and its execution mode are -specified to this directive. The ASR’s mode is distinct from -the task’s mode. For example, the task may allow preemption, -while that task’s ASR may have preemption disabled. Until a +specified to this directive. The ASR's mode is distinct from +the task's mode. For example, the task may allow preemption, +while that task's ASR may have preemption disabled. Until a task calls ``rtems_signal_catch`` the first time, its ASR is invalid, and no signal sets can be sent to the task. A task may invalidate its ASR and discard all pending signals by calling ``rtems_signal_catch`` -with a value of NULL for the ASR’s address. When a task’s +with a value of NULL for the ASR's address. When a task's ASR is invalid, new signal sets sent to this task are discarded. A task may disable ASR processing (``RTEMS_NO_ASR``) via the -task_mode directive. When a task’s ASR is disabled, the signals +task_mode directive. When a task's ASR is disabled, the signals sent to it are left pending to be processed later when the ASR is enabled. @@ -153,7 +153,7 @@ be called from an ASR. A task is only allowed one active ASR. Thus, each call to ``rtems_signal_catch`` replaces the previous one. -Normally, signal processing is disabled for the ASR’s +Normally, signal processing is disabled for the ASR's execution mode, but if signal processing is enabled for the ASR, the ASR must be reentrant. @@ -165,7 +165,7 @@ tasks and ISRs to send signals to a target task. The target task and a set of signals are specified to the``rtems_signal_send`` directive. The sending of a signal to a task has no effect on the execution state of that task. If the task is not the currently running task, then -the signals are left pending and processed by the task’s ASR the +the signals are left pending and processed by the task's ASR the next time the task is dispatched to run. The ASR is executed immediately before the task is dispatched. If the currently running task sends a signal to itself or is sent a signal from @@ -209,8 +209,8 @@ prior to entering the ASR. Directives ========== -This section details the signal manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the signal 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. @@ -242,7 +242,7 @@ specifies the entry point of the ASR. If asr_handler is NULL, the ASR for the calling task is invalidated and all pending signals are cleared. Any signals sent to a task with an invalid ASR are discarded. The mode parameter specifies the execution -mode for the ASR. This execution mode supersedes the task’s +mode for the ASR. This execution mode supersedes the task's execution mode while the ASR is executing. **NOTES:** @@ -308,7 +308,7 @@ time the task is dispatched to run. **NOTES:** Sending a signal set to a task has no effect on that -task’s state. If a signal set is sent to a blocked task, then +task's state. If a signal set is sent to a blocked task, then the task will remain blocked and the signals will be processed when the task becomes the running task. diff --git a/c_user/stack_bounds_checker.rst b/c_user/stack_bounds_checker.rst index 23ddac1..0cf075b 100644 --- a/c_user/stack_bounds_checker.rst +++ b/c_user/stack_bounds_checker.rst @@ -36,18 +36,18 @@ Execution --------- The stack bounds checker operates as a set of task extensions. At -task creation time, the task’s stack is filled with a pattern to +task creation time, the task's stack is filled with a pattern to indicate the stack is unused. As the task executes, it will overwrite -this pattern in memory. At each task switch, the stack bounds checker’s +this pattern in memory. At each task switch, the stack bounds checker's task switch extension is executed. This extension checks that: -- the last ``n`` bytes of the task’s stack have +- the last ``n`` bytes of the task's stack have not been overwritten. If this pattern has been damaged, it indicates that at some point since this task was context switch to the CPU, it has used too much stack space. - the current stack pointer of the task is not within - the address range allocated for use as the task’s stack. + the address range allocated for use as the task's stack. If either of these conditions is detected, then a blown stack error is reported using the ``printk`` routine. @@ -131,13 +131,13 @@ The following is an example of the output generated: Damaged pattern begins at 0x003e5758 and is 128 bytes long The above includes the task id and a pointer to the task control block as -well as enough information so one can look at the task’s stack and +well as enough information so one can look at the task's stack and see what was happening. Routines ======== -This section details the stack bounds checker’s routines. +This section details the stack bounds checker's routines. A subsection is dedicated to each of routines and describes the calling sequence, related constants, usage, and status codes. diff --git a/c_user/symmetric_multiprocessing_services.rst b/c_user/symmetric_multiprocessing_services.rst index 5e2e92c..998a066 100644 --- a/c_user/symmetric_multiprocessing_services.rst +++ b/c_user/symmetric_multiprocessing_services.rst @@ -173,7 +173,7 @@ 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, Björn B.: Scheduling and +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 @@ -220,9 +220,9 @@ 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, Björn B.: A fully preemptive multiprocessor semaphore protocol for +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*. +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). diff --git a/c_user/task_manager.rst b/c_user/task_manager.rst index 2ae5372..57c47f4 100644 --- a/c_user/task_manager.rst +++ b/c_user/task_manager.rst @@ -30,7 +30,7 @@ by the task manager are: - ``rtems_task_set_priority`` - Set task priority -- ``rtems_task_mode`` - Change current task’s mode +- ``rtems_task_mode`` - Change current task's mode - ``rtems_task_wake_after`` - Wake up after interval @@ -69,7 +69,7 @@ task concept: - a sequence of closely related computations which can execute concurrently with other computational sequences. -From RTEMS’ perspective, a task is the smallest thread of +From RTEMS' perspective, a task is the smallest thread of execution which can compete on its own for system resources. A task is manifested by the existence of a task control block (TCB). @@ -84,20 +84,20 @@ reserves a TCB for each task configured. A TCB is allocated upon creation of the task and is returned to the TCB free list upon deletion of the task. -The TCB’s elements are modified as a result of system calls made +The TCB's elements are modified as a result of system calls made by the application in response to external and internal stimuli. TCBs are the only RTEMS internal data structure that can be accessed by an application via user extension routines. The TCB -contains a task’s name, ID, current priority, current and +contains a task's name, ID, current priority, current and starting states, execution mode, TCB user extension pointer, scheduling control structures, as well as data required by a blocked task. -A task’s context is stored in the TCB when a task switch occurs. +A task's context is stored in the TCB when a task switch occurs. When the task regains control of the processor, its context is restored from the TCB. When a task is restarted, the initial state of the task is restored from the starting context area in -the task’s TCB. +the task's TCB. Task States ----------- @@ -131,7 +131,7 @@ Task Priority .. index:: priority, task .. index:: rtems_task_priority -A task’s priority determines its importance in relation to the +A task's priority determines its importance in relation to the other tasks executing on the same processor. RTEMS supports 255 levels of priority ranging from 1 to 255. The data type``rtems_task_priority`` is used to store task priorities. @@ -158,7 +158,7 @@ Task Mode .. index:: task mode .. index:: rtems_task_mode -A task’s execution mode is a combination of the following +A task's execution mode is a combination of the following four components: - preemption @@ -169,14 +169,14 @@ four components: - interrupt level -It is used to modify RTEMS’ scheduling process and to alter the +It is used to modify RTEMS' scheduling process and to alter the execution environment of the task. The data type``rtems_task_mode`` is used to manage the task execution mode... index:: preemption The preemption component allows a task to determine when control of the processor is relinquished. If preemption is disabled (``RTEMS_NO_PREEMPT``), the task will retain control of the -processor as long as it is in the executing state – even if a higher +processor as long as it is in the executing state - even if a higher priority task is made ready. If preemption is enabled (``RTEMS_PREEMPT``) and a higher priority task is made ready, then the processor will be taken away from the current task immediately and @@ -300,9 +300,9 @@ Per task variables are used to support global variables whose value may be unique to a task. After indicating that a variable should be treated as private (i.e. per-task) the task can access and modify the variable, but the modifications will not appear to other tasks, and -other tasks’ modifications to that variable will not affect the value +other tasks' modifications to that variable will not affect the value seen by the task. This is accomplished by saving and restoring the -variable’s value each time a task switch occurs to or from the calling task. +variable's value each time a task switch occurs to or from the calling task. The value seen by other tasks, including those which have not added the variable to their set and are thus accessing the variable as a common @@ -322,14 +322,14 @@ Task variables increase the context switch time to and from the tasks that own them so it is desirable to minimize the number of task variables. One efficient method is to have a single task variable that is a pointer to a dynamically allocated structure -containing the task’s private "global" data. +containing the task's private "global" data. A critical point with per-task variables is that each task must separately request that the same global variable is per-task private. *WARNING*: Per-Task variables are inherently broken on SMP systems. They only work correctly when there is one task executing in the system and -that task is the logical owner of the value in the per-task variable’s +that task is the logical owner of the value in the per-task variable's location. There is no way for a single memory image to contain the correct value for each task executing on each core. Consequently, per-task variables are disabled in SMP configurations of RTEMS. @@ -374,7 +374,7 @@ Building a Mode and Mask In general, a mode and its corresponding mask is built by a bitwise OR of the desired components. The set of valid mode -constants and each mode’s corresponding mask constant is +constants and each mode's corresponding mask constant is listed below: - ``RTEMS_PREEMPT`` is masked by``RTEMS_PREEMPT_MASK`` and enables preemption @@ -407,7 +407,7 @@ directive to place a task at interrupt level 3 and make it non-preemptible. The mode should be set to``RTEMS_INTERRUPT_LEVEL(3) | RTEMS_NO_PREEMPT`` to indicate the desired preemption mode and interrupt level, while the mask parameter should be set to``RTEMS_INTERRUPT_MASK | -RTEMS_NO_PREEMPT_MASK`` to indicate that the calling task’s +RTEMS_NO_PREEMPT_MASK`` to indicate that the calling task's interrupt level and preemption mode are being altered. Operations @@ -450,20 +450,20 @@ on a task prior to starting it are nullified when the task is started. With the ``rtems_task_start`` -directive the user specifies the task’s +directive the user specifies the task's starting address and argument. The argument is used to communicate some startup information to the task. As part of -this directive, RTEMS initializes the task’s stack based upon -the task’s initial execution mode and start address. The +this directive, RTEMS initializes the task's stack based upon +the task's initial execution mode and start address. The starting argument is passed to the task in accordance with the -target processor’s calling convention. +target processor's calling convention. The ``rtems_task_restart`` directive restarts a task at its initial starting address with its original priority and execution mode, but with a possibly different argument. The new argument may be used to distinguish between the original invocation of the task -and subsequent invocations. The task’s stack and control block +and subsequent invocations. The task's stack and control block are modified to reflect their original creation values. Although references to resources that have been requested are cleared, resources allocated by the task are NOT automatically @@ -519,9 +519,9 @@ Changing Task Priority The ``rtems_task_set_priority`` directive is used to obtain or change the current priority of either the calling task or another task. If -the new priority requested is``RTEMS_CURRENT_PRIORITY`` or the task’s +the new priority requested is``RTEMS_CURRENT_PRIORITY`` or the task's actual priority, then the current priority will be returned and -the task’s priority will remain unchanged. If the task’s +the task's priority will remain unchanged. If the task's priority is altered, then the task will be scheduled according to its new priority. @@ -534,9 +534,9 @@ Changing Task Mode The ``rtems_task_mode`` directive is used to obtain or change the current -execution mode of the calling task. A task’s execution mode is +execution mode of the calling task. A task's execution mode is used to enable preemption, timeslicing, ASR processing, and to -set the task’s interrupt level. +set the task's interrupt level. The ``rtems_task_restart`` directive resets the mode of a task to its @@ -548,9 +548,9 @@ Task Deletion RTEMS provides the ``rtems_task_delete`` directive to allow a task to delete itself or any other task. This directive removes all -RTEMS references to the task, frees the task’s control block, +RTEMS references to the task, frees the task's control block, removes it from resource wait queues, and deallocates its stack -as well as the optional floating point context. The task’s name +as well as the optional floating point context. The task's name and ID become inactive at this time, and any subsequent references to either of them is invalid. In fact, RTEMS may reuse the task ID for another task which is created later in the @@ -589,8 +589,8 @@ an option for some use cases. Directives ========== -This section details the task manager’s directives. A -subsection is dedicated to each of this manager’s directives and +This section details the task 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. @@ -629,7 +629,7 @@ TASK_CREATE - Create a task This directive creates a task which resides on the local node. It allocates and initializes a TCB, a stack, and an optional floating point context area. The mode parameter contains values -which sets the task’s initial execution mode. The``RTEMS_FLOATING_POINT`` attribute should be +which sets the task's initial execution mode. The``RTEMS_FLOATING_POINT`` attribute should be specified if the created task is to use a numeric coprocessor. For performance reasons, it is recommended that tasks not using the numeric coprocessor should @@ -713,7 +713,7 @@ target processor in a processor dependent fashion. Tasks should not be made global unless remote tasks must interact with them. This avoids the system overhead incurred by the creation of a global task. When a global task is created, -the task’s name and id must be transmitted to every node in the +the task's name and id must be transmitted to every node in the system for insertion in the local copy of the global object table. @@ -820,7 +820,7 @@ TASK_START - Start a task This directive readies the task, specified by ``id``, for execution based on the priority and execution mode specified when the task -was created. The starting address of the task is given in``entry_point``. The task’s starting argument is contained in +was created. The starting address of the task is given in``entry_point``. The task's starting argument is contained in argument. This argument can be a single value or used as an index into an array of parameter blocks. The type of this numeric argument is an unsigned integer type with the property that any valid pointer to void can be converted @@ -861,13 +861,13 @@ TASK_RESTART - Restart a task **DESCRIPTION:** This directive resets the task specified by id to begin -execution at its original starting address. The task’s priority +execution at its original starting address. The task's priority and execution mode are set to the original creation values. If the task is currently blocked, RTEMS automatically makes the task ready. A task can be restarted from any state, except the dormant state. -The task’s starting argument is contained in argument. This argument can be a +The task's starting argument is contained in argument. This argument can be a single value or an index into an array of parameter blocks. The type of this numeric argument is an unsigned integer type with the property that any valid pointer to void can be converted to this type and then converted back to a @@ -1086,16 +1086,16 @@ TASK_SET_PRIORITY - Set task priority This directive manipulates the priority of the task specified by id. An id of ``RTEMS_SELF`` is used to indicate the calling task. When new_priority is not equal to``RTEMS_CURRENT_PRIORITY``, the specified -task’s previous priority is returned in old_priority. When +task's previous priority is returned in old_priority. When new_priority is ``RTEMS_CURRENT_PRIORITY``, -the specified task’s current +the specified task's current priority is returned in old_priority. Valid priorities range from a high of 1 to a low of 255. **NOTES:** The calling task may be preempted if its preemption mode is -enabled and it lowers its own priority or raises another task’s +enabled and it lowers its own priority or raises another task's priority. In case the new priority equals the current priority of the task, then nothing @@ -1107,12 +1107,12 @@ change the priority of the specified task. If the task specified by id is currently holding any binary semaphores which use the priority inheritance algorithm, then -the task’s priority cannot be lowered immediately. If the -task’s priority were lowered immediately, then priority -inversion results. The requested lowering of the task’s +the task's priority cannot be lowered immediately. If the +task's priority were lowered immediately, then priority +inversion results. The requested lowering of the task's priority will occur when the task has released all priority -inheritance binary semaphores. The task’s priority can be -increased regardless of the task’s use of priority inheritance +inheritance binary semaphores. The task's priority can be +increased regardless of the task's use of priority inheritance binary semaphores. TASK_MODE - Change the current task mode @@ -1144,7 +1144,7 @@ TASK_MODE - Change the current task mode **DESCRIPTION:** This directive manipulates the execution mode of the calling -task. A task’s execution mode enables and disables preemption, +task. A task's execution mode enables and disables preemption, timeslicing, asynchronous signal processing, as well as specifying the current interrupt level. To modify an execution mode, the mode class(es) to be changed must be specified in the @@ -1167,7 +1167,7 @@ To temporarily disable the processing of a valid ASR, a task should call this directive with the ``RTEMS_NO_ASR`` indicator specified in mode. -The set of task mode constants and each mode’s corresponding +The set of task mode constants and each mode's corresponding mask constant is provided in the following table: - ``RTEMS_PREEMPT`` is masked by``RTEMS_PREEMPT_MASK`` and enables preemption @@ -1327,12 +1327,12 @@ This directive adds the memory location specified by the ptr argument to the context of the given task. The variable will then be private to the task. The task can access and modify the variable, but the modifications will not appear to other tasks, and -other tasks’ modifications to that variable will not affect the value +other tasks' modifications to that variable will not affect the value seen by the task. This is accomplished by saving and restoring the -variable’s value each time a task switch occurs to or from the calling task. -If the dtor argument is non-NULL it specifies the address of a ‘destructor’ +variable's value each time a task switch occurs to or from the calling task. +If the dtor argument is non-NULL it specifies the address of a 'destructor' function which will be called when the task is deleted. The argument -passed to the destructor function is the task’s value of the variable. +passed to the destructor function is the task's value of the variable. **NOTES:** @@ -1342,8 +1342,8 @@ Task variables increase the context switch time to and from the tasks that own them so it is desirable to minimize the number of task variables. One efficient method is to have a single task variable that is a pointer to a dynamically -allocated structure containing the task’s private ‘global’ data. -In this case the destructor function could be ‘free’. +allocated structure containing the task's private 'global' data. +In this case the destructor function could be 'free'. Per-task variables are disabled in SMP configurations and this service is not available. @@ -1420,7 +1420,7 @@ TASK_VARIABLE_DELETE - Remove per task variable **DESCRIPTION:** -This directive removes the given location from a task’s context. +This directive removes the given location from a task's context. **NOTES:** diff --git a/c_user/timer_manager.rst b/c_user/timer_manager.rst index 828cfe2..2d83bf9 100644 --- a/c_user/timer_manager.rst +++ b/c_user/timer_manager.rst @@ -183,16 +183,16 @@ Deleting a Timer The ``rtems_timer_delete`` directive is used to delete a timer. If the timer is running and has not expired, the timer is -automatically canceled. The timer’s control block is returned +automatically canceled. The timer's control block is returned to the TMCB free list when it is deleted. A timer can be deleted by a task other than the task which created the timer. -Any subsequent references to the timer’s name and ID are invalid. +Any subsequent references to the timer's name and ID are invalid. Directives ========== -This section details the timer manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the timer 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. diff --git a/c_user/timespec_helpers.rst b/c_user/timespec_helpers.rst index f7c9802..f8ef9c4 100644 --- a/c_user/timespec_helpers.rst +++ b/c_user/timespec_helpers.rst @@ -9,9 +9,9 @@ instances of the POSIX ``struct timespec`` structure. The directives provided by the timespec helpers manager are: -- ``rtems_timespec_set`` - Set timespec’s value +- ``rtems_timespec_set`` - Set timespec's value -- ``rtems_timespec_zero`` - Zero timespec’s value +- ``rtems_timespec_zero`` - Zero timespec's value - ``rtems_timespec_is_valid`` - Check if timespec is valid @@ -101,8 +101,8 @@ User can also check validity of timespec with``rtems_timespec_is_valid`` routine Directives ========== -This section details the Timespec Helpers manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the Timespec Helpers 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. diff --git a/c_user/user_extensions.rst b/c_user/user_extensions.rst index 1108afd..5b3ccb9 100644 --- a/c_user/user_extensions.rst +++ b/c_user/user_extensions.rst @@ -72,7 +72,7 @@ following structure:.. index:: rtems_extensions_table RTEMS allows the user to have multiple extension sets active at the same time. First, a single static extension set -may be defined as the application’s User Extension Table which +may be defined as the application's User Extension Table which is included as part of the Configuration Table. This extension set is active for the entire life of the system and may not be deleted. This extension set is especially important because it @@ -112,9 +112,9 @@ TCB Extension Area .. index:: TCB extension area RTEMS provides for a pointer to a user-defined data -area for each extension set to be linked to each task’s control +area for each extension set to be linked to each task's control block. This set of pointers is an extension of the TCB and can -be used to store additional data required by the user’s +be used to store additional data required by the user's extension functions. The TCB extension is an array of pointers in the TCB. The @@ -129,7 +129,7 @@ The number of pointers in the area is the same as the number of user extension sets configured. This allows an application to augment the TCB with user-defined information. For example, an application could implement task profiling by storing timing -statistics in the TCB’s extended memory area. When a task +statistics in the TCB's extended memory area. When a task context switch is being executed, the TASK_SWITCH extension could read a real-time clock to calculate how long the task being swapped out has run as well as timestamp the starting time @@ -144,9 +144,9 @@ be reinitialized by the TASK_RESTART extension and should be deallocated by the TASK_DELETE extension when the task is deleted. Since the TCB extension buffers would most likely be of a fixed size, the RTEMS partition manager could be used to -manage the application’s extended memory area. The application +manage the application's extended memory area. The application could create a partition of fixed size TCB extension buffers and -use the partition manager’s allocation and deallocation +use the partition manager's allocation and deallocation directives to obtain and release the extension buffers. Extensions @@ -286,7 +286,7 @@ following:.. index:: rtems_task_switch_extension where current_task can be used to access the TCB for the task that is being swapped out, and heir_task can be used to access the TCB for the task being swapped in. This extension is -invoked from RTEMS’ dispatcher routine after the current_task +invoked from RTEMS' dispatcher routine after the current_task context has been saved, but before the heir_task context has been restored. This extension should not call any RTEMS directives. @@ -360,8 +360,8 @@ where the_error is the error code passed to the fatal_error_occurred directive. This extension is invoked from the fatal_error_occurred directive. -If defined, the user’s FATAL error extension is -invoked before RTEMS’ default fatal error routine is invoked and +If defined, the user's FATAL error extension is +invoked before RTEMS' default fatal error routine is invoked and the processor is stopped. For example, this extension could be used to pass control to a debugger when a fatal error occurs. This extension should not call any RTEMS directives. @@ -410,7 +410,7 @@ error extension will be the last fatal error extension executed. Another example is use of the task delete extension by the Standard C Library. Extension sets which are installed after the Standard C Library will operate correctly even if they -utilize the C Library because the C Library’s TASK_DELETE +utilize the C Library because the C Library's TASK_DELETE extension is invoked after that of the other extensions. Operations @@ -444,17 +444,17 @@ Deleting an Extension Set ------------------------- The ``rtems_extension_delete`` directive is used to delete an -extension set. The extension set’s control block is returned to +extension set. The extension set's control block is returned to the ESCB free list when it is deleted. An extension set can be deleted by a task other than the task which created the -extension set. Any subsequent references to the extension’s +extension set. Any subsequent references to the extension's name and ID are invalid. Directives ========== -This section details the user extension manager’s -directives. A subsection is dedicated to each of this manager’s +This section details the user extension 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. diff --git a/cpu_supplement/atmel_avr.rst b/cpu_supplement/atmel_avr.rst index 98743fb..a075ef1 100644 --- a/cpu_supplement/atmel_avr.rst +++ b/cpu_supplement/atmel_avr.rst @@ -51,7 +51,7 @@ Register Usage -------------- A called function may clobber all registers, except RETS, R4-R7, P3-P5, -FP and SP. It may also modify the first 12 bytes in the callerâs stack +FP and SP. It may also modify the first 12 bytes in the caller's stack frame which is used as an argument area for the first three arguments (which are passed in R0...R3 but may be placed on the stack by the called function). @@ -80,7 +80,7 @@ protection mechanisms are not used. Interrupt Processing ==================== -Discussed in this chapter are the AVR’s interrupt response and +Discussed in this chapter are the AVR's interrupt response and control mechanisms as they pertain to RTEMS. Vectoring of an Interrupt Handler diff --git a/cpu_supplement/blackfin.rst b/cpu_supplement/blackfin.rst index 39f7b4f..5f517e7 100644 --- a/cpu_supplement/blackfin.rst +++ b/cpu_supplement/blackfin.rst @@ -55,7 +55,7 @@ Register Usage -------------- A called function may clobber all registers, except RETS, R4-R7, P3-P5, -FP and SP. It may also modify the first 12 bytes in the callerâs stack +FP and SP. It may also modify the first 12 bytes in the caller's stack frame which is used as an argument area for the first three arguments (which are passed in R0...R3 but may be placed on the stack by the called function). @@ -84,7 +84,7 @@ protection mechanisms are not used. Interrupt Processing ==================== -Discussed in this chapter are the Blackfin’s interrupt response and +Discussed in this chapter are the Blackfin's interrupt response and control mechanisms as they pertain to RTEMS. The Blackfin architecture support 16 kinds of interrupts broken down into Core and general-purpose interrupts. diff --git a/cpu_supplement/index.rst b/cpu_supplement/index.rst index b90e201..070fa21 100644 --- a/cpu_supplement/index.rst +++ b/cpu_supplement/index.rst @@ -2,7 +2,7 @@ RTEMS CPU Architecture Supplement ================================= -COPYRIGHT © 1988 - 2015. +COPYRIGHT (c) 1988 - 2015. On-Line Applications Research Corporation (OAR). diff --git a/cpu_supplement/intel_amd_x86.rst b/cpu_supplement/intel_amd_x86.rst index 59db1cd..1ba9498 100644 --- a/cpu_supplement/intel_amd_x86.rst +++ b/cpu_supplement/intel_amd_x86.rst @@ -9,14 +9,14 @@ than being designed for growth. For information on the i386 processor, refer to the following documents: -- *386 Programmer’s Reference Manual, Intel, Order No. 230985-002*. +- *386 Programmer's Reference Manual, Intel, Order No. 230985-002*. - *386 Microprocessor Hardware Reference Manual, Intel, Order No. 231732-003*. -- *80386 System Software Writer’s Guide, Intel, Order No. 231499-001*. +- *80386 System Software Writer's Guide, Intel, Order No. 231499-001*. -- *80387 Programmer’s Reference Manual, Intel, Order No. 231917-001*. +- *80387 Programmer's Reference Manual, Intel, Order No. 231917-001*. CPU Model Dependent Features ============================ @@ -33,7 +33,7 @@ The macro ``I386_HAS_BSWAP`` is set to 1 to indicate that this CPU model has the ``bswap`` instruction which endian swaps a thirty-two bit quantity. This instruction appears to be present in all CPU models -i486’s and above. +i486's and above. Calling Conventions =================== @@ -128,8 +128,8 @@ Interrupt Processing Although RTEMS hides many of the processor dependent details of interrupt processing, it is important to understand how the RTEMS interrupt manager is mapped onto the -processor’s unique architecture. Discussed in this chapter are -the the processor’s response and control mechanisms as they +processor's unique architecture. Discussed in this chapter are +the the processor's response and control mechanisms as they pertain to RTEMS. Vectoring of Interrupt Handler @@ -175,7 +175,7 @@ Interrupt Levels ---------------- Although RTEMS supports 256 interrupt levels, the -i386 only supports two – enabled and disabled. Interrupts are +i386 only supports two - enabled and disabled. Interrupts are enabled when the interrupt-enable flag (IF) in the extended flags (EFLAGS) is set. Conversely, interrupt processing is inhibited when the IF is cleared. During a non-maskable @@ -225,7 +225,7 @@ System Reset An RTEMS based application is initiated when the i386 processor is reset. When the i386 is reset, -- The EAX register is set to indicate the results of the processor’s +- The EAX register is set to indicate the results of the processor's power-up self test. If the self-test was not executed, the contents of this register are undefined. Otherwise, a non-zero value indicates the processor is faulty and a zero value indicates a successful self-test. @@ -253,7 +253,7 @@ When the i386 is reset, lines are lowered and the processor begins executing in the first megabyte of memory. -Typically, an intersegment JMP to the application’s initialization code is +Typically, an intersegment JMP to the application's initialization code is placed at address 0xFFFFFFF0. Processor Initialization @@ -306,7 +306,7 @@ which is executed before the call to initialize_executive has the following requirements: For more information regarding the i386 data structures and their -contents, refer to Intel’s 386 Programmer’s Reference Manual. +contents, refer to Intel's 386 Programmer's Reference Manual. .. COMMENT: COPYRIGHT (c) 1988-2002. diff --git a/cpu_supplement/lattice_micro32.rst b/cpu_supplement/lattice_micro32.rst index 5947c91..d5dae64 100644 --- a/cpu_supplement/lattice_micro32.rst +++ b/cpu_supplement/lattice_micro32.rst @@ -5,7 +5,7 @@ This chaper discusses the Lattice Mico32 architecture dependencies in this port of RTEMS. The Lattice Mico32 is a 32-bit Harvard, RISC architecture "soft" microprocessor, available for free with an open IP core licensing agreement. Although mainly targeted for Lattice FPGA -devices the microprocessor can be implemented on other vendors’ FPGAs, +devices the microprocessor can be implemented on other vendors' FPGAs, too. **Architecture Documents** @@ -192,7 +192,7 @@ handlers are configured or all of them return without taking action to shutdown the processor or reset, a default fatal error handler is invoked. Most of the action performed as part of processing the fatal error are -described in detail in the Fatal Error Manager chapter in the User’s +described in detail in the Fatal Error Manager chapter in the User's Guide. However, the if no user provided extension or BSP specific fatal error handler takes action, the final default action is to invoke a CPU architecture specific function. Typically this function disables @@ -221,7 +221,7 @@ In each of the architecture specific chapters, this section will present a discussion of architecture specific BSP issues. For more information on developing a BSP, refer to BSP and Device Driver Development Guide and the chapter titled Board Support Packages in the RTEMS -Applications User’s Guide. +Applications User's Guide. System Reset ------------ diff --git a/cpu_supplement/m68xxx_and_coldfire.rst b/cpu_supplement/m68xxx_and_coldfire.rst index 3ac41f9..e5c9f1b 100644 --- a/cpu_supplement/m68xxx_and_coldfire.rst +++ b/cpu_supplement/m68xxx_and_coldfire.rst @@ -17,9 +17,9 @@ For information on the MC68xxx and Coldfire architecture, refer to the following - *M68000 Family Reference, Motorola, FR68K/D*. -- *MC68020 User’s Manual, Motorola, MC68020UM/AD*. +- *MC68020 User's Manual, Motorola, MC68020UM/AD*. -- *MC68881/MC68882 Floating-Point Coprocessor User’s Manual, +- *MC68881/MC68882 Floating-Point Coprocessor User's Manual, Motorola, MC68881UM/AD*. CPU Model Dependent Features @@ -136,7 +136,7 @@ segmentation on any of the MC68xxx family members. Interrupt Processing ==================== -Discussed in this section are the MC68xxx’s interrupt response and +Discussed in this section are the MC68xxx's interrupt response and control mechanisms as they pertain to RTEMS. Vectoring of an Interrupt Handler @@ -182,7 +182,7 @@ interrupt stacks automatically perform the following actions: installed with the interrupt_catch directive, then the RTEMS interrupt handler will begin execution. The RTEMS interrupt handler saves all registers which are not preserved according to - the calling conventions and invokes the application’s ISR. + the calling conventions and invokes the application's ISR. A nested interrupt is processed similarly by these CPU models with the exception that only a single ISF is placed @@ -339,11 +339,11 @@ the following actions: Processor Initialization ------------------------ -The address of the application’s initialization code should be stored in +The address of the application's initialization code should be stored in the first vector of the EVT which will allow the immediate vectoring to the application code. If the application requires that the VBR be some value besides zero, then it should be set to the required value at this -point. All tasks share the same MC68020’s VBR value. Because interrupts +point. All tasks share the same MC68020's VBR value. Because interrupts are enabled automatically by RTEMS as part of the context switch to the first task, the VBR MUST be set by either RTEMS of the BSP before this occurs ensure correct interrupt vectoring. If processor caching is @@ -351,7 +351,7 @@ to be utilized, then it should be enabled during the reset application initialization code. In addition to the requirements described in the -Board Support Packages chapter of the Applications User’s +Board Support Packages chapter of the Applications User's Manual for the reset code which is executed before the call to initialize executive, the MC68020 version has the following specific requirements: @@ -366,7 +366,7 @@ specific requirements: minimum stack size of MINIMUM_STACK_SIZE bytes is provided for the initialize executive directive. -- Must initialize the MC68020’s vector table. +- Must initialize the MC68020's vector table. .. COMMENT: Copyright (c) 2014 embedded brains GmbH. All rights reserved. diff --git a/cpu_supplement/mips.rst b/cpu_supplement/mips.rst index 9db2bd7..b01b116 100644 --- a/cpu_supplement/mips.rst +++ b/cpu_supplement/mips.rst @@ -74,8 +74,8 @@ Interrupt Processing Although RTEMS hides many of the processor dependent details of interrupt processing, it is important to understand -how the RTEMS interrupt manager is mapped onto the processor’s -unique architecture. Discussed in this chapter are the MIPS’s +how the RTEMS interrupt manager is mapped onto the processor's +unique architecture. Discussed in this chapter are the MIPS's interrupt response and control mechanisms as they pertain to RTEMS. diff --git a/cpu_supplement/port.rst b/cpu_supplement/port.rst index c59216e..2a9a3b3 100644 --- a/cpu_supplement/port.rst +++ b/cpu_supplement/port.rst @@ -42,7 +42,7 @@ unit or coprocessor. When defining the list of features present on a particular CPU model, one simply notes that floating point hardware is or is not present and defines a single constant appropriately. Conditional compilation is utilized to include the appropriate source -code for this CPU model’s feature set. It is important to note that +code for this CPU model's feature set. It is important to note that this means that RTEMS is thus compiled using the appropriate feature set and compilation flags optimal for this CPU model used. The alternative would be to generate a binary which would execute on all family members @@ -118,7 +118,7 @@ Calling Conventions =================== Each high-level language compiler generates subroutine entry and exit -code based upon a set of rules known as the compiler’s calling convention. +code based upon a set of rules known as the compiler's calling convention. These rules address the following issues: - register preservation and usage @@ -127,7 +127,7 @@ These rules address the following issues: - call and return mechanism -A compiler’s calling convention is of importance when +A compiler's calling convention is of importance when interfacing to subroutines written in another language either assembly or high-level. Even when the high-level language and target processor are the same, different compilers may use @@ -177,7 +177,7 @@ Memory Model A processor may support any combination of memory models ranging from pure physical addressing to complex demand paged virtual memory systems. RTEMS supports a flat memory -model which ranges contiguously over the processor’s allowable +model which ranges contiguously over the processor's allowable address space. RTEMS does not support segmentation or virtual memory of any kind. The appropriate memory model for RTEMS provided by the targeted processor and related characteristics @@ -219,7 +219,7 @@ processors require that an interrupt handler utilize some special control mechanisms to return to the normal processing stream. Although RTEMS hides many of the processor dependent details of interrupt processing, it is important to understand how the RTEMS interrupt manager is mapped -onto the processor’s unique architecture. +onto the processor's unique architecture. RTEMS supports a dedicated interrupt stack for all architectures. On architectures with hardware support for a dedicated interrupt stack, @@ -243,7 +243,7 @@ to switch to the interrupt stack. In some configurations, RTEMS allocates the interrupt stack from the Workspace Area. The amount of memory allocated for the interrupt stack is user configured and based upon the ``confdefs.h`` parameter``CONFIGURE_INTERRUPT_STACK_SIZE``. This parameter is described -in detail in the Configuring a System chapter of the User’s Guide. +in detail in the Configuring a System chapter of the User's Guide. On configurations in which RTEMS allocates the interrupt stack, during the initialization process, RTEMS will also install its interrupt stack. In other configurations, the interrupt stack is allocated and installed @@ -318,7 +318,7 @@ handlers are configured or all of them return without taking action to shutdown the processor or reset, a default fatal error handler is invoked. Most of the action performed as part of processing the fatal error are -described in detail in the Fatal Error Manager chapter in the User’s +described in detail in the Fatal Error Manager chapter in the User's Guide. However, the if no user provided extension or BSP specific fatal error handler takes action, the final default action is to invoke a CPU architecture specific function. Typically this function disables @@ -414,7 +414,7 @@ In each of the architecture specific chapters, this section will present a discussion of architecture specific BSP issues. For more information on developing a BSP, refer to BSP and Device Driver Development Guide and the chapter titled Board Support Packages in the RTEMS -Applications User’s Guide. +Applications User's Guide. System Reset ------------ diff --git a/cpu_supplement/powerpc.rst b/cpu_supplement/powerpc.rst index 2f65bbb..acfcc61 100644 --- a/cpu_supplement/powerpc.rst +++ b/cpu_supplement/powerpc.rst @@ -20,27 +20,27 @@ the following documents available from Motorola and IBM: - *PowerPC Microprocessor Family: The Programming Environment* (Motorola Document MPRPPCFPE-01). -- *IBM PPC403GB Embedded Controller User’s Manual*. +- *IBM PPC403GB Embedded Controller User's Manual*. - *PoweRisControl MPC500 Family RCPU RISC Central Processing Unit Reference Manual* (Motorola Document RCPUURM/AD). -- *PowerPC 601 RISC Microprocessor User’s Manual* +- *PowerPC 601 RISC Microprocessor User's Manual* (Motorola Document MPR601UM/AD). -- *PowerPC 603 RISC Microprocessor User’s Manual* +- *PowerPC 603 RISC Microprocessor User's Manual* (Motorola Document MPR603UM/AD). -- *PowerPC 603e RISC Microprocessor User’s Manual* +- *PowerPC 603e RISC Microprocessor User's Manual* (Motorola Document MPR603EUM/AD). -- *PowerPC 604 RISC Microprocessor User’s Manual* +- *PowerPC 604 RISC Microprocessor User's Manual* (Motorola Document MPR604UM/AD). -- *PowerPC MPC821 Portable Systems Microprocessor User’s Manual* +- *PowerPC MPC821 Portable Systems Microprocessor User's Manual* (Motorola Document MPC821UM/AD). -- *PowerQUICC MPC860 User’s Manual* (Motorola Document MPC860UM/AD). +- *PowerQUICC MPC860 User's Manual* (Motorola Document MPC860UM/AD). Motorola maintains an on-line electronic library for the PowerPC at the following URL: @@ -75,7 +75,7 @@ model specified on the compilation command line. Alignment --------- -The macro PPC_ALIGNMENT is set to the PowerPC model’s worst case alignment +The macro PPC_ALIGNMENT is set to the PowerPC model's worst case alignment requirement for data types on a byte boundary. This value is used to derive the alignment restrictions for memory allocated from regions and partitions. @@ -411,8 +411,8 @@ Interrupt Processing Although RTEMS hides many of the processor dependent details of interrupt processing, it is important to understand -how the RTEMS interrupt manager is mapped onto the processor’s -unique architecture. Discussed in this chapter are the PowerPC’s +how the RTEMS interrupt manager is mapped onto the processor's +unique architecture. Discussed in this chapter are the PowerPC's interrupt response and control mechanisms as they pertain to RTEMS. @@ -468,10 +468,10 @@ interrupt handler, then upon receipt of the interrupt, the processor passes control to the RTEMS interrupt handler which performs the following actions: -- saves the state of the interrupted task on it’s stack, +- saves the state of the interrupted task on it's stack, - saves all registers which are not normally preserved - by the calling sequence so the user’s interrupt service + by the calling sequence so the user's interrupt service routine can be written in a high-level language. - if this is the outermost (i.e. non-nested) interrupt, @@ -560,7 +560,7 @@ An RTEMS based application is initiated or re-initiated when the PowerPC processor is reset. The PowerPC architecture defines a Reset Exception, but leaves the details of the CPU state as implementation specific. Please -refer to the User’s Manual for the CPU model in question. +refer to the User's Manual for the CPU model in question. In general, at power-up the PowerPC begin execution at address 0xFFF00100 in supervisor mode with all exceptions disabled. For @@ -579,7 +579,7 @@ observed to prevent some emulators from working properly, so it may be necessary to run with caching disabled to use these emulators. In addition to the requirements described in the*Board Support Packages* chapter of the RTEMS C -Applications User’s Manual for the reset code +Applications User's Manual for the reset code which is executed before the call to ``rtems_initialize_executive``, the PowrePC version has the following specific requirements: @@ -596,7 +596,7 @@ the PowrePC version has the following specific requirements: - Must enable traps so window overflow and underflow conditions can be properly handled. -- Must initialize the PowerPC’s initial Exception Table with default +- Must initialize the PowerPC's initial Exception Table with default handlers. .. COMMENT: COPYRIGHT (c) 1988-2002. diff --git a/cpu_supplement/sparc.rst b/cpu_supplement/sparc.rst index a69beb2..9a0c15b 100644 --- a/cpu_supplement/sparc.rst +++ b/cpu_supplement/sparc.rst @@ -33,7 +33,7 @@ the following documents available from SPARC International, Inc. **ERC32 Specific Information** -The European Space Agency’s ERC32 is a three chip +The European Space Agency's ERC32 is a three chip computing core implementing a SPARC V7 processor and associated support circuitry for embedded space applications. The integer and floating-point units (90C601E & 90C602E) are based on the @@ -56,7 +56,7 @@ browser at ftp://ftp.estec.esa.nl/pub/ws/wsd/erc32. - MEC Device Specification -Additionally, the SPARC RISC User’s Guide from Matra +Additionally, the SPARC RISC User's Guide from Matra MHS documents the functionality of the integer and floating point units including the instruction set information. To obtain this document as well as ERC32 components and VHDL models @@ -112,7 +112,7 @@ features present on a particular CPU model, one simply notes that floating point hardware is or is not present and defines a single constant appropriately. Conditional compilation is utilized to include the appropriate source code for this CPU -model’s feature set. It is important to note that this means +model's feature set. It is important to note that this means that RTEMS is thus compiled using the appropriate feature set and compilation flags optimal for this CPU model used. The alternative would be to generate a binary which would execute on @@ -130,7 +130,7 @@ CPU Model Name The macro CPU_MODEL_NAME is a string which designates the name of this CPU model. For example, for the European Space -Agency’s ERC32 SPARC model, this macro is set to the string +Agency's ERC32 SPARC model, this macro is set to the string "erc32". Floating Point Unit @@ -385,7 +385,7 @@ registers windows. Because the set of register windows is finite, it is possible to execute enough save instructions without -corresponding restore’s to consume all of the register windows. +corresponding restore's to consume all of the register windows. This is easily accomplished in a high level language because each subroutine typically performs a save instruction upon entry. Thus having a subroutine call depth greater than the @@ -396,7 +396,7 @@ is responsible for saving the contents of the oldest register window on the program stack. Similarly, the subroutines will eventually complete -and begin to perform restore’s. If the restore results in the +and begin to perform restore's. If the restore results in the need for a register window which has previously been written to memory as part of an overflow, then a window underflow condition results. Just like the window overflow, the window underflow @@ -458,7 +458,7 @@ Call and Return Mechanism The SPARC architecture supports a simple yet effective call and return mechanism. A subroutine is invoked via the call (call) instruction. This instruction places the -return address in the caller’s output register 7 (o7). After +return address in the caller's output register 7 (o7). After the callee executes a save instruction, this value is available in input register 7 (i7) until the corresponding restore instruction is executed. @@ -466,7 +466,7 @@ instruction is executed. The callee returns to the caller via a jmp to the return address. There is a delay slot following this instruction which is commonly used to execute a restore -instruction – if a register window was allocated by this +instruction - if a register window was allocated by this subroutine. It is important to note that the SPARC subroutine @@ -500,7 +500,7 @@ Parameter Passing ----------------- RTEMS assumes that arguments are placed in the -caller’s output registers with the first argument in output +caller's output registers with the first argument in output register 0 (o0), the second argument in output register 1 (o1), and so forth. Until the callee executes a save instruction, the parameters are still visible in the output registers. After the @@ -534,7 +534,7 @@ Memory Model A processor may support any combination of memory models ranging from pure physical addressing to complex demand paged virtual memory systems. RTEMS supports a flat memory -model which ranges contiguously over the processor’s allowable +model which ranges contiguously over the processor's allowable address space. RTEMS does not support segmentation or virtual memory of any kind. The appropriate memory model for RTEMS provided by the targeted processor and related characteristics @@ -601,8 +601,8 @@ Most processors require that an interrupt handler utilize some special control mechanisms to return to the normal processing stream. Although RTEMS hides many of the processor dependent details of interrupt processing, it is important to understand -how the RTEMS interrupt manager is mapped onto the processor’s -unique architecture. Discussed in this chapter are the SPARC’s +how the RTEMS interrupt manager is mapped onto the processor's +unique architecture. Discussed in this chapter are the SPARC's interrupt response and control mechanisms as they pertain to RTEMS. @@ -676,7 +676,7 @@ interrupt handler, then upon receipt of the interrupt, the processor passes control to the RTEMS interrupt handler which performs the following actions: -- saves the state of the interrupted task on it’s stack, +- saves the state of the interrupted task on it's stack, - insures that a register window is available for subsequent traps, @@ -713,7 +713,7 @@ trap cannot be correctly processed unless (1) traps are enabled and (2) a register window is reserved for traps. Thus, the RTEMS interrupt handler insures that a register window is available for subsequent traps before enabling traps and -invoking the user’s interrupt handler. +invoking the user's interrupt handler. Interrupt Levels ---------------- @@ -792,7 +792,7 @@ execute on the stack of the RTEMS task which they interrupted. This artificially inflates the stack requirements for each task since EVERY task stack would have to include enough space to account for the worst case interrupt stack requirements in -addition to it’s own worst case usage. RTEMS addresses this +addition to it's own worst case usage. RTEMS addresses this problem on the SPARC by providing a dedicated interrupt stack managed by software. @@ -864,7 +864,7 @@ to support a particular processor and target board combination. This chapter presents a discussion of SPARC specific BSP issues. For more information on developing a BSP, refer to the chapter titled Board Support Packages in the RTEMS -Applications User’s Guide. +Applications User's Guide. System Reset ------------ @@ -891,14 +891,14 @@ reflect the last trap which occurred before the reset. Processor Initialization ------------------------ -It is the responsibility of the application’s +It is the responsibility of the application's initialization code to initialize the TBR and install trap handlers for at least the register window overflow and register window underflow conditions. Traps should be enabled before invoking any subroutines to allow for register window management. However, interrupts should be disabled by setting the Processor Interrupt Level (pil) field of the psr to 15. -RTEMS installs it’s own Trap Table as part of initialization +RTEMS installs it's own Trap Table as part of initialization which is initialized with the contents of the Trap Table in place when the ``rtems_initialize_executive`` directive was invoked. Upon completion of executive initialization, interrupts are @@ -926,7 +926,7 @@ specific requirements: - Must enable traps so window overflow and underflow conditions can be properly handled. -- Must initialize the SPARC’s initial trap table with at +- Must initialize the SPARC's initial trap table with at least trap handlers for register window overflow and register window underflow. diff --git a/cpu_supplement/sparc64.rst b/cpu_supplement/sparc64.rst index a4325de..ad568cb 100644 --- a/cpu_supplement/sparc64.rst +++ b/cpu_supplement/sparc64.rst @@ -16,7 +16,7 @@ through UltraSPARC IV processors. The following documents were used in developing the SPARC-64 sun4u port: -- UltraSPARC Userâs Manual +- UltraSPARC User's Manual (http://www.sun.com/microelectronics/manuals/ultrasparc/802-7220-02.pdf) - UltraSPARC IIIi Processor (datasheets.chipdb.org/Sun/UltraSparc-IIIi.pdf) @@ -104,7 +104,7 @@ Calling Conventions Each high-level language compiler generates subroutine entry and exit code based upon a set of rules known -as the compiler’s calling convention. These rules address the +as the compiler's calling convention. These rules address the following issues: - register preservation and usage @@ -113,7 +113,7 @@ following issues: - call and return mechanism -A compiler’s calling convention is of importance when +A compiler's calling convention is of importance when interfacing to subroutines written in another language either assembly or high-level. Even when the high-level language and target processor are the same, different compilers may use @@ -222,7 +222,7 @@ The SPARC architecture includes a number of special registers: *``Processor State Register (pstate)``* The privileged pstate register contains control fields for the proces- - sorâs current state. Its flag fields include the interrupt enable, privi- + sor's current state. Its flag fields include the interrupt enable, privi- leged mode, and enable FPU. *``Processor Interrupt Level (pil)``* @@ -270,7 +270,7 @@ registers are shared between adjacent registers windows. Because the set of register windows is finite, it is possible to execute enough save instructions without -corresponding restore’s to consume all of the register windows. +corresponding restore's to consume all of the register windows. This is easily accomplished in a high level language because each subroutine typically performs a save instruction upon entry. Thus having a subroutine call depth greater than the @@ -281,7 +281,7 @@ is responsible for saving the contents of the oldest register window on the program stack. Similarly, the subroutines will eventually complete -and begin to perform restore’s. If the restore results in the +and begin to perform restore's. If the restore results in the need for a register window which has previously been written to memory as part of an overflow, then a window underflow condition results. Just like the window overflow, the window underflow @@ -338,7 +338,7 @@ Call and Return Mechanism The SPARC architecture supports a simple yet effective call and return mechanism. A subroutine is invoked via the call (call) instruction. This instruction places the -return address in the caller’s output register 7 (o7). After +return address in the caller's output register 7 (o7). After the callee executes a save instruction, this value is available in input register 7 (i7) until the corresponding restore instruction is executed. @@ -346,7 +346,7 @@ instruction is executed. The callee returns to the caller via a jmp to the return address. There is a delay slot following this instruction which is commonly used to execute a restore -instruction – if a register window was allocated by this +instruction - if a register window was allocated by this subroutine. It is important to note that the SPARC subroutine @@ -354,7 +354,7 @@ call and return mechanism does not automatically save and restore any registers. This is accomplished via the save and restore instructions which manage the set of registers windows. This allows for the compiler to generate leaf-optimized functions -that utilize the callerâs output registers without using save and restore. +that utilize the caller's output registers without using save and restore. Calling Mechanism ----------------- @@ -376,7 +376,7 @@ Parameter Passing ----------------- RTEMS assumes that arguments are placed in the -caller’s output registers with the first argument in output +caller's output registers with the first argument in output register 0 (o0), the second argument in output register 1 (o1), and so forth. Until the callee executes a save instruction, the parameters are still visible in the output registers. After the @@ -410,7 +410,7 @@ Memory Model A processor may support any combination of memory models ranging from pure physical addressing to complex demand paged virtual memory systems. RTEMS supports a flat memory -model which ranges contiguously over the processor’s allowable +model which ranges contiguously over the processor's allowable address space. RTEMS does not support segmentation or virtual memory of any kind. The appropriate memory model for RTEMS provided by the targeted processor and related characteristics @@ -542,7 +542,7 @@ interrupt handler, then upon receipt of the interrupt, the processor passes control to the RTEMS interrupt handler which performs the following actions: -- saves the state of the interrupted task on it’s stack, +- saves the state of the interrupted task on it's stack, - switches the processor to trap level 0, @@ -597,7 +597,7 @@ execute on the stack of the RTEMS task which they interrupted. This artificially inflates the stack requirements for each task since EVERY task stack would have to include enough space to account for the worst case interrupt stack requirements in -addition to it’s own worst case usage. RTEMS addresses this +addition to it's own worst case usage. RTEMS addresses this problem on the SPARC by providing a dedicated interrupt stack managed by software. @@ -661,7 +661,7 @@ to support a particular processor and target board combination. This chapter presents a discussion of SPARC specific BSP issues. For more information on developing a BSP, refer to the chapter titled Board Support Packages in the RTEMS -Applications User’s Guide. +Applications User's Guide. HelenOS and Open Firmware ------------------------- diff --git a/cpu_supplement/superh.rst b/cpu_supplement/superh.rst index 9d62dba..abede7f 100644 --- a/cpu_supplement/superh.rst +++ b/cpu_supplement/superh.rst @@ -84,8 +84,8 @@ Interrupt Processing Although RTEMS hides many of the processor dependent details of interrupt processing, it is important to understand -how the RTEMS interrupt manager is mapped onto the processor’s -unique architecture. Discussed in this chapter are the MIPS’s +how the RTEMS interrupt manager is mapped onto the processor's +unique architecture. Discussed in this chapter are the MIPS's interrupt response and control mechanisms as they pertain to RTEMS. diff --git a/develenv/directory.rst b/develenv/directory.rst index 0c30724..12b62c1 100644 --- a/develenv/directory.rst +++ b/develenv/directory.rst @@ -103,7 +103,7 @@ as ``${RTEMS_ROOT}`` in this discussion. be discussed further in this document. ``${RTEMS_ROOT}/cpukit/`` - This directory is the root for all of the "multilib’able" + This directory is the root for all of the "multilib'able" portions of RTEMS. This is a GNU way of saying the contents of this directory can be compiled like the C Library (``libc.a``) and the functionality is @@ -123,7 +123,7 @@ as ``${RTEMS_ROOT}`` in this discussion. ``${RTEMS_ROOT}/make/`` This directory contains files which support the - RTEMS Makefile’s. From a user’s perspective, the + RTEMS Makefile's. From a user's perspective, the most important parts are found in the ``custom/`` subdirectory. Each ".cfg" file in this directory is associated with a specific BSP and describes @@ -232,7 +232,7 @@ directory and a description of each. ``${RTEMS_ROOT}/c/src/nfsclient/`` This directory contains a Network File System (NFS) client - for RTEMS. With this file system, a user’s application can + for RTEMS. With this file system, a user's application can access files on a remote computer. ``${RTEMS_ROOT}/c/src/optman/`` @@ -554,10 +554,10 @@ and PostScript. ``${RTEMS_ROOT}/doc/ada_user/`` This directory contains the source code for the *RTEMS - Applications Ada User’s Guide* which documents the Ada95 + Applications Ada User's Guide* which documents the Ada95 binding to the Classic API. This manual is produced from from the same source base as the *RTEMS Application - C User’s Guide*. + C User's Guide*. ``${RTEMS_ROOT}/doc/bsp_howto/`` This directory contains the source code for the*RTEMS BSP and Device Driver Development Guide*. @@ -605,8 +605,8 @@ and PostScript. This directory contains the source code for the*RTEMS POSIX 1003.1 Compliance Guide*. ``${RTEMS_ROOT}/doc/posix_users/`` - This directory contains the source code for the*RTEMS POSIX API User’s Guide*. It is important to - note that RTEMS’ support for POSIX is a combination of + This directory contains the source code for the*RTEMS POSIX API User's Guide*. It is important to + note that RTEMS' support for POSIX is a combination of functionality provided by RTEMS and the Newlib C Library so some functionality is documented by Newlib. @@ -628,7 +628,7 @@ and PostScript. ``${RTEMS_ROOT}/doc/user/`` This directory contains the source code for the *RTEMS - Applications C User’s Guide* which documents the Classic API. + Applications C User's Guide* which documents the Classic API. .. COMMENT: COPYRIGHT (c) 1989-2007. diff --git a/develenv/index.rst b/develenv/index.rst index f1d4992..0e9cb59 100644 --- a/develenv/index.rst +++ b/develenv/index.rst @@ -2,7 +2,7 @@ RTEMS Development Environment Guide =================================== -COPYRIGHT © 1988 - 2015. +COPYRIGHT (c) 1988 - 2015. On-Line Applications Research Corporation (OAR). diff --git a/develenv/sample.rst b/develenv/sample.rst index fa35f6a..2531408 100644 --- a/develenv/sample.rst +++ b/develenv/sample.rst @@ -129,7 +129,7 @@ The following messages are printed: Hello World \*** END OF HELLO WORLD TEST \*** -These messages are printed from the application’s +These messages are printed from the application's single initialization task. If the above messages are not printed correctly, then either the BSP start up code or the console output routine is not operating properly. @@ -199,7 +199,7 @@ when using the Ada version to output the following messages: \*** END OF SAMPLE SINGLE PROCESSOR APPLICATION \*** The first two messages are printed from the -application’s single initialization task. The final messages +application's single initialization task. The final messages are printed from the single application task. Base Multiple Processor Application @@ -233,7 +233,7 @@ The second node will print the following messages: This task has the id of 0x20002 \*** END OF SAMPLE MULTIPROCESSOR APPLICATION \*** -The herald is printed from the application’s single +The herald is printed from the application's single initialization task on each node. The final messages are printed from the single application task on each node. diff --git a/develenv/utilities.rst b/develenv/utilities.rst index 76652a6..8bd52f4 100644 --- a/develenv/utilities.rst +++ b/develenv/utilities.rst @@ -116,7 +116,7 @@ smaller than download.sr. The source for packhex first appeared in the May 1993 issue of Embedded Systems magazine. The code was downloaded -from their BBS. Unfortunately, the author’s name was not +from their BBS. Unfortunately, the author's name was not provided in the listing. .. COMMENT: unhex @@ -133,7 +133,7 @@ unhex - Convert Hexadecimal File into Binary Equivalent **DESCRIPTION** unhex accepts Intel Hexadecimal, Motorola Srecord, or -TI ’B’ records and converts them to their binary equivalent. +TI 'B' records and converts them to their binary equivalent. The output may sent to standout or may be placed in a specified file with the -o option. The designated output file may not be an input file. Multiple input files may be specified with their diff --git a/filesystem/call_development.rst b/filesystem/call_development.rst index aafdf52..e8cd53b 100644 --- a/filesystem/call_development.rst +++ b/filesystem/call_development.rst @@ -1,10 +1,10 @@ System Call Development Notes ############################# -This set of routines represents the application’s interface to files and directories +This set of routines represents the application's interface to files and directories under the RTEMS filesystem. All routines are compliant with POSIX standards if a specific interface has been established. The list below represents the routines that have -been included as part of the application’s interface. +been included as part of the application's interface. # access() @@ -267,7 +267,7 @@ structure to make it an invalid file descriptor. Apparently the memory that is about to be freed may still be referenced before it is reallocated. -The dd_buf structure’s memory is reallocated before the control structure +The dd_buf structure's memory is reallocated before the control structure that contains the pointer to the dd_buf region. DIR control memory is reallocated. @@ -629,9 +629,9 @@ rtems_filesystem_is_separator. If it does the search starts from the root of the RTEMS filesystem; otherwise the search will start from the current directory. -The OPS table evalformake() function for the parent’s filesystem is used +The OPS table evalformake() function for the parent's filesystem is used to locate the node that will be the parent of the new link. It will also -locate the start of the new path’s name. This name will be used to define +locate the start of the new path's name. This name will be used to define a child under the parent directory. If the parent is found, the routine will determine if the hard link that diff --git a/filesystem/fileystem_implmentation.rst b/filesystem/fileystem_implmentation.rst index 817a09b..e1face6 100644 --- a/filesystem/fileystem_implmentation.rst +++ b/filesystem/fileystem_implmentation.rst @@ -78,7 +78,7 @@ The following POSIX constraints must be honored by all filesystems. system cannot be removed. - On filesystems supporting hard links, a link count is maintained. - Prior to node removal, the node’s link count is decremented by one. The + Prior to node removal, the node's link count is decremented by one. The link count must be less than one to allow for removal of the node. API Layering @@ -168,7 +168,7 @@ provided to the application: # write() -The filesystem’s type as well as the node type within the filesystem +The filesystem's type as well as the node type within the filesystem determine the nature of the processing that must be performed for each of the functions above. The RTEMS filesystem provides a framework that allows new filesystem to be developed and integrated without alteration @@ -634,7 +634,7 @@ const char \*dev The is intended to contain a string that identifies the device that contains the filesystem information. The filesystems that are currently implemented -are memory based and don’t require a device specification. +are memory based and don't require a device specification. If the mt_point_node.node_access is NULL then we are mounting the base file system. @@ -645,7 +645,7 @@ system. The node will have read, write and execute permissions for owner, group and others. -The node’s name will be a null string. +The node's name will be a null string. A filesystem information structure(fs_info) will be allocated and initialized for the IMFS filesystem. The fs_info pointer in the mount table @@ -759,7 +759,7 @@ File Handler Table Functions Handler table functions are defined in a ``rtems_filesystem_file_handlers_r`` structure. It defines functions that are specific to a node type in a given -filesystem. One table exists for each of the filesystem’s node types. The +filesystem. One table exists for each of the filesystem's node types. The structure definition appears below. It is followed by general developmental information on each of the functions associated with regular files contained in this function management structure. diff --git a/filesystem/in-memory.rst b/filesystem/in-memory.rst index b3dfb3d..59da32b 100644 --- a/filesystem/in-memory.rst +++ b/filesystem/in-memory.rst @@ -56,10 +56,10 @@ explanation of their role in the filesystem. is a unique node identification number *st_uid* - is the user ID of the file’s owner + is the user ID of the file's owner *st_gid* - is the group ID of the file’s owner + is the group ID of the file's owner *st_atime* is the time of the last access to this file @@ -499,7 +499,7 @@ filesystem for the system that contains the mount point. It will determine if the point that we are trying to mount onto is a node of IMFS_DIRECTORY type. -If it is the node’s info element is altered so that the info.directory.mt_fs +If it is the node's info element is altered so that the info.directory.mt_fs element points to the mount table chain entry that is associated with the mounted filesystem at this point. The info.directory.mt_fs element can be examined to determine if a filesystem is mounted at a directory. If it is @@ -602,7 +602,7 @@ const char \*dev The is intended to contain a string that identifies the device that contains the filesystem information. The filesystems that are currently implemented -are memory based and don’t require a device specification. +are memory based and don't require a device specification. If the mt_point_node.node_access is NULL then we are mounting the base file system. @@ -613,7 +613,7 @@ system. The node will have read, write and execute permissions for owner, group and others. -The node’s name will be a null string. +The node's name will be a null string. A filesystem information structure(fs_info) will be allocated and initialized for the IMFS filesystem. The fs_info pointer in the mount table @@ -658,7 +658,7 @@ This routine allows the IMFS to unmount a filesystem that has been mounted onto a IMFS directory. The mount entry mount point node access is verified to be a mounted -directory. It’s mt_fs is set to NULL. This identifies to future +directory. It's mt_fs is set to NULL. This identifies to future calles into the IMFS that this directory node is no longer a mount point. Additionally, it will allow any directories that were hidden by the mounted system to again become visible. @@ -741,7 +741,7 @@ Regular File Handler Table Functions Handler table functions are defined in a rtems_filesystem_file_handlers_r structure. It defines functions that are specific to a node type in a given -filesystem. One table exists for each of the filesystem’s node types. The +filesystem. One table exists for each of the filesystem's node types. The structure definition appears below. It is followed by general developmental information on each of the functions associated with regular files contained in this function management structure. @@ -1114,7 +1114,7 @@ Directory Handler Table Functions Handler table functions are defined in a rtems_filesystem_file_handlers_r structure. It defines functions that are specific to a node type in a given -filesystem. One table exists for each of the filesystem’s node types. The +filesystem. One table exists for each of the filesystem's node types. The structure definition appears below. It is followed by general developmental information on each of the functions associated with directories contained in this function management structure. @@ -1467,7 +1467,7 @@ Device Handler Table Functions Handler table functions are defined in a rtems_filesystem_file_handlers_r structure. It defines functions that are specific to a node type in a given -filesystem. One table exists for each of the filesystem’s node types. The +filesystem. One table exists for each of the filesystem's node types. The structure definition appears below. It is followed by general developmental information on each of the functions associated with devices contained in this function management structure. diff --git a/filesystem/index.rst b/filesystem/index.rst index aaead0a..1d781c9 100644 --- a/filesystem/index.rst +++ b/filesystem/index.rst @@ -2,7 +2,7 @@ RTEMS Filesystem Design Guide ============================= -COPYRIGHT © 1988 - 2015. +COPYRIGHT (c) 1988 - 2015. On-Line Applications Research Corporation (OAR). diff --git a/filesystem/pathname_eval.rst b/filesystem/pathname_eval.rst index a9ed6c4..de4d18f 100644 --- a/filesystem/pathname_eval.rst +++ b/filesystem/pathname_eval.rst @@ -66,8 +66,8 @@ parsed. *node_access* This element is filesystem specific. A filesystem can define and store any information necessary to identify a node at this location. This element - is normally filled in by the filesystem’s evaluate routine. For the - filesystem’s root node, the filesystem’s initilization routine should + is normally filled in by the filesystem's evaluate routine. For the + filesystem's root node, the filesystem's initilization routine should fill this in, and it should remain valid until the instance of the filesystem is unmounted. diff --git a/filesystem/system_init.rst b/filesystem/system_init.rst index 751bf34..ad8d656 100644 --- a/filesystem/system_init.rst +++ b/filesystem/system_init.rst @@ -1,16 +1,16 @@ System Initialization ##################### -After the RTEMS initialization is performed, the application’s +After the RTEMS initialization is performed, the application's initialization will be performed. Part of initialization is a call to -rtems_filesystem_initialize(). This routine will mount the ‘In Memory File -System’ as the base filesystem. Mounting the base filesystem consists +rtems_filesystem_initialize(). This routine will mount the 'In Memory File +System' as the base filesystem. Mounting the base filesystem consists of the following: - Initialization of mount table chain control structure - Allocation of a ``jnode`` structure that will server as the root node - of the ‘In Memory Filesystem’ + of the 'In Memory Filesystem' - Initialization of the allocated ``jnode`` with the appropriate OPS, directory handlers and pathconf limits and options. @@ -36,7 +36,7 @@ Base Filesystem RTEMS initially mounts a RAM based file system known as the base file system. The root directory of this file system tree serves as the logical root of the -directory hierarchy (Figure 3). Under the root directory a ‘/dev’ directory +directory hierarchy (Figure 3). Under the root directory a '/dev' directory is created under which all I/O device directories and files are registered as part of the file system hierarchy. .. code:: c @@ -61,8 +61,8 @@ required to manage the future file systems. Base Filesystem Mounting ------------------------ -At present, the first file system to be mounted is the ‘In Memory File -System’. It is mounted using a standard MOUNT() command in which the mount +At present, the first file system to be mounted is the 'In Memory File +System'. It is mounted using a standard MOUNT() command in which the mount point is NULL. This flags the mount as the first file system to be registered under the operating system and appropriate initialization of file system management information is performed (See figures 4 and 5). If a @@ -81,7 +81,7 @@ system (See ioman.c) a device registration process is performed. Device registration produces a unique dev_t handle that consists of a major and minor device number. In addition, the configuration information for each device contains a text string that represents the fully qualified pathname to -that device’s place in the base file system’s hierarchy. A file system node +that device's place in the base file system's hierarchy. A file system node is created for the device along the specified registration path. .. code:: c diff --git a/networking/dec_21140.rst b/networking/dec_21140.rst index 8cc041c..9064508 100644 --- a/networking/dec_21140.rst +++ b/networking/dec_21140.rst @@ -46,7 +46,7 @@ DEC21140 PCI Board Generalities This chapter describes rapidely the PCI interface of this Ethernet controller. The board we have chosen for our PC386 implementation is a D-Link DFE-500TX. This is a dual-speed 10/100Mbps Ethernet PCI adapter with a DEC21140AF chip. -Like other PCI devices, this board has a PCI device’s header containing some +Like other PCI devices, this board has a PCI device's header containing some required configuration registers, as shown in the PCI Register Figure. By reading or writing these registers, a driver can obtain information about the type of @@ -132,7 +132,7 @@ Receiver Thread --------------- This thread is event driven. Each time a DEC PCI board interrupt occurs, the -handler checks if this is a receive interrupt and send an event “reception” +handler checks if this is a receive interrupt and send an event "reception" to the receiver thread which looks into the entire buffer descriptors ring the ones that contain a valid incoming frame (bit OWN=0 means descriptor belongs to host processor). Each valid incoming ethernet frame is sent to the protocol diff --git a/networking/index.rst b/networking/index.rst index 0489422..db3b64c 100644 --- a/networking/index.rst +++ b/networking/index.rst @@ -1,7 +1,7 @@ ======================== RTEMS Network Supplement ======================== -COPYRIGHT © 1988 - 2015. +COPYRIGHT (c) 1988 - 2015. On-Line Applications Research Corporation (OAR). diff --git a/networking/network_servers.rst b/networking/network_servers.rst index be8a033..cf3ec71 100644 --- a/networking/network_servers.rst +++ b/networking/network_servers.rst @@ -6,7 +6,7 @@ RTEMS FTP Daemon The RTEMS FTPD is a complete file transfer protocol (FTP) daemon which can store, retrieve, and manipulate files on the local -filesystem. In addition, the RTEMS FTPD provides “hooks” +filesystem. In addition, the RTEMS FTPD provides "hooks" which are actions performed on received data. Hooks are useful in situations where a destination file is not necessarily appropriate or in cases when a formal device driver has not yet diff --git a/networking/network_task_structure.rst b/networking/network_task_structure.rst index 78609dd..7e1b269 100644 --- a/networking/network_task_structure.rst +++ b/networking/network_task_structure.rst @@ -23,7 +23,7 @@ The network task processes incoming packets and takes care of timed operations such as handling TCP timeouts and aging and removing routing table entries. -The ‘Network code’ contains routines which may run in the context of +The 'Network code' contains routines which may run in the context of the user application tasks, the interface receive task or the network task. A network semaphore ensures that the data structures manipulated by the network code remain consistent. diff --git a/networking/networking_driver.rst b/networking/networking_driver.rst index 0f7238b..7be9dde 100644 --- a/networking/networking_driver.rst +++ b/networking/networking_driver.rst @@ -6,7 +6,7 @@ Introduction This chapter is intended to provide an introduction to the procedure for writing RTEMS network device drivers. -The example code is taken from the ‘Generic 68360’ network device +The example code is taken from the 'Generic 68360' network device driver. The source code for this driver is located in the``c/src/lib/libbsp/m68k/gen68360/network`` directory in the RTEMS source code distribution. Having a copy of this driver at hand when reading the following notes will help significantly. @@ -15,7 +15,7 @@ Learn about the network device ============================== Before starting to write the network driver become completely -familiar with the programmer’s view of the device. +familiar with the programmer's view of the device. The following points list some of the details of the device that must be understood before a driver can be written. @@ -70,7 +70,7 @@ data structures and resources. To ensure the consistency of these structures the tasks execute only when they hold the network semaphore (``rtems_bsdnet_semaphore``). The transmit and receive tasks must abide by this protocol. Be very -careful to avoid ‘deadly embraces’ with the other network tasks. +careful to avoid 'deadly embraces' with the other network tasks. A number of routines are provided to make it easier for the network driver code to conform to the network task scheduling conventions. @@ -160,9 +160,9 @@ in the device-dependent data structure supplied and maintained by the driver: ``ifp->if_unit`` The device number. The network stack uses this number and the - device name for device name lookups. For example, if``ifp->if_name`` is ‘``scc``’ and ``ifp->if_unit`` is ‘``1``’, - the full device name would be ‘``scc1``’. The unit number should be - obtained from the ‘name’ entry in the configuration structure. + device name for device name lookups. For example, if``ifp->if_name`` is '``scc``' and ``ifp->if_unit`` is '``1``', + the full device name would be '``scc1``'. The unit number should be + obtained from the 'name' entry in the configuration structure. ``ifp->if_mtu`` The maximum transmission unit for the device. For Ethernet @@ -211,7 +211,7 @@ Once the attach function has set up the above entries it must link the driver data structure onto the list of devices by calling ``if_attach``. Ethernet devices should then call ``ether_ifattach``. Both functions take a pointer to the -device’s ``ifnet`` structure as their only argument. +device's ``ifnet`` structure as their only argument. The attach function should return a non-zero value to indicate that the driver has been successfully configured and attached. @@ -221,8 +221,8 @@ Write the Driver Start Function. This function is called each time the network stack wants to start the transmitter. This occures whenever the network stack adds a packet -to a device’s send queue and the ``IFF_OACTIVE`` bit in the -device’s ``if_flags`` is not set. +to a device's send queue and the ``IFF_OACTIVE`` bit in the +device's ``if_flags`` is not set. For many devices this function need only set the ``IFF_OACTIVE`` bit in the``if_flags`` and send an event to the transmit task indicating that a packet is in the driver transmit queue. diff --git a/networking/preface.rst b/networking/preface.rst index 40be9c9..9c1649c 100644 --- a/networking/preface.rst +++ b/networking/preface.rst @@ -11,7 +11,7 @@ who also ported the FreeBSD TCP/IP stack to RTEMS. The following is a list of resources which should be useful in trying to understand Ethernet: -- *Charles Spurgeon’s Ethernet Web Site* +- *Charles Spurgeon's Ethernet Web Site* "This site provides extensive information about Ethernet (IEEE 802.3) local area network (LAN) technology. Including the original 10 Megabit per second (Mbps) system, the 100 Mbps diff --git a/networking/testing_the_driver.rst b/networking/testing_the_driver.rst index d71747f..9a064e7 100644 --- a/networking/testing_the_driver.rst +++ b/networking/testing_the_driver.rst @@ -11,7 +11,7 @@ The network used to test the driver should include at least: the operation of the target machine. - An Ethernet network analyzer or a workstation with an - ‘Ethernet snoop’ program such as ``ethersnoop`` or``tcpdump``. + 'Ethernet snoop' program such as ``ethersnoop`` or``tcpdump``. - A workstation. @@ -39,7 +39,7 @@ is a list of them: - mbuf activity There are commented out calls to ``printf`` in the file``sys/mbuf.h`` in the network stack code. Uncommenting - these lines results in output when mbuf’s are allocated + these lines results in output when mbuf's are allocated and freed. This is very useful for finding memory leaks. - TX and RX queuing @@ -91,29 +91,29 @@ is a list of them: URL: (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-routing.html) For a quick reference to the flags, see the table below: - ‘``U``’ + '``U``' Up: The route is active. - ‘``H``’ + '``H``' Host: The route destination is a single host. - ‘``G``’ + '``G``' Gateway: Send anything for this destination on to this remote system, which will figure out from there where to send it. - ‘``S``’ + '``S``' Static: This route was configured manually, not automatically generated by the system. - ‘``C``’ + '``C``' Clone: Generates a new route based upon this route for machines we connect to. This type of route is normally used for local networks. - ‘``W``’ + '``W``' WasCloned: Indicated a route that was auto-configured based upon a local area network (Clone) route. - ‘``L``’ + '``L``' Link: Route involves references to Ethernet hardware. - ``mbuf`` @@ -182,29 +182,29 @@ The network demonstration program ``netdemo`` may be used for these tests. broadcast packets disabled: Verify that the program continues to run once the driver has been attached. -- Issue a ‘``u``’ command to send UDP - packets to the ‘discard’ port. +- Issue a '``u``' command to send UDP + packets to the 'discard' port. Verify that the packets appear on the network. -- Issue a ‘``s``’ command to print the network and driver statistics. +- Issue a '``s``' command to print the network and driver statistics. - On a workstation, add a static route to the target system. -- On that same workstation try to ‘ping’ the target system. +- On that same workstation try to 'ping' the target system. Verify that the ICMP echo request and reply packets appear on the net. - Remove the static route to the target system. Modify ``networkconfig.h`` to attach the driver with reception of broadcast packets enabled. - Try to ‘ping’ the target system again. + Try to 'ping' the target system again. Verify that ARP request/reply and ICMP echo request/reply packets appear on the net. -- Issue a ‘``t``’ command to send TCP - packets to the ‘discard’ port. +- Issue a '``t``' command to send TCP + packets to the 'discard' port. Verify that the packets appear on the network. -- Issue a ‘``s``’ command to print the network and driver statistics. +- Issue a '``s``' command to print the network and driver statistics. - Verify that you can telnet to ports 24742 and 24743 on the target system from one or more @@ -232,7 +232,7 @@ Giant packets - Recompile the driver with ``MAXIMUM_FRAME_SIZE`` set to a smaller value, say 514. -- ‘Ping’ the driver from another workstation and verify +- 'Ping' the driver from another workstation and verify that frames larger than 514 bytes are correctly rejected. - Recompile the driver with ``MAXIMUM_FRAME_SIZE`` restored to 1518. @@ -248,8 +248,8 @@ Resource Exhaustion - Verify that the program operates properly and that you can still telnet to both the ports. -- Display the driver statistics (Console ‘``s``’ command or telnet - ‘control-G’ character) and verify that: +- Display the driver statistics (Console '``s``' command or telnet + 'control-G' character) and verify that: # The number of transmit interrupts is non-zero. This indicates that all transmit descriptors have been in use at some time. @@ -262,7 +262,7 @@ Cable Faults - Run the ``netdemo`` program. -- Issue a ‘``u``’ console command to make the target machine transmit +- Issue a '``u``' console command to make the target machine transmit a bunch of UDP packets. - While the packets are being transmitted, disconnect and reconnect the @@ -277,7 +277,7 @@ Throughput ---------- Run the ``ttcp`` network benchmark program. -Transfer large amounts of data (100’s of megabytes) to and from the target +Transfer large amounts of data (100's of megabytes) to and from the target system. The procedure for testing throughput from a host to an RTEMS target diff --git a/networking/using_networking_rtems_app.rst b/networking/using_networking_rtems_app.rst index 0778385..bd6f9f5 100644 --- a/networking/using_networking_rtems_app.rst +++ b/networking/using_networking_rtems_app.rst @@ -126,7 +126,7 @@ below, you need to provide only the first two entries in this structure. You can also use ``rtems_bsdnet_do_bootp_rootfs`` to have a set of standard files created with the information return by the BOOTP/DHCP protocol. The IP address is added to :file:`/etc/hosts` with the host - name and domain returned. If no host name or domain is returned``me.mydomain`` is used. The BOOTP/DHCP server’s address is also + name and domain returned. If no host name or domain is returned``me.mydomain`` is used. The BOOTP/DHCP server's address is also added to :file:`/etc/hosts`. The domain name server listed in the BOOTP/DHCP information are added to :file:`/etc/resolv.conf`. A``search`` record is also added if a domain is returned. The files are created if they do not exist. @@ -162,7 +162,7 @@ below, you need to provide only the first two entries in this structure. ``char \*gateway`` The Internet host number of the network gateway machine, - specified in ’dotted decimal’ (``129.128.4.1``) form. + specified in 'dotted decimal' (``129.128.4.1``) form. ``char \*log_host`` The Internet host number of the machine to which ``syslog`` messages @@ -279,13 +279,13 @@ structure. ``char \*ip_address`` The Internet address of the device, - specified in ‘dotted decimal’ (``129.128.4.2``) form, or ``NULL`` + specified in 'dotted decimal' (``129.128.4.2``) form, or ``NULL`` if the device configuration information is being obtained from a BOOTP/DHCP server. ``char \*ip_netmask`` The Internet inetwork mask of the device, - specified in ‘dotted decimal’ (``255.255.255.0``) form, or ``NULL`` + specified in 'dotted decimal' (``255.255.255.0``) form, or ``NULL`` if the device configuration information is being obtained from a BOOTP/DHCP server. @@ -496,8 +496,8 @@ you when more data has arrived. (Condition 1.a.) For sending, when the socket is connected and the free space becomes at or above the "low water mark" for the send buffer (default 4096 bytes) -you will receive a writable callback. You don’t get continuous callbacks -if you don’t write anything. Using a non-blocking write socket, you can +you will receive a writable callback. You don't get continuous callbacks +if you don't write anything. Using a non-blocking write socket, you can then call write until it returns a value less than the amount of data requested to be sent or it produces error EWOULDBLOCK (indicating buffer full and no longer writable). When this happens you can @@ -837,13 +837,13 @@ returns. The priority argument is ignored. If the interval argument is greater than 0, the routine also starts an RTEMS task at the specified priority and polls the NTP server every -‘interval’ seconds. NOTE: This mode of operation has not yet been +'interval' seconds. NOTE: This mode of operation has not yet been implemented. On successful synchronization of the RTEMS time-of-day clock the routine returns 0. If an error occurs a message is printed and the routine returns -1 with an error code in errno. -There is no timeout – if there is no response from an NTP server the +There is no timeout - if there is no response from an NTP server the routine will wait forever. .. COMMENT: Written by Eric Norum diff --git a/porting/code_tuning.rst b/porting/code_tuning.rst index 8090cab..e28bdd7 100644 --- a/porting/code_tuning.rst +++ b/porting/code_tuning.rst @@ -87,7 +87,7 @@ Data Alignment Requirements Data Element Alignment ---------------------- -The CPU_ALIGNMENT macro should be set to the CPU’s worst alignment +The CPU_ALIGNMENT macro should be set to the CPU's worst alignment requirement for data types on a byte boundary. This is typically the alignment requirement for a C double. This alignment does not take into account the requirements for the stack. diff --git a/porting/cpu_init.rst b/porting/cpu_init.rst index 0406c35..f880cab 100644 --- a/porting/cpu_init.rst +++ b/porting/cpu_init.rst @@ -38,7 +38,7 @@ During the initialization of the context for tasks with floating point, the CPU dependent code is responsible for initializing the floating point context. If there is not an easy way to initialize the FP context during Context_Initialize, then it is usually easier to save an "uninitialized" -FP context here and copy it to the task’s during Context_Initialize. If +FP context here and copy it to the task's during Context_Initialize. If this technique is used to initialize the FP contexts, then it is important to ensure that the state of the floating point unit is in a coherent, initialized state. diff --git a/porting/cpu_model_variations.rst b/porting/cpu_model_variations.rst index 797a009..851df1f 100644 --- a/porting/cpu_model_variations.rst +++ b/porting/cpu_model_variations.rst @@ -105,8 +105,8 @@ processor families is not enough to address the needs of embedded systems developers. Custom board development is the norm for embedded systems. Each of these boards is optimized for a particular project. The processor and peripheral set have been chosen to meet a particular set of system -requirements. The tools in the embedded systems developers toolbox must -support their projects unique board. RTEMS addresses this issue via the +requirements. The tools in the embedded systems developers toolbox must +support their project's unique board. RTEMS addresses this issue via the Board Support Package. RTEMS segregates board specific code to make it possible for the embedded diff --git a/porting/idle_thread.rst b/porting/idle_thread.rst index 18ac5ce..7bba283 100644 --- a/porting/idle_thread.rst +++ b/porting/idle_thread.rst @@ -86,7 +86,7 @@ self" which is implemented in a routine as follows. } If the CPU dependent IDLE thread body is implementation centers upon using -a "halt", "idle", or "shutdown" instruction, then don’t forget to put it +a "halt", "idle", or "shutdown" instruction, then don't forget to put it in an infinite loop as the CPU will have to reexecute this instruction each time the IDLE thread is dispatched. .. code:: c diff --git a/porting/index.rst b/porting/index.rst index 982d2a6..346a463 100644 --- a/porting/index.rst +++ b/porting/index.rst @@ -1,7 +1,7 @@ =================== RTEMS Porting Guide =================== -COPYRIGHT © 1988 - 2015. +COPYRIGHT (c) 1988 - 2015. On-Line Applications Research Corporation (OAR). diff --git a/porting/interrupts.rst b/porting/interrupts.rst index d6958ab..8a69e1a 100644 --- a/porting/interrupts.rst +++ b/porting/interrupts.rst @@ -305,7 +305,7 @@ The ``_ISR_Handler`` routine provides the RTEMS interrupt management. This discussion ignores a lot of the ugly details in a real implementation such as saving enough registers/state to be able to do something real. -Keep in mind that the goal is to invoke a user’s ISR handler which is +Keep in mind that the goal is to invoke a user's ISR handler which is written in C. That ISR handler uses a known set of registers thus allowing the ISR to preserve only those that would normally be corrupted by a subroutine call. @@ -368,7 +368,7 @@ specific wrapper for ``_Thread_Dispatch`` used in this case. ISR Invoked with Frame Pointer ------------------------------ -Does the RTEMS invoke the user’s ISR with the vector number and a pointer +Does the RTEMS invoke the user's ISR with the vector number and a pointer to the saved interrupt frame (1) or just the vector number (0)? .. code:: c diff --git a/porting/miscellanous.rst b/porting/miscellanous.rst index 9bbd712..01073f7 100644 --- a/porting/miscellanous.rst +++ b/porting/miscellanous.rst @@ -5,7 +5,7 @@ Fatal Error Default Handler =========================== The ``_CPU_Fatal_halt`` routine is the default fatal error handler. This -routine copies _error into a known place – typically a stack location or +routine copies _error into a known place - typically a stack location or a register, optionally disables interrupts, and halts/stops the CPU. It is prototyped as follows and is often implemented as a macro: .. code:: c @@ -100,8 +100,8 @@ single instruction (e.g. i486). It is probably best to avoid an "endian swapping control bit" in the CPU. One good reason is that interrupts would probably have to be disabled to insure that an interrupt does not try to access the same "chunk" with the wrong endian. Another good reason -is that on some CPUs, the endian bit endianness for ALL fetches – both -code and data – so the code will be fetched incorrectly. +is that on some CPUs, the endian bit endianness for ALL fetches - both +code and data - so the code will be fetched incorrectly. The following is an implementation of the ``CPU_swap_u32`` routine that will work on any CPU. It operates by breaking the unsigned thirty-two bit @@ -142,8 +142,8 @@ single instruction (e.g. i486). It is probably best to avoid an "endian swapping control bit" in the CPU. One good reason is that interrupts would probably have to be disabled to insure that an interrupt does not try to access the same "chunk" with the wrong endian. Another good reason -is that on some CPUs, the endian bit endianness for ALL fetches – both -code and data – so the code will be fetched incorrectly. +is that on some CPUs, the endian bit endianness for ALL fetches - both +code and data - so the code will be fetched incorrectly. Similarly, here is a portable implementation of the ``CPU_swap_u16`` routine. Just as with the ``CPU_swap_u32`` routine, the porter diff --git a/porting/priority_bitmap.rst b/porting/priority_bitmap.rst index 36c294b..7b24451 100644 --- a/porting/priority_bitmap.rst +++ b/porting/priority_bitmap.rst @@ -85,8 +85,8 @@ major/minor) is the first bit found. This entire "find first bit" and mapping process depends heavily on the manner in which a priority is broken into a major and minor components with the major being the 4 MSB of a priority and minor the 4 LSB. Thus (0 -<< 4) + 0 corresponds to priority 0 – the highest priority. And (15 << -4) + 14 corresponds to priority 254 – the next to the lowest priority. +<< 4) + 0 corresponds to priority 0 - the highest priority. And (15 << +4) + 14 corresponds to priority 254 - the next to the lowest priority. If your CPU does not have a "find first bit" instruction, then there are ways to make do without it. Here are a handful of ways to implement this @@ -94,7 +94,7 @@ in software: - a series of 16 bit test instructions -- a "binary search using if’s" +- a "binary search using if's" - the following algorithm based upon a 16 entry lookup table. In this pseudo-code, bit_set_table[16] has values which indicate the first bit set: diff --git a/porting/task_context.rst b/porting/task_context.rst index 62626ed..ec2d1e0 100644 --- a/porting/task_context.rst +++ b/porting/task_context.rst @@ -200,15 +200,15 @@ and ``_CPU_Context_switch`` will return to its caller. Care should be exercise when writing this routine. All registers assumed to be preserved across subroutine calls must be preserved. These registers may be saved in -the task’s context area or on its stack. However, the +the task's context area or on its stack. However, the stack pointer and address to resume executing the task at must be included in the context (normally the subroutine return address to the caller of ``_Thread_Dispatch``. -The decision of where to store the task’s context is based +The decision of where to store the task's context is based on numerous factors including the capabilities of the CPU architecture itself and simplicity as well as external considerations such as debuggers wishing -to examine a task’s context. In this case, it is +to examine a task's context. In this case, it is often simpler to save all data in the context area. Also there may be special considerations @@ -292,7 +292,7 @@ is varying) macro is set based on the CPU family dependent macro. The macro name THIS_CPU_FAMILY_HAS_FPU should be made CPU specific. It indicates whether or not this CPU model has FP support. For example, the definition of the i386ex and i386sx CPU models would set I386_HAS_FPU to -FALSE to indicate that these CPU models are i386’s without an i387 and +FALSE to indicate that these CPU models are i386's without an i387 and wish to leave floating point support out of RTEMS when built for the i386_nofp processor model. On a CPU with a built-in FPU like the i486, this would be defined as TRUE. @@ -399,7 +399,7 @@ point context is dumped by a "FP save context" type instruction and the format is either not completely defined by the CPU documentation or the format is not critical for the implementation of the floating point context switch routines. In this case, there is no need to figure out the -exact format – only the size. Of course, although this is enough +exact format - only the size. Of course, although this is enough information for RTEMS, it is probably not enough for a debugger such as gdb. But that is another problem. .. code:: c @@ -416,7 +416,7 @@ Size of Floating Point Context Macro The CPU_CONTEXT_FP_SIZE macro is set to the size of the floating point context area. On some CPUs this will not be a "sizeof" because the format -of the floating point area is not defined – only the size is. This is +of the floating point area is not defined - only the size is. This is usually on CPUs with a "floating point save context" instruction. In general, though it is easier to define the structure as a "sizeof" operation and define the Context_Control_fp structure to be an area of diff --git a/posix1003_1/files_and_directories.rst b/posix1003_1/files_and_directories.rst index e3edd7c..d311def 100644 --- a/posix1003_1/files_and_directories.rst +++ b/posix1003_1/files_and_directories.rst @@ -243,7 +243,7 @@ Get Configurable Pathname Variables NOTE: The newlib unistd.h and sys/unistd.h are installed and the include search patch is used to get the right one. There are -conflicts between the newlib unistd.h and RTEMS’ version. +conflicts between the newlib unistd.h and RTEMS' version. .. COMMENT: COPYRIGHT (c) 1988-2002. diff --git a/posix1003_1/index.rst b/posix1003_1/index.rst index 2b1da05..fbd160b 100644 --- a/posix1003_1/index.rst +++ b/posix1003_1/index.rst @@ -2,7 +2,7 @@ RTEMS POSIX 1003.1 Compliance Guide =================================== -COPYRIGHT © 1988 - 2015. +COPYRIGHT (c) 1988 - 2015. On-Line Applications Research Corporation (OAR). diff --git a/posix1003_1/language_specific_services.rst b/posix1003_1/language_specific_services.rst index 79772af..554aec7 100644 --- a/posix1003_1/language_specific_services.rst +++ b/posix1003_1/language_specific_services.rst @@ -4,12 +4,12 @@ Language-Specific Services for the C Programming Language Referenced C Language Routines ============================== -ANSI C Section 4.2 — Diagnostics +ANSI C Section 4.2 - Diagnostics .. code:: c assert(), Function, Implemented -ANSI C Section 4.3 — Character Handling +ANSI C Section 4.3 - Character Handling .. code:: c isalnum(), Function, Implemented @@ -26,12 +26,12 @@ ANSI C Section 4.3 — Character Handling tolower(), Function, Implemented toupper(), Function, Implemented -ANSI C Section 4.4 — Localization +ANSI C Section 4.4 - Localization .. code:: c setlocale(), Function, Implemented -ANSI C Section 4.5 — Mathematics +ANSI C Section 4.5 - Mathematics .. code:: c acos(), Function, Implemented @@ -57,13 +57,13 @@ ANSI C Section 4.5 — Mathematics floor(), Function, Implemented fmod(), Function, Implemented -ANSI C Section 4.6 — Non-Local Jumps +ANSI C Section 4.6 - Non-Local Jumps .. code:: c setjmp(), Function, Implemented longjmp(), Function, Implemented -ANSI C Section 4.9 — Input/Output +ANSI C Section 4.9 - Input/Output .. code:: c FILE, Type, Implemented @@ -105,7 +105,7 @@ ANSI C Section 4.9 — Input/Output NOTE: ``rename`` is also included in another section. `Rename a File`_. -ANSI C Section 4.10 — General Utilities +ANSI C Section 4.10 - General Utilities .. code:: c abs(), Function, Implemented @@ -125,7 +125,7 @@ ANSI C Section 4.10 — General Utilities NOTE: ``getenv`` is also included in another section. `Environment Access`_. -ANSI C Section 4.11 — String Handling +ANSI C Section 4.11 - String Handling .. code:: c strcpy(), Function, Implemented @@ -143,7 +143,7 @@ ANSI C Section 4.11 — String Handling strtok(), Function, Implemented strlen(), Function, Implemented -ANSI C Section 4.12 — Date and Time Handling +ANSI C Section 4.12 - Date and Time Handling .. code:: c asctime(), Function, Implemented diff --git a/posix1003_1/posix1003_1.rst b/posix1003_1/posix1003_1.rst index b9bc495..7fb9b21 100644 --- a/posix1003_1/posix1003_1.rst +++ b/posix1003_1/posix1003_1.rst @@ -58,7 +58,7 @@ RTEMS POSIX 1003.1 Compliance Guide .. COMMENT: can force the copyright description onto a left hand page. -COPYRIGHT © 1988 - 2015. +COPYRIGHT (c) 1988 - 2015. On-Line Applications Research Corporation (OAR). @@ -293,7 +293,7 @@ C Language Limits ULONG_MAX, Constant, Implemented USHRT_MAX, Constant, Implemented -NOTE: These are implemented in GCC’s limits.h file. +NOTE: These are implemented in GCC's limits.h file. Minimum Values -------------- @@ -1138,7 +1138,7 @@ Get Configurable Pathname Variables NOTE: The newlib unistd.h and sys/unistd.h are installed and the include search patch is used to get the right one. There are -conflicts between the newlib unistd.h and RTEMS’ version. +conflicts between the newlib unistd.h and RTEMS' version. .. COMMENT: COPYRIGHT (c) 1988-2002. @@ -1580,12 +1580,12 @@ Language-Specific Services for the C Programming Language Referenced C Language Routines ============================== -ANSI C Section 4.2 — Diagnostics +ANSI C Section 4.2 - Diagnostics .. code:: c assert(), Function, Implemented -ANSI C Section 4.3 — Character Handling +ANSI C Section 4.3 - Character Handling .. code:: c isalnum(), Function, Implemented @@ -1602,12 +1602,12 @@ ANSI C Section 4.3 — Character Handling tolower(), Function, Implemented toupper(), Function, Implemented -ANSI C Section 4.4 — Localization +ANSI C Section 4.4 - Localization .. code:: c setlocale(), Function, Implemented -ANSI C Section 4.5 — Mathematics +ANSI C Section 4.5 - Mathematics .. code:: c acos(), Function, Implemented @@ -1633,13 +1633,13 @@ ANSI C Section 4.5 — Mathematics floor(), Function, Implemented fmod(), Function, Implemented -ANSI C Section 4.6 — Non-Local Jumps +ANSI C Section 4.6 - Non-Local Jumps .. code:: c setjmp(), Function, Implemented longjmp(), Function, Implemented -ANSI C Section 4.9 — Input/Output +ANSI C Section 4.9 - Input/Output .. code:: c FILE, Type, Implemented @@ -1681,7 +1681,7 @@ ANSI C Section 4.9 — Input/Output NOTE: ``rename`` is also included in another section. `Rename a File`_. -ANSI C Section 4.10 — General Utilities +ANSI C Section 4.10 - General Utilities .. code:: c abs(), Function, Implemented @@ -1701,7 +1701,7 @@ ANSI C Section 4.10 — General Utilities NOTE: ``getenv`` is also included in another section. `Environment Access`_. -ANSI C Section 4.11 — String Handling +ANSI C Section 4.11 - String Handling .. code:: c strcpy(), Function, Implemented @@ -1719,7 +1719,7 @@ ANSI C Section 4.11 — String Handling strtok(), Function, Implemented strlen(), Function, Implemented -ANSI C Section 4.12 — Date and Time Handling +ANSI C Section 4.12 - Date and Time Handling .. code:: c asctime(), Function, Implemented diff --git a/posix1003_1/terminology.rst b/posix1003_1/terminology.rst index 86d4d47..adf780a 100644 --- a/posix1003_1/terminology.rst +++ b/posix1003_1/terminology.rst @@ -131,7 +131,7 @@ C Language Limits ULONG_MAX, Constant, Implemented USHRT_MAX, Constant, Implemented -NOTE: These are implemented in GCC’s limits.h file. +NOTE: These are implemented in GCC's limits.h file. Minimum Values -------------- diff --git a/posix_users/clock.rst b/posix_users/clock.rst index f37c1b9..fe6aec3 100644 --- a/posix_users/clock.rst +++ b/posix_users/clock.rst @@ -41,8 +41,8 @@ There is currently no text in this section. Directives ========== -This section details the clock manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the clock 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. diff --git a/posix_users/condition_variable.rst b/posix_users/condition_variable.rst index 35bd3ad..d940e33 100644 --- a/posix_users/condition_variable.rst +++ b/posix_users/condition_variable.rst @@ -41,8 +41,8 @@ There is currently no text in this section. Directives ========== -This section details the condition variable manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the condition variable 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. diff --git a/posix_users/device_and_class_specific.rst b/posix_users/device_and_class_specific.rst index b2dda8c..0c344d2 100644 --- a/posix_users/device_and_class_specific.rst +++ b/posix_users/device_and_class_specific.rst @@ -46,8 +46,8 @@ There is currently no text in this section. Directives ========== -This section details the device- and class- specific functions manager’s -directives. A subsection is dedicated to each of this manager’s directives +This section details the device- and class- specific functions 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. diff --git a/posix_users/files_and_directory.rst b/posix_users/files_and_directory.rst index ea39ba3..7ebb8b4 100644 --- a/posix_users/files_and_directory.rst +++ b/posix_users/files_and_directory.rst @@ -103,8 +103,8 @@ There is currently no text in this section. Directives ========== -This section details the files and directories manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the files and directories 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. @@ -342,7 +342,7 @@ On error, this routine returns -1 and sets ``errno`` to one of the following: *EACCES* - Search permission is denied for a directory in a file’s path prefix. + Search permission is denied for a directory in a file's path prefix. *ENAMETOOLONG* Length of a filename string exceeds PATH_MAX and _POSIX_NO_TRUNC is @@ -388,7 +388,7 @@ On error, this routine returns -1 and sets ``errno`` to one of the following: *EACCES* - Search permission is denied for a directory in a file’s path prefix. + Search permission is denied for a directory in a file's path prefix. *ENAMETOOLONG* Length of a filename string exceeds PATH_MAX and _POSIX_NO_TRUNC is @@ -435,7 +435,7 @@ getcwd - Gets current working directory Result is too large *EACCES* - Search permission is denied for a directory in a file’s path prefix. + Search permission is denied for a directory in a file's path prefix. **DESCRIPTION:** @@ -475,7 +475,7 @@ open - Opens a file **STATUS CODES:** *EACCES* - Search permission is denied for a directory in a file’s path prefix. + Search permission is denied for a directory in a file's path prefix. *EEXIST* The named file already exists. @@ -695,7 +695,7 @@ link - Creates a link to a file **STATUS CODES:** *EACCES* - Search permission is denied for a directory in a file’s path prefix + Search permission is denied for a directory in a file's path prefix *EEXIST* The named file already exists. @@ -760,7 +760,7 @@ symlink - Creates a symbolic link to a file **STATUS CODES:** *EACCES* - Search permission is denied for a directory in a file’s path prefix + Search permission is denied for a directory in a file's path prefix *EEXIST* The named file already exists. @@ -818,7 +818,7 @@ readlink - Obtain the name of a symbolic link destination **STATUS CODES:** *EACCES* - Search permission is denied for a directory in a file’s path prefix + Search permission is denied for a directory in a file's path prefix *ENAMETOOLONG* Length of a filename string exceeds PATH_MAX and _POSIX_NO_TRUNC is in @@ -870,7 +870,7 @@ mkdir - Makes a directory **STATUS CODES:** *EACCES* - Search permission is denied for a directory in a file’s path prefix + Search permission is denied for a directory in a file's path prefix *EEXIST* The name file already exist. @@ -928,7 +928,7 @@ mkfifo - Makes a FIFO special file **STATUS CODES:** *EACCES* - Search permission is denied for a directory in a file’s path prefix + Search permission is denied for a directory in a file's path prefix *EEXIST* The named file already exists. @@ -973,7 +973,7 @@ unlink - Removes a directory entry **STATUS CODES:** *EACCES* - Search permission is denied for a directory in a file’s path prefix + Search permission is denied for a directory in a file's path prefix *EBUSY* The directory is in use. @@ -1032,11 +1032,11 @@ rmdir - Delete a directory *EACCES* Write access to the directory containing ``pathname`` was not - allowed for the process’s effective uid, or one of the directories in``pathname`` did not allow search (execute) permission. + allowed for the process's effective uid, or one of the directories in``pathname`` did not allow search (execute) permission. *EPERM* The directory containing ``pathname`` has the stickybit (S_ISVTX) - set and the process’s effective uid is neither the uid of the file to + set and the process's effective uid is neither the uid of the file to be delected nor that of the director containing it. *ENAMETOOLONG* @@ -1096,7 +1096,7 @@ rename - Renames a file **STATUS CODES:** *EACCES* - Search permission is denied for a directory in a file’s path prefix. + Search permission is denied for a directory in a file's path prefix. *EBUSY* The directory is in use. @@ -1174,7 +1174,7 @@ stat - Gets information about a file **STATUS CODES:** *EACCES* - Search permission is denied for a directory in a file’s path prefix. + Search permission is denied for a directory in a file's path prefix. *EBADF* Invalid file descriptor. @@ -1343,7 +1343,7 @@ chmod - Changes file mode. **STATUS CODES:** *EACCES* - Search permission is denied for a directory in a file’s path prefix + Search permission is denied for a directory in a file's path prefix *ENAMETOOLONG* Length of a filename string exceeds PATH_MAX and _POSIX_NO_TRUNC is in @@ -1393,7 +1393,7 @@ fchmod - Changes permissions of a file **STATUS CODES:** *EACCES* - Search permission is denied for a directory in a file’s path prefix. + Search permission is denied for a directory in a file's path prefix. *EBADF* The descriptor is not valid. @@ -1464,7 +1464,7 @@ and ``errno`` is set appropriately. Invalid file descriptor ``fd``. *EFAULT* - Argument points outside the calling process’s address space. + Argument points outside the calling process's address space. *EINVAL* Result buffer is too small. @@ -1505,7 +1505,7 @@ chown - Changes the owner and/or group of a file. **STATUS CODES:** *EACCES* - Search permission is denied for a directory in a file’s path prefix + Search permission is denied for a directory in a file's path prefix *EINVAL* Invalid argument @@ -1634,7 +1634,7 @@ ftruncate - truncate a file to a specified length An I/O error occurred updating the inode. *EFAULT* - ``Path`` points outside the process’s allocated address space. + ``Path`` points outside the process's allocated address space. *EBADF* The ``fd`` is not a valid descriptor. @@ -1702,7 +1702,7 @@ truncate - truncate a file to a specified length An I/O error occurred updating the inode. *EFAULT* - ``Path`` points outside the process’s allocated address space. + ``Path`` points outside the process's allocated address space. *EBADF* The ``fd`` is not a valid descriptor. @@ -1919,7 +1919,7 @@ named pipe) named ``pathname``, specified by ``mode`` and ``dev``. It should be a combination (using bitwise OR) of one of the file types listed below and the permissions for the new node. -The permissions are modified by the process’s ``umask`` in the usual way: the +The permissions are modified by the process's ``umask`` in the usual way: the permissions of the created node are ``(mode & ~umask)``. The file type should be one of ``S_IFREG``, ``S_IFCHR``, ``S_IFBLK`` and``S_IFIFO`` to specify a normal file (which will be created empty), character diff --git a/posix_users/index.rst b/posix_users/index.rst index d375aaf..c75c6f7 100644 --- a/posix_users/index.rst +++ b/posix_users/index.rst @@ -1,8 +1,8 @@ ============================ -RTEMS POSIX API User’s Guide +RTEMS POSIX API User's Guide ============================ -COPYRIGHT © 1988 - 2015. +COPYRIGHT (c) 1988 - 2015. On-Line Applications Research Corporation (OAR). diff --git a/posix_users/input_and_output.rst b/posix_users/input_and_output.rst index 8acb053..4ecd4bc 100644 --- a/posix_users/input_and_output.rst +++ b/posix_users/input_and_output.rst @@ -67,8 +67,8 @@ There is currently no text in this section. Directives ========== -This section details the input and output primitives manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the input and output primitives 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. @@ -359,7 +359,7 @@ fcntl - Manipulates an open file descriptor **STATUS CODES:** *EACCESS* - Search permission is denied for a direcotry in a file’s path + Search permission is denied for a direcotry in a file's path prefix. *EAGAIN* @@ -409,10 +409,10 @@ fcntl - Manipulates an open file descriptor significant bit is used). *F_GETFL* - Read the descriptor’s flags (all flags (as set by open()) are returned). + Read the descriptor's flags (all flags (as set by open()) are returned). *F_SETFL* - Set the descriptor’s flags to the value specified by ``arg``. Only``O_APPEND`` and ``O_NONBLOCK`` may be set. + Set the descriptor's flags to the value specified by ``arg``. Only``O_APPEND`` and ``O_NONBLOCK`` may be set. The flags are shared between copies (made with ``dup()`` etc.) of the same file descriptor. The flags and their semantics are described in ``open()``. diff --git a/posix_users/key.rst b/posix_users/key.rst index 1ce6c2a..71b04c7 100644 --- a/posix_users/key.rst +++ b/posix_users/key.rst @@ -30,8 +30,8 @@ There is currently no text in this section. Directives ========== -This section details the key manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the key 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. diff --git a/posix_users/language_specific_services.rst b/posix_users/language_specific_services.rst index be8c276..5c08933 100644 --- a/posix_users/language_specific_services.rst +++ b/posix_users/language_specific_services.rst @@ -64,8 +64,8 @@ There is currently no text in this section. Directives ========== -This section details the language-specific services for the C programming language manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the language-specific services for the C programming language 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. diff --git a/posix_users/memory_managment.rst b/posix_users/memory_managment.rst index 05bb99d..1095b39 100644 --- a/posix_users/memory_managment.rst +++ b/posix_users/memory_managment.rst @@ -42,8 +42,8 @@ There is currently no text in this section. Directives ========== -This section details the memory management manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the memory management 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. diff --git a/posix_users/message_passing.rst b/posix_users/message_passing.rst index 6192587..2900ac6 100644 --- a/posix_users/message_passing.rst +++ b/posix_users/message_passing.rst @@ -103,7 +103,7 @@ Notification of a Message on the Queue -------------------------------------- Every message queue has the ability to notify one (and only one) process -whenever the queue’s state changes from empty (0 messages) to nonempty. +whenever the queue's state changes from empty (0 messages) to nonempty. This means that the process does not have to block or constantly poll while it waits for a message. By calling mq_notify, you can attach a notification request to a message queue. When a message is received by an @@ -194,7 +194,7 @@ Receiving a Message from a Message Queue The mq_receive() function is used to receive the oldest of the highest priority message(s) from the message queue specified by mqdes. The messages are received in FIFO order within the priorities. The received -message’s priority is stored in the location referenced by the msg_prio. +message's priority is stored in the location referenced by the msg_prio. If the msg_prio is a NULL, the priority is discarded. The message is removed and stored in an area pointed to by msg_ptr whose length is of msg_len. The msg_len must be at least equal to the mq_msgsize attribute @@ -212,7 +212,7 @@ Notification of Receipt of a Message on an Empty Queue The mq_notify() function registers the calling process to be notified of message arrival at an empty message queue. Every message queue has the -ability to notify one (and only one) process whenever the queue’s state +ability to notify one (and only one) process whenever the queue's state changes from empty (0 messages) to nonempty. This means that the process does not have to block or constantly poll while it waits for a message. By calling mq_notify, a notification request is attached to a message @@ -265,8 +265,8 @@ was called. Directives ========== -This section details the message passing manager’s directives. A -subsection is dedicated to each of this manager’s directives and describes +This section details the message passing 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. mq_open - Open a Message Queue @@ -317,7 +317,7 @@ message queue with a message queue descriptor. If the message queue already exists, mq_open opens it, if the message queue does not exist, mq_open creates it. Message queues can have multiple senders and receivers. If mq_open is successful, the function returns a message queue -descriptor. Otherwise, the function returns a -1 and sets ’errno’ to +descriptor. Otherwise, the function returns a -1 and sets 'errno' to indicate the error. The name of the message queue is used as an argument. For the best of @@ -500,7 +500,7 @@ mq_receive - Receive a Message from a Message Queue The mq_receive function is used to receive the oldest of the highest priority message(s) from the message queue specified by mqdes. The messages are received in FIFO order within the priorities. The received -message’s priority is stored in the location referenced by the msg_prio. +message's priority is stored in the location referenced by the msg_prio. If the msg_prio is a NULL, the priority is discarded. The message is removed and stored in an area pointed to by msg_ptr whose length is of msg_len. The msg_len must be at least equal to the mq_msgsize attribute @@ -548,7 +548,7 @@ calling process to be notified of message arrival at an empty message queue associated with the specified message queue descriptor, mqdes. Every message queue has the ability to notify one (and only one) process -whenever the queue’s state changes from empty (0 messages) to nonempty. +whenever the queue's state changes from empty (0 messages) to nonempty. This means that the process does not have to block or constantly poll while it waits for a message. By calling mq_notify, a notification request is attached to a message queue. When a message is received by an diff --git a/posix_users/mutex.rst b/posix_users/mutex.rst index 067f284..0198664 100644 --- a/posix_users/mutex.rst +++ b/posix_users/mutex.rst @@ -87,8 +87,8 @@ There is currently no text in this section. Services ======== -This section details the mutex manager’s services. -A subsection is dedicated to each of this manager’s services +This section details the mutex manager's services. +A subsection is dedicated to each of this manager's services and describes the calling sequence, related constants, usage, and status codes. diff --git a/posix_users/preface.rst b/posix_users/preface.rst index e8e71f3..d4065b5 100644 --- a/posix_users/preface.rst +++ b/posix_users/preface.rst @@ -1,7 +1,7 @@ Preface ####### -This is the User’s Guide for the POSIX API support +This is the User's Guide for the POSIX API support provided in RTEMS. The functionality described in this document is based @@ -52,8 +52,8 @@ Acknowledgements documentation. Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1, 2004 Edition, Standard for Information - Technology â Operating System Interface (POSIX), The Open - Group Base Specifications Issue 6, Copyright © 2001-2004 by the + Technology Operating System Interface (POSIX), The Open + Group Base Specifications Issue 6, Copyright (c) 2001-2004 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. In the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original diff --git a/posix_users/process_creation_and_execution.rst b/posix_users/process_creation_and_execution.rst index 38f1ce1..7ba4588 100644 --- a/posix_users/process_creation_and_execution.rst +++ b/posix_users/process_creation_and_execution.rst @@ -57,8 +57,8 @@ is equivalent to invoking either ``exit`` or``rtems_shutdown_executive``. Directives ========== -This section details the process creation and execution manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the process creation and execution 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. diff --git a/posix_users/process_environment.rst b/posix_users/process_environment.rst index 0deee9d..50c89b0 100644 --- a/posix_users/process_environment.rst +++ b/posix_users/process_environment.rst @@ -103,7 +103,7 @@ POSIX allows for variables in the run-time environment. These are name/value pairs that make be dynamically set and obtained by programs. In a full POSIX environment with command line shell and multiple processes, environment variables may be set in -one process – such as the shell – and inherited by child +one process - such as the shell - and inherited by child processes. In RTEMS, there is only one process and thus only one set of environment variables across all processes. @@ -127,8 +127,8 @@ the ``putenv()`` service. Directives ========== -This section details the process environment manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the process environment 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. diff --git a/posix_users/scheduler.rst b/posix_users/scheduler.rst index 6c115e4..9d249b0 100644 --- a/posix_users/scheduler.rst +++ b/posix_users/scheduler.rst @@ -60,8 +60,8 @@ There is currently no text in this section. Directives ========== -This section details the scheduler manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the scheduler 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. diff --git a/posix_users/semaphore.rst b/posix_users/semaphore.rst index eda5bcd..47628df 100644 --- a/posix_users/semaphore.rst +++ b/posix_users/semaphore.rst @@ -78,8 +78,8 @@ There is currently no text in this section. Directives ========== -This section details the semaphore manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the semaphore 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. diff --git a/posix_users/services_provided_by_c.rst b/posix_users/services_provided_by_c.rst index 2389609..e061d0b 100644 --- a/posix_users/services_provided_by_c.rst +++ b/posix_users/services_provided_by_c.rst @@ -165,7 +165,7 @@ Input and Output (stdio.h) - ``puts`` - Write a character string on standard output -- ``remove`` - Delete a file’s name +- ``remove`` - Delete a file's name - ``rename`` - Rename a file diff --git a/posix_users/signal.rst b/posix_users/signal.rst index 51b43ab..6ad79b1 100644 --- a/posix_users/signal.rst +++ b/posix_users/signal.rst @@ -115,7 +115,7 @@ Signal Set Management Each process and each thread within that process has a set of individual signals and handlers associated with it. Services are provided to construct signal sets for the purposes of building -signal sets – type ``sigset_t`` – that are used to +signal sets - type ``sigset_t`` - that are used to provide arguments to the services that mask, unmask, and check on pending signals. @@ -138,8 +138,8 @@ the service ``kill()`` or at a thread by the service``pthread_kill()`` Directives ========== -This section details the signal manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the signal 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. diff --git a/posix_users/system_database.rst b/posix_users/system_database.rst index 56505a5..60d6e02 100644 --- a/posix_users/system_database.rst +++ b/posix_users/system_database.rst @@ -38,8 +38,8 @@ There is currently no text in this section. Directives ========== -This section details the system databases manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the system databases 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. diff --git a/posix_users/thread.rst b/posix_users/thread.rst index 4bd80ed..b6a6fca 100644 --- a/posix_users/thread.rst +++ b/posix_users/thread.rst @@ -85,12 +85,12 @@ the ``pthread_create`` routine. is the address of the optionally user specified stack area for this thread. If this value is NULL, then RTEMS allocates the memory for the thread stack from the RTEMS Workspace Area. Otherwise, this is the user specified - address for the memory to be used for the thread’s stack. Each thread must + address for the memory to be used for the thread's stack. Each thread must have a distinct stack area. Each processor family has different alignment rules which should be followed. *stack size* - is the minimum desired size for this thread’s stack area. + is the minimum desired size for this thread's stack area. If the size of this area as specified by the stack size attribute is smaller than the minimum for this processor family and the stack is not user specified, then RTEMS will automatically allocate a @@ -120,8 +120,8 @@ There is currently no text in this section. Services ======== -This section details the thread manager’s services. -A subsection is dedicated to each of this manager’s services +This section details the thread manager's services. +A subsection is dedicated to each of this manager's services and describes the calling sequence, related constants, usage, and status codes. @@ -852,7 +852,7 @@ pthread_create - Create a Thread *EINVAL* The user specified a stack address and the size of the area was not - large enough to meet this processor’s minimum stack requirements. + large enough to meet this processor's minimum stack requirements. *EINVAL* The specified scheduler inheritance policy was invalid. diff --git a/posix_users/thread_cancellation.rst b/posix_users/thread_cancellation.rst index 5c8aac3..5a70c40 100644 --- a/posix_users/thread_cancellation.rst +++ b/posix_users/thread_cancellation.rst @@ -34,8 +34,8 @@ There is currently no text in this section. Directives ========== -This section details the thread cancellation manager’s directives. -A subsection is dedicated to each of this manager’s directives +This section details the thread cancellation 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. diff --git a/posix_users/timer.rst b/posix_users/timer.rst index 4adf320..36801d8 100644 --- a/posix_users/timer.rst +++ b/posix_users/timer.rst @@ -27,8 +27,8 @@ Operations System Calls ============ -This section details the timer manager’s services. -A subsection is dedicated to each of this manager’s services +This section details the timer manager's services. +A subsection is dedicated to each of this manager's services and describes the calling sequence, related constants, usage, and status codes. diff --git a/shell/file_and_directory.rst b/shell/file_and_directory.rst index 23ec49e..152f678 100644 --- a/shell/file_and_directory.rst +++ b/shell/file_and_directory.rst @@ -536,7 +536,7 @@ The following options are available: *-i* Causes cp to write a prompt to the standard error output before copying a file that would overwrite an existing file. If the response from the standard input - begins with the character ’y’, the file copy is attempted. + begins with the character 'y', the file copy is attempted. *-L* If the -R option is specified, all symbolic links are followed. @@ -553,19 +553,19 @@ The following options are available: If the user ID and group ID cannot be preserved, no error message is displayed and the exit value is not altered. If the source file has its set user ID bit on and the user ID cannot be - preserved, the set user ID bit is not preserved in the copy’s permissions. If + preserved, the set user ID bit is not preserved in the copy's permissions. If the source file has its set group ID bit on and the group ID cannot be - preserved, the set group ID bit is not preserved in the copy’s permissions. If + preserved, the set group ID bit is not preserved in the copy's permissions. If the source file has both its set user ID and set group ID bits on, and either the user ID or group ID cannot be preserved, neither the set user ID or set - group ID bits are preserved in the copy’s permissions. + group ID bits are preserved in the copy's permissions. *-R* If source_file designates a directory, cp copies the directory and the entire subtree connected at that point. This option also causes symbolic links to be copied, rather than indirected through, and for cp to create special files rather than copying them as normal files. Created directories have the same - mode as the corresponding source directory, unmodified by the process’s umask. + mode as the corresponding source directory, unmodified by the process's umask. *-v* Cause cp to be verbose, showing files as they are copied. @@ -592,7 +592,7 @@ symbolic links are not followed, by default. The -H or -L flags (in conjunction with the -R flag), as well as the -P flag cause symbolic links to be followed as described above. The -H and -L options are ignored unless the -R option is specified. In addition, these options override eachsubhedading other and the -command’s actions are determined by the last one specified. +command's actions are determined by the last one specified. **EXIT STATUS:** @@ -747,7 +747,7 @@ The following operands are available: *progress=n* Switch on display of progress if n is set to any non-zero value. This - will cause a “.” to be printed (to the standard error output) for + will cause a "." to be printed (to the standard error output) for every n full or partial blocks written to the output file. *conv=value[,value...]* @@ -848,7 +848,7 @@ The following operands are available: discarded and a newline character is appended. Where sizes are specified, a decimal number of bytes is expected. Two -or more numbers may be separated by an “x” to indicate a product. +or more numbers may be separated by an "x" to indicate a product. Each number may have one of the following optional suffixes: *b* @@ -1230,7 +1230,7 @@ The options are as follows: *-C* Canonical hex+ASCII display. Display the input offset in hexadecimal, followed by sixteen space-separated, two column, hexadecimal bytes, - followed by the same sixteen bytes in %_p format enclosed in “|” + followed by the same sixteen bytes in %_p format enclosed in "|" characters. *-d* @@ -1298,16 +1298,16 @@ must be placed after the iteration count and/or before the byte count to disambiguate them. Any whitespace before or after the slash is ignored. -The format is required and must be surrounded by double quote (“ “) +The format is required and must be surrounded by double quote (" ") marks. It is interpreted as a fprintf-style format string (see*fprintf*), with the following exceptions: - An asterisk (\*) may not be used as a field width or precision. -- A byte count or field precision is required for each “s” con- +- A byte count or field precision is required for each "s" con- version character (unlike the fprintf(3) default which prints the entire string if the precision is unspecified). -- The conversion characters “h”, “l”, “n”, “p” and “q” are not +- The conversion characters "h", "l", "n", "p" and "q" are not supported. - The single character escape sequences described in the C standard @@ -1341,7 +1341,7 @@ Hexdump also supports the following additional conversion strings: *_p* Output characters in the default character set. Nonprinting - characters are displayed as a single “.”. + characters are displayed as a single ".". *_u* Output US ASCII characters, with the exception that control characters @@ -1369,9 +1369,9 @@ data required by each format unit, which is the iteration count times the byte count, or the iteration count times the number of bytes required by the format if the byte count is not specified. -The input is manipulated in “blocks”, where a block is defined as +The input is manipulated in "blocks", where a block is defined as the largest amount of data specified by any format string. Format -strings interpreting less than an input block’s worth of data, whose +strings interpreting less than an input block's worth of data, whose last format unit both interprets some number of bytes and does not have a specified iteration count, have the iteration count incremented until the entire input block has been processed or there is not enough @@ -1396,7 +1396,7 @@ Further output by such format strings is replaced by an equivalent number of spaces. An equivalent number of spaces is defined as the number of spaces output by an s conversion character with the same field width and precision as the original conversion character or -conversion string but with any “+”, “ ”, “#” conversion flag +conversion string but with any "+", " ", "#" conversion flag characters removed, and ref- erencing a NULL string. If no format strings are specified, the default display is equivalent @@ -1463,9 +1463,9 @@ ln - make links The ln utility creates a new directory entry (linked file) which has the same modes as the original file. It is useful for maintaining multiple copies of a file in many places at once without using up -storage for the “copies”; instead, a link “points” to the original +storage for the "copies"; instead, a link "points" to the original copy. There are two types of links; hard links and symbolic links. -How a link “points” to a file is one of the differences between a +How a link "points" to a file is one of the differences between a hard or symbolic link. The options are as follows: @@ -1481,7 +1481,7 @@ The options are as follows: *-i* Cause ln to write a prompt to standard error if the target file exists. If the response from the standard input begins with the - character ‘y’ or ‘Y’, then unlink the target file so that the link may + character 'y' or 'Y', then unlink the target file so that the link may occur. Otherwise, do not attempt the link. (The -i option overrides any previous -f options.) @@ -1903,7 +1903,7 @@ To make nodes manually, the arguments are: with a # to stop it being treated as a name. *name* - Device name, for example “tty” for a termios serial device or “hd” + Device name, for example "tty" for a termios serial device or "hd" for a disk. *b | c | p* @@ -1931,7 +1931,7 @@ To make nodes manually, the arguments are: *number* A single opaque device number. Useful for netbooted computers which - require device numbers packed in a format that isn’t supported by + require device numbers packed in a format that isn't supported by -F. **EXIT STATUS:** @@ -2104,10 +2104,10 @@ using the specified file system. The files systems are: - rfs - RTEMS File System -When the file system type is ’msdos’ or ’rfs’ the driver is a "block +When the file system type is 'msdos' or 'rfs' the driver is a "block device driver" node present in the file system. The driver is ignored -with the ’tftp’ and ’ftp’ file systems. For the ’nfs’ file system the -driver is the ’host:/path’ string that described NFS host and the +with the 'tftp' and 'ftp' file systems. For the 'nfs' file system the +driver is the 'host:/path' string that described NFS host and the exported file system path. **EXIT STATUS:** @@ -2120,27 +2120,27 @@ The mount point must exist. The services offered by each file-system vary. For example you cannot list the directory of a TFTP file-system as this server is not provided in the TFTP -protocol. You need to check each file-system’s documentation for the services +protocol. You need to check each file-system's documentation for the services provided. **EXAMPLES:** -Mount the Flash Disk driver to the ’/fd’ mount point: +Mount the Flash Disk driver to the '/fd' mount point: .. code:: c SHLL \[/] $ mount -t msdos /dev/flashdisk0 /fd -Mount the NFS file system exported path ’bar’ by host ’foo’: +Mount the NFS file system exported path 'bar' by host 'foo': .. code:: c $ mount -t nfs foo:/bar /nfs -Mount the TFTP file system on ’/tftp’: +Mount the TFTP file system on '/tftp': .. code:: c $ mount -t tftp /tftp -To access the TFTP files on server ’10.10.10.10’: +To access the TFTP files on server '10.10.10.10': .. code:: c $ cat /tftp/10.10.10.10/test.txt @@ -2235,12 +2235,12 @@ The following options are available: *-i* Causes mv to write a prompt to standard error before moving a file that would overwrite an existing file. If the response from the - standard input begins with the character ’y’, the move is attempted. + standard input begins with the character 'y', the move is attempted. *-v* Cause mv to be verbose, showing files as they are processed. -The last of any -f or -i options is the one which affects mv’s +The last of any -f or -i options is the one which affects mv's behavior. It is an error for any of the source operands to specify a nonexistent diff --git a/shell/index.rst b/shell/index.rst index 3420f25..8dcf0bc 100644 --- a/shell/index.rst +++ b/shell/index.rst @@ -1,8 +1,8 @@ ======================== -RTEMS Shell User’s Guide +RTEMS Shell User's Guide ======================== -COPYRIGHT © 1988 - 2015. +COPYRIGHT (c) 1988 - 2015. On-Line Applications Research Corporation (OAR). diff --git a/shell/network_commands.rst b/shell/network_commands.rst index 7778582..3fd39f5 100644 --- a/shell/network_commands.rst +++ b/shell/network_commands.rst @@ -391,11 +391,11 @@ ping - ping a host or IP address **DESCRIPTION:** -The ping utility uses the ICMP protocol’s mandatory ECHO_REQUEST +The ping utility uses the ICMP protocol's mandatory ECHO_REQUEST datagram to elicit an ICMP ECHO_RESPONSE from a host or gateway. -ECHO_REQUEST datagrams (“pings”) have an IP and ICMP header, -followed by a “struct timeval” and then an arbitrary number of -“pad” bytes used to fill out the packet. The options are as +ECHO_REQUEST datagrams ("pings") have an IP and ICMP header, +followed by a "struct timeval" and then an arbitrary number of +"pad" bytes used to fill out the packet. The options are as follows: *-A* @@ -417,7 +417,7 @@ follows: will consist of count packets. *-D* - Set the Don’t Fragment bit. + Set the Don't Fragment bit. *-d* Set the SO_DEBUG option on the socket being used. @@ -425,7 +425,7 @@ follows: *-f* Flood ping. Outputs packets as fast as they come back or one hundred times per second, whichever is more. For every ECHO_REQUEST - sent a period “.” is printed, while for every ECHO_REPLY received a + sent a period "." is printed, while for every ECHO_REPLY received a backspace is printed. This provides a rapid display of how many packets are being dropped. Only the super-user may use this option. This can be very hard on a network and should be used with caution. @@ -479,13 +479,13 @@ follows: Exit successfully after receiving one reply packet. *-p pattern* - You may specify up to 16 “pad” bytes to fill out the packet you + You may specify up to 16 "pad" bytes to fill out the packet you send. This is useful for diagnosing data-dependent problems in a - network. For example, “-p ff” will cause the sent packet to be + network. For example, "-p ff" will cause the sent packet to be filled with all ones. *-Q* - Somewhat quiet output. Don’t display ICMP error messages that are in + Somewhat quiet output. Don't display ICMP error messages that are in response to our query messages. Originally, the -v flag was required to display such errors, but -v displays all ICMP error messages. On a busy machine, this output can be overbear- ing. Without the -Q flag, @@ -518,7 +518,7 @@ follows: packets. On hosts with more than one IP address, this option can be used to force the source address to be something other than the IP address of the interface the probe packet is sent on. If the IP - address is not one of this machine’s interface addresses, an error is + address is not one of this machine's interface addresses, an error is returned and nothing is sent. *-s packetsize* @@ -564,7 +564,7 @@ any other value an error occurred. These values are defined in When using ping for fault isolation, it should first be run on the local host, to verify that the local network interface is up and running. Then, hosts and gateways further and further away should be -“pinged”. Round-trip times and packet loss statistics are computed. +"pinged". Round-trip times and packet loss statistics are computed. If duplicate packets are received, they are not included in the packet loss calculation, although the round trip time of these packets is used in calculating the round-trip time statistics. When the diff --git a/shell/preface.rst b/shell/preface.rst index b74f117..62af200 100644 --- a/shell/preface.rst +++ b/shell/preface.rst @@ -80,7 +80,7 @@ shell environment providing access to multiple POSIX compliant filesystems and TCP/IP stack. The subset of capabilities available is easy to configure and the standard Shell can be logged into from either a serial port or via telnet. But at another level, the Shell is a large set of components which can be -integrated into the user’s developed command interpreter. In either case, it +integrated into the user's developed command interpreter. In either case, it is trivial to add custom commands to the command set available. Acknowledgements @@ -102,9 +102,9 @@ have given us permission to reprint portions of their documentation. .. pull-quote:: Portions of this text are reprinted and reproduced in electronic form from - IEEE Std 1003.1, 2004 Edition, Standard for Information Technology â + IEEE Std 1003.1, 2004 Edition, Standard for Information Technology Operating System Interface (POSIX), The Open Group Base Specifications - Issue 6, Copyright © 2001-2004 by the Institute of Electrical and + Issue 6, Copyright (c) 2001-2004 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. In the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee |