Changeset 0fa66f2a in rtems


Ignore:
Timestamp:
10/08/99 18:11:31 (23 years ago)
Author:
Joel Sherrill <joel.sherrill@…>
Branches:
4.10, 4.11, 4.8, 4.9, 5, master
Children:
9bc1e52a
Parents:
6408000
Message:

Finished initial conversion to texinfo.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/filesystem/applayering.t

    r6408000 r0fa66f2a  
    11@c
    2 
    32@c  COPYRIGHT (c) 1988-1998.
    43@c  On-Line Applications Research Corporation (OAR).
     
    1312@section General
    1413
    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).
     14The RTEMS file system framework was intended to be compliant with the
     15POSIX Files and Directories interface standard. The following file system
     16characteristics resulted in a functional switching layer (See figures 6
     17and 7).
    1818
    1919
     
    2424@enumerate
    2525
    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
     27compliant functions that allow them to interface with the files, devices
     28and directories in the file system. The interfaces to these routines do
     29not reflect the type of subordinate file system implementation in which
     30the file will be found.
     31
     32@item The file system framework developed under RTEMS allows for mounting
     33file systems of different types under the base file system.( Figure 3 )
     34
     35@item The mechanics of locating file information may be quite different
     36between file system types.
     37
     38@item The process of locating a file may require crossing file system
     39boundaries.
     40
     41@item The transitions between file systems and the processing required to
     42access information in different file systems is not visible at the level
     43of the POSIX function call.
     44
     45@item The POSIX interface standard provides file access by character
     46pathname to the file in some functions and through an integer file
     47descriptor (Figure 8) in other functions.
     48
     49@item The nature of the integer file descriptor and its associated
     50processing is operating system and file system specific.
     51
     52@item Directory and device information must be processed with some of the
     53same routines that apply to files.
     54
     55@item The form and content of directory and device information differs
     56greatly from that of a regular file.
     57
     58@item Files, directories and devices represent elements (nodes) of a tree
     59hierarchy.
     60
     61@item The rules for processing each of the node types that exist under the
     62file system are node specific but are still not reflected in the POSIX
     63interface routines.
    6064
    6165@end enumerate
     
    7882
    7983
    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
     87The list of generic system calls includes the routines open(), read(),
     88write(), close(), etc..
     89
     90The Files and Directories section of the POSIX Application Programs
     91Interface specifies a set of functions with calling arguments that are
     92used to gain access to the information in a file system. To the
     93application program, these functions allow access to information in any
     94mounted file system without explicit knowledge of the file system type or
     95the file system mount configuration. The following are functions that are
     96provided to the application:
    9197
    9298@enumerate
     
    128134@end enumerate
    129135
    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
     136The file system's type as well as the node type within the file system
     137determine the nature of the processing that must be performed for each of
     138the functions above. The RTEMS file system provides a framework that
     139allows new file systems to be developed and integrated without alteration
     140to the basic framework.
     141
     142@subsection Use of function pointers for functional redirection
     143
     144To provide the functional switching that is required, each of the POSIX
     145file and directory functions have been implemented as a shell function.
     146The shell function adheres to the POSIX interface standard. Within this
     147functional shell, file system and node type information is accessed which
     148is then used to invoke the appropriate file system and node type specific
     149routine to process the POSIX function call.
     150
     151@subsection File/Device/Directory function access via file control block - rtems_libio_t structure
     152
     153The POSIX open() function returns an integer file descriptor that is used
     154as a reference to file control block information for a specific file. The
     155file control block contains information that is used to locate node, file
     156system, mount table and functional handler information. The diagram in
     157Figure 8 depicts the relationship between and among the following
     158components.
     159
     160@enumerate
     161
     162@item File Descriptor Table
     163
     164This is an internal RTEMS structure that tracks all currently defined file
     165descriptors in the system. The index that is returned by the file open()
     166operation references a slot in this table. The slot contains a pointer to
     167the file descriptor table entry for this file. The rtems_libio_t structure
     168represents the file control block.
     169
     170@item Allocation of entry in the File Descriptor Table
     171
     172Access to the file descriptor table is controlled through a semaphore that
     173is implemented using the rtems_libio_allocate() function. This routine
     174will grab a semaphore and then scan the file control blocks to determine
     175which slot is free for use. The first free slot is marked as used and the
     176index to this slot is returned as the file descriptor for the open()
     177request. After the alterations have been made to the file control block
     178table, the semaphore is released to allow further operations on the table.
     179
     180@item Maximum number of entries in the file descriptor table is
     181configurable through the src/exec/sapi/headers/confdefs.h file. If the
     182CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS constant is defined its value
     183will represent the maximum number of file descriptors that are allowed. 
     184If CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS is not specified a default
     185value of 20 will be used as the maximum number of file descriptors
     186allowed.
     187
     188@item File control block - rtems_libio_t structure
     189
     190@example
    172191struct rtems_libio_tt @{
    173     rtems_driver_name_t            *driver;
    174     off_t                                   size;      /* size of file */
    175     off_t                                   offset;    /* current offset into file */
    176     unsigned32                            flags;
    177     rtems_filesystem_location_info_t    pathinfo;
    178     Objects_Id                            sem;
    179     unsigned32                            data0;   /* private to "driver" */
    180     void                                   data1;     / . */
    181     void                                   file_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/
    183202@};
    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
     205A file control block can exist for regular files, devices and directories.
     206The 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
     211stored 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
     214the start of the file. For a directory this is the byte offset into a
     215sequence of dirent structures.
     216
     217@item Pathinfo - This is a structure that provides a pointer to node
     218information, OPS table functions, Handler functions and the mount table
     219entry associated with this node.
     220
     221@item file_info - A pointer to node information that is used by Handler
    196222functions
    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
     225a 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
     233The rtems_filesystem_location_info_tt structure below provides sufficient
    203234information to process nodes under a mounted file system.
    204235
    205 struct rtems_filesystem_location_info_tt
    206 @{
     236@example
     237struct rtems_filesystem_location_info_tt @{
    207238    void                                         *node_access;
    208239    rtems_filesystem_file_handlers_r         *handlers;
     
    210241    rtems_filesystem_mount_table_entry_t     *mt_entry;
    211242@};
    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
     245It contains a void pointer to file system specific nodal structure,
     246pointers to the OPS table for the file system that contains the node, the
     247node type specific handlers for the node and a reference pointer to the
     248mount 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
     301BSD/newlib has provided a set of POSIX directory access routines. These
     302routines allow directories to be open and the entries under the directory
     303read. The getdents routine allows for customization of the BSD routines to
     304a particular file system implementation. Some of the original BSD routines
     305were modified, but maintain the same calling interface as the original
     306BSD/newlib routine. The following directory access routines are included
     307in 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
     321XXX Jennifer will fill this section in.
     322
     323
Note: See TracChangeset for help on using the changeset viewer.