Changeset 5431beb in rtems-docs

Timestamp:

Nov 9, 2016, 5:54:02 AM (4 years ago)

Author:

Chris Johns <chrisj@…>

Branches:

4.11, 5, am, master

Children:

9330bfb

Parents:

f7dbf17

Message:

filesystem: Fix header levels.

Location:

filesystem

Files:

• call_development.rst (modified) (4 diffs)
• command_and_variable.rst (modified) (1 diff)
• conf.py (modified) (1 diff)
• fileystem_implmentation.rst (modified) (8 diffs)
• in-memory.rst (modified) (6 diffs)
• index.rst (modified) (2 diffs)
• minature_in-memory.rst (modified) (1 diff)
• mounting_and_unmounting.rst (modified) (1 diff)
• pathname_eval.rst (modified) (1 diff)
• preface.rst (modified) (2 diffs)
• system_init.rst (modified) (1 diff)
• trivial_ftp.rst (modified) (1 diff)

filesystem/call_development.rst

@@ -6 +6 @@
 
 System Call Development Notes
-#############################
+*****************************
 
 This set of routines represents the application's interface to files and
@@ -16 +16 @@
 #. access()
 
-# .chdir()
+#. chdir()
 
 #. chmod()
@@ -72 +72 @@
 ======
 
-**File:**
-
-access.c
-
-**Processing:**
-
-This routine is layered on the stat() function. It acquires the current status
-information for the specified file and then determines if the caller has the
-ability to access the file for read, write or execute according to the mode
-argument to this function.
-
-**Development Comments:**
-
-This routine is layered on top of the stat() function. As long as the st_mode
-element in the returned structure follow the standard UNIX conventions, this
-function should support other filesystems without alteration.
+File:
+    ``access.c``
+
+Processing:
+    This routine is layered on the stat() function. It acquires the current
+    status information for the specified file and then determines if the caller
+    has the ability to access the file for read, write or execute according to
+    the mode argument to this function.
+
+Development Comments:
+    This routine is layered on top of the stat() function. As long as the
+    st_mode element in the returned structure follow the standard UNIX
+    conventions, this function should support other filesystems without
+    alteration.
 
 chdir
 =====
 
-**File:**
-
-chdir.c
-
-**Processing:**
-
-This routine will determine if the pathname that we are attempting to make that
-current directory exists and is in fact a directory. If these conditions are
-met the global indication of the current directory (rtems_filesystem_current)
-is set to the rtems_filesystem_location_info_t structure that is returned by
-the rtems_filesystem_evaluate_path() routine.
-
-**Development Comments:**
-
-This routine is layered on the rtems_filesystem_evaluate_path() routine and the
-filesystem specific OP table function node_type().
-
-The routine ``node_type()`` must be a routine provided for each filesystem
-since it must access the filesystems node information to determine which of the
-following types the node is:
-
-- RTEMS_FILESYSTEM_DIRECTORY
-
-- RTEMS_FILESYSTEM_DEVICE
-
-- RTEMS_FILESYSTEM_HARD_LINK
-
-- RTEMS_FILESYSTEM_MEMORY_FILE
-
-This acknowledges that the form of the node management information can vary
-from one filesystem implementation to another.
-
-RTEMS has a special global structure that maintains the current directory
-location. This global variable is of type rtems_filesystem_location_info_t and
-is called rtems_filesystem_current. This structure is not always valid. In
-order to determine if the structure is valid, you must first test the
-node_access element of this structure. If the pointer is NULL, then the
-structure does not contain a valid indication of what the current directory is.
+File:
+    ``chdir.c``
+
+Processing:
+    This routine will determine if the pathname that we are attempting to make
+    that current directory exists and is in fact a directory. If these
+    conditions are met the global indication of the current directory
+    (rtems_filesystem_current) is set to the rtems_filesystem_location_info_t
+    structure that is returned by the rtems_filesystem_evaluate_path() routine.
+
+Development Comments:
+    This routine is layered on the rtems_filesystem_evaluate_path() routine and
+    the filesystem specific OP table function node_type().
+
+    The routine ``node_type()`` must be a routine provided for each filesystem
+    since it must access the filesystems node information to determine which of
+    the following types the node is:
+
+    - RTEMS_FILESYSTEM_DIRECTORY
+
+    - RTEMS_FILESYSTEM_DEVICE
+
+    - RTEMS_FILESYSTEM_HARD_LINK
+
+    - RTEMS_FILESYSTEM_MEMORY_FILE
+
+    This acknowledges that the form of the node management information can vary
+    from one filesystem implementation to another.
+
+    RTEMS has a special global structure that maintains the current directory
+    location. This global variable is of type rtems_filesystem_location_info_t
+    and is called rtems_filesystem_current. This structure is not always
+    valid. In order to determine if the structure is valid, you must first test
+    the node_access element of this structure. If the pointer is NULL, then the
+    structure does not contain a valid indication of what the current directory
+    is.
 
 chmod
 =====
 
-**File:**
-
-chmod.c
-
-**Processing:**
-
-This routine is layered on the ``open()``, ``fchmod()`` and ``close()``
-functions. As long as the standard interpretation of the mode_t value is
-maintained, this routine should not need modification to support other
-filesystems.
-
-**Development Comments:**
-
-The routine first determines if the selected file can be open with read/write
-access.  This is required to allow modification of the mode associated with the
-selected path.
-
-The ``fchmod()`` function is used to actually change the mode of the path using
-the integer file descriptor returned by the ``open()`` function.
-
-After mode modification, the open file descriptor is closed.
+File:
+    ``chmod.c``
+
+Processing:
+    This routine is layered on the ``open()``, ``fchmod()`` and ``close()``
+    functions. As long as the standard interpretation of the mode_t value is
+    maintained, this routine should not need modification to support other
+    filesystems.
+
+Development Comments:
+    The routine first determines if the selected file can be open with
+    read/write access.  This is required to allow modification of the mode
+    associated with the selected path.
+
+    The ``fchmod()`` function is used to actually change the mode of the path
+    using the integer file descriptor returned by the ``open()`` function.
+
+    After mode modification, the open file descriptor is closed.
 
 chown
 =====
 
-**File:**
-
-chown.c
-
-**Processing:**
-
-This routine is layered on the ``rtems_filesystem_evaluate_path()`` and the
-file system specific ``chown()`` routine that is specified in the OPS table for
-the file system.
-
-**Development Comments:**
-
-``rtems_filesystem_evaluate_path()`` is used to determine if the path specified
-actually exists. If it does a ``rtems_filesystem_location_info_t`` structure
-will be obtained that allows the shell function to locate the OPS table that is
-to be used for this filesystem.
-
-It is possible that the ``chown()`` function that should be in the OPS table is
-not defined. A test for a non-NULL OPS table ``chown()`` entry is performed
-before the function is called.
-
-If the ``chown()`` function is defined in the indicated OPS table, the function
-is called with the ``rtems_filesystem_location_info_t`` structure returned from
-the path evaluation routine, the desired owner, and group information.
+File:
+    ``chown.c``
+
+Processing:
+    This routine is layered on the ``rtems_filesystem_evaluate_path()`` and the
+    file system specific ``chown()`` routine that is specified in the OPS table
+    for the file system.
+
+Development Comments:
+    ``rtems_filesystem_evaluate_path()`` is used to determine if the path
+    specified actually exists. If it does a
+    ``rtems_filesystem_location_info_t`` structure will be obtained that allows
+    the shell function to locate the OPS table that is to be used for this
+    filesystem.
+
+    It is possible that the ``chown()`` function that should be in the OPS
+    table is not defined. A test for a non-NULL OPS table ``chown()`` entry is
+    performed before the function is called.
+
+    If the ``chown()`` function is defined in the indicated OPS table, the
+    function is called with the ``rtems_filesystem_location_info_t`` structure
+    returned from the path evaluation routine, the desired owner, and group
+    information.
 
 close
 =====
 
-**File:**
-
-close.c
-
-**Processing:**
-
-This routine will allow for the closing of both network connections and file
-system devices. If the file descriptor is associated with a network device, the
-appropriate network function handler will be selected from a table of
-previously registered network functions (``rtems_libio_handlers``) and that
-function will be invoked.
-
-If the file descriptor refers to an entry in the filesystem, the appropriate
-handler will be selected using information that has been placed in the file
-control block for the device (``rtems_libio_t`` structure).
-
-**Development Comments:**
-
-``rtems_file_descriptor_type`` examines some of the upper bits of the file
-descriptor index. If it finds that the upper bits are set in the file
-descriptor index, the device referenced is a network device.
-
-Network device handlers are obtained from a special registration table
-(``rtems_libio_handlers``) that is set up during network initialization. The
-network handler invoked and the status of the network handler will be returned
-to the calling process.
-
-If none of the upper bits are set in the file descriptor index, the file
-descriptor refers to an element of the RTEMS filesystem.
-
-The following sequence will be performed for any filesystem file descriptor:
-
-#. Use the ``rtems_libio_iop()`` function to obtain the ``rtems_libio_t``
-   structure for the file descriptor
-
-#. Range check the file descriptor using ``rtems_libio_check_fd()``
-
-#. Determine if there is actually a function in the selected handler table that
-   processes the ``close()`` operation for the filesystem and node type
-   selected.  This is generally done to avoid execution attempts on functions
-   that have not been implemented.
-
-# If the function has been defined it is invoked with the file control
-   block pointer as its argument.
-
-#. The file control block that was associated with the open file descriptor is
-   marked as free using ``rtems_libio_free()``.
-
-#. The return code from the close handler is then passed back to the calling
-   program.
- 
+File:
+    ``close.c``
+
+Processing:
+    This routine will allow for the closing of both network connections and
+    file system devices. If the file descriptor is associated with a network
+    device, the appropriate network function handler will be selected from a
+    table of previously registered network functions (``rtems_libio_handlers``)
+    and that function will be invoked.
+
+    If the file descriptor refers to an entry in the filesystem, the
+    appropriate handler will be selected using information that has been placed
+    in the file control block for the device (``rtems_libio_t`` structure).
+
+Development Comments:
+    ``rtems_file_descriptor_type`` examines some of the upper bits of the file
+    descriptor index. If it finds that the upper bits are set in the file
+    descriptor index, the device referenced is a network device.
+
+    Network device handlers are obtained from a special registration table
+    (``rtems_libio_handlers``) that is set up during network
+    initialization. The network handler invoked and the status of the network
+    handler will be returned to the calling process.
+
+    If none of the upper bits are set in the file descriptor index, the file
+    descriptor refers to an element of the RTEMS filesystem.
+
+    The following sequence will be performed for any filesystem file descriptor:
+
+    #. Use the ``rtems_libio_iop()`` function to obtain the ``rtems_libio_t``
+       structure for the file descriptor
+
+    #. Range check the file descriptor using ``rtems_libio_check_fd()``
+
+    #. Determine if there is actually a function in the selected handler table
+       that processes the ``close()`` operation for the filesystem and node
+       type selected.  This is generally done to avoid execution attempts on
+       functions that have not been implemented.
+
+    #. If the function has been defined it is invoked with the file control
+       block pointer as its argument.
+
+    #. The file control block that was associated with the open file descriptor
+       is marked as free using ``rtems_libio_free()``.
+
+    #. The return code from the close handler is then passed back to the
+       calling program.
+
 closedir
 ========
 
-**File:**
-
-closedir.c
-
-**Processing:**
-
-The code was obtained from the BSD group. This routine must clean up the memory
-resources that are required to track an open directory. The code is layered on
-the ``close()`` function and standard memory ``free()`` functions. It should
-not require alterations to support other filesystems.
-
-**Development Comments:**
-
-The routine alters the file descriptor and the index into the DIR 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 that
-contains the pointer to the dd_buf region.
-
-DIR control memory is reallocated.
-
-The ``close()`` function is used to free the file descriptor index.
+File:
+    ``closedir.c``
+
+Processing:
+    The code was obtained from the BSD group. This routine must clean up the
+    memory resources that are required to track an open directory. The code is
+    layered on the ``close()`` function and standard memory ``free()``
+    functions. It should not require alterations to support other filesystems.
+
+Development Comments:
+    The routine alters the file descriptor and the index into the DIR 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
+    that contains the pointer to the dd_buf region.
+
+    DIR control memory is reallocated.
+
+    The ``close()`` function is used to free the file descriptor index.
 
 dup()      Unimplemented
 ========================
 
-**File:**
-
-dup.c
-
-**Processing:**
-
-**Development Comments:**
+File:
+    ``dup.c``
+
+Processing:
+
+Development Comments:
 
 dup2()      Unimplemented
 =========================
 
-**File:**
-
-dup2.c
-
-**Processing:**
-
-**Development Comments:**
+File:
+    ``dup2.c``
+
+Processing:
+
+Development Comments:
 
 fchmod
 ======
 
-**File:**
-
-fchmod.c
-
-**Processing:**
-
-This routine will alter the permissions of a node in a filesystem. It is
-layered on the following functions and macros:
-
-- rtems_file_descriptor_type()
-
-- rtems_libio_iop()
-
-- rtems_libio_check_fd()
-
-- rtems_libio_check_permissions()
-
-- fchmod() function that is referenced by the handler table in the file control
-  block associated with this file descriptor
-
-**Development Comments:**
-
-The routine will test to see if the file descriptor index is associated with a
-network connection. If it is, an error is returned from this routine.
-
-The file descriptor index is used to obtain the associated file control block.
-
-The file descriptor value is range checked.
-
-The file control block is examined to determine if it has write permissions to
-allow us to alter the mode of the file.
-
-A test is made to determine if the handler table that is referenced in the file
-control block contains an entry for the ``fchmod()`` handler function. If it does
-not, an error is returned to the calling routine.
-
-If the ``fchmod()`` handler function exists, it is called with the file control
-block and the desired mode as parameters.
+File:
+    ``fchmod.c``
+
+Processing:
+    This routine will alter the permissions of a node in a filesystem. It is
+    layered on the following functions and macros:
+
+    - rtems_file_descriptor_type()
+
+    - rtems_libio_iop()
+
+    - rtems_libio_check_fd()
+
+    - rtems_libio_check_permissions()
+
+    - fchmod() function that is referenced by the handler table in the file
+      control block associated with this file descriptor
+
+Development Comments:
+    The routine will test to see if the file descriptor index is associated
+    with a network connection. If it is, an error is returned from this
+    routine.
+
+    The file descriptor index is used to obtain the associated file control
+    block.
+
+    The file descriptor value is range checked.
+
+    The file control block is examined to determine if it has write permissions
+    to allow us to alter the mode of the file.
+
+    A test is made to determine if the handler table that is referenced in the
+    file control block contains an entry for the ``fchmod()`` handler
+    function. If it does not, an error is returned to the calling routine.
+
+    If the ``fchmod()`` handler function exists, it is called with the file
+    control block and the desired mode as parameters.
 
 fcntl()
 =======
 
