source: rtems/doc/filesystem/basefs.t @ ffce9b39

4.104.114.84.95
Last change on this file since ffce9b39 was ffce9b39, checked in by Joel Sherrill <joel.sherrill@…>, on Oct 11, 1999 at 8:10:03 PM

More cleanup.

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