Convert all Unicode to ASCII(128)

6 files changed, 30 insertions, 30 deletions

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