-**File:**
-
-fcntl.c
-
-**Processing:**
-
-This routine currently only interacts with the file control block. If the
-structure of the file control block and the associated meanings do not change,
-the partial implementation of ``fcntl()`` should remain unaltered for other
-filesystem implementations.
-
-**Development Comments:**
-
-The only commands that have been implemented are the F_GETFD and F_SETFD.  The
-commands manipulate the LIBIO_FLAGS_CLOSE_ON_EXEC bit in the``flags`` element
-of the file control block associated with the file descriptor index.
-
-The current implementation of the function performs the sequence of
-operations below:
-
-# Test to see if we are trying to operate on a file descriptor
-  associated with a network connection
-
-# Obtain the file control block that is associated with the file
-  descriptor index
-
-# Perform a range check on the file descriptor index.
+File:
+    ``fcntl.c``
+
+Processing:
+    This routine currently only interacts with the file control block. If the
+    structure of the file control block and the associated meanings do not
+    change, the partial implementation of ``fcntl()`` should remain unaltered
+    for other filesystem implementations.
+
+Development Comments:
+    The only commands that have been implemented are the F_GETFD and F_SETFD.
+    The commands manipulate the LIBIO_FLAGS_CLOSE_ON_EXEC bit in the``flags``
+    element of the file control block associated with the file descriptor
+    index.
+
+    The current implementation of the function performs the sequence of
+    operations below:
+
+    #. Test to see if we are trying to operate on a file descriptor associated
+       with a network connection
+
+    #. Obtain the file control block that is associated with the file
+       descriptor index
+
+    #. Perform a range check on the file descriptor index.
 
 fdatasync
 =========
 
-**File:**
-
-fdatasync.c
-
-**Processing:**
-
-This routine is a template in the in memory filesystem that will route us to
-the appropriate handler function to carry out the fdatasync() processing. In
-the in memory filesystem this function is not necessary. Its function in a disk
-based file system that employs a memory cache is to flush all memory based data
-buffers to disk. It is layered on the following functions and macros:
-
-- rtems_file_descriptor_type()
-
-- rtems_libio_iop()
-
-- rtems_libio_check_fd()
-
-- rtems_libio_check_permissions()
-
-- fdatasync() function that is referenced by the handler table in the file
-  control block associated with this file descriptor
-
-**Development Comments:**
-
-The routine will test to see if the file descriptor index is associated with a
-network connection. If it is, an error is returned from this routine.
-
-The file descriptor index is used to obtain the associated file control block.
-
-The file descriptor value is range checked.
-
-The file control block is examined to determine if it has write permissions to
-the file.
-
-A test is made to determine if the handler table that is referenced in the file
-control block contains an entry for the fdatasync() handler function.  If it
-does not an error is returned to the calling routine.
-
-If the fdatasync() handler function exists, it is called with the file control
-block as its parameter.
+File:
+    ``fdatasync.c``
+
+Processing:
+    This routine is a template in the in memory filesystem that will route us
+    to the appropriate handler function to carry out the fdatasync()
+    processing. In the in memory filesystem this function is not necessary. Its
+    function in a disk based file system that employs a memory cache is to
+    flush all memory based data buffers to disk. It is layered on the following
+    functions and macros:
+
+    - rtems_file_descriptor_type()
+
+    - rtems_libio_iop()
+
+    - rtems_libio_check_fd()
+
+    - rtems_libio_check_permissions()
+
+    - fdatasync() function that is referenced by the handler table in the file
+      control block associated with this file descriptor
+
+Development Comments:
+    The routine will test to see if the file descriptor index is associated
+    with a network connection. If it is, an error is returned from this
+    routine.
+
+    The file descriptor index is used to obtain the associated file control
+    block.
+
+    The file descriptor value is range checked.
+
+    The file control block is examined to determine if it has write permissions
+    to the file.
+
+    A test is made to determine if the handler table that is referenced in the
+    file control block contains an entry for the fdatasync() handler function.
+    If it does not an error is returned to the calling routine.
+
+    If the fdatasync() handler function exists, it is called with the file
+    control block as its parameter.
 
 fpathconf
 =========
 
-**File:**
-
-fpathconf.c
-
-**Processing:**
-
-This routine is layered on the following functions and macros:
-
-- rtems_file_descriptor_type()
-
-- rtems_libio_iop()
-
-- rtems_libio_check_fd()
-
-- rtems_libio_check_permissions()
-
-When a filesystem is mounted, a set of constants is specified for the
-filesystem.  These constants are stored with the mount table entry for the
-filesystem. These constants appear in the POSIX standard and are listed below.
-
-- PCLINKMAX
-
-- PCMAXCANON
-
-- PCMAXINPUT
-
-- PCNAMEMAX
-
-- PCPATHMAX
-
-- PCPIPEBUF
-
-- PCCHOWNRESTRICTED
-
-- PCNOTRUNC
-
-- PCVDISABLE
-
-- PCASYNCIO
-
-- PCPRIOIO
-
-- PCSYNCIO
-
-This routine will find the mount table information associated the file control
-block for the specified file descriptor parameter. The mount table entry
-structure contains a set of filesystem specific constants that can be accessed
-by individual identifiers.
-
-**Development Comments:**
-
-The routine will test to see if the file descriptor index is associated with a
-network connection. If it is, an error is returned from this routine.
-
-The file descriptor index is used to obtain the associated file control block.
-
-The file descriptor value is range checked.
-
-The file control block is examined to determine if it has read permissions to
-the file.
-
-Pathinfo in the file control block is used to locate the mount table entry for
-the filesystem associated with the file descriptor.
-
-The mount table entry contains the pathconf_limits_and_options element.  This
-element is a table of constants that is associated with the filesystem.
-
-The name argument is used to reference the desired constant from the
-pathconf_limits_and_options table.
+File:
+    ``fpathconf.c``
+
+Processing:
+    This routine is layered on the following functions and macros:
+
+    - rtems_file_descriptor_type()
+
+    - rtems_libio_iop()
+
+    - rtems_libio_check_fd()
+
+    - rtems_libio_check_permissions()
+
+    When a filesystem is mounted, a set of constants is specified for the
+    filesystem.  These constants are stored with the mount table entry for the
+    filesystem. These constants appear in the POSIX standard and are listed
+    below.
+
+    - PCLINKMAX
+
+    - PCMAXCANON
+
+    - PCMAXINPUT
+
+    - PCNAMEMAX
+
+    - PCPATHMAX
+
+    - PCPIPEBUF
+
+    - PCCHOWNRESTRICTED
+
+    - PCNOTRUNC
+
+    - PCVDISABLE
+
+    - PCASYNCIO
+
+    - PCPRIOIO
+
+    - PCSYNCIO
+
+    This routine will find the mount table information associated the file
+    control block for the specified file descriptor parameter. The mount table
+    entry structure contains a set of filesystem specific constants that can be
+    accessed by individual identifiers.
+
+Development Comments:
+    The routine will test to see if the file descriptor index is associated
+    with a network connection. If it is, an error is returned from this
+    routine.
+
+    The file descriptor index is used to obtain the associated file control
+    block.
+
+    The file descriptor value is range checked.
+
+    The file control block is examined to determine if it has read permissions
+    to the file.
+
+    Pathinfo in the file control block is used to locate the mount table entry
+    for the filesystem associated with the file descriptor.
+
+    The mount table entry contains the pathconf_limits_and_options element.
+    This element is a table of constants that is associated with the
+    filesystem.
+
+    The name argument is used to reference the desired constant from the
+    pathconf_limits_and_options table.
 
 fstat
 =====
 
-**File:**
-
-fstat.c
-
-**Processing:**
-
-This routine will return information concerning a file or network
-connection. If the file descriptor is associated with a network connection, the
-current implementation of ``fstat()`` will return a mode set to
-``S_IFSOCK``. In a later version, this routine will map the status of a network
-connection to an external handler routine.
-
-If the file descriptor is associated with a node under a filesystem, the
-fstat() routine will map to the fstat() function taken from the node handler
-table.
-
-**Development Comments:**
-
-This routine validates that the struct stat pointer is not NULL so that the
-return location is valid.
-
-The struct stat is then initialized to all zeros.
-
-rtems_file_descriptor_type() is then used to determine if the file descriptor
-is associated with a network connection. If it is, network status processing is
-performed. In the current implementation, the file descriptor type processing
-needs to be improved. It currently just drops into the normal processing for
-file system nodes.
-
-If the file descriptor is associated with a node under a filesystem, the
-following steps are performed:
-
-# Obtain the file control block that is associated with the file descriptor
-  index.
-
-# Range check the file descriptor index.
-
-# Test to see if there is a non-NULL function pointer in the handler table for
-  the fstat() function. If there is, invoke the function with the file control
-  block and the pointer to the stat structure.
+File:
+    ``fstat.c``
+
+Processing:
+    This routine will return information concerning a file or network
+    connection. If the file descriptor is associated with a network connection,
+    the current implementation of ``fstat()`` will return a mode set to
+    ``S_IFSOCK``. In a later version, this routine will map the status of a
+    network connection to an external handler routine.
+
+    If the file descriptor is associated with a node under a filesystem, the
+    fstat() routine will map to the fstat() function taken from the node
+    handler table.
+
+Development Comments:
+    This routine validates that the struct stat pointer is not NULL so that the
+    return location is valid.
+
+    The struct stat is then initialized to all zeros.
+
+    rtems_file_descriptor_type() is then used to determine if the file
+    descriptor is associated with a network connection. If it is, network
+    status processing is performed. In the current implementation, the file
+    descriptor type processing needs to be improved. It currently just drops
+    into the normal processing for file system nodes.
+
+    If the file descriptor is associated with a node under a filesystem, the
+    following steps are performed:
+
+    #. Obtain the file control block that is associated with the file descriptor
+       index.
+
+    #. Range check the file descriptor index.
+
+    #. Test to see if there is a non-NULL function pointer in the handler table
+       for the fstat() function. If there is, invoke the function with the file
+       control block and the pointer to the stat structure.
 
 ioctl
 =====
 
-**File:**
-
-ioctl.c
-
-**Processing:**
-
-Not defined in the POSIX 1003.1b standard but commonly supported in most UNIX
-and POSIX system. Ioctl() is a catchall for I/O operations. Routine is layered
-on external network handlers and filesystem specific handlers.  The development
-of new filesystems should not alter the basic processing performed by this
-routine.
-
-**Development Comments:**
-
-The file descriptor is examined to determine if it is associated with a network
-device. If it is processing is mapped to an external network handler. The value
-returned by this handler is then returned to the calling program.
-
-File descriptors that are associated with a filesystem undergo the following
-processing:
-
-# The file descriptor index is used to obtain the associated file control
-  block.
-
-# The file descriptor value is range checked.
-
-# A test is made to determine if the handler table that is referenced
-  in the file control block contains an entry for the ioctl() handler
-  function. If it does not, an error is returned to the calling routine.
-
-# If the ioctl() handler function exists, it is called with the file control
-  block, the command and buffer as its parameters.
-
-# The return code from this function is then sent to the calling routine.
+File:
+    ``ioctl.c``
+
+Processing:
+    Not defined in the POSIX 1003.1b standard but commonly supported in most
+    UNIX and POSIX system. Ioctl() is a catchall for I/O operations. Routine is
+    layered on external network handlers and filesystem specific handlers.  The
+    development of new filesystems should not alter the basic processing
+    performed by this routine.
+
+Development Comments:
+    The file descriptor is examined to determine if it is associated with a
+    network device. If it is processing is mapped to an external network
+    handler. The value returned by this handler is then returned to the calling
+    program.
+
+    File descriptors that are associated with a filesystem undergo the
+    following processing:
+
+    #. The file descriptor index is used to obtain the associated file control
+       block.
+
+    #. The file descriptor value is range checked.
+
+    #. A test is made to determine if the handler table that is referenced in
+       the file control block contains an entry for the ioctl() handler
+       function. If it does not, an error is returned to the calling routine.
+
+    #. If the ioctl() handler function exists, it is called with the file
+       control block, the command and buffer as its parameters.
+
+    #. The return code from this function is then sent to the calling routine.
 
 link
 ====
 
-**File:**
-
-link.c
-
-**Processing:**
-
-This routine will establish a hard link to a file, directory or a device.  The
-target of the hard link must be in the same filesystem as the new link being
-created. A link to an existing link is also permitted but the existing link is
-evaluated before the new link is made. This implies that links to links are
-reduced to links to files, directories or devices before they are made.
-
-**Development Comments:**
-
-Calling parameters:
-
-.. code-block:: c
-
-    const char   *existing
-    const char   *new
-
-link() will determine if the target of the link actually exists using
-rtems_filesystem_evaluate_path()
-
-rtems_filesystem_get_start_loc() is used to determine where to start the path
-evaluation of the new name. This macro examines the first characters of the
-name to see if the name of the new link starts with a
-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 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 a child
-under the parent directory.
-
-If the parent is found, the routine will determine if the hard link that we are
-trying to create will cross a filesystem boundary. This is not permitted for
-hard-links.
-
-If the hard-link does not cross a filesystem boundary, a check is performed to
-determine if the OPS table contains an entry for the link() function.
-
-If a link() function is defined, the OPS table link() function will be called
-to establish the actual link within the filesystem.
-
-The return code from the OPS table link() function is returned to the calling
-program.
+File:
+    ``link.c``
+
+Processing:
+    This routine will establish a hard link to a file, directory or a device.
+    The target of the hard link must be in the same filesystem as the new link
+    being created. A link to an existing link is also permitted but the
+    existing link is evaluated before the new link is made. This implies that
+    links to links are reduced to links to files, directories or devices before
+    they are made.
+
+Development Comments:
+    Calling parameters:
+
+    .. code-block:: c
+
+        const char   *existing
+        const char   *new
+
+    link() will determine if the target of the link actually exists using
+    rtems_filesystem_evaluate_path()
+
+    rtems_filesystem_get_start_loc() is used to determine where to start the
+    path evaluation of the new name. This macro examines the first characters
+    of the name to see if the name of the new link starts with a
+    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 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 a
+    child under the parent directory.
+
+    If the parent is found, the routine will determine if the hard link that we
+    are trying to create will cross a filesystem boundary. This is not
+    permitted for hard-links.
+
+    If the hard-link does not cross a filesystem boundary, a check is performed
+    to determine if the OPS table contains an entry for the link() function.
+
+    If a link() function is defined, the OPS table link() function will be
+    called to establish the actual link within the filesystem.
+
+    The return code from the OPS table link() function is returned to the
+    calling program.
 
 lseek
 =====
 
