mirror of
https://git.rtems.org/rtems-docs/
synced 2025-07-23 07:51:52 +08:00
Fix filesystem formatting.
This commit is contained in:
parent
b0f29772e2
commit
4cacea0963
File diff suppressed because it is too large
Load Diff
@ -4,6 +4,3 @@ Command and Variable Index
|
||||
##########################
|
||||
|
||||
There are currently no Command and Variable Index entries.
|
||||
|
||||
.. COMMENT: @printindex fn
|
||||
|
||||
|
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -4,41 +4,38 @@
|
||||
RTEMS Filesystem Design Guide
|
||||
=============================
|
||||
|
||||
COPYRIGHT (c) 1988 - 2015.
|
||||
| COPYRIGHT (c) 1988 - 2015.
|
||||
| On-Line Applications Research Corporation (OAR).
|
||||
|
||||
On-Line Applications Research Corporation (OAR).
|
||||
The authors have used their best efforts in preparing this material. These
|
||||
efforts include the development, research, and testing of the theories and
|
||||
programs to determine their effectiveness. No warranty of any kind, expressed
|
||||
or implied, with regard to the software or the material contained in this
|
||||
document is provided. No liability arising out of the application or use of
|
||||
any product described in this document is assumed. The authors reserve the
|
||||
right to revise this material and to make changes from time to time in the
|
||||
content hereof without obligation to notify anyone of such revision or changes.
|
||||
|
||||
The authors have used their best efforts in preparing
|
||||
this material. These efforts include the development, research,
|
||||
and testing of the theories and programs to determine their
|
||||
effectiveness. No warranty of any kind, expressed or implied,
|
||||
with regard to the software or the material contained in this
|
||||
document is provided. No liability arising out of the
|
||||
application or use of any product described in this document is
|
||||
assumed. The authors reserve the right to revise this material
|
||||
and to make changes from time to time in the content hereof
|
||||
without obligation to notify anyone of such revision or changes.
|
||||
The RTEMS Project is hosted at http://www.rtems.org/. Any inquiries concerning
|
||||
RTEMS, its related support components, or its documentation should be directed
|
||||
to the Community Project hosted at http://www.rtems.org/.
|
||||
|
||||
The RTEMS Project is hosted at http://www.rtems.org. Any
|
||||
inquiries concerning RTEMS, its related support components, or its
|
||||
documentation should be directed to the Community Project hosted athttp://www.rtems.org.
|
||||
|
||||
Any inquiries for commercial services including training, support, custom
|
||||
development, application development assistance should be directed to http://www.rtems.com.
|
||||
|
||||
|
||||
Table of Contents
|
||||
-----------------
|
||||
|
||||
.. toctree::
|
||||
|
||||
preface
|
||||
.. topic:: RTEMS Online Resources
|
||||
|
||||
================ =============================
|
||||
Home https://www.rtems.org/
|
||||
Developers https://devel.rtems.org/
|
||||
Documentation https://docs.rtems.org/
|
||||
Bug Reporting https://devel.rtems.org/query
|
||||
Mailing Lists https://lists.rtems.org/
|
||||
Git Repositories https://git.rtems.org/
|
||||
================ =============================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
:numbered:
|
||||
|
||||
preface
|
||||
pathname_eval
|
||||
system_init
|
||||
mounting_and_unmounting
|
||||
@ -48,8 +45,6 @@ Table of Contents
|
||||
minature_in-memory
|
||||
trivial_ftp
|
||||
command_and_variable
|
||||
|
||||
|
||||
* :ref:`genindex`
|
||||
* :ref:`search`
|
||||
|
||||
|
||||
|
@ -1,18 +1,15 @@
|
||||
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
|
||||
|
||||
.. COMMENT: COPYRIGHT (c) 1988-2002.
|
||||
.. COMMENT: On-Line Applications Research Corporation (OAR).
|
||||
.. COMMENT: All rights reserved.
|
||||
|
||||
Miniature In-Memory Filesystem
|
||||
##############################
|
||||
|
||||
This chapter describes the Miniature In-Memory FileSystem (miniIMFS).
|
||||
The miniIMFS is a reduced feature version of the IMFS designed to
|
||||
provide minimal functionality and have a low memory footprint.
|
||||
|
||||
This chapter should be written after the IMFS chapter is completed
|
||||
and describe the implementation of the mini-IMFS.
|
||||
|
||||
.. COMMENT: COPYRIGHT (c) 1988-2002.
|
||||
|
||||
.. COMMENT: On-Line Applications Research Corporation (OAR).
|
||||
|
||||
.. COMMENT: All rights reserved.
|
||||
This chapter describes the Miniature In-Memory FileSystem (miniIMFS). The
|
||||
miniIMFS is a reduced feature version of the IMFS designed to provide minimal
|
||||
functionality and have a low memory footprint.
|
||||
|
||||
This chapter should be written after the IMFS chapter is completed and describe
|
||||
the implementation of the mini-IMFS.
|
||||
|
@ -1,5 +1,9 @@
|
||||
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
|
||||
|
||||
.. COMMENT: COPYRIGHT (c) 1988-2002.
|
||||
.. COMMENT: On-Line Applications Research Corporation (OAR).
|
||||
.. COMMENT: All rights reserved.
|
||||
|
||||
Mounting and Unmounting Filesystems
|
||||
###################################
|
||||
|
||||
@ -8,46 +12,47 @@ Mount Points
|
||||
|
||||
The following is the list of the characteristics of a mount point:
|
||||
|
||||
- The mount point must be a directory. It may have files and other
|
||||
directories under it. These files and directories will be hidden when the
|
||||
filesystem is mounted.
|
||||
- The mount point must be a directory. It may have files and other directories
|
||||
under it. These files and directories will be hidden when the filesystem is
|
||||
mounted.
|
||||
|
||||
- The task must have read/write/execute permissions to the mount point
|
||||
or the mount attempt will be rejected.
|
||||
- The task must have read/write/execute permissions to the mount point or the
|
||||
mount attempt will be rejected.
|
||||
|
||||
- Only one filesystem can be mounted to a single mount point.
|
||||
|
||||
- The Root of the mountable filesystem will be referenced by the name
|
||||
of the mount point after the mount is complete.
|
||||
- The Root of the mountable filesystem will be referenced by the name of the
|
||||
mount point after the mount is complete.
|
||||
|
||||
Mount Table Chain
|
||||
=================
|
||||
|
||||
The mount table chain is a dynamic list of structures that describe
|
||||
mounted filesystems a specific points in the filesystem hierarchy. It is
|
||||
initialized to an empty state during the base filesystem initialization.
|
||||
The mount operation will add entries to the mount table chain. The
|
||||
un-mount operation will remove entries from the mount table chain.
|
||||
The mount table chain is a dynamic list of structures that describe mounted
|
||||
filesystems a specific points in the filesystem hierarchy. It is initialized to
|
||||
an empty state during the base filesystem initialization. The mount operation
|
||||
will add entries to the mount table chain. The un-mount operation will remove
|
||||
entries from the mount table chain.
|
||||
|
||||
Each entry in the mount table chain is of the following type:
|
||||
.. code:: c
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
struct rtems_filesystem_mount_table_entry_tt
|
||||
{
|
||||
Chain_Node Node;
|
||||
rtems_filesystem_location_info_t mt_point_node;
|
||||
rtems_filesystem_location_info_t mt_fs_root;
|
||||
int options;
|
||||
void \*fs_info;
|
||||
rtems_filesystem_limits_and_options_t pathconf_limits_and_options;
|
||||
/*
|
||||
* When someone adds a mounted filesystem on a real device,
|
||||
* this will need to be used.
|
||||
*
|
||||
* The best option long term for this is probably an
|
||||
* open file descriptor.
|
||||
\*/
|
||||
char \*dev;
|
||||
Chain_Node Node;
|
||||
rtems_filesystem_location_info_t mt_point_node;
|
||||
rtems_filesystem_location_info_t mt_fs_root;
|
||||
int options;
|
||||
void *fs_info;
|
||||
rtems_filesystem_limits_and_options_t pathconf_limits_and_options;
|
||||
/*
|
||||
* When someone adds a mounted filesystem on a real device,
|
||||
* this will need to be used.
|
||||
*
|
||||
* The best option long term for this is probably an
|
||||
* open file descriptor.
|
||||
*/
|
||||
char \*dev;
|
||||
};
|
||||
|
||||
*Node*
|
||||
@ -57,15 +62,15 @@ Each entry in the mount table chain is of the following type:
|
||||
The mt_point_node contains all information necessary to access the
|
||||
directory where a filesystem is mounted onto. This element may contain
|
||||
memory that is allocated during a path evaluation of the filesystem
|
||||
containing the mountpoint directory. The generic code allows this
|
||||
memory to be returned by unmount when the filesystem identified by
|
||||
mt_fs_root is unmounted.
|
||||
containing the mountpoint directory. The generic code allows this memory
|
||||
to be returned by unmount when the filesystem identified by mt_fs_root is
|
||||
unmounted.
|
||||
|
||||
*mt_fs_root*
|
||||
The mt_fs_root contains all information necessary to identify the root
|
||||
of the mounted filesystem. The user is never allowed access to this
|
||||
node by the generic code, but it is used to identify to the mounted
|
||||
filesystem where to start evaluation of pathnames at.
|
||||
The mt_fs_root contains all information necessary to identify the root of
|
||||
the mounted filesystem. The user is never allowed access to this node by
|
||||
the generic code, but it is used to identify to the mounted filesystem
|
||||
where to start evaluation of pathnames at.
|
||||
|
||||
*options*
|
||||
XXX
|
||||
@ -74,7 +79,8 @@ Each entry in the mount table chain is of the following type:
|
||||
The fs_info element is a location available for use by the mounted file
|
||||
system to identify unique things applicable to this instance of the file
|
||||
system. For example the IMFS uses this space to provide node
|
||||
identification that is unique for each instance (mounting) of the filesystem.
|
||||
identification that is unique for each instance (mounting) of the
|
||||
filesystem.
|
||||
|
||||
*pathconf_limits_and_options*
|
||||
XXX
|
||||
@ -85,20 +91,13 @@ Each entry in the mount table chain is of the following type:
|
||||
Adding entries to the chain during mount
|
||||
========================================
|
||||
|
||||
When a filesystem is mounted, its presence and location in the file
|
||||
system hierarchy is recorded in a dynamic list structure known as a chain.
|
||||
A unique rtems_filesystem_mount_table_entry_tt structure is logged for
|
||||
each filesystem that is mounted. This includes the base filesystem.
|
||||
When a filesystem is mounted, its presence and location in the file system
|
||||
hierarchy is recorded in a dynamic list structure known as a chain. A unique
|
||||
rtems_filesystem_mount_table_entry_tt structure is logged for each filesystem
|
||||
that is mounted. This includes the base filesystem.
|
||||
|
||||
Removing entries from the chain during unmount
|
||||
==============================================
|
||||
|
||||
When a filesystem is dismounted its entry in the mount table chain is
|
||||
extracted and the memory for this entry is freed.
|
||||
|
||||
.. COMMENT: COPYRIGHT (c) 1988-2002.
|
||||
|
||||
.. COMMENT: On-Line Applications Research Corporation (OAR).
|
||||
|
||||
.. COMMENT: All rights reserved.
|
||||
|
||||
When a filesystem is dismounted its entry in the mount table chain is extracted
|
||||
and the memory for this entry is freed.
|
||||
|
@ -1,40 +1,44 @@
|
||||
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
|
||||
|
||||
.. COMMENT: COPYRIGHT (c) 1988-2002.
|
||||
.. COMMENT: On-Line Applications Research Corporation (OAR).
|
||||
.. COMMENT: All rights reserved.
|
||||
|
||||
Pathname Evaluation
|
||||
###################
|
||||
|
||||
This chapter describes the pathname evaluation process for the
|
||||
RTEMS Filesystem Infrastructure.
|
||||
.. code:: c
|
||||
This chapter describes the pathname evaluation process for the RTEMS Filesystem
|
||||
Infrastructure.
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
XXX Include graphic of the path evaluation process
|
||||
|
||||
Pathname Evaluation Handlers
|
||||
============================
|
||||
|
||||
There are two pathname evaluation routines. The handler patheval()
|
||||
is called to find, verify privlages on and return information on a node
|
||||
that exists. The handler evalformake() is called to find, verify
|
||||
permissions, and return information on a node that is to become a parent.
|
||||
Additionally, evalformake() returns a pointer to the start of the name of
|
||||
the new node to be created.
|
||||
There are two pathname evaluation routines. The handler patheval() is called
|
||||
to find, verify privlages on and return information on a node that exists. The
|
||||
handler ``evalformake()`` is called to find, verify permissions, and return
|
||||
information on a node that is to become a parent. Additionally, evalformake()
|
||||
returns a pointer to the start of the name of the new node to be created.
|
||||
|
||||
Pathname evaluation is specific to a filesystem.
|
||||
Each filesystem is required to provide both a patheval() and an evalformake()
|
||||
routine. Both of these routines gets a name to evaluate and a node indicating
|
||||
where to start the evaluation.
|
||||
Pathname evaluation is specific to a filesystem. Each filesystem is required
|
||||
to provide both a ``patheval()`` and an ``evalformake()`` routine. Both of
|
||||
these routines gets a name to evaluate and a node indicating where to start the
|
||||
evaluation.
|
||||
|
||||
Crossing a Mount Point During Path Evaluation
|
||||
=============================================
|
||||
|
||||
If the filesystem supports the mount command, the evaluate routines
|
||||
must handle crossing the mountpoint. The evaluate routine should evaluate
|
||||
the name upto the first directory node where the new filesystem is mounted.
|
||||
The filesystem may process terminator characters prior to calling the
|
||||
evaluate routine for the new filesystem. A pointer to the portion of the
|
||||
name which has not been evaluated along with the root node of the new
|
||||
file system ( gotten from the mount table entry ) is passed to the correct
|
||||
mounted filesystem evaluate routine.
|
||||
If the filesystem supports the mount command, the evaluate routines must handle
|
||||
crossing the mountpoint. The evaluate routine should evaluate the name upto
|
||||
the first directory node where the new filesystem is mounted. The filesystem
|
||||
may process terminator characters prior to calling the evaluate routine for the
|
||||
new filesystem. A pointer to the portion of the name which has not been
|
||||
evaluated along with the root node of the new file system (gotten from the
|
||||
mount table entry) is passed to the correct mounted filesystem evaluate
|
||||
routine.
|
||||
|
||||
The rtems_filesystem_location_info_t Structure
|
||||
==============================================
|
||||
@ -43,55 +47,49 @@ The ``rtems_filesystem_location_info_t`` structure contains all information
|
||||
necessary for identification of a node.
|
||||
|
||||
The generic rtems filesystem code defines two global
|
||||
rtems_filesystem_location_info_t structures, the``rtems_filesystem_root`` and the ``rtems_filesystem_current``.
|
||||
Both are initially defined to be the root node of the base filesystem.
|
||||
Once the chdir command is correctly used the ``rtems_filesystem_current``
|
||||
is set to the location specified by the command.
|
||||
rtems_filesystem_location_info_t structures, the``rtems_filesystem_root`` and
|
||||
the ``rtems_filesystem_current``. Both are initially defined to be the root
|
||||
node of the base filesystem. Once the chdir command is correctly used the
|
||||
``rtems_filesystem_current`` is set to the location specified by the command.
|
||||
|
||||
The filesystem generic code peeks at the first character in the name to be
|
||||
evaluated. If this character is a valid seperator, the``rtems_filesystem_root`` is used as the node to start the evaluation
|
||||
with. Otherwise, the ``rtems_filesystem_current`` node is used as the
|
||||
node to start evaluating with. Therefore, a valid
|
||||
rtems_filesystem_location_info_t is given to the evaluate routine to start
|
||||
evaluation with. The evaluate routines are then responsible for making
|
||||
any changes necessary to this structure to correspond to the name being
|
||||
parsed.
|
||||
.. code:: c
|
||||
evaluated. If this character is a valid seperator,
|
||||
the``rtems_filesystem_root`` is used as the node to start the evaluation with.
|
||||
Otherwise, the ``rtems_filesystem_current`` node is used as the node to start
|
||||
evaluating with. Therefore, a valid rtems_filesystem_location_info_t is given
|
||||
to the evaluate routine to start evaluation with. The evaluate routines are
|
||||
then responsible for making any changes necessary to this structure to
|
||||
correspond to the name being parsed.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
struct rtems_filesystem_location_info_tt {
|
||||
void \*node_access;
|
||||
rtems_filesystem_file_handlers_r \*handlers;
|
||||
rtems_filesystem_operations_table \*ops;
|
||||
rtems_filesystem_mount_table_entry_t \*mt_entry;
|
||||
void *node_access;
|
||||
rtems_filesystem_file_handlers_r *handlers;
|
||||
rtems_filesystem_operations_table *ops;
|
||||
rtems_filesystem_mount_table_entry_t *mt_entry;
|
||||
};
|
||||
|
||||
*node_access*
|
||||
This element is filesystem specific. A filesystem can define and store
|
||||
any information necessary to identify a node at this location. This element
|
||||
is normally filled in by the filesystem's evaluate routine. For the
|
||||
filesystem's root node, the filesystem's initilization routine should
|
||||
fill this in, and it should remain valid until the instance of the
|
||||
filesystem is unmounted.
|
||||
This element is filesystem specific. A filesystem can define and store any
|
||||
information necessary to identify a node at this location. This element is
|
||||
normally filled in by the filesystem's evaluate routine. For the
|
||||
filesystem's root node, the filesystem's initilization routine should fill
|
||||
this in, and it should remain valid until the instance of the filesystem is
|
||||
unmounted.
|
||||
|
||||
*handlers*
|
||||
This element is defined as a set of routines that may change within a
|
||||
given filesystem based upon node type. For example a directory and a
|
||||
memory file may have to completely different read routines. This element
|
||||
is set to an initialization state defined by the mount table, and may
|
||||
be set to the desired state by the evaluation routines.
|
||||
This element is defined as a set of routines that may change within a given
|
||||
filesystem based upon node type. For example a directory and a memory file
|
||||
may have to completely different read routines. This element is set to an
|
||||
initialization state defined by the mount table, and may be set to the
|
||||
desired state by the evaluation routines.
|
||||
|
||||
*ops*
|
||||
This element is defined as a set of routines that remain static for the
|
||||
filesystem. This element identifies entry points into the filesystem
|
||||
to the generic code.
|
||||
filesystem. This element identifies entry points into the filesystem to
|
||||
the generic code.
|
||||
|
||||
*mt_entry*
|
||||
This element identifies the mount table entry for this instance of the
|
||||
filesystem.
|
||||
|
||||
.. COMMENT: COPYRIGHT (c) 1988-2002.
|
||||
|
||||
.. COMMENT: On-Line Applications Research Corporation (OAR).
|
||||
|
||||
.. COMMENT: All rights reserved.
|
||||
|
||||
|
@ -1,12 +1,15 @@
|
||||
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
|
||||
|
||||
.. COMMENT: COPYRIGHT (c) 1988-2002.
|
||||
.. COMMENT: On-Line Applications Research Corporation (OAR).
|
||||
.. COMMENT: All rights reserved.
|
||||
|
||||
=======
|
||||
Preface
|
||||
=======
|
||||
|
||||
This document describes the implementation of the RTEMS filesystem
|
||||
infrastructure. This infrastructure supports the following
|
||||
capabilities:
|
||||
infrastructure. This infrastructure supports the following capabilities:
|
||||
|
||||
- Mountable file systems
|
||||
|
||||
@ -15,6 +18,7 @@ capabilities:
|
||||
- POSIX compliant set of routines for the manipulation of files and directories
|
||||
|
||||
- Individual file and directory support for the following:
|
||||
|
||||
# Permissions for read, write and execute
|
||||
# User ID
|
||||
# Group ID
|
||||
@ -26,44 +30,34 @@ capabilities:
|
||||
|
||||
- Symbolic links to files and directories
|
||||
|
||||
This has been implemented to provide the framework for a UNIX-like
|
||||
file system support. POSIX file and directory functions have been
|
||||
implemented that allow a standard method of accessing file, device and
|
||||
directory information within file systems. The file system concept that
|
||||
has been implemented allows for expansion and adaptation of the file
|
||||
system to a variety of existing and future data storage devices. To this
|
||||
end, file system mount and unmount capabilities have been included in this
|
||||
RTEMS framework.
|
||||
This has been implemented to provide the framework for a UNIX-like file system
|
||||
support. POSIX file and directory functions have been implemented that allow a
|
||||
standard method of accessing file, device and directory information within file
|
||||
systems. The file system concept that has been implemented allows for expansion
|
||||
and adaptation of the file system to a variety of existing and future data
|
||||
storage devices. To this end, file system mount and unmount capabilities have
|
||||
been included in this RTEMS framework.
|
||||
|
||||
This framework slightly alters the manner in which devices are handled
|
||||
under RTEMS from that of public release 4.0.0 and earlier. Devices that
|
||||
are defined under a given RTEMS configuration will now be registered as
|
||||
files in a mounted file system. Access to these device drivers and their
|
||||
associated devices may now be performed through the traditional file system
|
||||
open(), read(), write(), lseek(), fstat() and ioctl() functions in addition
|
||||
to the interface provided by the IO Manager in the RTEMS Classic API.
|
||||
This framework slightly alters the manner in which devices are handled under
|
||||
RTEMS from that of public release 4.0.0 and earlier. Devices that are defined
|
||||
under a given RTEMS configuration will now be registered as files in a mounted
|
||||
file system. Access to these device drivers and their associated devices may
|
||||
now be performed through the traditional file system open(), read(), write(),
|
||||
lseek(), fstat() and ioctl() functions in addition to the interface provided by
|
||||
the IO Manager in the RTEMS Classic API.
|
||||
|
||||
An In-Memory File System (IMFS) is included which provides full POSIX
|
||||
filesystem functionality yet is RAM based. The IMFS maintains a
|
||||
node structure for each file, device, and directory in each mounted
|
||||
instantiation of its file system. The node structure is used to
|
||||
manage ownership, access rights, access time, modification time,
|
||||
and creation time. A union of structures within the IMFS nodal
|
||||
structure provide for manipulation of file data, device selection,
|
||||
or directory content as required by the nodal type. Manipulation of
|
||||
these properties is accomplished through the POSIX set of file and
|
||||
directory functions. In addition to being useful in its own right,
|
||||
the IMFS serves as a full featured example filesystem.
|
||||
|
||||
The intended audience for this document is those persons implementing
|
||||
their own filesystem. Users of the filesystem may find information
|
||||
on the implementation useful. But the user interface to the filesystem
|
||||
is through the ISO/ANSI C Library and POSIX 1003.1b file and directory
|
||||
APIs.
|
||||
|
||||
.. COMMENT: COPYRIGHT (c) 1988-2002.
|
||||
|
||||
.. COMMENT: On-Line Applications Research Corporation (OAR).
|
||||
|
||||
.. COMMENT: All rights reserved.
|
||||
filesystem functionality yet is RAM based. The IMFS maintains a node structure
|
||||
for each file, device, and directory in each mounted instantiation of its file
|
||||
system. The node structure is used to manage ownership, access rights, access
|
||||
time, modification time, and creation time. A union of structures within the
|
||||
IMFS nodal structure provide for manipulation of file data, device selection,
|
||||
or directory content as required by the nodal type. Manipulation of these
|
||||
properties is accomplished through the POSIX set of file and directory
|
||||
functions. In addition to being useful in its own right, the IMFS serves as a
|
||||
full featured example filesystem.
|
||||
|
||||
The intended audience for this document is those persons implementing their own
|
||||
filesystem. Users of the filesystem may find information on the implementation
|
||||
useful. But the user interface to the filesystem is through the ISO/ANSI C
|
||||
Library and POSIX 1003.1b file and directory APIs.
|
||||
|
@ -1,30 +1,33 @@
|
||||
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
|
||||
|
||||
.. COMMENT: COPYRIGHT (c) 1988-2002.
|
||||
.. COMMENT: On-Line Applications Research Corporation (OAR).
|
||||
.. COMMENT: All rights reserved.
|
||||
|
||||
System Initialization
|
||||
#####################
|
||||
|
||||
After the RTEMS initialization is performed, the application's
|
||||
initialization will be performed. Part of initialization is a call to
|
||||
rtems_filesystem_initialize(). This routine will mount the 'In Memory File
|
||||
System' as the base filesystem. Mounting the base filesystem consists
|
||||
of the following:
|
||||
After the RTEMS initialization is performed, the application's initialization
|
||||
will be performed. Part of initialization is a call to
|
||||
``rtems_filesystem_initialize()``. This routine will mount the 'In Memory File
|
||||
System' as the base filesystem. Mounting the base filesystem consists of the
|
||||
following:
|
||||
|
||||
- Initialization of mount table chain control structure
|
||||
|
||||
- Allocation of a ``jnode`` structure that will server as the root node
|
||||
of the 'In Memory Filesystem'
|
||||
- Allocation of a ``jnode`` structure that will server as the root node of the
|
||||
'In Memory Filesystem'
|
||||
|
||||
- Initialization of the allocated ``jnode`` with the appropriate OPS,
|
||||
directory handlers and pathconf limits and options.
|
||||
- Initialization of the allocated ``jnode`` with the appropriate OPS, directory
|
||||
handlers and pathconf limits and options.
|
||||
|
||||
- Allocation of a memory region for filesystem specific global
|
||||
management variables
|
||||
- Allocation of a memory region for filesystem specific global management
|
||||
variables
|
||||
|
||||
- Creation of first mount table entry for the base filesystem
|
||||
|
||||
- Initialization of the first mount table chain entry to indicate that
|
||||
the mount point is NULL and the mounted filesystem is the base file
|
||||
system
|
||||
- Initialization of the first mount table chain entry to indicate that the
|
||||
mount point is NULL and the mounted filesystem is the base file system
|
||||
|
||||
After the base filesystem has been mounted, the following operations are
|
||||
performed under its directory structure:
|
||||
@ -38,10 +41,11 @@ Base Filesystem
|
||||
|
||||
RTEMS initially mounts a RAM based file system known as the base file system.
|
||||
The root directory of this file system tree serves as the logical root of the
|
||||
directory hierarchy (Figure 3). Under the root directory a '/dev' directory
|
||||
is created under which all I/O device directories and files are registered as
|
||||
part of the file system hierarchy.
|
||||
.. code:: c
|
||||
directory hierarchy (Figure 3). Under the root directory a '/dev' directory is
|
||||
created under which all I/O device directories and files are registered as part
|
||||
of the file system hierarchy.
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
Figure of the tree structure goes here.
|
||||
|
||||
@ -65,37 +69,29 @@ Base Filesystem Mounting
|
||||
|
||||
At present, the first file system to be mounted is the 'In Memory File
|
||||
System'. It is mounted using a standard MOUNT() command in which the mount
|
||||
point is NULL. This flags the mount as the first file system to be
|
||||
registered under the operating system and appropriate initialization of file
|
||||
system management information is performed (See figures 4 and 5). If a
|
||||
different file system type is desired as the base file system, alterations
|
||||
must be made to base_fs.c. This routine handles the mount of the base file
|
||||
system.
|
||||
point is NULL. This flags the mount as the first file system to be registered
|
||||
under the operating system and appropriate initialization of file system
|
||||
management information is performed (See figures 4 and 5). If a different file
|
||||
system type is desired as the base file system, alterations must be made to
|
||||
base_fs.c. This routine handles the mount of the base file system.
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: shell
|
||||
|
||||
Figure of the mount table chain goes here.
|
||||
|
||||
Once the root of the base file system has been established and it has been
|
||||
recorded as the mount point of the base file system, devices are integrated
|
||||
into the base file system. For every device that is configured into the
|
||||
system (See ioman.c) a device registration process is performed. Device
|
||||
registration produces a unique dev_t handle that consists of a major and
|
||||
minor device number. In addition, the configuration information for each
|
||||
device contains a text string that represents the fully qualified pathname to
|
||||
that device's place in the base file system's hierarchy. A file system node
|
||||
is created for the device along the specified registration path.
|
||||
into the base file system. For every device that is configured into the system
|
||||
(See ioman.c) a device registration process is performed. Device registration
|
||||
produces a unique dev_t handle that consists of a major and minor device
|
||||
number. In addition, the configuration information for each device contains a
|
||||
text string that represents the fully qualified pathname to that device's place
|
||||
in the base file system's hierarchy. A file system node is created for the
|
||||
device along the specified registration path.
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: shell
|
||||
|
||||
Figure of the Mount Table Processing goes here.
|
||||
|
||||
Note: Other file systems can be mounted but they are mounted onto points
|
||||
(directory mount points) in the base file system.
|
||||
|
||||
.. COMMENT: COPYRIGHT (c) 1988-2002.
|
||||
|
||||
.. COMMENT: On-Line Applications Research Corporation (OAR).
|
||||
|
||||
.. COMMENT: All rights reserved.
|
||||
|
||||
|
@ -5,6 +5,5 @@ Trivial FTP Client Filesystem
|
||||
|
||||
This chapter describes the Trivial FTP (TFTP) Client Filesystem.
|
||||
|
||||
This chapter should be written after the IMFS chapter is completed
|
||||
and describe the implementation of the TFTP.
|
||||
|
||||
This chapter should be written after the IMFS chapter is completed and describe
|
||||
the implementation of the TFTP.
|
||||
|
Loading…
x
Reference in New Issue
Block a user