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