-**File:**
-
-lseek.c
-
-**Processing:**
-
-This routine is layered on both external handlers and filesystem / node type
-specific handlers. This routine should allow for the support of new filesystems
-without modification.
-
-**Development Comments:**
-
-This routine will determine if the file descriptor is associated with a network
-device. If it is lseek will map to an external network handler.  The handler
-will be called with the file descriptor, offset and whence as its calling
-parameters. The return code from the external handler will be returned to the
-calling routine.
-
-If the file descriptor is not associated with a network connection, it is
-associated with a node in a filesystem. The following steps will be performed
-for filesystem nodes:
-
-# The file descriptor is used to obtain the file control block for the node.
-
-# The file descriptor is range checked.
-
-# The offset element of the file control block is altered as indicated by the
-  offset and whence calling parameters
-
-# The handler table in the file control block is examined to determine if it
-  contains an entry for the lseek() function. If it does not an error is
-  returned to the calling program.
-
-# The lseek() function from the designated handler table is called with the
-  file control block, offset and whence as calling arguments
-
-# The return code from the lseek() handler function is returned to the calling
-  program
+File:
+    ``lseek.c``
+
+Processing:
+    This routine is layered on both external handlers and filesystem / node
+    type specific handlers. This routine should allow for the support of new
+    filesystems without modification.
+
+Development Comments:
+    This routine will determine if the file descriptor is associated with a
+    network device. If it is lseek will map to an external network handler.
+    The handler will be called with the file descriptor, offset and whence as
+    its calling parameters. The return code from the external handler will be
+    returned to the calling routine.
+
+    If the file descriptor is not associated with a network connection, it is
+    associated with a node in a filesystem. The following steps will be
+    performed for filesystem nodes:
+
+    #. The file descriptor is used to obtain the file control block for the
+       node.
+
+    #. The file descriptor is range checked.
+
+    #. The offset element of the file control block is altered as indicated by
+       the offset and whence calling parameters
+
+    #. The handler table in the file control block is examined to determine if
+       it contains an entry for the lseek() function. If it does not an error
+       is returned to the calling program.
+
+    #. The lseek() function from the designated handler table is called with
+       the file control block, offset and whence as calling arguments
+
+    #. The return code from the lseek() handler function is returned to the
+       calling program
 
 mkdir
 =====
 
-**File:**
-
-mkdir.c
-
-**Processing:**
-
-This routine attempts to create a directory node under the filesystem. The
-routine is layered the mknod() function.
-
-**Development Comments:**
-
-See mknod() for developmental comments.
+File:
+    ``mkdir.c``
+
+Processing:
+    This routine attempts to create a directory node under the filesystem. The
+    routine is layered the mknod() function.
+
+Development Comments:
+    See mknod() for developmental comments.
 
 mkfifo
 ======
 
-**File:**
-
-mkfifo.c
-
-**Processing:**
-
-This routine attempts to create a FIFO node under the filesystem. The routine
-is layered the mknod() function.
-
-**Development Comments:**
-
-See mknod() for developmental comments
+File:
+    ``mkfifo.c``
+
+Processing:
+    This routine attempts to create a FIFO node under the filesystem. The
+    routine is layered the mknod() function.
+
+Development Comments:
+    See mknod() for developmental comments
 
 .. COMMENT: @page
@@ -691 +658 @@
 =====
 
-**File:**
-
-mknod.c
-
-**Processing:**
-
-This function will allow for the creation of the following types of nodes under
-the filesystem:
-
-- directories
-
-- regular files
-
-- character devices
-
-- block devices
-
-- fifos
-
-At the present time, an attempt to create a FIFO will result in an ENOTSUP
-error to the calling function. This routine is layered the filesystem specific
-routines evalformake and mknod. The introduction of a new filesystem must
-include its own evalformake and mknod function to support the generic mknod()
-function.  Under this condition the generic mknod() function should accommodate
-other filesystem types without alteration.
-
-**Development Comments:**
-
-Test for nodal types - I thought that this test should look like the following
-code:
-
-.. code-block:: c
-
-    if ( (mode & S_IFDIR) = = S_IFDIR) ||
-         (mode & S_IFREG) = = S_IFREG) ||
-         (mode & S_IFCHR) = = S_IFCHR) ||
-         (mode & S_IFBLK) = = S_IFBLK) ||
-         (mode & S_IFIFO) = = S_IFIFO))
-            Set_errno_and_return_minus_one (EINVAL);
-
-Where:
-
-- S_IFREG (0100000) - Creation of a regular file
-
-- S_IFCHR (0020000) - Creation of a character device
-
-- S_IFBLK (0060000) - Creation of a block device
-
-- S_IFIFO (0010000) - Creation of a FIFO
-
-Determine if the pathname that we are trying to create starts at the root
-directory or is relative to the current directory using the
-``rtems_filesystem_get_start_loc()`` function.
-
-Determine if the pathname leads to a valid directory that can be accessed for
-the creation of a node.
-
-If the pathname is a valid location to create a node, verify that a filesystem
-specific mknod() function exists.
-
-If the mknod() function exists, call the filesystem specific mknod() function.
-Pass the name, mode, device type and the location information associated with
-the directory under which the node will be created.
+File:
+    ``mknod.c``
+
+Processing:
+    This function will allow for the creation of the following types of nodes
+    under the filesystem:
+
+    - directories
+
+    - regular files
+
+    - character devices
+
+    - block devices
+
+    - fifos
+
+    At the present time, an attempt to create a FIFO will result in an ENOTSUP
+    error to the calling function. This routine is layered the filesystem
+    specific routines evalformake and mknod. The introduction of a new
+    filesystem must include its own evalformake and mknod function to support
+    the generic mknod() function.  Under this condition the generic mknod()
+    function should accommodate other filesystem types without alteration.
+
+Development Comments:
+    Test for nodal types - I thought that this test should look like the
+    following code:
+
+    .. code-block:: c
+
+        if ( (mode & S_IFDIR) = = S_IFDIR) ||
+             (mode & S_IFREG) = = S_IFREG) ||
+             (mode & S_IFCHR) = = S_IFCHR) ||
+             (mode & S_IFBLK) = = S_IFBLK) ||
+             (mode & S_IFIFO) = = S_IFIFO))
+                Set_errno_and_return_minus_one (EINVAL);
+
+    Where:
+
+    - S_IFREG (0100000) - Creation of a regular file
+
+    - S_IFCHR (0020000) - Creation of a character device
+
+    - S_IFBLK (0060000) - Creation of a block device
+
+    - S_IFIFO (0010000) - Creation of a FIFO
+
+    Determine if the pathname that we are trying to create starts at the root
+    directory or is relative to the current directory using the
+    ``rtems_filesystem_get_start_loc()`` function.
+
+    Determine if the pathname leads to a valid directory that can be accessed
+    for the creation of a node.
+
+    If the pathname is a valid location to create a node, verify that a
+    filesystem specific mknod() function exists.
+
+    If the mknod() function exists, call the filesystem specific mknod()
+    function.  Pass the name, mode, device type and the location information
+    associated with the directory under which the node will be created.
 
 mount
 =====
 
-**File:**
-
-mount.c
-
-Arguments (Not a standard POSIX call):
-
-.. code-block:: c
-
-    rtems_filesystem_mount_table_entry_t   **mt_entry,
-
-If the mount operation is successful, this pointer to a pointer will be set to
-reference the mount table chain entry that has been allocated for this file
-system mount.
-
-.. code-block:: c
-
-    rtems_filesystem_operations_table   *fs_ops,
-
-This is a pointer to a table of functions that are associated with the file
-system that we are about to mount. This is the mechanism to selected file
-system type without keeping a dynamic database of all possible file system
-types that are valid for the mount operation. Using this method, it is only
-necessary to configure the filesystems that we wish to use into the RTEMS
-build. Unused filesystems types will not be drawn into the build.
-
-.. code-block:: c
-
-    char                      *fsoptions,
-
-This argument points to a string that selects mounting for read only
-access or read/write access. Valid states are "RO" and "RW"
-
-.. code-block:: c
-
-    char                      *device,
-
-This argument is reserved for the name of a device that will be used to access
-the filesystem information. Current filesystem implementations are memory based
-and do not require a device to access filesystem information.
-
-.. code-block:: c
-
-    char                      *mount_point
-
-This is a pathname to a directory in a currently mounted filesystem that allows
-read, write and execute permissions.  If successful, the node found by
-evaluating this name, is stored in the mt_entry.
-
-**Processing:**
-
-This routine will handle the mounting of a filesystem on a mount point. If the
-operation is successful, a pointer to the mount table chain entry associated
-with the mounted filesystem will be returned to the calling function. The
-specifics about the processing required at the mount point and within the
-filesystem being mounted is isolated in the filesystem specific mount() and
-fsmount_me() functions. This allows the generic mount() function to remain
-unaltered even if new filesystem types are introduced.
-
-**Development Comments:**
-
-This routine will use get_file_system_options() to determine if the mount
-options are valid ("RO" or "RW").
-
-It confirms that a filesystem ops-table has been selected.
-
-Space is allocated for a mount table entry and selective elements of the
-temporary mount table entry are initialized.
-
-If a mount point is specified: The mount point is examined to determine that it
-is a directory and also has the appropriate permissions to allow a filesystem
-to be mounted.
-
-The current mount table chain is searched to determine that there is not
-another filesystem mounted at the mount point we are trying to mount onto.
-
-If a mount function is defined in the ops table for the filesystem containing
-the mount point, it is called at this time.
-
-If no mount point is specified: Processing if performed to set up the mount
-table chain entry as the base filesystem.
-
-If the fsmount_me() function is specified for ops-table of the filesystem being
-mounted, that function is called to initialize for the new filesystem.
-
-On successful completion, the temporary mount table entry will be placed on the
-mount table chain to record the presence of the mounted filesystem.
+File:
+    ``mount.c``
+
+    Arguments (Not a standard POSIX call):
+
+    .. code-block:: c
+
+        rtems_filesystem_mount_table_entry_t   **mt_entry,
+
+    If the mount operation is successful, this pointer to a pointer will be set
+    to reference the mount table chain entry that has been allocated for this
+    file system mount.
+
+    .. code-block:: c
+
+        rtems_filesystem_operations_table   *fs_ops,
+
+    This is a pointer to a table of functions that are associated with the file
+    system that we are about to mount. This is the mechanism to selected file
+    system type without keeping a dynamic database of all possible file system
+    types that are valid for the mount operation. Using this method, it is only
+    necessary to configure the filesystems that we wish to use into the RTEMS
+    build. Unused filesystems types will not be drawn into the build.
+
+    .. code-block:: c
+
+        char                      *fsoptions,
+
+    This argument points to a string that selects mounting for read only access
+    or read/write access. Valid states are "RO" and "RW"
+
+    .. code-block:: c
+
+        char                      *device,
+
+    This argument is reserved for the name of a device that will be used to
+    access the filesystem information. Current filesystem implementations are
+    memory based and do not require a device to access filesystem information.
+
+    .. code-block:: c
+
+        char                      *mount_point
+
+    This is a pathname to a directory in a currently mounted filesystem that
+    allows read, write and execute permissions.  If successful, the node found
+    by evaluating this name, is stored in the mt_entry.
+
+Processing:
+    This routine will handle the mounting of a filesystem on a mount point. If
+    the operation is successful, a pointer to the mount table chain entry
+    associated with the mounted filesystem will be returned to the calling
+    function. The specifics about the processing required at the mount point
+    and within the filesystem being mounted is isolated in the filesystem
+    specific mount() and fsmount_me() functions. This allows the generic
+    mount() function to remain unaltered even if new filesystem types are
+    introduced.
+
+Development Comments:
+    This routine will use get_file_system_options() to determine if the mount
+    options are valid ("RO" or "RW").
+
+    It confirms that a filesystem ops-table has been selected.
+
+    Space is allocated for a mount table entry and selective elements of the
+    temporary mount table entry are initialized.
+
+    If a mount point is specified: The mount point is examined to determine
+    that it is a directory and also has the appropriate permissions to allow a
+    filesystem to be mounted.
+
+    The current mount table chain is searched to determine that there is not
+    another filesystem mounted at the mount point we are trying to mount onto.
+
+    If a mount function is defined in the ops table for the filesystem
+    containing the mount point, it is called at this time.
+
+    If no mount point is specified: Processing if performed to set up the mount
+    table chain entry as the base filesystem.
+
+    If the fsmount_me() function is specified for ops-table of the filesystem
+    being mounted, that function is called to initialize for the new
+    filesystem.
+
+    On successful completion, the temporary mount table entry will be placed on
+    the mount table chain to record the presence of the mounted filesystem.
 
 open
 ====
 
-**File:**
-
-open.c
-
-**Processing:**
-
-This routine is layered on both RTEMS calls and filesystem specific
-implementations of the open() function. These functional interfaces should not
-change for new filesystems and therefore this code should be stable as new file
-systems are introduced.
-
-**Development Comments:**
-
-This routine will allocate a file control block for the file or device that we
-are about to open.
-
-It will then test to see if the pathname exists. If it does a
-rtems_filesystem_location_info_t data structure will be filled out. This
-structure contains information that associates node information, filesystem
-specific functions and mount table chain information with the pathname.
-
-If the create option has been it will attempt to create a node for a regular
-file along the specified path. If a file already exists along this path, an
-error will be generated; otherwise, a node will be allocated for the file under
-the filesystem that contains the pathname. When a new node is created, it is
-also evaluated so that an appropriate rtems_filesystem_location_info_t data
-structure can be filled out for the newly created node.
-
-If the file exists or the new file was created successfully, the file control
-block structure will be initialized with handler table information, node
-information and the rtems_filesystem_location_info_t data structure that
-describes the node and filesystem data in detail.
-
-If an open() function exists in the filesystem specific handlers table for the
-node that we are trying to open, it will be called at this time.
-
-If any error is detected in the process, cleanup is performed. It consists of
-freeing the file control block structure that was allocated at the beginning of
-the generic open() routine.
-
-On a successful open(), the index into the file descriptor table will be
-calculated and returned to the calling routine.
+File:
+    ``open.c``
+
+Processing:
+    This routine is layered on both RTEMS calls and filesystem specific
+    implementations of the open() function. These functional interfaces should
+    not change for new filesystems and therefore this code should be stable as
+    new file systems are introduced.
+
+Development Comments:
+    This routine will allocate a file control block for the file or device that
+    we are about to open.
+
+    It will then test to see if the pathname exists. If it does a
+    rtems_filesystem_location_info_t data structure will be filled out. This
+    structure contains information that associates node information, filesystem
+    specific functions and mount table chain information with the pathname.
+
+    If the create option has been it will attempt to create a node for a
+    regular file along the specified path. If a file already exists along this
+    path, an error will be generated; otherwise, a node will be allocated for
+    the file under the filesystem that contains the pathname. When a new node
+    is created, it is also evaluated so that an appropriate
+    rtems_filesystem_location_info_t data structure can be filled out for the
+    newly created node.
+
+    If the file exists or the new file was created successfully, the file
+    control block structure will be initialized with handler table information,
+    node information and the rtems_filesystem_location_info_t data structure
+    that describes the node and filesystem data in detail.
+
+    If an open() function exists in the filesystem specific handlers table for
+    the node that we are trying to open, it will be called at this time.
+
+    If any error is detected in the process, cleanup is performed. It consists
+    of freeing the file control block structure that was allocated at the
+    beginning of the generic open() routine.
+
+    On a successful open(), the index into the file descriptor table will be
+    calculated and returned to the calling routine.
 
 opendir
 =======
 
