summaryrefslogtreecommitdiffstats
path: root/filesystem
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 /filesystem
parent11e1a6f969dc0b255dd7aed12509484cf7c7ed60 (diff)
downloadrtems-docs-d389819eea3a84e388935153e3be847342809da3.tar.bz2
Convert all Unicode to ASCII(128)
Diffstat (limited to 'filesystem')
-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
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