Changeset 0fa66f2a in rtems
- Timestamp:
- 10/08/99 18:11:31 (23 years ago)
- Branches:
- 4.10, 4.11, 4.8, 4.9, 5, master
- Children:
- 9bc1e52a
- Parents:
- 6408000
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/filesystem/applayering.t
r6408000 r0fa66f2a 1 1 @c 2 3 2 @c COPYRIGHT (c) 1988-1998. 4 3 @c On-Line Applications Research Corporation (OAR). … … 13 12 @section General 14 13 15 The RTEMS file system framework was intended to be compliant with the POSIX 16 Files and Directories interface standard. The following file system characteristics 17 resulted in a functional switching layer (See figures 6 and 7). 14 The RTEMS file system framework was intended to be compliant with the 15 POSIX Files and Directories interface standard. The following file system 16 characteristics resulted in a functional switching layer (See figures 6 17 and 7). 18 18 19 19 … … 24 24 @enumerate 25 25 26 @item Application programs are presented with a standard set of POSIX compliant 27 functions that allow them to interface with the files, devices and directories in the 28 file system. The interfaces to these routines do not reflect the type of subordinate 29 file system implementation in which the file will be found. 30 31 @item The file system framework developed under RTEMS allows for mounting file 32 systems of different types under the base file system.( Figure 3 ) 33 34 @item The mechanics of locating file information may be quite different between file 35 system types. 36 37 @item The process of locating a file may require crossing file system boundaries. 38 39 @item The transitions between file systems and the processing required to access 40 information in different file systems is not visible at the level of the POSIX 41 function call. 42 43 @item The POSIX interface standard provides file access by character pathname to the 44 file in some functions and through an integer file descriptor (Figure 8) in other 45 functions. 46 47 @item The nature of the integer file descriptor and its associated processing is operating 48 system and file system specific. 49 50 @item Directory and device information must be processed with some of the same 51 routines that apply to files. 52 53 @item The form and content of directory and device information differs greatly from that 54 of a regular file. 55 56 @item Files, directories and devices represent elements (nodes) of a tree hierarchy. 57 58 @item The rules for processing each of the node types that exist under the file system are 59 node specific but are still not reflected in the POSIX interface routines. 26 @item Application programs are presented with a standard set of POSIX 27 compliant functions that allow them to interface with the files, devices 28 and directories in the file system. The interfaces to these routines do 29 not reflect the type of subordinate file system implementation in which 30 the file will be found. 31 32 @item The file system framework developed under RTEMS allows for mounting 33 file systems of different types under the base file system.( Figure 3 ) 34 35 @item The mechanics of locating file information may be quite different 36 between file system types. 37 38 @item The process of locating a file may require crossing file system 39 boundaries. 40 41 @item The transitions between file systems and the processing required to 42 access information in different file systems is not visible at the level 43 of the POSIX function call. 44 45 @item The POSIX interface standard provides file access by character 46 pathname to the file in some functions and through an integer file 47 descriptor (Figure 8) in other functions. 48 49 @item The nature of the integer file descriptor and its associated 50 processing is operating system and file system specific. 51 52 @item Directory and device information must be processed with some of the 53 same routines that apply to files. 54 55 @item The form and content of directory and device information differs 56 greatly from that of a regular file. 57 58 @item Files, directories and devices represent elements (nodes) of a tree 59 hierarchy. 60 61 @item The rules for processing each of the node types that exist under the 62 file system are node specific but are still not reflected in the POSIX 63 interface routines. 60 64 61 65 @end enumerate … … 78 82 79 83 80 81 @section Mapping of Generic System Calls to File System Specific OP Table or Handler Functions 82 83 @subsection Generic routines (open (), read (), write (), close (), . ) 84 85 The Files and Directories section of the POSIX Application Programs Interface 86 specifies a set of functions with calling arguments that are used to gain access to the 87 information in a file system. To the application program, these functions allow access 88 to information in any mounted file system without explicit knowledge of the file 89 system type or the file system mount configuration. The following are functions that 90 are provided to the application: 84 @section Mapping of Generic System Calls to File System Specific Functions 85 86 87 The list of generic system calls includes the routines open(), read(), 88 write(), close(), etc.. 89 90 The Files and Directories section of the POSIX Application Programs 91 Interface specifies a set of functions with calling arguments that are 92 used to gain access to the information in a file system. To the 93 application program, these functions allow access to information in any 94 mounted file system without explicit knowledge of the file system type or 95 the file system mount configuration. The following are functions that are 96 provided to the application: 91 97 92 98 @enumerate … … 128 134 @end enumerate 129 135 130 The file system's type as well as the node type within the file system determine the 131 nature of the processing that must be performed for each of the functions above. The 132 RTEMS file system provides a framework that allows new file systems to be 133 developed and integrated without alteration to the basic framework. 134 135 ? Use of function pointers for functional redirection 136 To provide the functional switching that is required, each of the POSIX file and 137 directory functions have been implemented as a shell function. The shell function 138 adheres to the POSIX interface standard. Within this functional shell, file system and 139 node type information is accessed which is then used to invoke the appropriate file 140 system and node type specific routine to process the POSIX function call. 141 142 ? File/Device/Directory function access via file control block - rtems_libio_t 143 structure 144 The POSIX open() function returns an integer file descriptor that is used as a 145 reference to file control block information for a specific file. The file control block 146 contains information that is used to locate node, file system, mount table and 147 functional handler information. The diagram in Figure 8 depicts the relationship 148 between and among the following components. 149 150 1. File Descriptor Table - This is an internal RTEMS structure that tracks all 151 currently defined file descriptors in the system. The index that is returned by 152 the file open() operation references a slot in this table. The slot contains a 153 pointer to the file descriptor table entry for this file. The rtems_libio_t 154 structure represents the file control block. 155 2. Allocation of entry in the File Descriptor Table - Access to the file descriptor 156 table is controlled through a semaphore that is implemented using the 157 rtems_libio_allocate() function. This routine will grab a semaphore and then 158 scan the file control blocks to determine which slot is free for use. The first 159 free slot is marked as used and the index to this slot is returned as the file 160 descriptor for the open () request. After the alterations have been made to the 161 file control block table, the semaphore is released to allow further operations 162 on the table. 163 3. Maximum number of entries in the file descriptor table is configurable 164 through the src/exec/sapi/headers/confdefs.h file. If the 165 CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS constant is 166 defined its value will represent the maximum number of file descriptors that 167 are allowed. 168 If CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS is not 169 specified a default value of 20 will be used as the maximum number of file 170 descriptors allowed. 171 4. File control block - rtems_libio_t structure 136 The file system's type as well as the node type within the file system 137 determine the nature of the processing that must be performed for each of 138 the functions above. The RTEMS file system provides a framework that 139 allows new file systems to be developed and integrated without alteration 140 to the basic framework. 141 142 @subsection Use of function pointers for functional redirection 143 144 To provide the functional switching that is required, each of the POSIX 145 file and directory functions have been implemented as a shell function. 146 The shell function adheres to the POSIX interface standard. Within this 147 functional shell, file system and node type information is accessed which 148 is then used to invoke the appropriate file system and node type specific 149 routine to process the POSIX function call. 150 151 @subsection File/Device/Directory function access via file control block - rtems_libio_t structure 152 153 The POSIX open() function returns an integer file descriptor that is used 154 as a reference to file control block information for a specific file. The 155 file control block contains information that is used to locate node, file 156 system, mount table and functional handler information. The diagram in 157 Figure 8 depicts the relationship between and among the following 158 components. 159 160 @enumerate 161 162 @item File Descriptor Table 163 164 This is an internal RTEMS structure that tracks all currently defined file 165 descriptors in the system. The index that is returned by the file open() 166 operation references a slot in this table. The slot contains a pointer to 167 the file descriptor table entry for this file. The rtems_libio_t structure 168 represents the file control block. 169 170 @item Allocation of entry in the File Descriptor Table 171 172 Access to the file descriptor table is controlled through a semaphore that 173 is implemented using the rtems_libio_allocate() function. This routine 174 will grab a semaphore and then scan the file control blocks to determine 175 which slot is free for use. The first free slot is marked as used and the 176 index to this slot is returned as the file descriptor for the open() 177 request. After the alterations have been made to the file control block 178 table, the semaphore is released to allow further operations on the table. 179 180 @item Maximum number of entries in the file descriptor table is 181 configurable through the src/exec/sapi/headers/confdefs.h file. If the 182 CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS constant is defined its value 183 will represent the maximum number of file descriptors that are allowed. 184 If CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS is not specified a default 185 value of 20 will be used as the maximum number of file descriptors 186 allowed. 187 188 @item File control block - rtems_libio_t structure 189 190 @example 172 191 struct rtems_libio_tt @{ 173 rtems_driver_name_t*driver;174 off_tsize; /* size of file */175 off_toffset; /* current offset into file */176 unsigned32flags;177 rtems_filesystem_location_info_tpathinfo;178 Objects_Idsem;179 unsigned32 data0;/* private to "driver" */180 voiddata1; / . */181 voidfile_info; /used by file handlers/182 rtems_filesystem_file_handlers_r handlers;/type specific handlers/192 rtems_driver_name_t *driver; 193 off_t size; /* size of file */ 194 off_t offset; /* current offset into file */ 195 unsigned32 flags; 196 rtems_filesystem_location_info_t pathinfo; 197 Objects_Id sem; 198 unsigned32 data0; /* private to "driver" */ 199 void data1; / . */ 200 void file_info; /used by file handlers/ 201 rtems_filesystem_file_handlers_r handlers; /type specific handlers/ 183 202 @}; 184 185 A file control block can exist for regular files, devices and directories. The 186 following fields are important for regular file and directory access: 187 ? Size - For a file this represents the number of bytes currently stored in 188 a file. For a directory this field is not filled in. 189 ? Offset - For a file this is the byte file position index relative to the start 190 of the file. For a directory this is the byte offset into a sequence of 191 dirent structures. 192 ? Pathinfo - This is a structure that provides a pointer to node 193 information, OPS table functions, Handler functions and the mount 194 table entry associated with this node. 195 ? file_info - A pointer to node information that is used by Handler 203 @end example 204 205 A file control block can exist for regular files, devices and directories. 206 The following fields are important for regular file and directory access: 207 208 @itemize @bullet 209 210 @item Size - For a file this represents the number of bytes currently 211 stored in a file. For a directory this field is not filled in. 212 213 @item Offset - For a file this is the byte file position index relative to 214 the start of the file. For a directory this is the byte offset into a 215 sequence of dirent structures. 216 217 @item Pathinfo - This is a structure that provides a pointer to node 218 information, OPS table functions, Handler functions and the mount table 219 entry associated with this node. 220 221 @item file_info - A pointer to node information that is used by Handler 196 222 functions 197 ? handlers - A pointer to a table of handler functions that operate on a 198 file, device or directory through a file descriptor index 199 200 ? File/Directory function access via rtems_filesystem_location_info_t structure 201 202 The rtems_filesystem_location_info_tt structure below provides sufficient 223 224 @item handlers - A pointer to a table of handler functions that operate on 225 a file, device or directory through a file descriptor index 226 227 @end itemize 228 229 @end enumerate 230 231 @subsection File/Directory function access via rtems_filesystem_location_info_t structure 232 233 The rtems_filesystem_location_info_tt structure below provides sufficient 203 234 information to process nodes under a mounted file system. 204 235 205 struct rtems_filesystem_location_info_tt 206 @{236 @example 237 struct rtems_filesystem_location_info_tt @{ 207 238 void *node_access; 208 239 rtems_filesystem_file_handlers_r *handlers; … … 210 241 rtems_filesystem_mount_table_entry_t *mt_entry; 211 242 @}; 212 213 It contains a void pointer to file system specific nodal structure, pointers to the 214 OPS table for the file system that contains the node, the node type specific 215 handlers for the node and a reference pointer to the mount table entry associated 216 with the file system containing the node 217 218 ? File System Functional Interface to Files and Directories 219 ? Access using relative or absolute path names to file 220 ? OP Table for File System - rtems_filesystem_operations_table 221 1. evalpath () 222 2. evalformake () 223 3. link () 224 4. unlink () 225 5. node_type () 226 6. mknod () 227 7. rmnod () 228 8. chown () 229 9. freenod () 230 10. mount () 231 11. fsmount_me () 232 12. unmount () 233 13. fsunmount_me () 234 14. utime () 235 15. eval_link () 236 16. symlink () 237 17. readlink () 238 239 ? Access using file handle 240 ? Handlers for file system node types ( regular file, directories, and devices ) - 241 rtems_filesystem_file_handlers_r 242 1. open () 243 2. close () 244 3. read () 245 4. write () 246 5. ioctl () 247 6. lseek () 248 7. fstat () 249 8. fchmod () 250 9. ftruncate () 251 10. fpathconf () 252 11. fsync () 253 12. fdatasync () 254 255 256 257 ? POSIX Directory Access Functions 258 259 BSD/newlib has provided a set of POSIX directory access routines. These routines 260 allow directories to be open and the entries under the directory read. The getdents 261 routine allows for customization of the BSD routines to a particular file system 262 implementation. Some of the original BSD routines were modified, but maintain the 263 same calling interface as the original BSD/newlib routine. 264 The following directory access routines are included in the BSD set: 265 266 ? opendir ()closedir () 267 ? readdir () 268 ? getdents () 269 ? closedir () 270 ? *** rewinddir () 271 ? scandir () (built on fstat () ) 272 ? *** seekdir () 273 ? telldir () 274 275 *** Not the original BSD stuff 276 277 278 Jennifer will fill this section in. 279 280 243 @end example 244 245 It contains a void pointer to file system specific nodal structure, 246 pointers to the OPS table for the file system that contains the node, the 247 node type specific handlers for the node and a reference pointer to the 248 mount table entry associated with the file system containing the node 249 250 @subsection File System Functional Interface to Files and Directories 251 252 @itemize @bullet 253 254 @item Access using relative or absolute path names to file 255 256 @item OP Table for File System - rtems_filesystem_operations_table 257 258 @enumerate 259 @item evalpath() 260 @item evalformake() 261 @item link() 262 @item unlink() 263 @item node_type() 264 @item mknod() 265 @item rmnod() 266 @item chown() 267 @item freenod() 268 @item mount() 269 @item fsmount_me() 270 @item unmount() 271 @item fsunmount_me() 272 @item utime() 273 @item eval_link() 274 @item symlink() 275 @item readlink() 276 @end enumerate 277 278 @item Access using file handle 279 280 @item Handlers for file system node types ( regular file, directories, and devices ) - rtems_filesystem_file_handlers_r 281 282 @enumerate 283 @item open() 284 @item close() 285 @item read() 286 @item write() 287 @item ioctl() 288 @item lseek() 289 @item fstat() 290 @item fchmod() 291 @item ftruncate() 292 @item fpathconf() 293 @item fsync() 294 @item fdatasync() 295 @end enumerate 296 297 @end itemize 298 299 @section POSIX Directory Access Functions 300 301 BSD/newlib has provided a set of POSIX directory access routines. These 302 routines allow directories to be open and the entries under the directory 303 read. The getdents routine allows for customization of the BSD routines to 304 a particular file system implementation. Some of the original BSD routines 305 were modified, but maintain the same calling interface as the original 306 BSD/newlib routine. The following directory access routines are included 307 in the BSD set: 308 309 @itemize @bullet 310 @item opendir() 311 @item closedir() 312 @item readdir() 313 @item getdents() 314 @item closedir() 315 @item rewinddir() (not BSD) 316 @item scandir() (built on fstat() ) 317 @item seekdir() (not BSD) 318 @item telldir() 319 @end itemize 320 321 XXX Jennifer will fill this section in. 322 323
Note: See TracChangeset
for help on using the changeset viewer.