-**File:**
-
-opendir.c
-
-**Processing:**
-
-This routine will attempt to open a directory for read access. It will setup a
-DIR control structure that will be used to access directory information. This
-routine is layered on the generic open() routine and filesystem specific
-directory processing routines.
-
-**Development Comments:**
-
-The BSD group provided this routine.
+File:
+    ``opendir.c``
+
+Processing:
+    This routine will attempt to open a directory for read access. It will
+    setup a DIR control structure that will be used to access directory
+    information. This routine is layered on the generic open() routine and
+    filesystem specific directory processing routines.
+
+Development Comments:
+    The BSD group provided this routine.
 
 pathconf
 ========
 
-**File:**
-
-pathconf.c
-
-**Processing:**
-
-This routine will obtain the value of one of the path configuration parameters
-and return it to the calling routine. It is layered on the generic open() and
-fpathconf() functions. These interfaces should not change with the addition of
-new filesystem types.
-
-**Development Comments:**
-
-This routine will try to open the file indicated by path.
-
-If successful, the file descriptor will be used to access the pathconf value
-specified by ``name`` using the fpathconf() function.
-
-The file that was accessed is then closed.
+File:
+    ``pathconf.c``
+
+Processing:
+    This routine will obtain the value of one of the path configuration
+    parameters and return it to the calling routine. It is layered on the
+    generic open() and fpathconf() functions. These interfaces should not
+    change with the addition of new filesystem types.
+
+Development Comments:
+    This routine will try to open the file indicated by path.
+
+    If successful, the file descriptor will be used to access the pathconf
+    value specified by ``name`` using the fpathconf() function.
+
+    The file that was accessed is then closed.
 
 read
 ====
 
-**File:**
-
-deviceio.c
-
-**Processing:**
-
-This routine is layered on a set of RTEMS calls and filesystem specific read
-operations. The functions are layered in such a way as to isolate them from
-change as new filesystems are introduced.
-
-**Development Comments:**
-
-This routine will examine the type of file descriptor it is sent.
-
-If the file descriptor is associated with a network device, the read function
-will be mapped to a special network handler. The return code from the network
-handler will then be sent as the return code from generic read() function.
-
-For file descriptors that are associated with the filesystem the following
-sequence will be performed:
-
-# Obtain the file control block associated with the file descriptor
-
-# Range check the file descriptor
-
-# Determine that the buffer pointer is not invalid
-
-# Check that the count is not zero
-
-# Check the file control block to see if we have permissions to read
-
-# If there is a read function in the handler table, invoke the handler table
-  read() function
-
-# Use the return code from the handler table read function(number of bytes
-  read) to increment the offset element of the file control block
-
-# Return the number of bytes read to the calling program
+File:
+    ``deviceio.c``
+
+Processing:
+    This routine is layered on a set of RTEMS calls and filesystem specific
+    read operations. The functions are layered in such a way as to isolate them
+    from change as new filesystems are introduced.
+
+Development Comments:
+    This routine will examine the type of file descriptor it is sent.
+
+    If the file descriptor is associated with a network device, the read
+    function will be mapped to a special network handler. The return code from
+    the network handler will then be sent as the return code from generic
+    read() function.
+
+    For file descriptors that are associated with the filesystem the following
+    sequence will be performed:
+
+    #. Obtain the file control block associated with the file descriptor
+
+    #. Range check the file descriptor
+
+    #. Determine that the buffer pointer is not invalid
+
+    #. Check that the count is not zero
+
+    #. Check the file control block to see if we have permissions to read
+
+    #. If there is a read function in the handler table, invoke the handler
+       table read() function
+
+    #. Use the return code from the handler table read function(number of bytes
+       read) to increment the offset element of the file control block
+
+    #. Return the number of bytes read to the calling program
 
 readdir
 =======
 
-**File:**
-
-readdir.c
-
-**Processing:**
-
-This routine was acquired from the BSD group. It has not been altered from its
-original form.
-
-**Development Comments:**
-
-The routine calls a customized getdents() function that is provided by the
-user.  This routine provides the filesystem specific aspects of reading a
-directory.
-
-It is layered on the read() function in the directory handler table. This
-function has been mapped to the Imfs_dir_read() function.
+File:
+    ``readdir.c``
+
+Processing:
+    This routine was acquired from the BSD group. It has not been altered from
+    its original form.
+
+Development Comments:
+    The routine calls a customized getdents() function that is provided by the
+    user.  This routine provides the filesystem specific aspects of reading a
+    directory.
+
+    It is layered on the read() function in the directory handler table. This
+    function has been mapped to the Imfs_dir_read() function.
 
 unmount
 =======
 
-**File:**
-
-unmount.c
-
-**Processing:**
-
-This routine will attempt to dismount a mounted filesystem and then free all
-resources that were allocated for the management of that filesystem.
-
-**Development Comments:**
-
-- This routine will determine if there are any filesystems currently mounted
-  under the filesystem that we are trying to dismount. This would prevent the
-  dismount of the filesystem.
-
-- It will test to see if the current directory is in the filesystem that we are
-  attempting to dismount. This would prevent the dismount of the filesystem.
-
-- It will scan all the currently open file descriptors to determine is there is
-  an open file descriptor to a file in the filesystem that we are attempting to
-  unmount().
-
-If the above preconditions are met then the following sequence is performed:
-
-# Call the filesystem specific unmount() function for the filesystem that
-  contains the mount point. This routine should indicate that the mount point
-  no longer has a filesystem mounted below it.
-
-# Call the filesystem specific fsunmount_me() function for the mounted
-  filesystem that we are trying to unmount(). This routine should clean up any
-  resources that are no longer needed for the management of the file system
-  being un-mounted.
-
-# Extract the mount table entry for the filesystem that was just dismounted
-  from the mount table chain.
-
-# Free the memory associated with the extracted mount table entry.
+File:
+    ``unmount.c``
+
+Processing:
+    This routine will attempt to dismount a mounted filesystem and then free
+    all resources that were allocated for the management of that filesystem.
+
+Development Comments:
+    - This routine will determine if there are any filesystems currently
+      mounted under the filesystem that we are trying to dismount. This would
+      prevent the dismount of the filesystem.
+
+    - It will test to see if the current directory is in the filesystem that we
+      are attempting to dismount. This would prevent the dismount of the
+      filesystem.
+
+    - It will scan all the currently open file descriptors to determine is
+      there is an open file descriptor to a file in the filesystem that we are
+      attempting to unmount().
+
+    If the above preconditions are met then the following sequence is
+    performed:
+
+    #. Call the filesystem specific unmount() function for the filesystem that
+       contains the mount point. This routine should indicate that the mount
+       point no longer has a filesystem mounted below it.
+
+    #. Call the filesystem specific fsunmount_me() function for the mounted
+       filesystem that we are trying to unmount(). This routine should clean up
+       any resources that are no longer needed for the management of the file
+       system being un-mounted.
+
+    #. Extract the mount table entry for the filesystem that was just dismounted
+       from the mount table chain.
+
+    #. Free the memory associated with the extracted mount table entry.
 
 eval
 ====
 
-**File:**
-
-XXX
-
-**Processing:**
-
-XXX
-
-**Development Comments:**
-
-XXX
+File:
+    ``XXX``
+
+Processing:
+    XXX
+
+Development Comments:
+    XXX
 
 getdentsc
 =========
 
-**File:**
-
-XXX
-
-**Processing:**
-
-XXX
-
-**Development Comments:**
-
-XXX
+File:
+    ``XXX``
+
+Processing:
+    XXX
+
+Development Comments:
+    XXX

filesystem/command_and_variable.rst

@@ -2 +2 @@
 
 Command and Variable Index
-##########################
+**************************
 
 There are currently no Command and Variable Index entries.

filesystem/conf.py

@@ -4 +4 @@
 from conf import *
 
-version = '1.0'
-release = '5.0'
+version = '4.11.0'
+release = '4.11.0'
+
+project = "RTEMS Filesystem Design Guide"
 
 latex_documents = [
-        ('index', 'filesystem.tex', u'RTEMS Filesystem', u'RTEMS Documentation Project', 'manual'),
+        ('index', 'filesystem.tex', u'RTEMS Filesystem Design Guide', u'RTEMS Filesystem Design Guide', 'manual'),
 ]

filesystem/fileystem_implmentation.rst

@@ -6 +6 @@
 
 Filesystem Implementation Requirements
-######################################
+**************************************
 
 This chapter details the behavioral requirements that all filesystem
@@ -106 +106 @@
 application:
 
-# access()
-
-# chdir()
-
-# chmod()
-
-# chown()
-
-# close()
-
-# closedir()
-
-# fchmod()
-
-# fcntl()
-
-# fdatasync()
-
-# fpathconf()
-
-# fstat()
-
-# fsync()
-
-# ftruncate()
-
-# link()
-
-# lseek()
-
-# mkdir()
-
-# mknod()
-
-# mount()
-
-# open()
-
-# opendir()
-
-# pathconf()
-
-# read()
-
-# readdir()
-
-# rewinddir()
-
-# rmdir()
-
-# rmnod()
-
-# scandir()
-
-# seekdir()
-
-# stat()
-
-# telldir()
-
-# umask()
-
-# unlink()
-
-# unmount()
-
-# utime()
-
-# write()
+#. access()
+
+#. chdir()
+
+#. chmod()
+
+#. chown()
+
+#. close()
+
+#. closedir()
+
+#. fchmod()
+
+#. fcntl()
+
+#. fdatasync()
+
+#. fpathconf()
+
+#. fstat()
+
+#. fsync()
+
+#. ftruncate()
+
+#. link()
+
+#. lseek()
+
+#. mkdir()
+
+#. mknod()
+
+#. mount()
+
+#. open()
+
+#. opendir()
+
+#. pathconf()
+
+#. read()
+
+#. readdir()
+
+#. rewinddir()
+
+#. rmdir()
+
+#. rmnod()
+
+#. scandir()
+
+#. seekdir()
+
+#. stat()
+
+#. telldir()
+
+#. umask()
+
+#. unlink()
+
+#. unmount()
+
+#. utime()
+
+#. write()
 
 The filesystem's type as well as the node type within the filesystem determine
@@ -197 +197 @@
 the relationship between and among the following components.
 
-# File Descriptor Table
+File Descriptor Table:
   This is an internal RTEMS structure that tracks all currently defined file
   descriptors in the system. The index that is returned by the file open()
@@ -204 +204 @@
   represents the file control block.
 
-# Allocation of entry in the File Descriptor Table
+Allocation of entry in the File Descriptor Table:
   Access to the file descriptor table is controlled through a semaphore that is
   implemented using the rtems_libio_allocate() function. This routine will grab
@@ -213 +213 @@
   released to allow further operations on the table.
 
-# Maximum number of entries in the file descriptor table is configurable
+  Maximum number of entries in the file descriptor table is configurable
   through the src/exec/sapi/headers/confdefs.h file. If the
-  CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS constant is defined its value will
-  represent the maximum number of file descriptors that are allowed.  If
-  CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS is not specified a default value of
-  20 will be used as the maximum number of file descriptors allowed.
-
-# File control block - rtems_libio_t structure
-
+  ``CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS`` constant is defined its value
+  will represent the maximum number of file descriptors that are allowed.  If
+  ``CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS`` is not specified a default value
+  of 20 will be used as the maximum number of file descriptors allowed.
+
+File control block - rtems_libio_t structure:
   .. code-block:: c
 
@@ -259 +258 @@
 -----------------------------------------------------------------------------
 
-The rtems_filesystem_location_info_tt structure below provides sufficient
+The ``rtems_filesystem_location_info_tt`` structure below provides sufficient
 information to process nodes under a mounted filesystem.
 
@@ -317 +316 @@
 
 evalpath Handler
-~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-evalpath
-
-**Arguments:**
-
-.. code-block:: c
-
-    const char                        *pathname,      /* IN     */
-    int                                flags,         /* IN     */
-    rtems_filesystem_location_info_t  *pathloc        /* IN/OUT */
-
-**Description:**
-
-This routine is responsible for evaluating the pathname passed in based upon
-the flags and the valid ``rthems_filesystem_location_info_t``.  Additionally,
-it must make any changes to pathloc necessary to identify the pathname node.
-This should include calling the evalpath for a mounted filesystem, if the given
-filesystem supports the mount command.
-
-This routine returns a 0 if the evaluation was successful.  Otherwise, it
-returns a -1 and sets errno to the correct error.
-
-This routine is required and should NOT be set to NULL.
+^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``evalpath``
+
+Arguments:
+    .. code-block:: c
+
+        const char                        *pathname,      /* IN     */
+        int                                flags,         /* IN     */
+        rtems_filesystem_location_info_t  *pathloc        /* IN/OUT */
+
+Description:
+    This routine is responsible for evaluating the pathname passed in based
+    upon the flags and the valid ``rthems_filesystem_location_info_t``.
+    Additionally, it must make any changes to pathloc necessary to identify the
+    pathname node.  This should include calling the evalpath for a mounted
+    filesystem, if the given filesystem supports the mount command.
+
+    This routine returns a 0 if the evaluation was successful.  Otherwise, it
+    returns a -1 and sets errno to the correct error.
+
+    This routine is required and should NOT be set to NULL.
 
 evalformake Handler
