From df4edf29fef5ef310a8047c9032fdb06518c7c07 Mon Sep 17 00:00:00 2001 From: Joel Sherrill Date: Thu, 7 Oct 1999 22:31:00 +0000 Subject: Added Base File System chapter. Builds completely. --- doc/filesystem/Makefile | 51 ++----- doc/filesystem/basefs.t | 309 +++++++++++++++++++++++++++++++++++++++++ doc/filesystem/filesystem.texi | 2 + doc/filesystem/preface.texi | 2 +- 4 files changed, 325 insertions(+), 39 deletions(-) create mode 100644 doc/filesystem/basefs.t diff --git a/doc/filesystem/Makefile b/doc/filesystem/Makefile index 74d2a8df30..79c4967f3a 100644 --- a/doc/filesystem/Makefile +++ b/doc/filesystem/Makefile @@ -21,7 +21,7 @@ dirs: COMMON_FILES=../common/cpright.texi ../common/setup.texi -GENERATED_FILES= +GENERATED_FILES=basefs.texi FILES= $(PROJECT).texi \ preface.texi $(GENERATED_FILES) @@ -51,45 +51,20 @@ $(PROJECT).dvi: $(FILES) $(TEXI2DVI) $(PROJECT).texi cp $(PROJECT).dvi $(WWW_INSTALL)/$(PROJECT) -networktasks.texi: networktasks.t Makefile +basefs.texi: basefs.t Makefile $(BMENU) -p "Preface" \ -u "Top" \ - -n "Networking Driver" ${*}.t - -driver.texi: driver.t Makefile - $(BMENU) -p "Network Task Structure and Data Flow" \ - -u "Top" \ - -n "Using Networking in an RTEMS Application" ${*}.t - -networkapp.texi: networkapp.t Makefile - $(BMENU) -p "Write the Driver Statistic-Printing Function" \ - -u "Top" \ - -n "Testing the Driver" ${*}.t - -testing.texi: testing.t Makefile - $(BMENU) -p "Socket Options" \ - -u "Top" \ - -n "Network Servers" ${*}.t - -servers.texi: servers.t Makefile - $(BMENU) -p "Throughput" \ - -u "Top" \ - -n "DEC 21140 Driver" ${*}.t - -decdriver.texi: decdriver.t Makefile - $(BMENU) -p "Using Hooks" \ - -u "Top" \ - -n "Command and Variable Index" ${*}.t + -n "" ${*}.t html: dirs $(FILES) -mkdir -p $(WWW_INSTALL)/$(PROJECT) - rm -f $(WWW_INSTALL)/$(PROJECT)/networkflow.jpg - rm -f $(WWW_INSTALL)/$(PROJECT)/networkflow.png - rm -f $(WWW_INSTALL)/$(PROJECT)/PCIreg.jpg - cp recvbd.jpg $(WWW_INSTALL)/$(PROJECT)/recvbd.jpg - cp networkflow.jpg $(WWW_INSTALL)/$(PROJECT)/networkflow.jpg - cp networkflow.png $(WWW_INSTALL)/$(PROJECT)/networkflow.png - cp PCIreg.jpg $(WWW_INSTALL)/$(PROJECT)/PCIreg.jpg + # rm -f $(WWW_INSTALL)/$(PROJECT)/networkflow.jpg + # rm -f $(WWW_INSTALL)/$(PROJECT)/networkflow.png + # rm -f $(WWW_INSTALL)/$(PROJECT)/PCIreg.jpg + # cp recvbd.jpg $(WWW_INSTALL)/$(PROJECT)/recvbd.jpg + # cp networkflow.jpg $(WWW_INSTALL)/$(PROJECT)/networkflow.jpg + # cp networkflow.png $(WWW_INSTALL)/$(PROJECT)/networkflow.png + # cp PCIreg.jpg $(WWW_INSTALL)/$(PROJECT)/PCIreg.jpg $(TEXI2WWW) $(TEXI2WWW_ARGS) -dir $(WWW_INSTALL)/$(PROJECT) \ $(PROJECT).texi @@ -103,6 +78,6 @@ clean: rm -f *.fixed _* convert: - /usr/bin/gs -dMaxBitmap=300000000 -g5500x7500 -sDEVICE=pdfwrite -q -dNOPAUSE -dSAFER -sOutputFile=networkflow.pdf -- networkflow.eps -c -quit - /usr/bin/gs -dMaxBitmap=300000000 -g4500x5500 -sDEVICE=pdfwrite -q -dNOPAUSE -dSAFER -sOutputFile=PCIreg.pdf -- PCIreg.eps -c -quit - /usr/bin/gs -dMaxBitmap=300000000 -g4500x5500 -sDEVICE=pdfwrite -q -dNOPAUSE -dSAFER -sOutputFile=recvbd.pdf -- recvbd.eps -c -quit +# /usr/bin/gs -dMaxBitmap=300000000 -g5500x7500 -sDEVICE=pdfwrite -q -dNOPAUSE -dSAFER -sOutputFile=networkflow.pdf -- networkflow.eps -c -quit +# /usr/bin/gs -dMaxBitmap=300000000 -g4500x5500 -sDEVICE=pdfwrite -q -dNOPAUSE -dSAFER -sOutputFile=PCIreg.pdf -- PCIreg.eps -c -quit +# /usr/bin/gs -dMaxBitmap=300000000 -g4500x5500 -sDEVICE=pdfwrite -q -dNOPAUSE -dSAFER -sOutputFile=recvbd.pdf -- recvbd.eps -c -quit diff --git a/doc/filesystem/basefs.t b/doc/filesystem/basefs.t new file mode 100644 index 0000000000..e8b4464fc8 --- /dev/null +++ b/doc/filesystem/basefs.t @@ -0,0 +1,309 @@ +@c +@c COPYRIGHT (c) 1988-1998. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + + +@chapter Base File System + +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. + +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 File System 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 4 +@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 5 +@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 File System Node Structure and Function + +Each regular file, device, hard link, and directory is represented by a data +structure called a @code{jnode}. The -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 -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 File System (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 File System + +@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 File System + +@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 File System + +@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 + diff --git a/doc/filesystem/filesystem.texi b/doc/filesystem/filesystem.texi index b22dd665e8..05fd99d993 100644 --- a/doc/filesystem/filesystem.texi +++ b/doc/filesystem/filesystem.texi @@ -63,6 +63,7 @@ END-INFO-DIR-ENTRY @c The alternative is to rework a sentence to avoid this problem. @include preface.texi +@include basefs.texi @ifinfo @node Top, Preface, (dir), (dir) @top filesystem @@ -71,6 +72,7 @@ This is the online version of the RTEMS Filesystem Design Guide. @menu * Preface:: +* Base File System:: * Command and Variable Index:: * Concept Index:: @end menu diff --git a/doc/filesystem/preface.texi b/doc/filesystem/preface.texi index d9b55d89a7..e8841b49a1 100644 --- a/doc/filesystem/preface.texi +++ b/doc/filesystem/preface.texi @@ -7,7 +7,7 @@ @c @ifinfo -@node Preface, , Top, Top +@node Preface, Base File System, Top, Top @end ifinfo @unnumbered Preface -- cgit v1.2.3