Convert all Unicode to ASCII(128)

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.

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

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.

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.

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.

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).
 

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.
 

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.
 

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

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

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``’,
+    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
+    the full device name would be '``scc1``'.  The unit number should be
-    obtained from the ‘name’ entry in the configuration structure.
+    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
+to a device's send queue and the ``IFF_OACTIVE`` bit in the
-device’s ``if_flags`` is not set.
+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.

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

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 of a board had Vendor A's RTC chip and the second
-generation had Vendor B’s RTC chip, RTC_Table could contain
+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.

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 )

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.

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

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
+This section details the barrier manager's
-directives.  A subsection is dedicated to each of this 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:**

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
+case, without special assistance every task's stack must include
-enough space to handle the task’s worst-case stack usage as well as
+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.
 

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
+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
+node address on the chain to be easly cast to the user's structure
 address.
 
 Controls

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
+decrementing the running task's time-remaining counter when both
-timeslicing and preemption are enabled.  If the task’s timeslice
+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.
+This section details the clock manager's directives.
-A subsection is dedicated to each of this 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.
 

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
+  - - If the data type is RTEMS NAME then the value should be
-    an integer>=0 or RTEMS_BUILD_NAME( ’U’, ’I’, ’1’, ’ ’ )
+    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:**
 

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.
+This section details the Constant Bandwidth Server's directives.
-A subsection is dedicated to each of this 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.
 