-~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-evalformake
-
-**Arguments:**
-
-.. code-block:: c
-
-    const char                       *path,       /* IN */
-    rtems_filesystem_location_info_t *pathloc,    /* IN/OUT */
-    const char                      **name        /* OUT */
-
-**Description:**
-
-This method is given a path to evaluate and a valid start location.  It is
-responsible for finding the parent node for a requested make command, setting
-pathloc information to identify the parent node, and setting the name pointer
-to the first character of the name of the new node.  Additionally, if the
-filesystem supports the mount command, this method should call the evalformake
-routine for the mounted filesystem.
-
-This routine returns a 0 if the evaluation was successful.  Otherwise, it
-returns a -1 and sets errno to the correct error.
-
-This routine is required and should NOT be set to NULL.  However, if the
-filesystem does not support user creation of a new node, it may set errno to
-ENOSYS and return -1.
+^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``evalformake``
+
+Arguments:
+    .. code-block:: c
+
+        const char                       *path,       /* IN */
+        rtems_filesystem_location_info_t *pathloc,    /* IN/OUT */
+        const char                      **name        /* OUT */
+
+Description:
+    This method is given a path to evaluate and a valid start location.  It is
+    responsible for finding the parent node for a requested make command,
+    setting pathloc information to identify the parent node, and setting the
+    name pointer to the first character of the name of the new node.
+    Additionally, if the filesystem supports the mount command, this method
+    should call the evalformake routine for the mounted filesystem.
+
+    This routine returns a 0 if the evaluation was successful.  Otherwise, it
+    returns a -1 and sets errno to the correct error.
+
+    This routine is required and should NOT be set to NULL.  However, if the
+    filesystem does not support user creation of a new node, it may set errno
+    to ENOSYS and return -1.
 
 link Handler
-~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-link
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_location_info_t    *to_loc,      /* IN */
-    rtems_filesystem_location_info_t    *parent_loc,  /* IN */
-    const char                          *token        /* IN */
-
-**Description:**
-
-This routine is used to create a hard-link.
-
-It will first examine the st_nlink count of the node that we are trying to.  If
-the link count exceeds LINK_MAX an error will be returned.
-
-The name of the link will be normalized to remove extraneous separators from
-the end of the name.
-
-This routine is not required and may be set to NULL.
+^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``link``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_location_info_t    *to_loc,      /* IN */
+        rtems_filesystem_location_info_t    *parent_loc,  /* IN */
+        const char                          *token        /* IN */
+
+Description:
+    This routine is used to create a hard-link.
+
+    It will first examine the st_nlink count of the node that we are trying to.
+    If the link count exceeds LINK_MAX an error will be returned.
+
+    The name of the link will be normalized to remove extraneous separators
+    from the end of the name.
+
+    This routine is not required and may be set to NULL.
 
 unlink Handler
-~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``unlink``
+
+Arguments:
+    XXX
+
+Description:
+    XXX
 
 node_type Handler
-~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-node_type()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_location_info_t    *pathloc        /* IN */
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``node_type()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_location_info_t    *pathloc        /* IN */
+
+Description:
+    XXX
 
 mknod Handler
-~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-mknod()
-
-**Arguments:**
-
-.. code-block:: c
-
-    const char                          *token,        /* IN */
-    mode_t                               mode,         /* IN */
-    dev_t                                dev,          /* IN */
-    rtems_filesystem_location_info_t    *pathloc       /* IN/OUT */
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``mknod()``
+
+Arguments:
+    .. code-block:: c
+
+        const char                          *token,        /* IN */
+        mode_t                               mode,         /* IN */
+        dev_t                                dev,          /* IN */
+        rtems_filesystem_location_info_t    *pathloc       /* IN/OUT */
+
+Description:
+    XXX
 
 rmnod Handler
-~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``rmnod()``
+
+Arguments:
+    XXX
+
+Description:
+    XXX
 
 chown Handler
-~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-chown()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_location_info_t    *pathloc        /* IN */
-    uid_t                                owner          /* IN */
-    gid_t                                group          /* IN */
-
-**Description:**
-
-XXX
-
-.. COMMENT: @page
+^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``chown()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_location_info_t    *pathloc        /* IN */
+        uid_t                                owner          /* IN */
+        gid_t                                group          /* IN */
+
+Description:
+    XXX
 
 freenod Handler
-~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-freenod()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_location_info_t      *pathloc       /* IN */
-
-**Description:**
-
-This routine is used by the generic code to allow memory to be allocated during
-the evaluate routines, and set free when the generic code is finished accessing
-a node.  If the evaluate routines allocate memory to identify a node this
-routine should be utilized to free that memory.
-
-This routine is not required and may be set to NULL.
+^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``freenod()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_location_info_t      *pathloc       /* IN */
+
+Description:
+    This routine is used by the generic code to allow memory to be allocated
+    during the evaluate routines, and set free when the generic code is
+    finished accessing a node.  If the evaluate routines allocate memory to
+    identify a node this routine should be utilized to free that memory.
+
+    This routine is not required and may be set to NULL.
 
 mount Handler
-~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-mount()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_mount_table_entry_t   *mt_entry
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``mount()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_mount_table_entry_t   *mt_entry
+
+Description:
+    XXX
 
 fsmount_me Handler
-~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_mount_table_entry_t   *mt_entry
-
-**Description:**
-
-This function is provided with a filesystem to take care of the internal
-filesystem management details associated with mounting that filesystem under
-the RTEMS environment.
-
-It is not responsible for the mounting details associated the filesystem
-containing the mount point.
-
-The rtems_filesystem_mount_table_entry_t structure contains the key elements
-below:
-
-.. code-block:: c
-
-    rtems_filesystem_location_info_t         *mt_point_node,
-
-This structure contains information about the mount point. This
-allows us to find the ops-table and the handling functions
-associated with the filesystem containing the mount point.
-
-.. code-block:: c
-
-    rtems_filesystem_location_info_t         *fs_root_node,
-
-This structure contains information about the root node in the file
-system to be mounted. It allows us to find the ops-table and the
-handling functions associated with the filesystem to be mounted.
-
-.. code-block:: c
+^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``imfs_fsmount_me``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_mount_table_entry_t   *mt_entry
+
+Description:
+    This function is provided with a filesystem to take care of the internal
+    filesystem management details associated with mounting that filesystem
+    under the RTEMS environment.
+
+    It is not responsible for the mounting details associated the filesystem
+    containing the mount point.
+
+    The rtems_filesystem_mount_table_entry_t structure contains the key
+    elements below:
+
+    .. code-block:: c
+
+        rtems_filesystem_location_info_t         *mt_point_node,
+
+    This structure contains information about the mount point. This allows us
+    to find the ops-table and the handling functions associated with the
+    filesystem containing the mount point.
+
+    .. code-block:: c
+
+        rtems_filesystem_location_info_t         *fs_root_node,
+
+    This structure contains information about the root node in the file system
+    to be mounted. It allows us to find the ops-table and the handling
+    functions associated with the filesystem to be mounted.
+
+    .. code-block:: c
 
     rtems_filesystem_options_t                 options,
 
-Read only or read/write access
-
-.. code-block:: c
-
-    void                                         *fs_info,
-
-This points to an allocated block of memory the will be used to hold any
-filesystem specific information of a global nature. This allocated region if
-important because it allows us to mount the same filesystem type more than once
-under the RTEMS system.  Each instance of the mounted filesystem has its own
-set of global management information that is separate from the global
-management information associated with the other instances of the mounted
-filesystem type.
-
-.. code-block:: c
-
-    rtems_filesystem_limits_and_options_t    pathconf_info,
-
-The table contains the following set of values associated with the mounted
-filesystem:
-
-- link_max
-
-- max_canon
-
-- max_input
-
-- name_max
-
-- path_max
-
-- pipe_buf
-
-- posix_async_io
-
-- posix_chown_restrictions
-
-- posix_no_trunc
-
-- posix_prio_io
-
-- posix_sync_io
-
-- posix_vdisable
-
-These values are accessed with the pathconf() and the fpathconf () functions.
-
-.. code-block:: c
-
-    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.
-
-If the mt_point_node.node_access is NULL then we are mounting the base file
-system.
-
-The routine will create a directory node for the root of the IMFS file system.
-
-The node will have read, write and execute permissions for owner, group and
-others.
-
-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 entry will be
-set to point the filesystem information structure.
-
-The pathconf_info element of the mount table will be set to the appropriate
-table of path configuration constants (LIMITS_AND_OPTIONS).
-
-The fs_root_node structure will be filled in with the following:
-
-- pointer to the allocated root node of the filesystem
-
-- directory handlers for a directory node under the IMFS filesystem
-
-- OPS table functions for the IMFS
-
-A 0 will be returned to the calling routine if the process succeeded, otherwise
-a 1 will be returned.
+    Read only or read/write access
+
+    .. code-block:: c
+
+        void                                         *fs_info,
+
+    This points to an allocated block of memory the will be used to hold any
+    filesystem specific information of a global nature. This allocated region
+    if important because it allows us to mount the same filesystem type more
+    than once under the RTEMS system.  Each instance of the mounted filesystem
+    has its own set of global management information that is separate from the
+    global management information associated with the other instances of the
+    mounted filesystem type.
+
+    .. code-block:: c
+
+        rtems_filesystem_limits_and_options_t    pathconf_info,
+
+    The table contains the following set of values associated with the mounted
+    filesystem:
+
+    - link_max
+
+    - max_canon
+
+    - max_input
+
+    - name_max
+
+    - path_max
+
+    - pipe_buf
+
+    - posix_async_io
+
+    - posix_chown_restrictions
+
+    - posix_no_trunc
+
+    - posix_prio_io
+
+    - posix_sync_io
+
+    - posix_vdisable
+
+    These values are accessed with the pathconf() and the fpathconf () functions.
+
+    .. code-block:: c
+
+        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.
+
+    If the mt_point_node.node_access is NULL then we are mounting the base file
+    system.
+
+    The routine will create a directory node for the root of the IMFS file
+    system.
+
+    The node will have read, write and execute permissions for owner, group and
+    others.
+
+    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
+    entry will be set to point the filesystem information structure.
+
+    The pathconf_info element of the mount table will be set to the appropriate
+    table of path configuration constants (LIMITS_AND_OPTIONS).
+
+    The fs_root_node structure will be filled in with the following:
+
+    - pointer to the allocated root node of the filesystem
+
+    - directory handlers for a directory node under the IMFS filesystem
+
+    - OPS table functions for the IMFS
+
+    A 0 will be returned to the calling routine if the process succeeded,
+    otherwise a 1 will be returned.
 
 unmount Handler
-~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+Description:
+    XXX
 
 fsunmount_me Handler
-~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-imfs_fsunmount_me()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_mount_table_entry_t   *mt_entry
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``imfs_fsunmount_me()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_mount_table_entry_t   *mt_entry
+
+Description:
+    XXX
 
 utime Handler
-~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+Description:
+    XXX
 
 eval_link Handler
-~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+Description:
+    XXX
 
 symlink Handler
-~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+Description:
+    XXX
 
 File Handler Table Functions
@@ -763 +713 @@
 
 open Handler
-~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-open()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t   *iop,
-    const char      *pathname,
-    unsigned32       flag,
-    unsigned32       mode
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``open()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t   *iop,
+        const char      *pathname,
+        unsigned32       flag,
+        unsigned32       mode
+
+Description:
+    XXX
 
 close Handler
 ~~~~~~~~~~~~~
 
-**Corresponding Structure Element:**
-
-close()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t     *iop
-
-**Description:**
-
-XXX
-
-**NOTES:**
-
-XXX
+Corresponding Structure Element:
+    ``close()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t     *iop
+
+Description:
+    XXX
+
+NOTES:
+    XXX
 
 read Handler
 ~~~~~~~~~~~~
 
-**Corresponding Structure Element:**
-
-read()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t     *iop,
-    void              *buffer,
-    unsigned32         count
-
-**Description:**
-
-XXX
-
-**NOTES:**
-
-XXX
+Corresponding Structure Element:
+    ``read()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t     *iop,
+        void              *buffer,
+        unsigned32         count
+
+Description:
+    XXX
+
+NOTES:
+    XXX
 
 write Handler
 ~~~~~~~~~~~~~
 
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**Description:**
-
-XXX
-
-**NOTES:**
-
-XXX
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+Description:
+    XXX
+
+NOTES:
+    XXX
 
 ioctl Handler
 ~~~~~~~~~~~~~
 
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t     *iop,
-    unsigned32       command,
-    void              *buffer
-
-**Description:**
-
-XXX
-
-**NOTES:**
-
-XXX
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t     *iop,
+        unsigned32       command,
+        void              *buffer
+
+Description:
+    XXX
+
+NOTES:
+    XXX
 
 lseek Handler
 ~~~~~~~~~~~~~
 
-**Corresponding Structure Element:**
-
-lseek()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t     *iop,
-    off_t              offset,
-    int                whence
-
-**Description:**
-
-XXX
-
-**NOTES:**
-
-XXX
+Corresponding Structure Element:
+    ``lseek()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t     *iop,
+        off_t              offset,
+        int                whence
+
+Description:
+    XXX
+
+NOTES:
+    XXX
 
 fstat Handler
 ~~~~~~~~~~~~~
 
-**Corresponding Structure Element:**
-
-fstat()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_location_info_t   *loc,
-    struct stat                        *buf
-
-**Description:**
-
-The following information is extracted from the filesystem specific node and
-placed in the ``stat`` structure:
-
-- st_mode
-
-- st_nlink
-
-- st_ino
-
-- st_uid
-
-- st_gid
-
-- st_atime
-
-- st_mtime
-
-- st_ctime
-
-**NOTES:**
-
-Both the ``stat()`` and ``lstat()`` services are implemented directly using the
-``fstat()`` handler.  The difference in behavior is determined by how the path
-is evaluated prior to this handler being called on a particular file entity.
-
-The ``fstat()`` system call is implemented directly on top of this filesystem
-handler.
+Corresponding Structure Element:
+    ``fstat()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_location_info_t   *loc,
+        struct stat                        *buf
+
+Description:
+    The following information is extracted from the filesystem specific node
+    and placed in the ``stat`` structure:
+
+    - st_mode
+
+    - st_nlink
+
+    - st_ino
+
+    - st_uid
+
+    - st_gid
+
+    - st_atime
+
+    - st_mtime
+
+    - st_ctime
+
+NOTES:
+    Both the ``stat()`` and ``lstat()`` services are implemented directly using
+    the ``fstat()`` handler.  The difference in behavior is determined by how
+    the path is evaluated prior to this handler being called on a particular
+    file entity.
+
+    The ``fstat()`` system call is implemented directly on top of this
+    filesystem handler.
 
 fchmod Handler
 ~~~~~~~~~~~~~~
 
