forked from Imagelibrary/rtems
Dispersed.
This commit is contained in:
Joel Sherrill
@@ -1,324 +0,0 @@
|
|||||||
@c
|
|
||||||
@c COPYRIGHT (c) 1988-1998.
|
|
||||||
@c On-Line Applications Research Corporation (OAR).
|
|
||||||
@c All rights reserved.
|
|
||||||
@c
|
|
||||||
@c $Id$
|
|
||||||
@c
|
|
||||||
|
|
||||||
|
|
||||||
@chapter 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.
|
|
||||||
|
|
||||||
@example
|
|
||||||
Figure of the tree structure goes here.
|
|
||||||
@end example
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
@section 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.
|
|
||||||
|
|
||||||
|
|
||||||
@example
|
|
||||||
Figure of the mount table chain goes here.
|
|
||||||
@end example
|
|
||||||
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
@example
|
|
||||||
Figure of the Mount Table Processing goes here.
|
|
||||||
@end example
|
|
||||||
|
|
||||||
|
|
||||||
Note: Other file systems can be mounted but they are mounted onto points
|
|
||||||
(directory mount points) in the base file system.
|
|
||||||
|
|
||||||
|
|
||||||
@subsection Base Filesystem Node Structure and Function
|
|
||||||
|
|
||||||
Each regular file, device, hard link, and directory is represented by a data
|
|
||||||
structure called a @code{jnode}. The @code{jnode} is formally represented by the
|
|
||||||
structure:
|
|
||||||
|
|
||||||
@example
|
|
||||||
struct IMFS_jnode_tt @{
|
|
||||||
Chain_Node Node; /* for chaining them together */
|
|
||||||
IMFS_jnode_t *Parent; /* Parent node */
|
|
||||||
char name[NAME_MAX+1]; /* "basename" */
|
|
||||||
mode_t st_mode; /* File mode */
|
|
||||||
nlink_t st_nlink; /* Link count */
|
|
||||||
ino_t st_ino; /* inode */
|
|
||||||
|
|
||||||
uid_t st_uid; /* User ID of owner */
|
|
||||||
gid_t st_gid; /* Group ID of owner */
|
|
||||||
time_t st_atime; /* Time of last access */
|
|
||||||
time_t st_mtime; /* Time of last modification */
|
|
||||||
time_t st_ctime; /* Time of last status change */
|
|
||||||
IMFS_jnode_types_t type; /* Type of this entry */
|
|
||||||
IMFS_typs_union info;
|
|
||||||
@};
|
|
||||||
@end example
|
|
||||||
|
|
||||||
The key elements of this structure are listed below together with a brief
|
|
||||||
explanation of their role in the file system.
|
|
||||||
|
|
||||||
@table @b
|
|
||||||
|
|
||||||
@item Node
|
|
||||||
This element exists simply to allow the entire @code{jnode} structure to be
|
|
||||||
included in a chain.
|
|
||||||
|
|
||||||
@item Parent
|
|
||||||
A pointer to another @code{jnode} structure that is the logical parent of the
|
|
||||||
node in which it appears. There are circumstances that will produce a null
|
|
||||||
parent pointer within a @code{jnode}. This can occur when a hard link is
|
|
||||||
created to a file and the file is then removed without removing the hard
|
|
||||||
link.
|
|
||||||
|
|
||||||
@item name
|
|
||||||
The name of this node within the file system hierarchical tree. Example: If
|
|
||||||
the fully qualified pathname to the @code{jnode} was /a/b/c, the @code{jnode} name
|
|
||||||
field would contain the null terminated string "c"
|
|
||||||
|
|
||||||
@item st_mode
|
|
||||||
The standard Unix access permissions for the file or directory.
|
|
||||||
|
|
||||||
@item st_nlink
|
|
||||||
The number of hard links to this file. When a @code{jnode} is first created
|
|
||||||
its link count is set to 1. A @code{jnode} and its associated resources
|
|
||||||
cannot be deleted unless its link count is less than 1.
|
|
||||||
|
|
||||||
@item st_ino
|
|
||||||
A unique node identification number
|
|
||||||
|
|
||||||
@item st_uid
|
|
||||||
The user ID of the file's owner
|
|
||||||
|
|
||||||
@item st_gid
|
|
||||||
The group ID of the file's owner
|
|
||||||
|
|
||||||
@item st_atime
|
|
||||||
The time of the last access to this file
|
|
||||||
|
|
||||||
@item st_mtime
|
|
||||||
The time of the last modification of this file
|
|
||||||
|
|
||||||
@item st_ctime
|
|
||||||
The time of the last status change to the file
|
|
||||||
|
|
||||||
@item type
|
|
||||||
The indication of node type must be one of the following states:
|
|
||||||
|
|
||||||
@itemize @bullet
|
|
||||||
@item IMFS_DIRECTORY
|
|
||||||
@item IMFS_MEMORY_FILE
|
|
||||||
@item IMFS_HARD_LINK
|
|
||||||
@item IMFS_SYM_LINK
|
|
||||||
@item IMFS_DEVICE
|
|
||||||
@end itemize
|
|
||||||
|
|
||||||
|
|
||||||
@item info
|
|
||||||
This contains a structure that is unique to file type (See IMFS_typs_union
|
|
||||||
in imfs.h).
|
|
||||||
|
|
||||||
@itemize @bullet
|
|
||||||
|
|
||||||
@item IMFS_DIRECTORY
|
|
||||||
|
|
||||||
An in memory file system directory contains a dynamic chain structure that
|
|
||||||
records all files and directories that are subordinate to the directory node.
|
|
||||||
|
|
||||||
@item IMFS_MEMORY_FILE
|
|
||||||
|
|
||||||
Under the in memory file system regular files hold data. Data is dynamically
|
|
||||||
allocated to the file in 128 byte chunks of memory. The individual chunks of
|
|
||||||
memory are tracked by arrays of pointers that record the address of the
|
|
||||||
allocated chunk of memory. Single, double, and triple indirection pointers
|
|
||||||
are used to record the locations of all segments of the file. These
|
|
||||||
memory-tracking techniques are graphically depicted in figures XXX and XXX of
|
|
||||||
appendix A.
|
|
||||||
|
|
||||||
@item IMFS_HARD_LINK
|
|
||||||
|
|
||||||
The IMFS file system supports the concept of hard links to other nodes in the
|
|
||||||
IMFS file system. These hard links are actual pointers to the memory
|
|
||||||
associated with other nodes in the file system. This type of link cannot
|
|
||||||
cross-file system boundaries.
|
|
||||||
|
|
||||||
@item IMFS_SYM_LINK
|
|
||||||
|
|
||||||
The IMFS file system supports the concept of symbolic links to other nodes in
|
|
||||||
any file system. A symbolic link consists of a pointer to a character string
|
|
||||||
that represents the pathname to the target node. This type of link can
|
|
||||||
cross-file system boundaries.
|
|
||||||
|
|
||||||
@item IMFS_DEVICE
|
|
||||||
|
|
||||||
All RTEMS devices now appear as files under the in memory file system. On
|
|
||||||
system initialization, all devices are registered as nodes under the file
|
|
||||||
system.
|
|
||||||
|
|
||||||
@end itemize
|
|
||||||
|
|
||||||
@end table
|
|
||||||
|
|
||||||
|
|
||||||
@subsection Node removal constraints for the base files system
|
|
||||||
|
|
||||||
@itemize @bullet
|
|
||||||
|
|
||||||
@item If a node is a directory with children it cannot be removed.
|
|
||||||
|
|
||||||
@item The root node of the base file system or the mounted file system
|
|
||||||
cannot be removed.
|
|
||||||
|
|
||||||
@item A node that is a directory that is acting as the mount point of a file
|
|
||||||
system cannot be removed.
|
|
||||||
|
|
||||||
@item Prior to node removal, decrement the node's link count by one. The
|
|
||||||
link count must be less than one to allow for removal of the node.
|
|
||||||
|
|
||||||
@end itemize
|
|
||||||
|
|
||||||
@subsection Housekeeping
|
|
||||||
|
|
||||||
@itemize @bullet
|
|
||||||
|
|
||||||
@item If the global variable rtems_filesystem_current refers to the node that
|
|
||||||
we are trying to remove, the node_access element of this structure must be
|
|
||||||
set to NULL to invalidate it.
|
|
||||||
|
|
||||||
@item If the node was of IMFS_MEMORY_FILE type, free the memory associated
|
|
||||||
with the memory file before freeing the node. Use the IMFS_memfile_remove()
|
|
||||||
function.
|
|
||||||
|
|
||||||
@end itemize
|
|
||||||
|
|
||||||
|
|
||||||
@section IMFS
|
|
||||||
|
|
||||||
@subsection OPS Table Functions for the In Memory Filesystem (IMFS)
|
|
||||||
|
|
||||||
@example
|
|
||||||
|
|
||||||
OPS Table Functions File Routine Name
|
|
||||||
|
|
||||||
Evalpath Imfs_eval.c IMFS_eval_path()
|
|
||||||
Evalformake Imfs_eval.c IMFS_evaluate_for_make()
|
|
||||||
Link Imfs_link.c IMFS_link()
|
|
||||||
Unlink Imfs_unlink.c IMFS_unlink()
|
|
||||||
Node_type Imfs_ntype.c IMFS_node_type()
|
|
||||||
Mknod Imfs_mknod.c IMFS_mknod()
|
|
||||||
Rmnod Imfs_rmnod.c IMFS_rmnod()
|
|
||||||
Chown Imfs_chown.c IMFS_chown()
|
|
||||||
Freenod Imfs_free.c IMFS_freenodinfo()
|
|
||||||
Mount Imfs_mount.c IMFS_mount()
|
|
||||||
Fsmount_me Imfs_init.c IMFS_initialize()
|
|
||||||
Unmount Imfs_unmount.c IMFS_unmount()
|
|
||||||
Fsunmount_me Imfs_init.c IMFS_fsunmount()
|
|
||||||
Utime Imfs_utime.c IMFS_utime()
|
|
||||||
Eval_link Imfs_eval.c IMFS_evaluate_link()
|
|
||||||
Symlink Imfs_symlink.c IMFS_symlink()
|
|
||||||
Readlink Imfs_readlink.c IMFS_readlink()
|
|
||||||
@end example
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@subsection Handler Functions for Regular Files of In Memory Filesystem
|
|
||||||
|
|
||||||
@example
|
|
||||||
Handler Function File Routine Name
|
|
||||||
|
|
||||||
Open Memfile.c Memfile_open()
|
|
||||||
Close Memfile.c Memfile_close()
|
|
||||||
Read Memfile.c Memfile_read()
|
|
||||||
Write Memfile.c Memfile_write()
|
|
||||||
Ioctl Memfile.c Memfile_ioctl()
|
|
||||||
Lseek Memfile.c Memfile_lseek()
|
|
||||||
Fstat Imfs_stat.c IMFS_stat()
|
|
||||||
Fchmod Imfs_fchmod.c IMFS_fchmod()
|
|
||||||
Ftruncate Memfile.c Memfile_ftruncate()
|
|
||||||
Fpathconf NA NULL
|
|
||||||
Fsync NA NULL
|
|
||||||
Fdatasync NA NULL
|
|
||||||
@end example
|
|
||||||
|
|
||||||
|
|
||||||
@subsection Handler Functions for Directories of In Memory Filesystem
|
|
||||||
|
|
||||||
@example
|
|
||||||
Handler Function File Routine Name
|
|
||||||
|
|
||||||
Open imfs_directory.c Imfs_dir_open()
|
|
||||||
Close imfs_directory.c Imfs_dir_close()
|
|
||||||
Read imfs_directory.c Imfs_dir_read()
|
|
||||||
Write imfs_directory.c NULL
|
|
||||||
Ioctl imfs_directory.c NULL
|
|
||||||
Lseek imfs_directory.c Imfs_dir_lseek()
|
|
||||||
Fstat imfs_directory.c Imfs_dir_fstat()
|
|
||||||
Fchmod imfs_fchmod.c IMFS_fchmod()
|
|
||||||
Ftruncate NA NULL
|
|
||||||
Fpathconf NA NULL
|
|
||||||
Fsync NA NULL
|
|
||||||
Fdatasync NA NULL
|
|
||||||
@end example
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@subsection Handler Functions for Devices of In Memory Filesystem
|
|
||||||
|
|
||||||
@example
|
|
||||||
Handler Function File Routine Name
|
|
||||||
|
|
||||||
Open deviceio.c Device_open()
|
|
||||||
Close deviceio.c Device_close()
|
|
||||||
Read deviceio.c Device_read()
|
|
||||||
Write deviceio.c Device_write()
|
|
||||||
Ioctl deviceio.c Device_ioctl()
|
|
||||||
Lseek deviceio.c Device_lseek()
|
|
||||||
Fstat imfs_stat.c IMFS_stat()
|
|
||||||
Fchmod imfs_fchmod.c IMFS_fchmod()
|
|
||||||
Ftruncate NA NULL
|
|
||||||
Fpathconf NA NULL
|
|
||||||
Fsync NA NULL
|
|
||||||
Fdatasync NA NULL
|
|
||||||
@end example
|
|
||||||
|
|
||||||
Reference in New Issue
Block a user