mirror of
https://git.rtems.org/rtems-docs/
synced 2025-05-14 05:09:33 +08:00
Split document into seperate files by section.
This commit is contained in:
Amar Takhar
parent
c142f5b338
commit
2d1dc3fe73
1132
filesystem/call_development.rst
Normal file
1132
filesystem/call_development.rst
Normal file
File diff suppressed because it is too large
Load Diff
7
filesystem/command_and_variable.rst
Normal file
7
filesystem/command_and_variable.rst
Normal file
@ -0,0 +1,7 @@
|
||||
Command and Variable Index
|
||||
##########################
|
||||
|
||||
There are currently no Command and Variable Index entries.
|
||||
|
||||
.. COMMENT: @printindex fn
|
||||
|
||||
1105
filesystem/fileystem_implmentation.rst
Normal file
1105
filesystem/fileystem_implmentation.rst
Normal file
File diff suppressed because it is too large
Load Diff
1869
filesystem/in-memory.rst
Normal file
1869
filesystem/in-memory.rst
Normal file
File diff suppressed because it is too large
Load Diff
@ -1 +1,100 @@
|
||||
.. include:: filesystem.rst
|
||||
.. COMMENT: %**end of header
|
||||
|
||||
.. COMMENT: COPYRIGHT (c) 1989-2013.
|
||||
|
||||
.. COMMENT: On-Line Applications Research Corporation (OAR).
|
||||
|
||||
.. COMMENT: All rights reserved.
|
||||
|
||||
.. COMMENT: Master file for the Filesystem Design Guide
|
||||
|
||||
.. COMMENT: COPYRIGHT (c) 1988-2002.
|
||||
|
||||
.. COMMENT: On-Line Applications Research Corporation (OAR).
|
||||
|
||||
.. COMMENT: All rights reserved.
|
||||
|
||||
.. COMMENT: The following determines which set of the tables and figures we will use.
|
||||
|
||||
.. COMMENT: We default to ASCII but if available TeX or HTML versions will
|
||||
|
||||
.. COMMENT: be used instead.
|
||||
|
||||
.. COMMENT: @clear use-html
|
||||
|
||||
.. COMMENT: @clear use-tex
|
||||
|
||||
.. COMMENT: The following variable says to use texinfo or html for the two column
|
||||
|
||||
.. COMMENT: texinfo tables. For somethings the format does not look good in html.
|
||||
|
||||
.. COMMENT: With our adjustment to the left column in TeX, it nearly always looks
|
||||
|
||||
.. COMMENT: good printed.
|
||||
|
||||
.. COMMENT: Custom whitespace adjustments. We could fiddle a bit more.
|
||||
|
||||
.. COMMENT: Title Page Stuff
|
||||
|
||||
.. COMMENT: I don't really like having a short title page. -joel
|
||||
|
||||
.. COMMENT: @shorttitlepage RTEMS Filesystem Design Guide
|
||||
|
||||
=============================
|
||||
RTEMS Filesystem Design Guide
|
||||
=============================
|
||||
|
||||
.. COMMENT: COPYRIGHT (c) 1988-2015.
|
||||
|
||||
.. COMMENT: On-Line Applications Research Corporation (OAR).
|
||||
|
||||
.. COMMENT: All rights reserved.
|
||||
|
||||
.. COMMENT: The following puts a space somewhere on an otherwise empty page so we
|
||||
|
||||
.. COMMENT: can force the copyright description onto a left hand page.
|
||||
|
||||
COPYRIGHT © 1988 - 2015.
|
||||
|
||||
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 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 tohttp://www.rtems.com.
|
||||
|
||||
.. COMMENT: This prevents a black box from being printed on "overflow" lines.
|
||||
.. COMMENT: The alternative is to rework a sentence to avoid this problem.
|
||||
|
||||
|
||||
Table of Contents
|
||||
-----------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
:numbered:
|
||||
|
||||
preface
|
||||
pathname_eval
|
||||
system_init
|
||||
mounting_and_unmounting
|
||||
call_development
|
||||
fileystem_implmentation
|
||||
in-memory
|
||||
minature_in-memory
|
||||
trivial_ftp
|
||||
command_and_variable
|
||||
|
||||
|
||||
16
filesystem/minature_in-memory.rst
Normal file
16
filesystem/minature_in-memory.rst
Normal file
@ -0,0 +1,16 @@
|
||||
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.
|
||||
|
||||
102
filesystem/mounting_and_unmounting.rst
Normal file
102
filesystem/mounting_and_unmounting.rst
Normal file
@ -0,0 +1,102 @@
|
||||
Mounting and Unmounting Filesystems
|
||||
###################################
|
||||
|
||||
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 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.
|
||||
|
||||
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
|
||||
|
||||
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;
|
||||
};
|
||||
|
||||
*Node*
|
||||
The Node is used to produce a linked list of mount table entry nodes.
|
||||
|
||||
*mt_point_node*
|
||||
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.
|
||||
|
||||
*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.
|
||||
|
||||
*options*
|
||||
XXX
|
||||
|
||||
*fs_info*
|
||||
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.
|
||||
|
||||
*pathconf_limits_and_options*
|
||||
XXX
|
||||
|
||||
*dev*
|
||||
This character string represents the device where the filesystem will reside.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
95
filesystem/pathname_eval.rst
Normal file
95
filesystem/pathname_eval.rst
Normal file
@ -0,0 +1,95 @@
|
||||
Pathname Evaluation
|
||||
###################
|
||||
|
||||
This chapter describes the pathname evaluation process for the
|
||||
RTEMS Filesystem Infrastructure.
|
||||
.. code:: c
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
The rtems_filesystem_location_info_t Structure
|
||||
==============================================
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
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;
|
||||
};
|
||||
|
||||
*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.
|
||||
|
||||
*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.
|
||||
|
||||
*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.
|
||||
|
||||
*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.
|
||||
|
||||
66
filesystem/preface.rst
Normal file
66
filesystem/preface.rst
Normal file
@ -0,0 +1,66 @@
|
||||
Preface
|
||||
#######
|
||||
|
||||
This document describes the implementation of the RTEMS filesystem
|
||||
infrastructure. This infrastructure supports the following
|
||||
capabilities:
|
||||
|
||||
- Mountable file systems
|
||||
|
||||
- Hierarchical file system directory structure
|
||||
|
||||
- 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
|
||||
# Access time
|
||||
# Modification time
|
||||
# Creation time
|
||||
|
||||
- Hard links to files and directories
|
||||
|
||||
- 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 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.
|
||||
|
||||
99
filesystem/system_init.rst
Normal file
99
filesystem/system_init.rst
Normal file
@ -0,0 +1,99 @@
|
||||
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:
|
||||
|
||||
- Initialization of mount table chain control structure
|
||||
|
||||
- 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.
|
||||
|
||||
- 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
|
||||
|
||||
After the base filesystem has been mounted, the following operations are
|
||||
performed under its directory structure:
|
||||
|
||||
- Creation of the /dev directory
|
||||
|
||||
- Registration of devices under /dev directory
|
||||
|
||||
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
|
||||
|
||||
Figure of the tree structure goes here.
|
||||
|
||||
A RAM based file system draws its management resources from memory. File and
|
||||
directory nodes are simply allocated blocks of memory. Data associated with
|
||||
regular files is stored in collections of memory blocks. When the system is
|
||||
turned off or restarted all memory-based components of the file system are
|
||||
lost.
|
||||
|
||||
The base file system serves as a starting point for the mounting of file
|
||||
systems that are resident on semi-permanent storage media. Examples of such
|
||||
media include non- volatile memory, flash memory and IDE hard disk drives
|
||||
(Figure 3). File systems of other types will be mounted onto mount points
|
||||
within the base file system or other file systems that are subordinate to the
|
||||
base file system. The framework set up under the base file system will allow
|
||||
for these new file system types and the unique data and functionality that is
|
||||
required to manage the future file systems.
|
||||
|
||||
Base Filesystem Mounting
|
||||
------------------------
|
||||
|
||||
At present, the first file system to be mounted is the ‘In Memory File
|
||||
System’. It is mounted using a standard MOUNT() command in which the mount
|
||||
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
|
||||
|
||||
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.
|
||||
|
||||
.. code:: c
|
||||
|
||||
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.
|
||||
|
||||
8
filesystem/trivial_ftp.rst
Normal file
8
filesystem/trivial_ftp.rst
Normal file
@ -0,0 +1,8 @@
|
||||
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.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user