-**Corresponding Structure Element:**
-
-fchmod()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t     *iop
-    mode_t             mode
-
-**Description:**
-
-XXX
-
-**NOTES:**
-
-XXX
+Corresponding Structure Element:
+    ``fchmod()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t     *iop
+        mode_t             mode
+
+Description:
+    XXX
+
+NOTES:
+    XXX
 
 ftruncate Handler
 ~~~~~~~~~~~~~~~~~
 
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**Description:**
-
-XXX
-
-**NOTES:**
-
-XXX
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+Description:
+    XXX
+
+NOTES:
+    XXX
 
 fpathconf Handler
 ~~~~~~~~~~~~~~~~~
 
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**Description:**
-
-XXX
-
-**NOTES:**
-
-XXX
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+Description:
+    XXX
+
+NOTES:
+    XXX
 
 fsync Handler
 ~~~~~~~~~~~~~
 
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**Description:**
-
-XXX
-
-**NOTES:**
-
-XXX
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+Description:
+    XXX
+
+NOTES:
+    XXX
 
 fdatasync Handler
 ~~~~~~~~~~~~~~~~~
 
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**Description:**
-
-XXX
-
-**NOTES:**
-
-XXX
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+Description:
+    XXX
+
+NOTES:
+    XXX
 
 fcntl Handler
 ~~~~~~~~~~~~~
 
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**Description:**
-
-XXX
-
-**NOTES:**
-
-XXX
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+Description:
+    XXX
+
+NOTES:
+    XXX

filesystem/in-memory.rst

@@ -6 +6 @@
 
 In-Memory Filesystem
-####################
+********************
 
 This chapter describes the In-Memory FileSystem (IMFS).  The IMFS is a full
@@ -130 +130 @@
 Miscellaneous IMFS Information
 ==============================
+
+TBD
 
 Memory associated with the IMFS
@@ -198 +200 @@
 
 IMFS_evalpath()
-~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**File:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+File:
+    XXX
+
+Description:
+    XXX
 
 IMFS_evalformake()
-~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**File:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+File:
+    XXX
+
+Description:
+    XXX
 
 IMFS_link()
-~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-link
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_location_info_t    *to_loc,      /* IN */
-    rtems_filesystem_location_info_t    *parent_loc,  /* IN */
-    const char                          *token        /* IN */
-
-**File:**
-
-imfs_link.c
-
-**Description:**
-
-This routine is used in the IMFS filesystem to create a hard-link.
-
-It will first examine the st_nlink count of the node that we are trying to.  If
-the link count exceeds LINK_MAX an error will be returned.
-
-The name of the link will be normalized to remove extraneous separators from
-the end of the name.
-
-IMFS_create_node will be used to create a filesystem node that will have the
-following characteristics:
-
-- parent that was determined in the link() function in file link.c
-
-- Type will be set to IMFS_HARD_LINK
-
-- name will be set to the normalized name
-
-- mode of the hard-link will be set to the mode of the target node
-
-If there was trouble allocating memory for the new node an error will be
-returned.
-
-The st_nlink count of the target node will be incremented to reflect the new
-link.
-
-The time fields of the link will be set to reflect the creation time of the
-hard-link.
+^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``link``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_location_info_t    *to_loc,      /* IN */
+        rtems_filesystem_location_info_t    *parent_loc,  /* IN */
+        const char                          *token        /* IN */
+
+File:
+    ``imfs_link.c``
+
+Description:
+
+    This routine is used in the IMFS filesystem to create a hard-link.
+
+    It will first examine the st_nlink count of the node that we are trying to.
+    If the link count exceeds LINK_MAX an error will be returned.
+
+    The name of the link will be normalized to remove extraneous separators
+    from the end of the name.
+
+    IMFS_create_node will be used to create a filesystem node that will have
+    the following characteristics:
+
+    - parent that was determined in the link() function in file link.c
+
+    - Type will be set to IMFS_HARD_LINK
+
+    - name will be set to the normalized name
+
+    - mode of the hard-link will be set to the mode of the target node
+
+    If there was trouble allocating memory for the new node an error will be
+    returned.
+
+    The st_nlink count of the target node will be incremented to reflect the
+    new link.
+
+    The time fields of the link will be set to reflect the creation time of the
+    hard-link.
 
 IMFS_unlink()
-~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**File:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+File:
+    XXX
+
+Description:
+    XXX
 
 IMFS_node_type()
-~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-IMFS_node_type()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_location_info_t    *pathloc        /* IN */
-
-**File:**
-
-imfs_ntype.c
-
-**Description:**
-
-This routine will locate the IMFS_jnode_t structure that holds ownership
-information for the selected node in the filesystem.
-
-This structure is pointed to by pathloc->node_access.
-
-The IMFS_jnode_t type element indicates one of the node types listed below:
-
-- RTEMS_FILESYSTEM_DIRECTORY
-
-- RTEMS_FILESYSTEM_DEVICE
-
-- RTEMS_FILESYSTEM_HARD_LINK
-
-- RTEMS_FILESYSTEM_MEMORY_FILE
+^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``IMFS_node_type()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_location_info_t    *pathloc        /* IN */
+
+File:
+    ``imfs_ntype.c``
+
+Description:
+    This routine will locate the IMFS_jnode_t structure that holds ownership
+    information for the selected node in the filesystem.
+
+    This structure is pointed to by pathloc->node_access.
+
+    The IMFS_jnode_t type element indicates one of the node types listed below:
+
+    - RTEMS_FILESYSTEM_DIRECTORY
+
+    - RTEMS_FILESYSTEM_DEVICE
+
+    - RTEMS_FILESYSTEM_HARD_LINK
+
+    - RTEMS_FILESYSTEM_MEMORY_FILE
 
 .. COMMENT: @page
 
 IMFS_mknod()
-~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-IMFS_mknod()
-
-**Arguments:**
-
-.. code-block:: c
-
-    const char                          *token,        /* IN */
-    mode_t                               mode,         /* IN */
-    dev_t                                dev,          /* IN */
-    rtems_filesystem_location_info_t    *pathloc       /* IN/OUT */
-
-**File:**
-
-imfs_mknod.c
-
-**Description:**
-
-This routine will examine the mode argument to determine is we are trying to
-create a directory, regular file and a device node. The creation of other node
-types is not permitted and will cause an assert.
-
-Memory space will be allocated for a ``jnode`` and the node will be set up
-according to the nodal type that was specified. The IMFS_create_node() function
-performs the allocation and setup of the node.
-
-The only problem that is currently reported is the lack of memory when we
-attempt to allocate space for the ``jnode`` (ENOMEN).
+^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``IMFS_mknod()``
+
+Arguments:
+    .. code-block:: c
+
+        const char                          *token,        /* IN */
+        mode_t                               mode,         /* IN */
+        dev_t                                dev,          /* IN */
+        rtems_filesystem_location_info_t    *pathloc       /* IN/OUT */
+
+File:
+    ``imfs_mknod.c``
+
+Description:
+    This routine will examine the mode argument to determine is we are trying
+    to create a directory, regular file and a device node. The creation of
+    other node types is not permitted and will cause an assert.
+
+    Memory space will be allocated for a ``jnode`` and the node will be set up
+    according to the nodal type that was specified. The IMFS_create_node()
+    function performs the allocation and setup of the node.
+
+    The only problem that is currently reported is the lack of memory when we
+    attempt to allocate space for the ``jnode`` (ENOMEN).
 
 IMFS_rmnod()
-~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**File:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+File:
+    XXX
+
+Description:
+    XXX
 
 IMFS_chown()
-~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-IMFS_chown()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_location_info_t    *pathloc        /* IN */
-    uid_t                                owner          /* IN */
-    gid_t                                group          /* IN */
-
-**File:**
-
-imfs_chown.c
-
-**Description:**
-
-This routine will locate the IMFS_jnode_t structure that holds ownership
-information for the selected node in the filesystem.
-
-This structure is pointed to by pathloc->node_access.
-
-The st_uid and st_gid fields of the node are then modified. Since this is a
-memory based filesystem, no further action is required to alter the ownership
-of the IMFS_jnode_t structure.
+^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``IMFS_chown()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_location_info_t    *pathloc        /* IN */
+        uid_t                                owner          /* IN */
+        gid_t                                group          /* IN */
+
+File:
+    ``imfs_chown.c``
+
+Description:
+    This routine will locate the IMFS_jnode_t structure that holds ownership
+    information for the selected node in the filesystem.
+
+    This structure is pointed to by pathloc->node_access.
+
+    The st_uid and st_gid fields of the node are then modified. Since this is a
+    memory based filesystem, no further action is required to alter the
+    ownership of the IMFS_jnode_t structure.
 
 IMFS_freenod()
-~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-IMFS_freenod()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_location_info_t      *pathloc       /* IN */
-
-**File:**
-
-imfs_free.c
-
-**Description:**
-
-This method is a private function to the IMFS.  It is called by IMFS routines
-to free nodes that have been allocated.  Examples of where this routine may be
-called from are unlink and rmnod.
-
-Note: This routine should not be confused with the filesystem callback freenod.
-The IMFS allocates memory until the node no longer exists.
+^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``IMFS_freenod()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_location_info_t      *pathloc       /* IN */
+
+File:
+    ``imfs_free.c``
+
+Description:
+    This method is a private function to the IMFS.  It is called by IMFS
+    routines to free nodes that have been allocated.  Examples of where this
+    routine may be called from are unlink and rmnod.
+
+    Note: This routine should not be confused with the filesystem callback
+    freenod.  The IMFS allocates memory until the node no longer exists.
 
 IMFS_freenodinfo()
-~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-IMFS_freenodinfo()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_location_info_t      *pathloc       /* IN */
-
-**File:**
-
-imfs_free.c
-
-**Description:**
-
-The In-Memory File System does not need to allocate memory during the evaluate
-routines. Therefore, this routine simply routines PASS.
+^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``IMFS_freenodinfo()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_location_info_t      *pathloc       /* IN */
+
+File:
+    ``imfs_free.c``
+
+Description:
+    The In-Memory File System does not need to allocate memory during the
+    evaluate routines. Therefore, this routine simply routines PASS.
 
 IMFS_mount()
-~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-IMFS_mount()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_mount_table_entry_t   *mt_entry
-
-**File:**
-
-imfs_mount.c
-
-**Description:**
-
-This routine provides the filesystem specific processing required to mount a
-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
-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 NULL,
-the directory does not serve as a mount point. A non-NULL entry indicates that
-the directory does serve as a mount point and the value of info.directory.mt_fs
-can be used to locate the mount table chain entry that describes the filesystem
-mounted at this point.
+^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``IMFS_mount()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_mount_table_entry_t   *mt_entry
+
+File:
+    ``imfs_mount.c``
+
+Description:
+    This routine provides the filesystem specific processing required to mount
+    a 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 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 NULL, the directory does not serve as a
+    mount point. A non-NULL entry indicates that the directory does serve as a
+    mount point and the value of info.directory.mt_fs can be used to locate the
+    mount table chain entry that describes the filesystem mounted at this
+    point.
 
 IMFS_fsmount_me()
-~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-IMFS_initialize()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_mount_table_entry_t   *mt_entry
-
-**File:**
-
-imfs_init.c
-
-**Description:**
-
-This function is provided with a filesystem to take care of the internal
-filesystem management details associated with mounting that filesystem under
-the RTEMS environment.
-
-It is not responsible for the mounting details associated the filesystem
-containing the mount point.
-
-The rtems_filesystem_mount_table_entry_t structure contains the key elements
-below:
-
-.. code-block:: c
-
-    rtems_filesystem_location_info_t         *mt_point_node,
-
-This structure contains information about the mount point. This
-allows us to find the ops-table and the handling functions
-associated with the filesystem containing the mount point.
-
-.. code-block:: c
-
-    rtems_filesystem_location_info_t         *fs_root_node,
-
-This structure contains information about the root node in the file
-system to be mounted. It allows us to find the ops-table and the
-handling functions associated with the filesystem to be mounted.
-
-.. code-block:: c
-
-    rtems_filesystem_options_t                 options,
-
-Read only or read/write access
-
-.. code-block:: c
-
-    void                                         *fs_info,
-
-This points to an allocated block of memory the will be used to hold any
-filesystem specific information of a global nature. This allocated region if
-important because it allows us to mount the same filesystem type more than once
-under the RTEMS system.  Each instance of the mounted filesystem has its own
-set of global management information that is separate from the global
-management information associated with the other instances of the mounted
-filesystem type.
-
-.. code-block:: c
-
-    rtems_filesystem_limits_and_options_t    pathconf_info,
-
-The table contains the following set of values associated with the mounted
-filesystem:
-
-- link_max
-
-- max_canon
-
-- max_input
-
-- name_max
-
-- path_max
-
-- pipe_buf
-
-- posix_async_io
-
-- posix_chown_restrictions
-
-- posix_no_trunc
-
-- posix_prio_io
-
-- posix_sync_io
-
-- posix_vdisable
-
-These values are accessed with the pathconf() and the fpathconf () functions.
-
-.. code-block:: c
-
-    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.
-
-If the mt_point_node.node_access is NULL then we are mounting the base file
-system.
-
-The routine will create a directory node for the root of the IMFS file system.
-
-The node will have read, write and execute permissions for owner, group and
-others.
-
-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 entry will be
-set to point the filesystem information structure.
-
-The pathconf_info element of the mount table will be set to the appropriate
-table of path configuration constants ( IMFS_LIMITS_AND_OPTIONS ).
-
-The fs_root_node structure will be filled in with the following:
-
-- pointer to the allocated root node of the filesystem
-
-- directory handlers for a directory node under the IMFS filesystem
-
-- OPS table functions for the IMFS
-
-A 0 will be returned to the calling routine if the process succeeded, otherwise
-a 1 will be returned.
+^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``IMFS_initialize()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_mount_table_entry_t   *mt_entry
+
+File:
+    ``imfs_init.c``
+
+Description:
+    This function is provided with a filesystem to take care of the internal
+    filesystem management details associated with mounting that filesystem
+    under the RTEMS environment.
+
+    It is not responsible for the mounting details associated the filesystem
+    containing the mount point.
+
+    The rtems_filesystem_mount_table_entry_t structure contains the key
+    elements below:
+
+    .. code-block:: c
+
+        rtems_filesystem_location_info_t         *mt_point_node,
+
+    This structure contains information about the mount point. This allows us
+    to find the ops-table and the handling functions associated with the
+    filesystem containing the mount point.
+
+    .. code-block:: c
+
+        rtems_filesystem_location_info_t         *fs_root_node,
+
+    This structure contains information about the root node in the file system
+    to be mounted. It allows us to find the ops-table and the handling
+    functions associated with the filesystem to be mounted.
+
+    .. code-block:: c
+
+        rtems_filesystem_options_t                 options,
+
+    Read only or read/write access
+
+    .. code-block:: c
+
+        void                                         *fs_info,
+
+    This points to an allocated block of memory the will be used to hold any
+    filesystem specific information of a global nature. This allocated region
+    if important because it allows us to mount the same filesystem type more
+    than once under the RTEMS system.  Each instance of the mounted filesystem
+    has its own set of global management information that is separate from the
+    global management information associated with the other instances of the
+    mounted filesystem type.
+
+    .. code-block:: c
+
+        rtems_filesystem_limits_and_options_t    pathconf_info,
+
+    The table contains the following set of values associated with the mounted
+    filesystem:
+
+    - link_max
+
+    - max_canon
+
+    - max_input
+
+    - name_max
+
+    - path_max
+
+    - pipe_buf
+
+    - posix_async_io
+
+    - posix_chown_restrictions
+
+    - posix_no_trunc
+
+    - posix_prio_io
+
+    - posix_sync_io
+
+    - posix_vdisable
+
+    These values are accessed with the pathconf() and the fpathconf ()
+    functions.
+
+    .. code-block:: c
+
+        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.
+
+    If the mt_point_node.node_access is NULL then we are mounting the base file
+    system.
+
+    The routine will create a directory node for the root of the IMFS file
+    system.
+
+    The node will have read, write and execute permissions for owner, group and
+    others.
+
+    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
+    entry will be set to point the filesystem information structure.
+
+    The pathconf_info element of the mount table will be set to the appropriate
+    table of path configuration constants ( IMFS_LIMITS_AND_OPTIONS ).
+
+    The fs_root_node structure will be filled in with the following:
+
+    - pointer to the allocated root node of the filesystem
+
+    - directory handlers for a directory node under the IMFS filesystem
+
+    - OPS table functions for the IMFS
+
+    A 0 will be returned to the calling routine if the process succeeded,
+    otherwise a 1 will be returned.
 
 IMFS_unmount()
