summaryrefslogtreecommitdiffstats
path: root/doc/filesystem
diff options
context:
space:
mode:
authorJoel Sherrill <joel.sherrill@OARcorp.com>1999-10-12 21:44:38 +0000
committerJoel Sherrill <joel.sherrill@OARcorp.com>1999-10-12 21:44:38 +0000
commit87c2f9ce992bdf00e3b75d68de19bf6f5cef3027 (patch)
treed51fc76a3ebef780912a7d1775e2ac96427ec6ae /doc/filesystem
parentDispersed. (diff)
downloadrtems-87c2f9ce992bdf00e3b75d68de19bf6f5cef3027.tar.bz2
Dispersed.
Diffstat (limited to 'doc/filesystem')
-rw-r--r--doc/filesystem/basefs.t324
1 files changed, 0 insertions, 324 deletions
diff --git a/doc/filesystem/basefs.t b/doc/filesystem/basefs.t
deleted file mode 100644
index 14233a000d..0000000000
--- a/doc/filesystem/basefs.t
+++ /dev/null
@@ -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
-