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