-~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-IMFS_unmount()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_mount_table_entry_t   *mt_entry
-
-**File:**
-
-imfs_unmount.c
-
-**Description:**
-
-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 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.
+^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``IMFS_unmount()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_mount_table_entry_t   *mt_entry
+
+File:
+    ``imfs_unmount.c``
+
+Description:
+    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 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.
 
 IMFS_fsunmount()
-~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-imfs_fsunmount()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_mount_table_entry_t   *mt_entry
-
-**File:**
-
-imfs_init.c
-
-**Description:**
-
-This method unmounts this instance of the IMFS file system.  It is the
-counterpart to the IMFS_initialize routine.  It is called by the generic code
-under the fsunmount_me callback.
-
-All method loops finding the first encountered node with no children and
-removing the node from the tree, thus returning allocated resources.  This is
-done until all allocated nodes are returned.
+^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``imfs_fsunmount()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_mount_table_entry_t   *mt_entry
+
+File:
+    ``imfs_init.c``
+
+Description:
+    This method unmounts this instance of the IMFS file system.  It is the
+    counterpart to the IMFS_initialize routine.  It is called by the generic
+    code under the fsunmount_me callback.
+
+    All method loops finding the first encountered node with no children and
+    removing the node from the tree, thus returning allocated resources.  This
+    is done until all allocated nodes are returned.
 
 IMFS_utime()
-~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**File:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+File:
+    XXX
+
+Description:
+    XXX
 
 IMFS_eval_link()
-~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**File:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+File:
+    XXX
+
+Description:
+    XXX
 
 Regular File Handler Table Functions
@@ -754 +698 @@
 
 memfile_open() for Regular Files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-memfile_open()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t   *iop,
-    const char      *pathname,
-    unsigned32       flag,
-    unsigned32       mode
-
-**File:**
-
-memfile.c
-
-**Description:**
-
-Currently this function is a shell. No meaningful processing is performed and a
-success code is always returned.
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``memfile_open()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t   *iop,
+        const char      *pathname,
+        unsigned32       flag,
+        unsigned32       mode
+
+File:
+    ``memfile.c``
+
+Description:
+    Currently this function is a shell. No meaningful processing is performed
+    and a success code is always returned.
 
 memfile_close() for Regular Files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-memfile_close()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t     *iop
-
-**File:**
-
-memfile.c
-
-**Description:**
-
-This routine is a dummy for regular files under the base filesystem. It
-performs a capture of the IMFS_jnode_t pointer from the file control block and
-then immediately returns a success status.
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``memfile_close()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t     *iop
+
+File:
+    ``memfile.c``
+
+Description:
+    This routine is a dummy for regular files under the base filesystem. It
+    performs a capture of the IMFS_jnode_t pointer from the file control block
+    and then immediately returns a success status.
 
 memfile_read() for Regular Files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-memfile_read()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t     *iop,
-    void              *buffer,
-    unsigned32         count
-
-**File:**
-
-memfile.c
-
-**Description:**
-
-This routine will determine the ``jnode`` that is associated with this file.
-
-It will then call IMFS_memfile_read() with the ``jnode``, file position index,
-buffer and transfer count as arguments.
-
-IMFS_memfile_read() will do the following:
-
-- Verify that the ``jnode`` is associated with a memory file
-
-- Verify that the destination of the read is valid
-
-- Adjust the length of the read if it is too long
-
-- Acquire data from the memory blocks associated with the file
-
-- Update the access time for the data in the file
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``memfile_read()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t     *iop,
+        void              *buffer,
+        unsigned32         count
+
+File:
+    ``memfile.c``
+
+Description:
+    This routine will determine the ``jnode`` that is associated with this
+    file.
+
+    It will then call IMFS_memfile_read() with the ``jnode``, file position
+    index, buffer and transfer count as arguments.
+
+    IMFS_memfile_read() will do the following:
+
+    - Verify that the ``jnode`` is associated with a memory file
+
+    - Verify that the destination of the read is valid
+
+    - Adjust the length of the read if it is too long
+
+    - Acquire data from the memory blocks associated with the file
+
+    - Update the access time for the data in the file
 
 memfile_write() for Regular Files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**File:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+File:
+    XXX
+
+Description:
+    XXX
 
 memfile_ioctl() for Regular Files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t   *iop,
-    unsigned32       command,
-    void            *buffer
-
-**File:**
-
-memfile.c
-
-**Description:**
-
-The current code is a placeholder for future development. The routine returns
-a successful completion status.
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t   *iop,
+        unsigned32       command,
+        void            *buffer
+
+File:
+    ``memfile.c``
+
+Description:
+    The current code is a placeholder for future development. The routine
+    returns a successful completion status.
 
 memfile_lseek() for Regular Files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-Memfile_lseek()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t     *iop,
-    off_t              offset,
-    int                whence
-
-**File:**
-
-memfile.c
-
-**Description:**
-
-This routine make sure that the memory based file is sufficiently large to
-allow for the new file position index.
-
-The IMFS_memfile_extend() function is used to evaluate the current size of the
-memory file and allocate additional memory blocks if required by the new file
-position index. A success code is always returned from this routine.
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``Memfile_lseek()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t     *iop,
+        off_t              offset,
+        int                whence
+
+File:
+    ``memfile.c``
+
+Description:
+    This routine make sure that the memory based file is sufficiently large to
+    allow for the new file position index.
+
+    The IMFS_memfile_extend() function is used to evaluate the current size of
+    the memory file and allocate additional memory blocks if required by the
+    new file position index. A success code is always returned from this
+    routine.
 
 IMFS_stat() for Regular Files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-IMFS_stat()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_location_info_t   *loc,
-    struct stat                        *buf
-
-**File:**
-
-imfs_stat.c
-
-**Description:**
-
-This routine actually performs status processing for both devices and regular
-files.
-
-The IMFS_jnode_t structure is referenced to determine the type of node under
-the filesystem.
-
-If the node is associated with a device, node information is extracted and
-transformed to set the st_dev element of the stat structure.
-
-If the node is a regular file, the size of the regular file is extracted from
-the node.
-
-This routine rejects other node types.
-
-The following information is extracted from the node and placed in the stat
-structure:
-
-- st_mode
-
-- st_nlink
-
-- st_ino
-
-- st_uid
-
-- st_gid
-
-- st_atime
-
-- st_mtime
-
-- st_ctime
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``IMFS_stat()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_location_info_t   *loc,
+        struct stat                        *buf
+
+File:
+    ``imfs_stat.c``
+
+Description:
+    This routine actually performs status processing for both devices and
+    regular files.
+
+    The IMFS_jnode_t structure is referenced to determine the type of node
+    under the filesystem.
+
+    If the node is associated with a device, node information is extracted and
+    transformed to set the st_dev element of the stat structure.
+
+    If the node is a regular file, the size of the regular file is extracted
+    from the node.
+
+    This routine rejects other node types.
+
+    The following information is extracted from the node and placed in the stat
+    structure:
+
+    - st_mode
+
+    - st_nlink
+
+    - st_ino
+
+    - st_uid
+
+    - st_gid
+
+    - st_atime
+
+    - st_mtime
+
+    - st_ctime
 
 IMFS_fchmod() for Regular Files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-IMFS_fchmod()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t     *iop
-    mode_t             mode
-
-**File:**
-
-imfs_fchmod.c
-
-**Description:**
-
-This routine will obtain the pointer to the IMFS_jnode_t structure from the
-information currently in the file control block.
-
-Based on configuration the routine will acquire the user ID from a call to
-getuid() or from the IMFS_jnode_t structure.
-
-It then checks to see if we have the ownership rights to alter the mode of the
-file.  If the caller does not, an error code is returned.
-
-An additional test is performed to verify that the caller is not trying to
-alter the nature of the node. If the caller is attempting to alter more than
-the permissions associated with user group and other, an error is returned.
-
-If all the preconditions are met, the user, group and other fields are set
-based on the mode calling parameter.
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``IMFS_fchmod()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t     *iop
+        mode_t             mode
+
+File:
+    ``imfs_fchmod.c``
+
+Description:
+    This routine will obtain the pointer to the IMFS_jnode_t structure from the
+    information currently in the file control block.
+
+    Based on configuration the routine will acquire the user ID from a call to
+    getuid() or from the IMFS_jnode_t structure.
+
+    It then checks to see if we have the ownership rights to alter the mode of
+    the file.  If the caller does not, an error code is returned.
+
+    An additional test is performed to verify that the caller is not trying to
+    alter the nature of the node. If the caller is attempting to alter more
+    than the permissions associated with user group and other, an error is
+    returned.
+
+    If all the preconditions are met, the user, group and other fields are set
+    based on the mode calling parameter.
 
 memfile_ftruncate() for Regular Files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**File:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+File:
+    XXX
+
+Description:
+    XXX
 
 No pathconf() for Regular Files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-NULL
-
-**Arguments:**
-
-Not Implemented
-
-**File:**
-
-Not Implemented
-
-**Description:**
-
-Not Implemented
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``NULL``
+
+Arguments:
+    Not Implemented
+
+File:
+    Not Implemented
+
+Description:
+    Not Implemented
 
 No fsync() for Regular Files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**File:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+File:
+    XXX
+
+Description:
+    XXX
 
 IMFS_fdatasync() for Regular Files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**File:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+File:
+    XXX
+
+Description:
+    XXX
 
 Directory Handler Table Functions
@@ -1104 +1003 @@
 
 IMFS_dir_open() for Directories
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-imfs_dir_open()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t  *iop,
-    const char     *pathname,
-    unsigned32      flag,
-    unsigned32      mode
-
-**File:**
-
-imfs_directory.c
-
-**Description:**
-
-This routine will look into the file control block to find the ``jnode`` that
-is associated with the directory.
-
-The routine will verify that the node is a directory. If its not a directory an
-error code will be returned.
-
-If it is a directory, the offset in the file control block will be set to 0.
-This allows us to start reading at the beginning of the directory.
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``imfs_dir_open()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t  *iop,
+        const char     *pathname,
+        unsigned32      flag,
+        unsigned32      mode
+
+File:
+    ``imfs_directory.c``
+
+Description:
+    This routine will look into the file control block to find the ``jnode``
+    that is associated with the directory.
+
+    The routine will verify that the node is a directory. If its not a
+    directory an error code will be returned.
+
+    If it is a directory, the offset in the file control block will be set
+    to 0.  This allows us to start reading at the beginning of the directory.
 
 IMFS_dir_close() for Directories
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-imfs_dir_close()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t     *iop
-
-**File:**
-
-imfs_directory.c
-
-**Description:**
-
-This routine is a dummy for directories under the base filesystem. It
-immediately returns a success status.
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``imfs_dir_close()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t     *iop
+
+File:
+    ``imfs_directory.c``
+
+Description:
+    This routine is a dummy for directories under the base filesystem. It
+    immediately returns a success status.
 
 IMFS_dir_read() for Directories
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-imfs_dir_read
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t  *iop,
-    void           *buffer,
-    unsigned32      count
-
-**File:**
-
-imfs_directory.c
-
-**Description:**
-
-This routine will read a fixed number of directory entries from the current
-directory offset. The number of directory bytes read will be returned from this
-routine.
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``imfs_dir_read``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t  *iop,
+        void           *buffer,
+        unsigned32      count
+
+File:
+    ``imfs_directory.c``
+
+Description:
+    This routine will read a fixed number of directory entries from the current
+    directory offset. The number of directory bytes read will be returned from
+    this routine.
 
 No write() for Directories
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**File:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+File:
+    XXX
+
+Description:
+    XXX
 
 No ioctl() for Directories
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-ioctl
-
-**Arguments:**
-
-**File:**
-
-Not supported
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``ioctl``
+
+Arguments:
+    Not supported
+
+File:
+    Not supported
+
+Description:
+    XXX
 
 IMFS_dir_lseek() for Directories
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-imfs_dir_lseek()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t      *iop,
-    off_t               offset,
-    int                 whence
-
-**File:**
-
-imfs_directory.c
-
-**Description:**
-
-This routine alters the offset in the file control block.
-
-No test is performed on the number of children under the current open
-directory.  The imfs_dir_read() function protects against reads beyond the
-current size to the directory by returning a 0 bytes transfered to the calling
-programs whenever the file position index exceeds the last entry in the open
-directory.
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``imfs_dir_lseek()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t      *iop,
+        off_t               offset,
+        int                 whence
+
+File:
+    ``imfs_directory.c``
+
+Description:
+    This routine alters the offset in the file control block.
+
+    No test is performed on the number of children under the current open
+    directory.  The imfs_dir_read() function protects against reads beyond the
+    current size to the directory by returning a 0 bytes transfered to the
+    calling programs whenever the file position index exceeds the last entry in
+    the open directory.
 
 IMFS_dir_fstat() for Directories
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-imfs_dir_fstat()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_location_info_t   *loc,
-    struct stat                        *buf
-
-**File:**
-
-imfs_directory.c
-
-**Description:**
-
-The node access information in the rtems_filesystem_location_info_t structure
-is used to locate the appropriate IMFS_jnode_t structure. The following
-information is taken from the IMFS_jnode_t structure and placed in the stat
-structure:
-
-- st_ino
-
-- st_mode
-
-- st_nlink
-
-- st_uid
-
-- st_gid
-
-- st_atime
-
-- st_mtime
-
-- st_ctime
-
-The st_size field is obtained by running through the chain of directory entries
-and summing the sizes of the dirent structures associated with each of the
-children of the directory.
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``imfs_dir_fstat()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_location_info_t   *loc,
+        struct stat                        *buf
+
+File:
+    ``imfs_directory.c``
+
+Description:
+    The node access information in the rtems_filesystem_location_info_t
+    structure is used to locate the appropriate IMFS_jnode_t structure. The
+    following information is taken from the IMFS_jnode_t structure and placed
+    in the stat structure:
+
+    - st_ino
+
+    - st_mode
+
+    - st_nlink
+
+    - st_uid
+
+    - st_gid
+
+    - st_atime
+
+    - st_mtime
+
+    - st_ctime
+
+    The st_size field is obtained by running through the chain of directory
+    entries and summing the sizes of the dirent structures associated with each
+    of the children of the directory.
 
 IMFS_fchmod() for Directories
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-IMFS_fchmod()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t     *iop
-    mode_t             mode
-
-**File:**
-
-imfs_fchmod.c
-
-**Description:**
-
-This routine will obtain the pointer to the IMFS_jnode_t structure from the
-information currently in the file control block.
-
-Based on configuration the routine will acquire the user ID from a call to
-getuid() or from the IMFS_jnode_t structure.
-
-It then checks to see if we have the ownership rights to alter the mode of the
-file.  If the caller does not, an error code is returned.
-
-An additional test is performed to verify that the caller is not trying to
-alter the nature of the node. If the caller is attempting to alter more than
-the permissions associated with user group and other, an error is returned.
-
-If all the preconditions are met, the user, group and other fields are set
-based on the mode calling parameter.
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``IMFS_fchmod()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t     *iop
+        mode_t             mode
+
+File:
+    ``imfs_fchmod.c``
+
+Description:
+    This routine will obtain the pointer to the IMFS_jnode_t structure from the
+    information currently in the file control block.
+
+    Based on configuration the routine will acquire the user ID from a call to
+    getuid() or from the IMFS_jnode_t structure.
+
+    It then checks to see if we have the ownership rights to alter the mode of
+    the file.  If the caller does not, an error code is returned.
+
+    An additional test is performed to verify that the caller is not trying to
+    alter the nature of the node. If the caller is attempting to alter more
+    than the permissions associated with user group and other, an error is
+    returned.
+
+    If all the preconditions are met, the user, group and other fields are set
+    based on the mode calling parameter.
 
 No ftruncate() for Directories
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**File:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+File:
+    XXX
+
+Description:
+    XXX
 
 No fpathconf() for Directories
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-fpathconf
-
-**Arguments:**
-
-Not Implemented
-
-**File:**
-
-Not Implemented
-
-**Description:**
-
-Not Implemented
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``fpathconf``
+
+Arguments:
+    Not Implemented
+
+File:
+    Not Implemented
+
+Description:
+    Not Implemented
 
 No fsync() for Directories
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**File:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+File:
+    XXX
+
+Description:
+    XXX
 
 IMFS_fdatasync() for Directories
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**File:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+File:
+    XXX
+
+Description:
+    XXX
 
 Device Handler Table Functions