@@ -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.
 

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.
+This section details the CPU usage statistics manager's directives.
-A subsection is dedicated to each of this 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.
 

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
+This section details the dual-ported memory manager's
-directives.  A subsection is dedicated to each of this 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.
 

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.
+This section details the event manager's directives.
-A subsection is dedicated to each of this 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

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
+This section details the fatal error manager's
-directives.  A subsection is dedicated to each of this 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:**

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`

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).
 

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
+This section details the Initialization Manager's
-directives.  A subsection is dedicated to each of this 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.
 

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
+installs the RTEMS interrupt wrapper in the processor's
-Interrupt Vector Table and the address of the user’s ISR in the
+Interrupt Vector Table and the address of the user's ISR in the
-RTEMS’ Vector Table.  This directive returns the previous
+RTEMS' Vector Table.  This directive returns the previous
-contents of the specified vector in the RTEMS’ Vector Table.
+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
+This section details the interrupt manager's
-directives.  A subsection is dedicated to each of this 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:**

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
+be NULL.  RTEMS will return``RTEMS_SUCCESSFUL`` as the executive's and
-zero (0) as the device driver’s return code for these device
+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
+This section details the I/O manager's directives.  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.
 
@@ -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.
 

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:

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
+This section details the message manager's
-directives.  A subsection is dedicated to each of this 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.
 

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.
 

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.
 

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
+This section details the partition manager's
-directives.  A subsection is dedicated to each of this 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.
 

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.
 

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
+standardization by AT&T's System V Interface Definition and
-IEEE’s POSIX efforts.  A compliant multiprocessing executive
+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.

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
+This section details the rate monotonic manager's
-directives.  A subsection is dedicated to each of this 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

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
+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.
+calculate the structure's address from the node's address.
 
 Controls
 --------

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.
+This section details the region manager's directives.
-A subsection is dedicated to each of this 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
 ------------------------------------------------

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
 

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.

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
+This section details the semaphore manager's
-directives.  A subsection is dedicated to each of this 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.
 

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
+specified to this directive.  The ASR's mode is distinct from
-the task’s mode.  For example, the task may allow preemption,
+the task's mode.  For example, the task may allow preemption,
-while that task’s ASR may have preemption disabled.  Until a
+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.
+This section details the signal manager's directives.
-A subsection is dedicated to each of this 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.
 

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.

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).

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
+this directive, RTEMS initializes the task's stack based upon
-the task’s initial execution mode and start address.  The
+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
+This section details the task manager's directives.  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.
 
@@ -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
+the task's priority cannot be lowered immediately.  If the
-task’s priority were lowered immediately, then priority
+task's priority were lowered immediately, then priority
-inversion results.  The requested lowering of the task’s
+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
+inheritance binary semaphores.  The task's priority can be
-increased regardless of the task’s use of priority inheritance
+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.
+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’
+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.
+allocated structure containing the task's private 'global' data.
-In this case the destructor function could be ‘free’.
+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:**
 

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.
+This section details the timer manager's directives.
-A subsection is dedicated to each of this 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.
 

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.
+This section details the Timespec Helpers manager's directives.
-A subsection is dedicated to each of this 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.
 

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
+If defined, the user's FATAL error extension is
-invoked before RTEMS’ default fatal error routine is invoked and
+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
+This section details the user extension manager's
-directives.  A subsection is dedicated to each of this 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.
 

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

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.

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).
 

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
+processor's unique architecture. Discussed in this chapter are
-the the processor’s response and control mechanisms as they
+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.
 

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
 ------------

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.
 

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
+how the RTEMS interrupt manager is mapped onto the processor's
-unique architecture. Discussed in this chapter are the MIPS’s
+unique architecture. Discussed in this chapter are the MIPS's
 interrupt response and control mechanisms as they pertain to
 RTEMS.
 

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
 ------------

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
+how the RTEMS interrupt manager is mapped onto the processor's
-unique architecture. Discussed in this chapter are the PowerPC’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.

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
+how the RTEMS interrupt manager is mapped onto the processor's
-unique architecture. Discussed in this chapter are the SPARC’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.
 

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
 -------------------------

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
+how the RTEMS interrupt manager is mapped onto the processor's
-unique architecture. Discussed in this chapter are the MIPS’s
+unique architecture. Discussed in this chapter are the MIPS's
 interrupt response and control mechanisms as they pertain to
 RTEMS.
 

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
+    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
+    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.
 

develenv/index.rst

@@ -2,7 +2,7 @@
 RTEMS Development Environment Guide
 ===================================
 
-COPYRIGHT © 1988 - 2015.
+COPYRIGHT (c) 1988 - 2015.
 
 On-Line Applications Research Corporation (OAR).
 

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.
 

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

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

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.

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.

filesystem/index.rst

@@ -2,7 +2,7 @@
 RTEMS Filesystem Design Guide
 =============================
 
-COPYRIGHT © 1988 - 2015.
+COPYRIGHT (c) 1988 - 2015.
 
 On-Line Applications Research Corporation (OAR).
 

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
+    is normally filled in by the filesystem's evaluate routine. For the
-    filesystem’s root node, the filesystem’s initilization routine should
+    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.
 

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
+rtems_filesystem_initialize(). This routine will mount the 'In Memory File
-System’ as the base filesystem.  Mounting the base filesystem consists
+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
+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
+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

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

networking/index.rst

@@ -1,7 +1,7 @@
 ========================
 RTEMS Network Supplement
 ========================
-COPYRIGHT © 1988 - 2015.
+COPYRIGHT (c) 1988 - 2015.
 
 On-Line Applications Research Corporation (OAR).
 

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

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.

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``’,
+    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
+    the full device name would be '``scc1``'.  The unit number should be
-    obtained from the ‘name’ entry in the configuration structure.
+    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
+to a device's send queue and the ``IFF_OACTIVE`` bit in the
-device’s ``if_flags`` is not set.
+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.

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

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
+- Issue a '``u``' command to send UDP
-  packets to the ‘discard’ port.
+  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
+- Issue a '``t``' command to send TCP
-  packets to the ‘discard’ port.
+  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
+- Display the driver statistics (Console '``s``' command or telnet
-  ‘control-G’ character) and verify that:
+  '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

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
+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
+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

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.

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.

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
+requirements.  The tools in the embedded systems developers toolbox must
-support their project’s unique board.  RTEMS addresses this issue via the
+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

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

porting/index.rst

@@ -1,7 +1,7 @@
 ===================
 RTEMS Porting Guide
 ===================
-COPYRIGHT © 1988 - 2015.
+COPYRIGHT (c) 1988 - 2015.
 
 On-Line Applications Research Corporation (OAR).
 

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
 

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
+is that on some CPUs, the endian bit endianness for ALL fetches - both
-code and data – so the code will be fetched incorrectly.
+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
+is that on some CPUs, the endian bit endianness for ALL fetches - both
-code and data – so the code will be fetched incorrectly.
+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

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) + 0 corresponds to priority 0 - the highest priority.  And (15 <<
-4) + 14 corresponds to priority 254 – the next to the lowest priority.
+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:
 

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

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.
 

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).
 

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

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

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
 --------------

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.
+This section details the clock manager's directives.
-A subsection is dedicated to each of this 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.
 

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.
+This section details the condition variable manager's directives.
-A subsection is dedicated to each of this 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.
 

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
+This section details the device- and class- specific functions manager's
-directives. A subsection is dedicated to each of this manager’s directives
+directives. A subsection is dedicated to each of this manager's directives
 and describes the calling sequence, related constants, usage,
 and status codes.
 

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.
+This section details the files and directories manager's directives.
-A subsection is dedicated to each of this 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

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).