From 37fb1c8160fb2ef358d2bdb6232ff2556d6d2f9f Mon Sep 17 00:00:00 2001 From: Joel Sherrill Date: Mon, 11 Oct 1999 14:53:30 +0000 Subject: Cleanup. --- doc/filesystem/applayering.t | 22 ++++- doc/filesystem/basefs.t | 209 +++++++++++++++++++++++-------------------- doc/filesystem/imfs.t | 14 +-- doc/filesystem/init.t | 4 +- 4 files changed, 140 insertions(+), 109 deletions(-) diff --git a/doc/filesystem/applayering.t b/doc/filesystem/applayering.t index 324406d236..2a971e2595 100644 --- a/doc/filesystem/applayering.t +++ b/doc/filesystem/applayering.t @@ -18,9 +18,24 @@ and 7). @example -Figure 6 +Figure of the File System Functional Layering goes here. +This figure includes networking and disk caching layering. @end example +@ifset use-ascii +@example +@group +@end group +@end example +@end ifset + +@ifset use-tex +@c @image{FunctionalLayerCake,6in,4in} +@end ifset + +@ifset use-html +@end ifset + @enumerate @item Application programs are presented with a standard set of POSIX @@ -66,7 +81,8 @@ interface routines. @example -Figure 7 +Figure of the File System Functional Layering goes here. +This figure focuses on the Base File System and IMFS. @end example @@ -74,7 +90,7 @@ Figure 7 @example -Figure 8 +Figure of the IMFS Memfile control blocks @end example diff --git a/doc/filesystem/basefs.t b/doc/filesystem/basefs.t index e8b4464fc8..e670347c0c 100644 --- a/doc/filesystem/basefs.t +++ b/doc/filesystem/basefs.t @@ -9,112 +9,121 @@ @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. +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 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 +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 +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. - +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 +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. +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: +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; + 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. +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 +@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 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" +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. +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 @@ -147,41 +156,45 @@ The indication of node type must be one of the following states: @item info -This contains a structure that is unique to file type(See IMFS_typs_union in -imfs.h ) +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. + +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. + +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. + +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. + +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. + +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 @@ -193,6 +206,7 @@ nodes under the file 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. @@ -208,13 +222,13 @@ link count must be less than one to allow for removal of the node. @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 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. +@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 @@ -224,6 +238,7 @@ IMFS_memfile_remove() function. @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() diff --git a/doc/filesystem/imfs.t b/doc/filesystem/imfs.t index 0127261d5d..d0882f93ce 100644 --- a/doc/filesystem/imfs.t +++ b/doc/filesystem/imfs.t @@ -243,12 +243,12 @@ This routine will examine the mode argument to determine is we are trying to create a directory, regular file and a device node. The creation of other node types is not permitted and will cause an assert. -Memory space will be allocated for a -jnode- and the node will be set up +Memory space will be allocated for a @code{jnode} and the node will be set up according to the nodal type that was specified. The IMFS_create_node() function performs the allocation and setup of the node. The only problem that is currently reported is the lack of memory when we -attempt to allocate space for the -jnode- (ENOMEN). +attempt to allocate space for the @code{jnode} (ENOMEN). @c @@ -731,16 +731,16 @@ memfile.c @subheading Development Comments: -This routine will determine the -jnode- that is associated with this file. +This routine will determine the @code{jnode} that is associated with this file. -It will then call IMFS_memfile_read() with the -jnode-, file position index, +It will then call IMFS_memfile_read() with the @code{jnode}, file position index, buffer and transfer count as arguments. IMFS_memfile_read() will do the following: @itemize @bullet -@item Verify that the -jnode- is associated with a memory file +@item Verify that the @code{jnode} is associated with a memory file @item Verify that the destination of the read is valid @@ -1093,7 +1093,7 @@ imfs_directory.c @subheading Development Comments: -This routine will look into the file control block to find the -jnode- that +This routine will look into the file control block to find the @code{jnode} that is associated with the directory. The routine will verify that the node is a directory. If its not a directory @@ -1482,7 +1482,7 @@ deviceio.c This routine will use the file control block to locate the node structure for the device. -It will extract the major and minor device numbers from the -jnode-. +It will extract the major and minor device numbers from the @code{jnode}. The major and minor device numbers will be used to make a rtems_io_open() function call to open the device driver. An argument list is sent to the diff --git a/doc/filesystem/init.t b/doc/filesystem/init.t index 68d58ff783..0a36258b73 100644 --- a/doc/filesystem/init.t +++ b/doc/filesystem/init.t @@ -18,10 +18,10 @@ of the following: @item Initialization of mount table chain control structure -@item Allocation of a -jnode- structure that will server as the root node +@item Allocation of a @code{jnode} structure that will server as the root node of the `In Memory File System' -@item Initialization of the allocated -jnode- with the appropriate OPS, +@item Initialization of the allocated @code{jnode} with the appropriate OPS, directory handlers and pathconf limits and options. @item Allocation of a memory region for file system specific global -- cgit v1.2.3