@@ -1431 +1285 @@
 
 device_open() for Devices
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-device_open()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t     *iop,
-    const char        *pathname,
-    unsigned32         flag,
-    unsigned32         mode
-
-**File:**
-
-deviceio.c
-
-**Description:**
-
-This routine will use the file control block to locate the node structure for
-the device.
-
-It will extract the major and minor device numbers from the ``jnode``.
-
-The major and minor device numbers will be used to make a rtems_io_open()
-function call to open the device driver. An argument list is sent to the driver
-that contains the file control block, flags and mode information.
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``device_open()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t     *iop,
+        const char        *pathname,
+        unsigned32         flag,
+        unsigned32         mode
+
+File:
+    ``deviceio.c``
+
+Description:
+    This routine will use the file control block to locate the node structure
+    for the device.
+
+    It will extract the major and minor device numbers from the ``jnode``.
+
+    The major and minor device numbers will be used to make a rtems_io_open()
+    function call to open the device driver. An argument list is sent to the
+    driver that contains the file control block, flags and mode information.
 
 device_close() for Devices
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-device_close()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t     *iop
-
-**File:**
-
-deviceio.c
-
-**Description:**
-
-This routine extracts the major and minor device driver numbers from the
-IMFS_jnode_t that is referenced in the file control block.
-
-It also forms an argument list that contains the file control block.
-
-A rtems_io_close() function call is made to close the device specified by the
-major and minor device numbers.
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``device_close()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t     *iop
+
+File:
+    ``deviceio.c``
+
+Description:
+    This routine extracts the major and minor device driver numbers from the
+    IMFS_jnode_t that is referenced in the file control block.
+
+    It also forms an argument list that contains the file control block.
+
+    A rtems_io_close() function call is made to close the device specified by
+    the major and minor device numbers.
 
 device_read() for Devices
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-device_read()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t     *iop,
-    void              *buffer,
-    unsigned32         count
-
-**File:**
-
-deviceio.c
-
-**Description:**
-
-This routine will extract the major and minor numbers for the device from the -
-jnode- associated with the file descriptor.
-
-A rtems_io_read() call will be made to the device driver associated with the
-file descriptor. The major and minor device number will be sent as arguments as
-well as an argument list consisting of:
-
-- file control block
-
-- file position index
-
-- buffer pointer where the data read is to be placed
-
-- count indicating the number of bytes that the program wishes to read
-  from the device
-
-- flags from the file control block
-
-On return from the rtems_io_read() the number of bytes that were actually read
-will be returned to the calling program.
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``device_read()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t     *iop,
+        void              *buffer,
+        unsigned32         count
+
+File:
+    ``deviceio.c``
+
+Description:
+    This routine will extract the major and minor numbers for the device from
+    the - jnode- associated with the file descriptor.
+
+    A rtems_io_read() call will be made to the device driver associated with
+    the file descriptor. The major and minor device number will be sent as
+    arguments as well as an argument list consisting of:
+
+    - file control block
+
+    - file position index
+
+    - buffer pointer where the data read is to be placed
+
+    - count indicating the number of bytes that the program wishes to read from
+      the device
+
+    - flags from the file control block
+
+    On return from the rtems_io_read() the number of bytes that were actually
+    read will be returned to the calling program.
 
 device_write() for Devices
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**File:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+File:
+    XXX
+
+Description:
+    XXX
 
 device_ioctl() for Devices
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-ioctl
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t     *iop,
-    unsigned32         command,
-    void              *buffer
-
-**File:**
-
-deviceio.c
-
-**Description:**
-
-This handler will obtain status information about a device.
-
-The form of status is device dependent.
-
-The rtems_io_control() function uses the major and minor number of the device
-to obtain the status information.
-
-rtems_io_control() requires an rtems_libio_ioctl_args_t argument list which
-contains the file control block, device specific command and a buffer pointer
-to return the device status information.
-
-The device specific command should indicate the nature of the information that
-is desired from the device.
-
-After the rtems_io_control() is processed, the buffer should contain the
-requested device information.
-
-If the device information is not obtained properly a -1 will be returned to the
-calling program, otherwise the ioctl_return value is returned.
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``ioctl``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t     *iop,
+        unsigned32         command,
+        void              *buffer
+
+File:
+    ``deviceio.c``
+
+Description:
+    This handler will obtain status information about a device.
+
+    The form of status is device dependent.
+
+    The rtems_io_control() function uses the major and minor number of the
+    device to obtain the status information.
+
+    rtems_io_control() requires an rtems_libio_ioctl_args_t argument list which
+    contains the file control block, device specific command and a buffer
+    pointer to return the device status information.
+
+    The device specific command should indicate the nature of the information
+    that is desired from the device.
+
+    After the rtems_io_control() is processed, the buffer should contain the
+    requested device information.
+
+    If the device information is not obtained properly a -1 will be returned to
+    the calling program, otherwise the ioctl_return value is returned.
 
 device_lseek() for Devices
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-device_lseek()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t     *iop,
-    off_t              offset,
-    int                whence
-
-**File:**
-
-deviceio.c
-
-**Description:**
-
-At the present time this is a placeholder function. It always returns a
-successful status.
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``device_lseek()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t     *iop,
+        off_t              offset,
+        int                whence
+
+File:
+    ``deviceio.c``
+
+Description:
+    At the present time this is a placeholder function. It always returns a
+    successful status.
 
 IMFS_stat() for Devices
-~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-IMFS_stat()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_filesystem_location_info_t   *loc,
-    struct stat                        *buf
-
-**File:**
-
-imfs_stat.c
-
-**Description:**
-
-This routine actually performs status processing for both devices and regular files.
-
-The IMFS_jnode_t structure is referenced to determine the type of node under
-the filesystem.
-
-If the node is associated with a device, node information is extracted and
-transformed to set the st_dev element of the stat structure.
-
-If the node is a regular file, the size of the regular file is extracted from
-the node.
-
-This routine rejects other node types.
-
-The following information is extracted from the node and placed in the stat
-structure:
-
-- st_mode
-
-- st_nlink
-
-- st_ino
-
-- st_uid
-
-- st_gid
-
-- st_atime
-
-- st_mtime
-
-- st_ctime
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``IMFS_stat()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_filesystem_location_info_t   *loc,
+        struct stat                        *buf
+
+File:
+    ``imfs_stat.c``
+
+Description:
+    This routine actually performs status processing for both devices and
+    regular files.
+
+    The IMFS_jnode_t structure is referenced to determine the type of node
+    under the filesystem.
+
+    If the node is associated with a device, node information is extracted and
+    transformed to set the st_dev element of the stat structure.
+
+    If the node is a regular file, the size of the regular file is extracted
+    from the node.
+
+    This routine rejects other node types.
+
+    The following information is extracted from the node and placed in the stat
+    structure:
+
+    - st_mode
+
+    - st_nlink
+
+    - st_ino
+
+    - st_uid
+
+    - st_gid
+
+    - st_atime
+
+    - st_mtime
+
+    - st_ctime
 
 IMFS_fchmod() for Devices
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-IMFS_fchmod()
-
-**Arguments:**
-
-.. code-block:: c
-
-    rtems_libio_t     *iop
-    mode_t             mode
-
-**File:**
-
-imfs_fchmod.c
-
-**Description:**
-
-This routine will obtain the pointer to the IMFS_jnode_t structure from the
-information currently in the file control block.
-
-Based on configuration the routine will acquire the user ID from a call to
-getuid()  or from the IMFS_jnode_t structure.
-
-It then checks to see if we have the ownership rights to alter the mode of the
-file.  If the caller does not, an error code is returned.
-
-An additional test is performed to verify that the caller is not trying to
-alter the nature of the node. If the caller is attempting to alter more than
-the permissions associated with user group and other, an error is returned.
-
-If all the preconditions are met, the user, group and other fields are set
-based on the mode calling parameter.
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``IMFS_fchmod()``
+
+Arguments:
+    .. code-block:: c
+
+        rtems_libio_t     *iop
+        mode_t             mode
+
+File:
+    ``imfs_fchmod.c``
+
+Description:
+    This routine will obtain the pointer to the IMFS_jnode_t structure from the
+    information currently in the file control block.
+
+    Based on configuration the routine will acquire the user ID from a call to
+    getuid() or from the IMFS_jnode_t structure.
+
+    It then checks to see if we have the ownership rights to alter the mode of
+    the file.  If the caller does not, an error code is returned.
+
+    An additional test is performed to verify that the caller is not trying to
+    alter the nature of the node. If the caller is attempting to alter more
+    than the permissions associated with user group and other, an error is
+    returned.
+
+    If all the preconditions are met, the user, group and other fields are set
+    based on the mode calling parameter.
 
 No ftruncate() for Devices
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**File:**
-
-XXX
-
-**Description:**
-
-XXX
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+File:
+    XXX
+
+Description:
+    XXX
 
 No fpathconf() for Devices
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-fpathconf
-
-**Arguments:**
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    ``fpathconf``
+
+Arguments:
+    Not Implemented
+
+File:
+    Not Implemented
+
+Description:
+    Not Implemented
+
+No fsync() for Devices
+^^^^^^^^^^^^^^^^^^^^^^
+
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+File:
+    XXX
+
+Description:
+    XXX
+
+No fdatasync() for Devices
+^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Not Implemented
 
-**File:**
-
-Not Implemented
-
-**Description:**
-
-Not Implemented
-
-No fsync() for Devices
-~~~~~~~~~~~~~~~~~~~~~~
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**File:**
-
-XXX
-
-**Description:**
-
-XXX
-
-No fdatasync() for Devices
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Not Implemented
-
-**Corresponding Structure Element:**
-
-XXX
-
-**Arguments:**
-
-XXX
-
-**File:**
-
-XXX
-
-**Description:**
-
-XXX
+Corresponding Structure Element:
+    XXX
+
+Arguments:
+    XXX
+
+File:
+    XXX
+
+Description:
+    XXX

filesystem/index.rst

@@ -4 +4 @@
 RTEMS Filesystem Design Guide
 =============================
+
+RTEMS Filesystem Design Guide
+-----------------------------
 
  | COPYRIGHT (c) 1988 - 2015.
@@ -33 +36 @@
 
 .. toctree::
-        :maxdepth: 3
+        :maxdepth: 5
         :numbered:
 

filesystem/minature_in-memory.rst

@@ -6 +6 @@
 
 Miniature In-Memory Filesystem
-##############################
+******************************
 
 This chapter describes the Miniature In-Memory FileSystem (miniIMFS).  The

filesystem/mounting_and_unmounting.rst

@@ -6 +6 @@
 
 Mounting and Unmounting Filesystems
-###################################
+***********************************
 
 Mount Points

filesystem/pathname_eval.rst

@@ -6 +6 @@
 
 Pathname Evaluation
-###################
+*******************
 
 This chapter describes the pathname evaluation process for the RTEMS Filesystem

filesystem/preface.rst

@@ -5 +5 @@
 .. COMMENT: All rights reserved.
 
-=======
 Preface
-=======
+*******
 
 This document describes the implementation of the RTEMS filesystem
@@ -20 +19 @@
 - Individual file and directory support for the following:
 
-  # Permissions for read, write and execute
-  # User ID
-  # Group ID
-  # Access time
-  # Modification time
-  # Creation time
+  #. Permissions for read, write and execute
+  #. User ID
+  #. Group ID
+  #. Access time
+  #. Modification time
+  #. Creation time
 
 - Hard links to files and directories

filesystem/system_init.rst

@@ -6 +6 @@
 
 System Initialization
-#####################
+*********************
 
 After the RTEMS initialization is performed, the application's initialization

filesystem/trivial_ftp.rst

@@ -2 +2 @@
 
 Trivial FTP Client Filesystem
-#############################
+*****************************
 
 This chapter describes the Trivial FTP (TFTP) Client Filesystem.