[df4edf29] | 1 | @c |
---|
| 2 | @c COPYRIGHT (c) 1988-1998. |
---|
| 3 | @c On-Line Applications Research Corporation (OAR). |
---|
| 4 | @c All rights reserved. |
---|
| 5 | @c |
---|
| 6 | @c $Id$ |
---|
| 7 | @c |
---|
| 8 | |
---|
| 9 | |
---|
| 10 | @chapter Base File System |
---|
| 11 | |
---|
| 12 | RTEMS initially mounts a RAM based file system known as the base file system. |
---|
| 13 | The root directory of this file system tree serves as the logical root of the directory |
---|
| 14 | hierarchy (Figure 3). Under the root directory a `/dev' directory is created under which all |
---|
| 15 | I/O device directories and files are registered as part of the file system hierarchy. |
---|
| 16 | |
---|
| 17 | A RAM based file system draws its management resources from memory. File |
---|
| 18 | and directory nodes are simply allocated blocks of memory. Data associated with regular |
---|
| 19 | files is stored in collections of memory blocks. When the system is turned off or restarted |
---|
| 20 | all memory-based components of the file system are lost. |
---|
| 21 | |
---|
| 22 | The base file system serves as a starting point for the mounting of file systems |
---|
| 23 | that are resident on semi-permanent storage media. Examples of such media include non- |
---|
| 24 | volatile memory, flash memory and IDE hard disk drives (Figure 3). File systems of other |
---|
| 25 | types will be mounted onto mount points within the base file system or other file systems |
---|
| 26 | that are subordinate to the base file system. The framework set up under the base file |
---|
| 27 | system will allow for these new file system types and the unique data and functionality |
---|
| 28 | that is required to manage the future file systems. |
---|
| 29 | |
---|
| 30 | @section Base File System Mounting |
---|
| 31 | |
---|
| 32 | At present, the first file system to be mounted is the `In Memory File System'. It |
---|
| 33 | is mounted using a standard MOUNT() command in which the mount point is NULL. |
---|
| 34 | This flags the mount as the first file system to be registered under the operating system |
---|
| 35 | and appropriate initialization of file system management information is performed (See |
---|
| 36 | figures 4 and 5). If a different file system type is desired as the base file system, |
---|
| 37 | alterations must be made to base_fs.c. This routine handles the mount of the base file |
---|
| 38 | system. |
---|
| 39 | |
---|
| 40 | |
---|
| 41 | @example |
---|
| 42 | Figure 4 |
---|
| 43 | @end example |
---|
| 44 | |
---|
| 45 | |
---|
| 46 | Once the root of the base file system has been established and it has been |
---|
| 47 | recorded as the mount point of the base file system, devices are integrated into the base |
---|
| 48 | file system. For every device that is configured into the system (See ioman.c) a device |
---|
| 49 | registration process is performed. Device registration produces a unique dev_t handle that |
---|
| 50 | consists of a major and minor device number. In addition, the configuration information |
---|
| 51 | for each device contains a text string that represents the fully qualified pathname to that |
---|
| 52 | device's place in the base file system's hierarchy. A file system node is created for the |
---|
| 53 | device along the specified registration path. |
---|
| 54 | |
---|
| 55 | |
---|
| 56 | |
---|
| 57 | @example |
---|
| 58 | Figure 5 |
---|
| 59 | @end example |
---|
| 60 | |
---|
| 61 | |
---|
| 62 | Note: Other file systems can be mounted but they are mounted onto points (directory |
---|
| 63 | mount points) in the base file system. |
---|
| 64 | |
---|
| 65 | |
---|
| 66 | @subsection Base File System Node Structure and Function |
---|
| 67 | |
---|
| 68 | Each regular file, device, hard link, and directory is represented by a data |
---|
| 69 | structure called a @code{jnode}. The -jnode- is formally represented by the structure: |
---|
| 70 | |
---|
| 71 | @example |
---|
| 72 | struct IMFS_jnode_tt @{ |
---|
| 73 | Chain_Node Node; /* for chaining them together */ |
---|
| 74 | IMFS_jnode_t *Parent; /* Parent node */ |
---|
| 75 | char name[NAME_MAX+1]; /* "basename" */ |
---|
| 76 | mode_t st_mode; /* File mode */ |
---|
| 77 | nlink_t st_nlink; /* Link count */ |
---|
| 78 | ino_t st_ino; /* inode */ |
---|
| 79 | |
---|
| 80 | uid_t st_uid; /* User ID of owner */ |
---|
| 81 | gid_t st_gid; /* Group ID of owner */ |
---|
| 82 | |
---|
| 83 | time_t st_atime; /* Time of last access */ |
---|
| 84 | time_t st_mtime; /* Time of last modification */ |
---|
| 85 | time_t st_ctime; /* Time of last status change */ |
---|
| 86 | IMFS_jnode_types_t type; /* Type of this entry */ |
---|
| 87 | IMFS_typs_union info; |
---|
| 88 | @}; |
---|
| 89 | @end example |
---|
| 90 | |
---|
| 91 | The key elements of this structure are listed below together with a brief explanation of |
---|
| 92 | their role in the file system. |
---|
| 93 | |
---|
| 94 | @table @b |
---|
| 95 | |
---|
| 96 | @item node |
---|
| 97 | This element exists simply to allow the entire @code{jnode} structure to be |
---|
| 98 | included in a chain. |
---|
| 99 | |
---|
| 100 | @item parent |
---|
| 101 | A pointer to another @code{jnode} structure that is the logical parent of the |
---|
| 102 | node in which it appears. There are circumstances that will produce a null parent |
---|
| 103 | pointer within a @code{jnode}. This can occur when a hard link is created to a file and |
---|
| 104 | the file is then removed without removing the hard link. |
---|
| 105 | |
---|
| 106 | @item name |
---|
| 107 | The name of this node within the file system hierarchical tree. Example: |
---|
| 108 | If the fully qualified pathname to the @code{jnode} was /a/b/c, the -jnode- name field |
---|
| 109 | would contain the null terminated string "c" |
---|
| 110 | |
---|
| 111 | @item st_mode |
---|
| 112 | The standard Unix access permissions for the file or directory. |
---|
| 113 | |
---|
| 114 | @item st_nlink |
---|
| 115 | The number of hard links to this file. When a @code{jnode} is first created its |
---|
| 116 | link count is set to 1. A @code{jnode} and its associated resources cannot be deleted |
---|
| 117 | unless its link count is less than 1. |
---|
| 118 | |
---|
| 119 | @item st_ino |
---|
| 120 | A unique node identification number |
---|
| 121 | |
---|
| 122 | @item st_uid |
---|
| 123 | The user ID of the file's owner |
---|
| 124 | |
---|
| 125 | @item st_gid |
---|
| 126 | The group ID of the file's owner |
---|
| 127 | |
---|
| 128 | @item st_atime |
---|
| 129 | The time of the last access to this file |
---|
| 130 | |
---|
| 131 | @item st_mtime |
---|
| 132 | The time of the last modification of this file |
---|
| 133 | |
---|
| 134 | @item st_ctime |
---|
| 135 | The time of the last status change to the file |
---|
| 136 | |
---|
| 137 | @item type |
---|
| 138 | The indication of node type must be one of the following states: |
---|
| 139 | |
---|
| 140 | @itemize @bullet |
---|
| 141 | @item IMFS_DIRECTORY |
---|
| 142 | @item IMFS_MEMORY_FILE |
---|
| 143 | @item IMFS_HARD_LINK |
---|
| 144 | @item IMFS_SYM_LINK |
---|
| 145 | @item IMFS_DEVICE |
---|
| 146 | @end itemize |
---|
| 147 | |
---|
| 148 | |
---|
| 149 | @item info |
---|
| 150 | This contains a structure that is unique to file type(See IMFS_typs_union in |
---|
| 151 | imfs.h ) |
---|
| 152 | |
---|
| 153 | @itemize @bullet |
---|
| 154 | |
---|
| 155 | @item IMFS_DIRECTORY |
---|
| 156 | An in memory file system directory contains a |
---|
| 157 | dynamic chain structure that records all files and directories that are |
---|
| 158 | subordinate to the directory node. |
---|
| 159 | |
---|
| 160 | @item IMFS_MEMORY_FILE |
---|
| 161 | Under the in memory file system regular files hold |
---|
| 162 | data. Data is dynamically allocated to the file in 128 byte chunks of memory. |
---|
| 163 | The individual chunks of memory are tracked by arrays of pointers that record |
---|
| 164 | the address of the allocated chunk of memory. Single, double, and triple |
---|
| 165 | indirection pointers are used to record the locations of all segments of the file. |
---|
| 166 | These memory-tracking techniques are graphically depicted in figures XXX |
---|
| 167 | and XXX of appendix A. |
---|
| 168 | |
---|
| 169 | @item IMFS_HARD_LINK |
---|
| 170 | The IMFS file system supports the concept of hard |
---|
| 171 | links to other nodes in the IMFS file system. These hard links are actual |
---|
| 172 | pointers to the memory associated with other nodes in the file system. This |
---|
| 173 | type of link cannot cross-file system boundaries. |
---|
| 174 | |
---|
| 175 | @item IMFS_SYM_LINK |
---|
| 176 | The IMFS file system supports the concept of symbolic |
---|
| 177 | links to other nodes in any file system. A symbolic link consists of a pointer to |
---|
| 178 | a character string that represents the pathname to the target node. This type of |
---|
| 179 | link can cross-file system boundaries. |
---|
| 180 | |
---|
| 181 | @item IMFS_DEVICE |
---|
| 182 | All RTEMS devices now appear as files under the in |
---|
| 183 | memory file system. On system initialization, all devices are registered as |
---|
| 184 | nodes under the file system. |
---|
| 185 | |
---|
| 186 | @end itemize |
---|
| 187 | |
---|
| 188 | @end table |
---|
| 189 | |
---|
| 190 | |
---|
| 191 | @subsection Node removal constraints for the base files system |
---|
| 192 | |
---|
| 193 | @itemize @bullet |
---|
| 194 | |
---|
| 195 | @item If a node is a directory with children it cannot be removed. |
---|
| 196 | @item The root node of the base file system or the mounted file system |
---|
| 197 | cannot be removed. |
---|
| 198 | |
---|
| 199 | @item A node that is a directory that is acting as the mount point of a file |
---|
| 200 | system cannot be removed. |
---|
| 201 | |
---|
| 202 | @item Prior to node removal, decrement the node's link count by one. The |
---|
| 203 | link count must be less than one to allow for removal of the node. |
---|
| 204 | |
---|
| 205 | @end itemize |
---|
| 206 | |
---|
| 207 | @subsection Housekeeping |
---|
| 208 | |
---|
| 209 | @itemize @bullet |
---|
| 210 | |
---|
| 211 | @item If the global variable rtems_filesystem_current refers to the node that |
---|
| 212 | we are trying to remove, the node_access element of this structure |
---|
| 213 | must be set to NULL to invalidate it. |
---|
| 214 | |
---|
| 215 | @item If the node was of IMFS_MEMORY_FILE type, free the memory |
---|
| 216 | associated with the memory file before freeing the node. Use the |
---|
| 217 | IMFS_memfile_remove() function. |
---|
| 218 | |
---|
| 219 | @end itemize |
---|
| 220 | |
---|
| 221 | |
---|
| 222 | @section IMFS |
---|
| 223 | |
---|
| 224 | @subsection OPS Table Functions for the In Memory File System (IMFS) |
---|
| 225 | |
---|
| 226 | @example |
---|
| 227 | OPS Table Functions File Routine Name |
---|
| 228 | |
---|
| 229 | Evalpath Imfs_eval.c IMFS_eval_path() |
---|
| 230 | Evalformake Imfs_eval.c IMFS_evaluate_for_make() |
---|
| 231 | Link Imfs_link.c IMFS_link() |
---|
| 232 | Unlink Imfs_unlink.c IMFS_unlink() |
---|
| 233 | Node_type Imfs_ntype.c IMFS_node_type() |
---|
| 234 | Mknod Imfs_mknod.c IMFS_mknod() |
---|
| 235 | Rmnod Imfs_rmnod.c IMFS_rmnod() |
---|
| 236 | Chown Imfs_chown.c IMFS_chown() |
---|
| 237 | Freenod Imfs_free.c IMFS_freenodinfo() |
---|
| 238 | Mount Imfs_mount.c IMFS_mount() |
---|
| 239 | Fsmount_me Imfs_init.c IMFS_initialize() |
---|
| 240 | Unmount Imfs_unmount.c IMFS_unmount() |
---|
| 241 | Fsunmount_me Imfs_init.c IMFS_fsunmount() |
---|
| 242 | Utime Imfs_utime.c IMFS_utime() |
---|
| 243 | Eval_link Imfs_eval.c IMFS_evaluate_link() |
---|
| 244 | Symlink Imfs_symlink.c IMFS_symlink() |
---|
| 245 | Readlink Imfs_readlink.c IMFS_readlink() |
---|
| 246 | @end example |
---|
| 247 | |
---|
| 248 | |
---|
| 249 | |
---|
| 250 | @subsection Handler Functions for Regular Files of In Memory File System |
---|
| 251 | |
---|
| 252 | @example |
---|
| 253 | Handler Function File Routine Name |
---|
| 254 | |
---|
| 255 | Open Memfile.c Memfile_open() |
---|
| 256 | Close Memfile.c Memfile_close() |
---|
| 257 | Read Memfile.c Memfile_read() |
---|
| 258 | Write Memfile.c Memfile_write() |
---|
| 259 | Ioctl Memfile.c Memfile_ioctl() |
---|
| 260 | Lseek Memfile.c Memfile_lseek() |
---|
| 261 | Fstat Imfs_stat.c IMFS_stat() |
---|
| 262 | Fchmod Imfs_fchmod.c IMFS_fchmod() |
---|
| 263 | Ftruncate Memfile.c Memfile_ftruncate() |
---|
| 264 | Fpathconf NA NULL |
---|
| 265 | Fsync NA NULL |
---|
| 266 | Fdatasync NA NULL |
---|
| 267 | @end example |
---|
| 268 | |
---|
| 269 | |
---|
| 270 | @subsection Handler Functions for Directories of In Memory File System |
---|
| 271 | |
---|
| 272 | @example |
---|
| 273 | Handler Function File Routine Name |
---|
| 274 | |
---|
| 275 | Open imfs_directory.c Imfs_dir_open() |
---|
| 276 | Close imfs_directory.c Imfs_dir_close() |
---|
| 277 | Read imfs_directory.c Imfs_dir_read() |
---|
| 278 | Write imfs_directory.c NULL |
---|
| 279 | Ioctl imfs_directory.c NULL |
---|
| 280 | Lseek imfs_directory.c Imfs_dir_lseek() |
---|
| 281 | Fstat imfs_directory.c Imfs_dir_fstat() |
---|
| 282 | Fchmod imfs_fchmod.c IMFS_fchmod() |
---|
| 283 | Ftruncate NA NULL |
---|
| 284 | Fpathconf NA NULL |
---|
| 285 | Fsync NA NULL |
---|
| 286 | Fdatasync NA NULL |
---|
| 287 | @end example |
---|
| 288 | |
---|
| 289 | |
---|
| 290 | |
---|
| 291 | @subsection Handler Functions for Devices of In Memory File System |
---|
| 292 | |
---|
| 293 | @example |
---|
| 294 | Handler Function File Routine Name |
---|
| 295 | |
---|
| 296 | Open deviceio.c Device_open() |
---|
| 297 | Close deviceio.c Device_close() |
---|
| 298 | Read deviceio.c Device_read() |
---|
| 299 | Write deviceio.c Device_write() |
---|
| 300 | Ioctl deviceio.c Device_ioctl() |
---|
| 301 | Lseek deviceio.c Device_lseek() |
---|
| 302 | Fstat imfs_stat.c IMFS_stat() |
---|
| 303 | Fchmod imfs_fchmod.c IMFS_fchmod() |
---|
| 304 | Ftruncate NA NULL |
---|
| 305 | Fpathconf NA NULL |
---|
| 306 | Fsync NA NULL |
---|
| 307 | Fdatasync NA NULL |
---|
| 308 | @end example |
---|
| 309 | |
---|