mirror of
https://git.rtems.org/rtems-docs/
synced 2025-07-24 02:12:07 +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
|
||||
|
||||
|
@ -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.
|
||||
|
||||
Filesystem Implementation Requirements
|
||||
######################################
|
||||
|
||||
@ -9,45 +13,45 @@ implementations must adhere to.
|
||||
General
|
||||
=======
|
||||
|
||||
The RTEMS filesystem framework was intended to be compliant with the
|
||||
POSIX Files and Directories interface standard. The following filesystem
|
||||
The RTEMS filesystem framework was intended to be compliant with the POSIX
|
||||
Files and Directories interface standard. The following filesystem
|
||||
characteristics resulted in a functional switching layer.
|
||||
.. code:: c
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
Figure of the Filesystem Functional Layering goes here.
|
||||
This figure includes networking and disk caching layering.
|
||||
|
||||
# Application programs are presented with a standard set of POSIX
|
||||
compliant functions that allow them to interface with the files, devices
|
||||
and directories in the filesystem. The interfaces to these routines do
|
||||
not reflect the type of subordinate filesystem implementation in which
|
||||
the file will be found.
|
||||
# Application programs are presented with a standard set of POSIX compliant
|
||||
functions that allow them to interface with the files, devices and
|
||||
directories in the filesystem. The interfaces to these routines do not
|
||||
reflect the type of subordinate filesystem implementation in which the file
|
||||
will be found.
|
||||
|
||||
# The filesystem framework developed under RTEMS allows for mounting
|
||||
filesystem of different types under the base filesystem.
|
||||
# The filesystem framework developed under RTEMS allows for mounting filesystem
|
||||
of different types under the base filesystem.
|
||||
|
||||
# The mechanics of locating file information may be quite different
|
||||
between filesystem types.
|
||||
# The mechanics of locating file information may be quite different between
|
||||
filesystem types.
|
||||
|
||||
# The process of locating a file may require crossing filesystem
|
||||
boundaries.
|
||||
# The process of locating a file may require crossing filesystem boundaries.
|
||||
|
||||
# The transitions between filesystem and the processing required to
|
||||
access information in different filesystem is not visible at the level
|
||||
of the POSIX function call.
|
||||
# The transitions between filesystem and the processing required to access
|
||||
information in different filesystem is not visible at the level of the POSIX
|
||||
function call.
|
||||
|
||||
# The POSIX interface standard provides file access by character
|
||||
pathname to the file in some functions and through an integer file
|
||||
descriptor in other functions.
|
||||
# The POSIX interface standard provides file access by character pathname to
|
||||
the file in some functions and through an integer file descriptor in other
|
||||
functions.
|
||||
|
||||
# The nature of the integer file descriptor and its associated
|
||||
processing is operating system and filesystem specific.
|
||||
# The nature of the integer file descriptor and its associated processing is
|
||||
operating system and filesystem specific.
|
||||
|
||||
# Directory and device information must be processed with some of the
|
||||
same routines that apply to files.
|
||||
# Directory and device information must be processed with some of the same
|
||||
routines that apply to files.
|
||||
|
||||
# The form and content of directory and device information differs
|
||||
greatly from that of a regular file.
|
||||
# The form and content of directory and device information differs greatly from
|
||||
that of a regular file.
|
||||
|
||||
# Files, directories and devices represent elements (nodes) of a tree
|
||||
hierarchy.
|
||||
@ -56,15 +60,16 @@ characteristics resulted in a functional switching layer.
|
||||
filesystem are node specific but are still not reflected in the POSIX
|
||||
interface routines.
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: shell
|
||||
|
||||
Figure of the Filesystem Functional Layering goes here.
|
||||
This figure focuses on the Base Filesystem and IMFS.
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: shell
|
||||
|
||||
Figure of the IMFS Memfile control blocks
|
||||
|
||||
.. _file-and-directory-removal-constraints:
|
||||
|
||||
File and Directory Removal Constraints
|
||||
======================================
|
||||
@ -73,15 +78,15 @@ The following POSIX constraints must be honored by all filesystems.
|
||||
|
||||
- If a node is a directory with children it cannot be removed.
|
||||
|
||||
- The root node of any filesystem, whether the base filesystem or a
|
||||
mounted filesystem, cannot be removed.
|
||||
- The root node of any filesystem, whether the base filesystem or a mounted
|
||||
filesystem, cannot be removed.
|
||||
|
||||
- A node that is a directory that is acting as the mount point of a file
|
||||
system cannot be removed.
|
||||
- A node that is a directory that is acting as the mount point of a file system
|
||||
cannot be removed.
|
||||
|
||||
- On filesystems supporting hard links, a link count is maintained.
|
||||
Prior to node removal, the node's link count is decremented by one. The
|
||||
link count must be less than one to allow for removal of the node.
|
||||
- On filesystems supporting hard links, a link count is maintained. Prior to
|
||||
node removal, the node's link count is decremented by one. The link count
|
||||
must be less than one to allow for removal of the node.
|
||||
|
||||
API Layering
|
||||
============
|
||||
@ -89,16 +94,16 @@ API Layering
|
||||
Mapping of Generic System Calls to Filesystem Specific Functions
|
||||
----------------------------------------------------------------
|
||||
|
||||
The list of generic system calls includes the routines open(), read(),
|
||||
write(), close(), etc..
|
||||
The list of generic system calls includes the routines open(), read(), write(),
|
||||
close(), etc..
|
||||
|
||||
The Files and Directories section of the POSIX Application Programs
|
||||
Interface specifies a set of functions with calling arguments that are
|
||||
used to gain access to the information in a filesystem. To the
|
||||
application program, these functions allow access to information in any
|
||||
mounted filesystem without explicit knowledge of the filesystem type or
|
||||
the filesystem mount configuration. The following are functions that are
|
||||
provided to the application:
|
||||
The Files and Directories section of the POSIX Application Programs Interface
|
||||
specifies a set of functions with calling arguments that are used to gain
|
||||
access to the information in a filesystem. To the application program, these
|
||||
functions allow access to information in any mounted filesystem without
|
||||
explicit knowledge of the filesystem type or the filesystem mount
|
||||
configuration. The following are functions that are provided to the
|
||||
application:
|
||||
|
||||
# access()
|
||||
|
||||
@ -170,59 +175,56 @@ provided to the application:
|
||||
|
||||
# write()
|
||||
|
||||
The filesystem's type as well as the node type within the filesystem
|
||||
determine the nature of the processing that must be performed for each of
|
||||
the functions above. The RTEMS filesystem provides a framework that
|
||||
allows new filesystem to be developed and integrated without alteration
|
||||
to the basic framework.
|
||||
The filesystem's type as well as the node type within the filesystem determine
|
||||
the nature of the processing that must be performed for each of the functions
|
||||
above. The RTEMS filesystem provides a framework that allows new filesystem to
|
||||
be developed and integrated without alteration to the basic framework.
|
||||
|
||||
To provide the functional switching that is required, each of the POSIX
|
||||
file and directory functions have been implemented as a shell function.
|
||||
The shell function adheres to the POSIX interface standard. Within this
|
||||
functional shell, filesystem and node type information is accessed which
|
||||
is then used to invoke the appropriate filesystem and node type specific
|
||||
routine to process the POSIX function call.
|
||||
To provide the functional switching that is required, each of the POSIX file
|
||||
and directory functions have been implemented as a shell function. The shell
|
||||
function adheres to the POSIX interface standard. Within this functional shell,
|
||||
filesystem and node type information is accessed which is then used to invoke
|
||||
the appropriate filesystem and node type specific routine to process the POSIX
|
||||
function call.
|
||||
|
||||
File/Device/Directory function access via file control block - rtems_libio_t structure
|
||||
--------------------------------------------------------------------------------------
|
||||
|
||||
The POSIX open() function returns an integer file descriptor that is used
|
||||
as a reference to file control block information for a specific file. The
|
||||
file control block contains information that is used to locate node, file
|
||||
system, mount table and functional handler information. The diagram in
|
||||
Figure 8 depicts the relationship between and among the following
|
||||
components.
|
||||
The POSIX open() function returns an integer file descriptor that is used as a
|
||||
reference to file control block information for a specific file. The file
|
||||
control block contains information that is used to locate node, file system,
|
||||
mount table and functional handler information. The diagram in Figure 8 depicts
|
||||
the relationship between and among the following components.
|
||||
|
||||
# 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()
|
||||
operation references a slot in this table. The slot contains a pointer to
|
||||
the file descriptor table entry for this file. The rtems_libio_t structure
|
||||
operation references a slot in this table. The slot contains a pointer to the
|
||||
file descriptor table entry for this file. The rtems_libio_t structure
|
||||
represents the file control block.
|
||||
|
||||
# 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 a semaphore and then scan the file control blocks to determine
|
||||
which slot is free for use. The first free slot is marked as used and the
|
||||
index to this slot is returned as the file descriptor for the open()
|
||||
request. After the alterations have been made to the file control block
|
||||
table, the semaphore is released to allow further operations on the 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
|
||||
a semaphore and then scan the file control blocks to determine which slot is
|
||||
free for use. The first free slot is marked as used and the index to this
|
||||
slot is returned as the file descriptor for the open() request. After the
|
||||
alterations have been made to the file control block table, the semaphore is
|
||||
released to allow further operations on the table.
|
||||
|
||||
# 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.
|
||||
# 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
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: c
|
||||
|
||||
struct rtems_libio_tt {
|
||||
rtems_driver_name_t \*driver;
|
||||
rtems_driver_name_t *driver;
|
||||
off_t size;
|
||||
off_t offset;
|
||||
unsigned32 flags;
|
||||
@ -237,22 +239,21 @@ components.
|
||||
A file control block can exist for regular files, devices and directories.
|
||||
The following fields are important for regular file and directory access:
|
||||
|
||||
- Size - For a file this represents the number of bytes currently
|
||||
stored in a file. For a directory this field is not filled in.
|
||||
- Size - For a file this represents the number of bytes currently stored in a
|
||||
file. For a directory this field is not filled in.
|
||||
|
||||
- Offset - For a file this is the byte file position index relative to
|
||||
the start of the file. For a directory this is the byte offset into a
|
||||
sequence of dirent structures.
|
||||
- Offset - For a file this is the byte file position index relative to the
|
||||
start of the file. For a directory this is the byte offset into a sequence
|
||||
of dirent structures.
|
||||
|
||||
- Pathinfo - This is a structure that provides a pointer to node
|
||||
information, OPS table functions, Handler functions and the mount table
|
||||
entry associated with this node.
|
||||
- Pathinfo - This is a structure that provides a pointer to node information,
|
||||
OPS table functions, Handler functions and the mount table entry associated
|
||||
with this node.
|
||||
|
||||
- file_info - A pointer to node information that is used by Handler
|
||||
functions
|
||||
- file_info - A pointer to node information that is used by Handler functions
|
||||
|
||||
- handlers - A pointer to a table of handler functions that operate on
|
||||
a file, device or directory through a file descriptor index
|
||||
- handlers - A pointer to a table of handler functions that operate on a
|
||||
file, device or directory through a file descriptor index
|
||||
|
||||
File/Directory function access via rtems_filesystem_location_info_t structure
|
||||
-----------------------------------------------------------------------------
|
||||
@ -260,41 +261,40 @@ File/Directory function access via rtems_filesystem_location_info_t structure
|
||||
The rtems_filesystem_location_info_tt structure below provides sufficient
|
||||
information to process nodes under a mounted filesystem.
|
||||
|
||||
.. code:: c
|
||||
.. 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;
|
||||
};
|
||||
|
||||
It contains a void pointer to filesystem specific nodal structure,
|
||||
pointers to the OPS table for the filesystem that contains the node, the
|
||||
node type specific handlers for the node and a reference pointer to the
|
||||
mount table entry associated with the filesystem containing the node
|
||||
It contains a void pointer to filesystem specific nodal structure, pointers to
|
||||
the OPS table for the filesystem that contains the node, the node type specific
|
||||
handlers for the node and a reference pointer to the mount table entry
|
||||
associated with the filesystem containing the node
|
||||
|
||||
Operation Tables
|
||||
================
|
||||
|
||||
Filesystem specific operations are invoked indirectly. The set of
|
||||
routines that implement the filesystem are configured into two tables.
|
||||
The Filesystem Handler Table has routines that are specific to a
|
||||
filesystem but remain constant regardless of the actual file type.
|
||||
The File Handler Table has routines that are both filesystem and file type
|
||||
specific.
|
||||
Filesystem specific operations are invoked indirectly. The set of routines
|
||||
that implement the filesystem are configured into two tables. The Filesystem
|
||||
Handler Table has routines that are specific to a filesystem but remain
|
||||
constant regardless of the actual file type. The File Handler Table has
|
||||
routines that are both filesystem and file type specific.
|
||||
|
||||
Filesystem Handler Table Functions
|
||||
----------------------------------
|
||||
|
||||
OPS table functions are defined in a ``rtems_filesystem_operations_table``
|
||||
structure. It defines functions that are specific to a given filesystem.
|
||||
One table exists for each filesystem that is supported in the RTEMS
|
||||
structure. It defines functions that are specific to a given filesystem. One
|
||||
table exists for each filesystem that is supported in the RTEMS
|
||||
configuration. The structure definition appears below and is followed by
|
||||
general developmental information on each of the functions contained in this
|
||||
function management structure.
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: c
|
||||
|
||||
typedef struct {
|
||||
rtems_filesystem_evalpath_t evalpath;
|
||||
@ -315,8 +315,6 @@ function management structure.
|
||||
rtems_filesystem_symlink_t symlink;
|
||||
} rtems_filesystem_operations_table;
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
evalpath Handler
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -326,27 +324,25 @@ evalpath
|
||||
|
||||
**Arguments:**
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: c
|
||||
|
||||
const char \*pathname, /* IN \*/
|
||||
int flags, /* IN \*/
|
||||
rtems_filesystem_location_info_t \*pathloc /* IN/OUT \*/
|
||||
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 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 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.
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
evalformake Handler
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -356,29 +352,27 @@ evalformake
|
||||
|
||||
**Arguments:**
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: c
|
||||
|
||||
const char \*path, /* IN \*/
|
||||
rtems_filesystem_location_info_t \*pathloc, /* IN/OUT \*/
|
||||
const char \**name /* OUT \*/
|
||||
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 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.
|
||||
|
||||
.. COMMENT: @page
|
||||
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
|
||||
~~~~~~~~~~~~
|
||||
@ -389,26 +383,24 @@ link
|
||||
|
||||
**Arguments:**
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: c
|
||||
|
||||
rtems_filesystem_location_info_t \*to_loc, /* IN \*/
|
||||
rtems_filesystem_location_info_t \*parent_loc, /* IN \*/
|
||||
const char \*token /* IN \*/
|
||||
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.
|
||||
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.
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
unlink Handler
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
@ -424,8 +416,6 @@ XXX
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
node_type Handler
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -435,16 +425,14 @@ node_type()
|
||||
|
||||
**Arguments:**
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: c
|
||||
|
||||
rtems_filesystem_location_info_t \*pathloc /* IN \*/
|
||||
rtems_filesystem_location_info_t *pathloc /* IN */
|
||||
|
||||
**Description:**
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
mknod Handler
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
@ -454,19 +442,17 @@ mknod()
|
||||
|
||||
**Arguments:**
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: c
|
||||
|
||||
const char \*token, /* IN \*/
|
||||
mode_t mode, /* IN \*/
|
||||
dev_t dev, /* IN \*/
|
||||
rtems_filesystem_location_info_t \*pathloc /* IN/OUT \*/
|
||||
const char *token, /* IN */
|
||||
mode_t mode, /* IN */
|
||||
dev_t dev, /* IN */
|
||||
rtems_filesystem_location_info_t *pathloc /* IN/OUT */
|
||||
|
||||
**Description:**
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
rmnod Handler
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
@ -482,8 +468,6 @@ XXX
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
chown Handler
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
@ -493,11 +477,11 @@ chown()
|
||||
|
||||
**Arguments:**
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: c
|
||||
|
||||
rtems_filesystem_location_info_t \*pathloc /* IN \*/
|
||||
uid_t owner /* IN \*/
|
||||
gid_t group /* IN \*/
|
||||
rtems_filesystem_location_info_t *pathloc /* IN */
|
||||
uid_t owner /* IN */
|
||||
gid_t group /* IN */
|
||||
|
||||
**Description:**
|
||||
|
||||
@ -514,21 +498,19 @@ freenod()
|
||||
|
||||
**Arguments:**
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: c
|
||||
|
||||
rtems_filesystem_location_info_t \*pathloc /* IN \*/
|
||||
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 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.
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
mount Handler
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
@ -538,16 +520,14 @@ mount()
|
||||
|
||||
**Arguments:**
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: c
|
||||
|
||||
rtems_filesystem_mount_table_entry_t \*mt_entry
|
||||
rtems_filesystem_mount_table_entry_t *mt_entry
|
||||
|
||||
**Description:**
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
fsmount_me Handler
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -557,15 +537,15 @@ XXX
|
||||
|
||||
**Arguments:**
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: c
|
||||
|
||||
rtems_filesystem_mount_table_entry_t \*mt_entry
|
||||
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.
|
||||
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.
|
||||
@ -573,37 +553,46 @@ containing the mount point.
|
||||
The rtems_filesystem_mount_table_entry_t structure contains the key elements
|
||||
below:
|
||||
|
||||
rtems_filesystem_location_info_t \*mt_point_node,
|
||||
.. 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.
|
||||
|
||||
rtems_filesystem_location_info_t \*fs_root_node,
|
||||
.. 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
|
||||
|
||||
void \*fs_info,
|
||||
.. code-block:: c
|
||||
|
||||
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.
|
||||
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:
|
||||
The table contains the following set of values associated with the mounted
|
||||
filesystem:
|
||||
|
||||
- link_max
|
||||
|
||||
@ -629,29 +618,29 @@ mounted filesystem:
|
||||
|
||||
- posix_vdisable
|
||||
|
||||
These values are accessed with the pathconf() and the fpathconf ()
|
||||
functions.
|
||||
These values are accessed with the pathconf() and the fpathconf () functions.
|
||||
|
||||
const char \*dev
|
||||
.. 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.
|
||||
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 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.
|
||||
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).
|
||||
@ -664,10 +653,8 @@ The fs_root_node structure will be filled in with the following:
|
||||
|
||||
- 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.
|
||||
|
||||
.. COMMENT: @page
|
||||
A 0 will be returned to the calling routine if the process succeeded, otherwise
|
||||
a 1 will be returned.
|
||||
|
||||
unmount Handler
|
||||
~~~~~~~~~~~~~~~
|
||||
@ -684,8 +671,6 @@ XXX
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
fsunmount_me Handler
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -695,16 +680,14 @@ imfs_fsunmount_me()
|
||||
|
||||
**Arguments:**
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: c
|
||||
|
||||
rtems_filesystem_mount_table_entry_t \*mt_entry
|
||||
rtems_filesystem_mount_table_entry_t *mt_entry
|
||||
|
||||
**Description:**
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
utime Handler
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
@ -720,8 +703,6 @@ XXX
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
eval_link Handler
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -737,8 +718,6 @@ XXX
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
symlink Handler
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
@ -754,8 +733,6 @@ XXX
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
File Handler Table Functions
|
||||
----------------------------
|
||||
|
||||
@ -763,9 +740,10 @@ Handler table functions are defined in a ``rtems_filesystem_file_handlers_r``
|
||||
structure. It defines functions that are specific to a node type in a given
|
||||
filesystem. One table exists for each of the filesystem's node types. The
|
||||
structure definition appears below. It is followed by general developmental
|
||||
information on each of the functions associated with regular files contained
|
||||
in this function management structure.
|
||||
.. code:: c
|
||||
information on each of the functions associated with regular files contained in
|
||||
this function management structure.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
typedef struct {
|
||||
rtems_filesystem_open_t open;
|
||||
@ -783,8 +761,6 @@ in this function management structure.
|
||||
rtems_filesystem_fcntl_t fcntl;
|
||||
} rtems_filesystem_file_handlers_r;
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
open Handler
|
||||
~~~~~~~~~~~~
|
||||
|
||||
@ -794,10 +770,10 @@ open()
|
||||
|
||||
**Arguments:**
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: c
|
||||
|
||||
rtems_libio_t \*iop,
|
||||
const char \*pathname,
|
||||
rtems_libio_t *iop,
|
||||
const char *pathname,
|
||||
unsigned32 flag,
|
||||
unsigned32 mode
|
||||
|
||||
@ -805,8 +781,6 @@ open()
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
close Handler
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
@ -816,9 +790,9 @@ close()
|
||||
|
||||
**Arguments:**
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: c
|
||||
|
||||
rtems_libio_t \*iop
|
||||
rtems_libio_t *iop
|
||||
|
||||
**Description:**
|
||||
|
||||
@ -828,8 +802,6 @@ XXX
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
read Handler
|
||||
~~~~~~~~~~~~
|
||||
|
||||
@ -839,10 +811,10 @@ read()
|
||||
|
||||
**Arguments:**
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: c
|
||||
|
||||
rtems_libio_t \*iop,
|
||||
void \*buffer,
|
||||
rtems_libio_t *iop,
|
||||
void *buffer,
|
||||
unsigned32 count
|
||||
|
||||
**Description:**
|
||||
@ -853,8 +825,6 @@ XXX
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
write Handler
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
@ -874,8 +844,6 @@ XXX
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
ioctl Handler
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
@ -885,11 +853,11 @@ XXX
|
||||
|
||||
**Arguments:**
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: c
|
||||
|
||||
rtems_libio_t \*iop,
|
||||
rtems_libio_t *iop,
|
||||
unsigned32 command,
|
||||
void \*buffer
|
||||
void *buffer
|
||||
|
||||
**Description:**
|
||||
|
||||
@ -899,8 +867,6 @@ XXX
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
lseek Handler
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
@ -910,9 +876,9 @@ lseek()
|
||||
|
||||
**Arguments:**
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: c
|
||||
|
||||
rtems_libio_t \*iop,
|
||||
rtems_libio_t *iop,
|
||||
off_t offset,
|
||||
int whence
|
||||
|
||||
@ -924,8 +890,6 @@ XXX
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
fstat Handler
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
@ -935,15 +899,15 @@ fstat()
|
||||
|
||||
**Arguments:**
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: c
|
||||
|
||||
rtems_filesystem_location_info_t \*loc,
|
||||
struct stat \*buf
|
||||
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:
|
||||
The following information is extracted from the filesystem specific node and
|
||||
placed in the ``stat`` structure:
|
||||
|
||||
- st_mode
|
||||
|
||||
@ -963,16 +927,12 @@ specific node and placed in the ``stat`` structure:
|
||||
|
||||
**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.
|
||||
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.
|
||||
|
||||
.. COMMENT: @page
|
||||
The ``fstat()`` system call is implemented directly on top of this filesystem
|
||||
handler.
|
||||
|
||||
fchmod Handler
|
||||
~~~~~~~~~~~~~~
|
||||
@ -983,9 +943,9 @@ fchmod()
|
||||
|
||||
**Arguments:**
|
||||
|
||||
.. code:: c
|
||||
.. code-block:: c
|
||||
|
||||
rtems_libio_t \*iop
|
||||
rtems_libio_t *iop
|
||||
mode_t mode
|
||||
|
||||
**Description:**
|
||||
@ -996,8 +956,6 @@ XXX
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
ftruncate Handler
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -1036,8 +994,6 @@ XXX
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
fsync Handler
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
@ -1057,8 +1013,6 @@ XXX
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
fdatasync Handler
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -1078,8 +1032,6 @@ XXX
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: @page
|
||||
|
||||
fcntl Handler
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
@ -1098,10 +1050,3 @@ XXX
|
||||
**NOTES:**
|
||||
|
||||
XXX
|
||||
|
||||
.. COMMENT: COPYRIGHT (c) 1988-2002.
|
||||
|
||||
.. COMMENT: On-Line Applications Research Corporation (OAR).
|
||||
|
||||
.. COMMENT: All rights reserved.
|
||||
|
||||
|
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
|
||||
@ -51,5 +48,3 @@ Table of Contents
|
||||
|
||||
* :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,29 +12,30 @@ 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
|
||||
{
|
||||
@ -38,7 +43,7 @@ Each entry in the mount table chain is of the following type:
|
||||
rtems_filesystem_location_info_t mt_point_node;
|
||||
rtems_filesystem_location_info_t mt_fs_root;
|
||||
int options;
|
||||
void \*fs_info;
|
||||
void *fs_info;
|
||||
rtems_filesystem_limits_and_options_t pathconf_limits_and_options;
|
||||
/*
|
||||
* When someone adds a mounted filesystem on a real device,
|
||||
@ -46,7 +51,7 @@ Each entry in the mount table chain is of the following type:
|
||||
*
|
||||
* The best option long term for this is probably an
|
||||
* open file descriptor.
|
||||
\*/
|
||||
*/
|
||||
char \*dev;
|
||||
};
|
||||
|
||||
@ -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