1 | @c |
---|
2 | @c COPYRIGHT (c) 1988-2002. |
---|
3 | @c On-Line Applications Research Corporation (OAR). |
---|
4 | @c All rights reserved. |
---|
5 | @c |
---|
6 | @c $Id$ |
---|
7 | @c |
---|
8 | |
---|
9 | @chapter System Call Development Notes |
---|
10 | |
---|
11 | This set of routines represents the application's interface to files and directories |
---|
12 | under the RTEMS filesystem. All routines are compliant with POSIX standards if a |
---|
13 | specific interface has been established. The list below represents the routines that have |
---|
14 | been included as part of the application's interface. |
---|
15 | |
---|
16 | @enumerate |
---|
17 | @item access() |
---|
18 | @item chdir() |
---|
19 | @item chmod() |
---|
20 | @item chown() |
---|
21 | @item close() |
---|
22 | @item closedir() |
---|
23 | @item dup() |
---|
24 | @item dup2() |
---|
25 | @item fchmod() |
---|
26 | @item fcntl() |
---|
27 | @item fdatasync() |
---|
28 | @item fpathconf() |
---|
29 | @item fstat() |
---|
30 | @item ioctl() |
---|
31 | @item link() |
---|
32 | @item lseek() |
---|
33 | @item mkdir() |
---|
34 | @item mkfifo() |
---|
35 | @item mknod() |
---|
36 | @item mount() |
---|
37 | @item open() |
---|
38 | @item opendir() |
---|
39 | @item pathconf() |
---|
40 | @item read() |
---|
41 | @item readdir() |
---|
42 | @item unmount() |
---|
43 | @end enumerate |
---|
44 | |
---|
45 | The sections that follow provide developmental information concerning each |
---|
46 | of these functions. |
---|
47 | |
---|
48 | |
---|
49 | @c @page |
---|
50 | @section access |
---|
51 | |
---|
52 | @subheading File: |
---|
53 | |
---|
54 | access.c |
---|
55 | |
---|
56 | @subheading Processing: |
---|
57 | |
---|
58 | This routine is layered on the stat() function. It acquires the current |
---|
59 | status information for the specified file and then determines if the |
---|
60 | caller has the ability to access the file for read, write or execute |
---|
61 | according to the mode argument to this function. |
---|
62 | |
---|
63 | @subheading Development Comments: |
---|
64 | |
---|
65 | This routine is layered on top of the stat() function. As long as the |
---|
66 | st_mode element in the returned structure follow the standard UNIX |
---|
67 | conventions, this function should support other filesystems without |
---|
68 | alteration. |
---|
69 | |
---|
70 | @c @page |
---|
71 | @section chdir |
---|
72 | |
---|
73 | @subheading File: |
---|
74 | |
---|
75 | chdir.c |
---|
76 | |
---|
77 | |
---|
78 | @subheading Processing: |
---|
79 | |
---|
80 | This routine will determine if the pathname that we are attempting to make |
---|
81 | that current directory exists and is in fact a directory. If these |
---|
82 | conditions are met the global indication of the current directory |
---|
83 | (rtems_filesystem_current) is set to the rtems_filesystem_location_info_t |
---|
84 | structure that is returned by the rtems_filesystem_evaluate_path() |
---|
85 | routine. |
---|
86 | |
---|
87 | @subheading Development Comments: |
---|
88 | |
---|
89 | This routine is layered on the rtems_filesystem_evaluate_path() routine |
---|
90 | and the filesystem specific OP table function node_type(). |
---|
91 | |
---|
92 | The routine node_type() must be a routine provided for each filesystem |
---|
93 | since it must access the filesystems node information to determine which |
---|
94 | of the following types the node is: |
---|
95 | |
---|
96 | @itemize @bullet |
---|
97 | @item RTEMS_FILESYSTEM_DIRECTORY |
---|
98 | @item RTEMS_FILESYSTEM_DEVICE |
---|
99 | @item RTEMS_FILESYSTEM_HARD_LINK |
---|
100 | @item RTEMS_FILESYSTEM_MEMORY_FILE |
---|
101 | @end itemize |
---|
102 | |
---|
103 | This acknowledges that the form of the node management information can |
---|
104 | vary from one filesystem implementation to another. |
---|
105 | |
---|
106 | RTEMS has a special global structure that maintains the current directory |
---|
107 | location. This global variable is of type rtems_filesystem_location_info_t |
---|
108 | and is called rtems_filesystem_current. This structure is not always |
---|
109 | valid. In order to determine if the structure is valid, you must first |
---|
110 | test the node_access element of this structure. If the pointer is NULL, |
---|
111 | then the structure does not contain a valid indication of what the current |
---|
112 | directory is. |
---|
113 | |
---|
114 | @c @page |
---|
115 | @section chmod |
---|
116 | |
---|
117 | @subheading File: |
---|
118 | |
---|
119 | chmod.c |
---|
120 | |
---|
121 | @subheading Processing: |
---|
122 | |
---|
123 | This routine is layered on the open(), fchmod() and close() functions. As |
---|
124 | long as the standard interpretation of the mode_t value is maintained, |
---|
125 | this routine should not need modification to support other filesystems. |
---|
126 | |
---|
127 | @subheading Development Comments: |
---|
128 | |
---|
129 | The routine first determines if the selected file can be open with |
---|
130 | read/write access. This is required to allow modification of the mode |
---|
131 | associated with the selected path. |
---|
132 | |
---|
133 | The fchmod() function is used to actually change the mode of the path |
---|
134 | using the integer file descriptor returned by the open() function. |
---|
135 | |
---|
136 | After mode modification, the open file descriptor is closed. |
---|
137 | |
---|
138 | @c @page |
---|
139 | @section chown |
---|
140 | |
---|
141 | @subheading File: |
---|
142 | |
---|
143 | chown.c |
---|
144 | |
---|
145 | @subheading Processing: |
---|
146 | |
---|
147 | This routine is layered on the rtems_filesystem_evaluate_path() and the |
---|
148 | file system specific chown() routine that is specified in the OPS table |
---|
149 | for the file system. |
---|
150 | |
---|
151 | @subheading Development Comments: |
---|
152 | |
---|
153 | rtems_filesystem_evaluate_path() is used to determine if the path |
---|
154 | specified actually exists. If it does a rtems_filesystem_location_info_t |
---|
155 | structure will be obtained that allows the shell function to locate the |
---|
156 | OPS table that is to be used for this filesystem. |
---|
157 | |
---|
158 | It is possible that the chown() function that should be in the OPS table |
---|
159 | is not defined. A test for a non-NULL OPS table chown() entry is performed |
---|
160 | before the function is called. |
---|
161 | |
---|
162 | If the chown() function is defined in the indicated OPS table, the |
---|
163 | function is called with the rtems_filesystem_location_info_t structure |
---|
164 | returned from the path evaluation routine, the desired owner, and group |
---|
165 | information. |
---|
166 | |
---|
167 | @c @page |
---|
168 | @section close |
---|
169 | |
---|
170 | @subheading File: |
---|
171 | |
---|
172 | close.c |
---|
173 | |
---|
174 | @subheading Processing: |
---|
175 | |
---|
176 | This routine will allow for the closing of both network connections and |
---|
177 | file system devices. If the file descriptor is associated with a network |
---|
178 | device, the appropriate network function handler will be selected from a |
---|
179 | table of previously registered network functions (rtems_libio_handlers) |
---|
180 | and that function will be invoked. |
---|
181 | |
---|
182 | If the file descriptor refers to an entry in the filesystem, the |
---|
183 | appropriate handler will be selected using information that has been |
---|
184 | placed in the file control block for the device (rtems_libio_t structure). |
---|
185 | |
---|
186 | @subheading Development Comments: |
---|
187 | |
---|
188 | rtems_file_descriptor_type examines some of the upper bits of the file |
---|
189 | descriptor index. If it finds that the upper bits are set in the file |
---|
190 | descriptor index, the device referenced is a network device. |
---|
191 | |
---|
192 | Network device handlers are obtained from a special registration table |
---|
193 | (rtems_libio_handlers) that is set up during network initialization. The |
---|
194 | network handler invoked and the status of the network handler will be |
---|
195 | returned to the calling process. |
---|
196 | |
---|
197 | If none of the upper bits are set in the file descriptor index, the file |
---|
198 | descriptor refers to an element of the RTEMS filesystem. |
---|
199 | |
---|
200 | The following sequence will be performed for any filesystem file |
---|
201 | descriptor: |
---|
202 | |
---|
203 | @enumerate |
---|
204 | |
---|
205 | @item Use the rtems_libio_iop() function to obtain the rtems_libio_t |
---|
206 | structure for the file descriptor |
---|
207 | |
---|
208 | @item Range check the file descriptor using rtems_libio_check_fd() |
---|
209 | |
---|
210 | @item Determine if there is actually a function in the selected handler |
---|
211 | table that processes the close() operation for the filesystem and node |
---|
212 | type selected. This is generally done to avoid execution attempts on |
---|
213 | functions that have not been implemented. |
---|
214 | |
---|
215 | @item If the function has been defined it is invoked with the file control |
---|
216 | block pointer as its argument. |
---|
217 | |
---|
218 | @item The file control block that was associated with the open file |
---|
219 | descriptor is marked as free using rtems_libio_free(). |
---|
220 | |
---|
221 | @item The return code from the close handler is then passed back to the |
---|
222 | calling program. |
---|
223 | |
---|
224 | @end enumerate |
---|
225 | |
---|
226 | @c @page |
---|
227 | @section closedir |
---|
228 | |
---|
229 | @subheading File: |
---|
230 | |
---|
231 | closedir.c |
---|
232 | |
---|
233 | @subheading Processing: |
---|
234 | |
---|
235 | The code was obtained from the BSD group. This routine must clean up the |
---|
236 | memory resources that are required to track an open directory. The code is |
---|
237 | layered on the close() function and standard memory free() functions. It |
---|
238 | should not require alterations to support other filesystems. |
---|
239 | |
---|
240 | @subheading Development Comments: |
---|
241 | |
---|
242 | The routine alters the file descriptor and the index into the DIR |
---|
243 | structure to make it an invalid file descriptor. Apparently the memory |
---|
244 | that is about to be freed may still be referenced before it is |
---|
245 | reallocated. |
---|
246 | |
---|
247 | The dd_buf structure's memory is reallocated before the control structure |
---|
248 | that contains the pointer to the dd_buf region. |
---|
249 | |
---|
250 | DIR control memory is reallocated. |
---|
251 | |
---|
252 | The close() function is used to free the file descriptor index. |
---|
253 | |
---|
254 | |
---|
255 | @c @page |
---|
256 | @section dup() Unimplemented |
---|
257 | |
---|
258 | @subheading File: |
---|
259 | |
---|
260 | dup.c |
---|
261 | |
---|
262 | @subheading Processing: |
---|
263 | |
---|
264 | |
---|
265 | @subheading Development Comments: |
---|
266 | |
---|
267 | |
---|
268 | |
---|
269 | |
---|
270 | |
---|
271 | @c @page |
---|
272 | @section dup2() Unimplemented |
---|
273 | |
---|
274 | @subheading File: |
---|
275 | |
---|
276 | dup2.c |
---|
277 | |
---|
278 | @subheading Processing: |
---|
279 | |
---|
280 | |
---|
281 | @subheading Development Comments: |
---|
282 | |
---|
283 | |
---|
284 | |
---|
285 | |
---|
286 | |
---|
287 | |
---|
288 | @c @page |
---|
289 | @section fchmod |
---|
290 | |
---|
291 | @subheading File: |
---|
292 | |
---|
293 | fchmod.c |
---|
294 | |
---|
295 | @subheading Processing: |
---|
296 | |
---|
297 | This routine will alter the permissions of a node in a filesystem. It is |
---|
298 | layered on the following functions and macros: |
---|
299 | |
---|
300 | @itemize @bullet |
---|
301 | @item rtems_file_descriptor_type() |
---|
302 | |
---|
303 | @item rtems_libio_iop() |
---|
304 | |
---|
305 | @item rtems_libio_check_fd() |
---|
306 | |
---|
307 | @item rtems_libio_check_permissions() |
---|
308 | |
---|
309 | @item fchmod() function that is referenced by the handler table in the |
---|
310 | file control block associated with this file descriptor |
---|
311 | |
---|
312 | @end itemize |
---|
313 | |
---|
314 | @subheading Development Comments: |
---|
315 | |
---|
316 | The routine will test to see if the file descriptor index is associated |
---|
317 | with a network connection. If it is, an error is returned from this |
---|
318 | routine. |
---|
319 | |
---|
320 | The file descriptor index is used to obtain the associated file control |
---|
321 | block. |
---|
322 | |
---|
323 | The file descriptor value is range checked. |
---|
324 | |
---|
325 | The file control block is examined to determine if it has write |
---|
326 | permissions to allow us to alter the mode of the file. |
---|
327 | |
---|
328 | A test is made to determine if the handler table that is referenced in the |
---|
329 | file control block contains an entry for the fchmod() handler function. If |
---|
330 | it does not, an error is returned to the calling routine. |
---|
331 | |
---|
332 | If the fchmod() handler function exists, it is called with the file |
---|
333 | control block and the desired mode as parameters. |
---|
334 | |
---|
335 | @c @page |
---|
336 | @section fcntl() |
---|
337 | |
---|
338 | @subheading File: |
---|
339 | |
---|
340 | fcntl.c |
---|
341 | |
---|
342 | @subheading Processing: |
---|
343 | |
---|
344 | This routine currently only interacts with the file control block. If the |
---|
345 | structure of the file control block and the associated meanings do not |
---|
346 | change, the partial implementation of fcntl() should remain unaltered for |
---|
347 | other filesystem implementations. |
---|
348 | |
---|
349 | @subheading Development Comments: |
---|
350 | |
---|
351 | The only commands that have been implemented are the F_GETFD and F_SETFD. |
---|
352 | The commands manipulate the LIBIO_FLAGS_CLOSE_ON_EXEC bit in the |
---|
353 | @code{flags} element of the file control block associated with the file |
---|
354 | descriptor index. |
---|
355 | |
---|
356 | The current implementation of the function performs the sequence of |
---|
357 | operations below: |
---|
358 | |
---|
359 | @enumerate |
---|
360 | |
---|
361 | @item Test to see if we are trying to operate on a file descriptor |
---|
362 | associated with a network connection |
---|
363 | |
---|
364 | @item Obtain the file control block that is associated with the file |
---|
365 | descriptor index |
---|
366 | |
---|
367 | @item Perform a range check on the file descriptor index. |
---|
368 | |
---|
369 | @end enumerate |
---|
370 | |
---|
371 | |
---|
372 | |
---|
373 | @c @page |
---|
374 | @section fdatasync |
---|
375 | |
---|
376 | @subheading File: |
---|
377 | |
---|
378 | fdatasync.c |
---|
379 | |
---|
380 | @subheading Processing: |
---|
381 | |
---|
382 | This routine is a template in the in memory filesystem that will route us to the |
---|
383 | appropriate handler function to carry out the fdatasync() processing. In the in |
---|
384 | memory filesystem this function is not necessary. Its function in a disk based file |
---|
385 | system that employs a memory cache is to flush all memory based data buffers to |
---|
386 | disk. It is layered on the following functions and macros: |
---|
387 | |
---|
388 | @itemize @bullet |
---|
389 | |
---|
390 | @item rtems_file_descriptor_type() |
---|
391 | |
---|
392 | @item rtems_libio_iop() |
---|
393 | |
---|
394 | @item rtems_libio_check_fd() |
---|
395 | |
---|
396 | @item rtems_libio_check_permissions() |
---|
397 | |
---|
398 | @item fdatasync() function that is referenced by the handler table in the |
---|
399 | file control block associated with this file descriptor |
---|
400 | |
---|
401 | @end itemize |
---|
402 | |
---|
403 | @subheading Development Comments: |
---|
404 | |
---|
405 | The routine will test to see if the file descriptor index is associated |
---|
406 | with a network connection. If it is, an error is returned from this |
---|
407 | routine. |
---|
408 | |
---|
409 | The file descriptor index is used to obtain the associated file control |
---|
410 | block. |
---|
411 | |
---|
412 | The file descriptor value is range checked. |
---|
413 | |
---|
414 | The file control block is examined to determine if it has write |
---|
415 | permissions to the file. |
---|
416 | |
---|
417 | A test is made to determine if the handler table that is referenced in the |
---|
418 | file control block contains an entry for the fdatasync() handler function. |
---|
419 | If it does not an error is returned to the calling routine. |
---|
420 | |
---|
421 | If the fdatasync() handler function exists, it is called with the file |
---|
422 | control block as its parameter. |
---|
423 | |
---|
424 | @c @page |
---|
425 | @section fpathconf |
---|
426 | |
---|
427 | @subheading File: |
---|
428 | |
---|
429 | fpathconf.c |
---|
430 | |
---|
431 | @subheading Processing: |
---|
432 | |
---|
433 | This routine is layered on the following functions and macros: |
---|
434 | |
---|
435 | @itemize @bullet |
---|
436 | |
---|
437 | @item rtems_file_descriptor_type() |
---|
438 | |
---|
439 | @item rtems_libio_iop() |
---|
440 | |
---|
441 | @item rtems_libio_check_fd() |
---|
442 | |
---|
443 | @item rtems_libio_check_permissions() |
---|
444 | |
---|
445 | @end itemize |
---|
446 | |
---|
447 | When a filesystem is mounted, a set of constants is specified for the |
---|
448 | filesystem. These constants are stored with the mount table entry for the |
---|
449 | filesystem. These constants appear in the POSIX standard and are listed |
---|
450 | below. |
---|
451 | |
---|
452 | @itemize @bullet |
---|
453 | |
---|
454 | @item PCLINKMAX |
---|
455 | |
---|
456 | @item PCMAXCANON |
---|
457 | |
---|
458 | @item PCMAXINPUT |
---|
459 | |
---|
460 | @item PCNAMEMAX |
---|
461 | |
---|
462 | @item PCPATHMAX |
---|
463 | |
---|
464 | @item PCPIPEBUF |
---|
465 | |
---|
466 | @item PCCHOWNRESTRICTED |
---|
467 | |
---|
468 | @item PCNOTRUNC |
---|
469 | |
---|
470 | @item PCVDISABLE |
---|
471 | |
---|
472 | @item PCASYNCIO |
---|
473 | |
---|
474 | @item PCPRIOIO |
---|
475 | |
---|
476 | @item PCSYNCIO |
---|
477 | |
---|
478 | |
---|
479 | @end itemize |
---|
480 | |
---|
481 | This routine will find the mount table information associated the file |
---|
482 | control block for the specified file descriptor parameter. The mount table |
---|
483 | entry structure contains a set of filesystem specific constants that can |
---|
484 | be accessed by individual identifiers. |
---|
485 | |
---|
486 | @subheading Development Comments: |
---|
487 | |
---|
488 | The routine will test to see if the file descriptor index is associated |
---|
489 | with a network connection. If it is, an error is returned from this |
---|
490 | routine. |
---|
491 | |
---|
492 | The file descriptor index is used to obtain the associated file control |
---|
493 | block. |
---|
494 | |
---|
495 | The file descriptor value is range checked. |
---|
496 | |
---|
497 | The file control block is examined to determine if it has read permissions |
---|
498 | to the file. |
---|
499 | |
---|
500 | Pathinfo in the file control block is used to locate the mount table entry |
---|
501 | for the filesystem associated with the file descriptor. |
---|
502 | |
---|
503 | The mount table entry contains the pathconf_limits_and_options element. |
---|
504 | This element is a table of constants that is associated with the |
---|
505 | filesystem. |
---|
506 | |
---|
507 | The name argument is used to reference the desired constant from the |
---|
508 | pathconf_limits_and_options table. |
---|
509 | |
---|
510 | |
---|
511 | @c @page |
---|
512 | @section fstat |
---|
513 | |
---|
514 | @subheading File: |
---|
515 | |
---|
516 | fstat.c |
---|
517 | |
---|
518 | @subheading Processing: |
---|
519 | |
---|
520 | This routine will return information concerning a file or network |
---|
521 | connection. If the file descriptor is associated with a network |
---|
522 | connection, the current implementation of @code{fstat()} will return a |
---|
523 | mode set to @code{S_IFSOCK}. In a later version, this routine will map the |
---|
524 | status of a network connection to an external handler routine. |
---|
525 | |
---|
526 | If the file descriptor is associated with a node under a filesystem, the |
---|
527 | fstat() routine will map to the fstat() function taken from the node |
---|
528 | handler table. |
---|
529 | |
---|
530 | @subheading Development Comments: |
---|
531 | |
---|
532 | This routine validates that the struct stat pointer is not NULL so that |
---|
533 | the return location is valid. |
---|
534 | |
---|
535 | The struct stat is then initialized to all zeros. |
---|
536 | |
---|
537 | rtems_file_descriptor_type() is then used to determine if the file |
---|
538 | descriptor is associated with a network connection. If it is, network |
---|
539 | status processing is performed. In the current implementation, the file |
---|
540 | descriptor type processing needs to be improved. It currently just drops |
---|
541 | into the normal processing for file system nodes. |
---|
542 | |
---|
543 | If the file descriptor is associated with a node under a filesystem, the |
---|
544 | following steps are performed: |
---|
545 | |
---|
546 | @enumerate |
---|
547 | |
---|
548 | @item Obtain the file control block that is associated with the file descriptor |
---|
549 | index. |
---|
550 | |
---|
551 | @item Range check the file descriptor index. |
---|
552 | |
---|
553 | @item Test to see if there is a non-NULL function pointer in the handler |
---|
554 | table for the fstat() function. If there is, invoke the function with the |
---|
555 | file control block and the pointer to the stat structure. |
---|
556 | |
---|
557 | @end enumerate |
---|
558 | |
---|
559 | @c @page |
---|
560 | @section ioctl |
---|
561 | |
---|
562 | @subheading File: |
---|
563 | |
---|
564 | ioctl.c |
---|
565 | |
---|
566 | @subheading Processing: |
---|
567 | |
---|
568 | Not defined in the POSIX 1003.1b standard but commonly supported in most |
---|
569 | UNIX and POSIX system. Ioctl() is a catchall for I/O operations. Routine |
---|
570 | is layered on external network handlers and filesystem specific handlers. |
---|
571 | The development of new filesystems should not alter the basic processing |
---|
572 | performed by this routine. |
---|
573 | |
---|
574 | @subheading Development Comments: |
---|
575 | |
---|
576 | |
---|
577 | The file descriptor is examined to determine if it is associated with a |
---|
578 | network device. If it is processing is mapped to an external network |
---|
579 | handler. The value returned by this handler is then returned to the |
---|
580 | calling program. |
---|
581 | |
---|
582 | File descriptors that are associated with a filesystem undergo the |
---|
583 | following processing: |
---|
584 | |
---|
585 | @enumerate |
---|
586 | |
---|
587 | @item The file descriptor index is used to obtain the associated file |
---|
588 | control block. |
---|
589 | |
---|
590 | @item The file descriptor value is range checked. |
---|
591 | |
---|
592 | @item A test is made to determine if the handler table that is referenced |
---|
593 | in the file control block contains an entry for the ioctl() handler |
---|
594 | function. If it does not, an error is returned to the calling routine. |
---|
595 | |
---|
596 | @item If the ioctl() handler function exists, it is called with the file |
---|
597 | control block, the command and buffer as its parameters. |
---|
598 | |
---|
599 | @item The return code from this function is then sent to the calling |
---|
600 | routine. |
---|
601 | |
---|
602 | @end enumerate |
---|
603 | |
---|
604 | |
---|
605 | @c @page |
---|
606 | @section link |
---|
607 | |
---|
608 | @subheading File: |
---|
609 | |
---|
610 | link.c |
---|
611 | |
---|
612 | @subheading Processing: |
---|
613 | |
---|
614 | This routine will establish a hard link to a file, directory or a device. |
---|
615 | The target of the hard link must be in the same filesystem as the new link |
---|
616 | being created. A link to an existing link is also permitted but the |
---|
617 | existing link is evaluated before the new link is made. This implies that |
---|
618 | links to links are reduced to links to files, directories or devices |
---|
619 | before they are made. |
---|
620 | |
---|
621 | @subheading Development Comments: |
---|
622 | |
---|
623 | Calling parameters: |
---|
624 | const char *existing |
---|
625 | const char *new |
---|
626 | |
---|
627 | link() will determine if the target of the link actually exists using |
---|
628 | rtems_filesystem_evaluate_path() |
---|
629 | |
---|
630 | rtems_filesystem_get_start_loc() is used to determine where to start the |
---|
631 | path evaluation of the new name. This macro examines the first characters |
---|
632 | of the name to see if the name of the new link starts with a |
---|
633 | rtems_filesystem_is_separator. If it does the search starts from the root |
---|
634 | of the RTEMS filesystem; otherwise the search will start from the current |
---|
635 | directory. |
---|
636 | |
---|
637 | The OPS table evalformake() function for the parent's filesystem is used |
---|
638 | to locate the node that will be the parent of the new link. It will also |
---|
639 | locate the start of the new path's name. This name will be used to define |
---|
640 | a child under the parent directory. |
---|
641 | |
---|
642 | If the parent is found, the routine will determine if the hard link that |
---|
643 | we are trying to create will cross a filesystem boundary. This is not |
---|
644 | permitted for hard-links. |
---|
645 | |
---|
646 | If the hard-link does not cross a filesystem boundary, a check is |
---|
647 | performed to determine if the OPS table contains an entry for the link() |
---|
648 | function. |
---|
649 | |
---|
650 | If a link() function is defined, the OPS table link() function will be |
---|
651 | called to establish the actual link within the filesystem. |
---|
652 | |
---|
653 | The return code from the OPS table link() function is returned to the |
---|
654 | calling program. |
---|
655 | |
---|
656 | @c @page |
---|
657 | @section lseek |
---|
658 | |
---|
659 | @subheading File: |
---|
660 | |
---|
661 | lseek.c |
---|
662 | |
---|
663 | @subheading Processing: |
---|
664 | |
---|
665 | This routine is layered on both external handlers and filesystem / node |
---|
666 | type specific handlers. This routine should allow for the support of new |
---|
667 | filesystems without modification. |
---|
668 | |
---|
669 | @subheading Development Comments: |
---|
670 | |
---|
671 | This routine will determine if the file descriptor is associated with a |
---|
672 | network device. If it is lseek will map to an external network handler. |
---|
673 | The handler will be called with the file descriptor, offset and whence as |
---|
674 | its calling parameters. The return code from the external handler will be |
---|
675 | returned to the calling routine. |
---|
676 | |
---|
677 | If the file descriptor is not associated with a network connection, it is |
---|
678 | associated with a node in a filesystem. The following steps will be |
---|
679 | performed for filesystem nodes: |
---|
680 | |
---|
681 | @enumerate |
---|
682 | |
---|
683 | @item The file descriptor is used to obtain the file control block for the |
---|
684 | node. |
---|
685 | |
---|
686 | @item The file descriptor is range checked. |
---|
687 | |
---|
688 | @item The offset element of the file control block is altered as indicated |
---|
689 | by the offset and whence calling parameters |
---|
690 | |
---|
691 | @item The handler table in the file control block is examined to determine |
---|
692 | if it contains an entry for the lseek() function. If it does not an error |
---|
693 | is returned to the calling program. |
---|
694 | |
---|
695 | @item The lseek() function from the designated handler table is called |
---|
696 | with the file control block, offset and whence as calling arguments |
---|
697 | |
---|
698 | @item The return code from the lseek() handler function is returned to the |
---|
699 | calling program |
---|
700 | |
---|
701 | @end enumerate |
---|
702 | |
---|
703 | |
---|
704 | @c @page |
---|
705 | @section mkdir |
---|
706 | |
---|
707 | @subheading File: |
---|
708 | |
---|
709 | mkdir.c |
---|
710 | |
---|
711 | @subheading Processing: |
---|
712 | |
---|
713 | This routine attempts to create a directory node under the filesystem. The |
---|
714 | routine is layered the mknod() function. |
---|
715 | |
---|
716 | @subheading Development Comments: |
---|
717 | |
---|
718 | See mknod() for developmental comments. |
---|
719 | |
---|
720 | @c @page |
---|
721 | @section mkfifo |
---|
722 | |
---|
723 | @subheading File: |
---|
724 | |
---|
725 | mkfifo.c |
---|
726 | |
---|
727 | @subheading Processing: |
---|
728 | |
---|
729 | This routine attempts to create a FIFO node under the filesystem. The |
---|
730 | routine is layered the mknod() function. |
---|
731 | |
---|
732 | @subheading Development Comments: |
---|
733 | |
---|
734 | See mknod() for developmental comments |
---|
735 | |
---|
736 | @c @page |
---|
737 | @section mknod |
---|
738 | |
---|
739 | @subheading File: |
---|
740 | |
---|
741 | mknod.c |
---|
742 | |
---|
743 | @subheading Processing: |
---|
744 | |
---|
745 | This function will allow for the creation of the following types of nodes |
---|
746 | under the filesystem: |
---|
747 | |
---|
748 | @itemize @bullet |
---|
749 | |
---|
750 | @item directories |
---|
751 | |
---|
752 | @item regular files |
---|
753 | |
---|
754 | @item character devices |
---|
755 | |
---|
756 | @item block devices |
---|
757 | |
---|
758 | @item fifos |
---|
759 | |
---|
760 | @end itemize |
---|
761 | |
---|
762 | At the present time, an attempt to create a FIFO will result in an ENOTSUP |
---|
763 | error to the calling function. This routine is layered the filesystem |
---|
764 | specific routines evalformake and mknod. The introduction of a new |
---|
765 | filesystem must include its own evalformake and mknod function to support |
---|
766 | the generic mknod() function. Under this condition the generic mknod() |
---|
767 | function should accommodate other filesystem types without alteration. |
---|
768 | |
---|
769 | @subheading Development Comments: |
---|
770 | |
---|
771 | Test for nodal types - I thought that this test should look like the |
---|
772 | following code: |
---|
773 | |
---|
774 | @example |
---|
775 | if ( (mode & S_IFDIR) = = S_IFDIR) || |
---|
776 | (mode & S_IFREG) = = S_IFREG) || |
---|
777 | (mode & S_IFCHR) = = S_IFCHR) || |
---|
778 | (mode & S_IFBLK) = = S_IFBLK) || |
---|
779 | (mode & S_IFIFO) = = S_IFIFO)) |
---|
780 | Set_errno_and_return_minus_one (EINVAL); |
---|
781 | |
---|
782 | @end example |
---|
783 | |
---|
784 | Where: |
---|
785 | |
---|
786 | @itemize @bullet |
---|
787 | @item S_IFREG (0100000) - Creation of a regular file |
---|
788 | @item S_IFCHR (0020000) - Creation of a character device |
---|
789 | @item S_IFBLK (0060000) - Creation of a block device |
---|
790 | @item S_IFIFO (0010000) - Creation of a FIFO |
---|
791 | @end itemize |
---|
792 | |
---|
793 | Determine if the pathname that we are trying to create starts at the root |
---|
794 | directory or is relative to the current directory using the |
---|
795 | rtems_filesystem_get_start_loc() function. |
---|
796 | |
---|
797 | Determine if the pathname leads to a valid directory that can be accessed |
---|
798 | for the creation of a node. |
---|
799 | |
---|
800 | If the pathname is a valid location to create a node, verify that a |
---|
801 | filesystem specific mknod() function exists. |
---|
802 | |
---|
803 | If the mknod() function exists, call the filesystem specific mknod() |
---|
804 | function. Pass the name, mode, device type and the location information |
---|
805 | associated with the directory under which the node will be created. |
---|
806 | |
---|
807 | @c @page |
---|
808 | @section mount |
---|
809 | |
---|
810 | @subheading File: |
---|
811 | |
---|
812 | mount.c |
---|
813 | |
---|
814 | |
---|
815 | Arguments (Not a standard POSIX call): |
---|
816 | |
---|
817 | rtems_filesystem_mount_table_entry_t **mt_entry, |
---|
818 | |
---|
819 | If the mount operation is successful, this pointer to a pointer will be |
---|
820 | set to reference the mount table chain entry that has been allocated for |
---|
821 | this file system mount. |
---|
822 | |
---|
823 | rtems_filesystem_operations_table *fs_ops, |
---|
824 | |
---|
825 | This is a pointer to a table of functions that are associated with the |
---|
826 | file system that we are about to mount. This is the mechanism to selected |
---|
827 | file system type without keeping a dynamic database of all possible file |
---|
828 | system types that are valid for the mount operation. Using this method, it |
---|
829 | is only necessary to configure the filesystems that we wish to use into |
---|
830 | the RTEMS build. Unused filesystems types will not be drawn into the |
---|
831 | build. |
---|
832 | |
---|
833 | char *fsoptions, |
---|
834 | |
---|
835 | This argument points to a string that selects mounting for read only |
---|
836 | access or read/write access. Valid states are "RO" and "RW" |
---|
837 | |
---|
838 | char *device, |
---|
839 | |
---|
840 | This argument is reserved for the name of a device that will be used to |
---|
841 | access the filesystem information. Current filesystem implementations are |
---|
842 | memory based and do not require a device to access filesystem information. |
---|
843 | |
---|
844 | char *mount_point |
---|
845 | |
---|
846 | This is a pathname to a directory in a currently mounted filesystem that |
---|
847 | allows read, write and execute permissions. If successful, the node found |
---|
848 | by evaluating this name, is stored in the mt_entry. |
---|
849 | |
---|
850 | @subheading Processing: |
---|
851 | |
---|
852 | This routine will handle the mounting of a filesystem on a mount point. If |
---|
853 | the operation is successful, a pointer to the mount table chain entry |
---|
854 | associated with the mounted filesystem will be returned to the calling |
---|
855 | function. The specifics about the processing required at the mount point |
---|
856 | and within the filesystem being mounted is isolated in the filesystem |
---|
857 | specific mount() and fsmount_me() functions. This allows the generic |
---|
858 | mount() function to remain unaltered even if new filesystem types are |
---|
859 | introduced. |
---|
860 | |
---|
861 | |
---|
862 | |
---|
863 | @subheading Development Comments: |
---|
864 | |
---|
865 | This routine will use get_file_system_options() to determine if the mount |
---|
866 | options are valid ("RO" or "RW"). |
---|
867 | |
---|
868 | It confirms that a filesystem ops-table has been selected. |
---|
869 | |
---|
870 | Space is allocated for a mount table entry and selective elements of the |
---|
871 | temporary mount table entry are initialized. |
---|
872 | |
---|
873 | If a mount point is specified: The mount point is examined to determine |
---|
874 | that it is a directory and also has the appropriate permissions to allow a |
---|
875 | filesystem to be mounted. |
---|
876 | |
---|
877 | The current mount table chain is searched to determine that there is not |
---|
878 | another filesystem mounted at the mount point we are trying to mount onto. |
---|
879 | |
---|
880 | If a mount function is defined in the ops table for the filesystem |
---|
881 | containing the mount point, it is called at this time. |
---|
882 | |
---|
883 | If no mount point is specified: Processing if performed to set up the |
---|
884 | mount table chain entry as the base filesystem. |
---|
885 | |
---|
886 | If the fsmount_me() function is specified for ops-table of the filesystem |
---|
887 | being mounted, that function is called to initialize for the new |
---|
888 | filesystem. |
---|
889 | |
---|
890 | On successful completion, the temporary mount table entry will be placed |
---|
891 | on the mount table chain to record the presence of the mounted filesystem. |
---|
892 | |
---|
893 | @c @page |
---|
894 | @section open |
---|
895 | |
---|
896 | @subheading File: |
---|
897 | |
---|
898 | open.c |
---|
899 | |
---|
900 | @subheading Processing: |
---|
901 | |
---|
902 | This routine is layered on both RTEMS calls and filesystem specific |
---|
903 | implementations of the open() function. These functional interfaces should |
---|
904 | not change for new filesystems and therefore this code should be stable as |
---|
905 | new file systems are introduced. |
---|
906 | |
---|
907 | @subheading Development Comments: |
---|
908 | |
---|
909 | This routine will allocate a file control block for the file or device |
---|
910 | that we are about to open. |
---|
911 | |
---|
912 | It will then test to see if the pathname exists. If it does a |
---|
913 | rtems_filesystem_location_info_t data structure will be filled out. This |
---|
914 | structure contains information that associates node information, |
---|
915 | filesystem specific functions and mount table chain information with the |
---|
916 | pathname. |
---|
917 | |
---|
918 | If the create option has been it will attempt to create a node for a |
---|
919 | regular file along the specified path. If a file already exists along this |
---|
920 | path, an error will be generated; otherwise, a node will be allocated for |
---|
921 | the file under the filesystem that contains the pathname. When a new node |
---|
922 | is created, it is also evaluated so that an appropriate |
---|
923 | rtems_filesystem_location_info_t data structure can be filled out for the |
---|
924 | newly created node. |
---|
925 | |
---|
926 | If the file exists or the new file was created successfully, the file |
---|
927 | control block structure will be initialized with handler table |
---|
928 | information, node information and the rtems_filesystem_location_info_t |
---|
929 | data structure that describes the node and filesystem data in detail. |
---|
930 | |
---|
931 | If an open() function exists in the filesystem specific handlers table for |
---|
932 | the node that we are trying to open, it will be called at this time. |
---|
933 | |
---|
934 | If any error is detected in the process, cleanup is performed. It consists |
---|
935 | of freeing the file control block structure that was allocated at the |
---|
936 | beginning of the generic open() routine. |
---|
937 | |
---|
938 | On a successful open(), the index into the file descriptor table will be |
---|
939 | calculated and returned to the calling routine. |
---|
940 | |
---|
941 | @c @page |
---|
942 | @section opendir |
---|
943 | |
---|
944 | @subheading File: |
---|
945 | |
---|
946 | opendir.c |
---|
947 | |
---|
948 | @subheading Processing: |
---|
949 | |
---|
950 | This routine will attempt to open a directory for read access. It will |
---|
951 | setup a DIR control structure that will be used to access directory |
---|
952 | information. This routine is layered on the generic open() routine and |
---|
953 | filesystem specific directory processing routines. |
---|
954 | |
---|
955 | @subheading Development Comments: |
---|
956 | |
---|
957 | The BSD group provided this routine. |
---|
958 | |
---|
959 | @c @page |
---|
960 | @section pathconf |
---|
961 | |
---|
962 | @subheading File: |
---|
963 | |
---|
964 | pathconf.c |
---|
965 | |
---|
966 | @subheading Processing: |
---|
967 | |
---|
968 | This routine will obtain the value of one of the path configuration |
---|
969 | parameters and return it to the calling routine. It is layered on the |
---|
970 | generic open() and fpathconf() functions. These interfaces should not |
---|
971 | change with the addition of new filesystem types. |
---|
972 | |
---|
973 | @subheading Development Comments: |
---|
974 | |
---|
975 | This routine will try to open the file indicated by path. |
---|
976 | |
---|
977 | If successful, the file descriptor will be used to access the pathconf |
---|
978 | value specified by @code{name} using the fpathconf() function. |
---|
979 | |
---|
980 | The file that was accessed is then closed. |
---|
981 | |
---|
982 | @c @page |
---|
983 | @section read |
---|
984 | |
---|
985 | @subheading File: |
---|
986 | |
---|
987 | deviceio.c |
---|
988 | |
---|
989 | @subheading Processing: |
---|
990 | |
---|
991 | This routine is layered on a set of RTEMS calls and filesystem specific |
---|
992 | read operations. The functions are layered in such a way as to isolate |
---|
993 | them from change as new filesystems are introduced. |
---|
994 | |
---|
995 | @subheading Development Comments: |
---|
996 | |
---|
997 | This routine will examine the type of file descriptor it is sent. |
---|
998 | |
---|
999 | If the file descriptor is associated with a network device, the read |
---|
1000 | function will be mapped to a special network handler. The return code from |
---|
1001 | the network handler will then be sent as the return code from generic |
---|
1002 | read() function. |
---|
1003 | |
---|
1004 | For file descriptors that are associated with the filesystem the following |
---|
1005 | sequence will be performed: |
---|
1006 | |
---|
1007 | @enumerate |
---|
1008 | |
---|
1009 | @item Obtain the file control block associated with the file descriptor |
---|
1010 | |
---|
1011 | @item Range check the file descriptor |
---|
1012 | |
---|
1013 | @item Determine that the buffer pointer is not invalid |
---|
1014 | |
---|
1015 | @item Check that the count is not zero |
---|
1016 | |
---|
1017 | @item Check the file control block to see if we have permissions to read |
---|
1018 | |
---|
1019 | @item If there is a read function in the handler table, invoke the handler |
---|
1020 | table read() function |
---|
1021 | |
---|
1022 | @item Use the return code from the handler table read function(number of |
---|
1023 | bytes read) to increment the offset element of the file control block |
---|
1024 | |
---|
1025 | @item Return the number of bytes read to the calling program |
---|
1026 | |
---|
1027 | @end enumerate |
---|
1028 | |
---|
1029 | @c @page |
---|
1030 | @section readdir |
---|
1031 | |
---|
1032 | @subheading File: |
---|
1033 | |
---|
1034 | readdir.c |
---|
1035 | |
---|
1036 | @subheading Processing: |
---|
1037 | |
---|
1038 | This routine was acquired from the BSD group. It has not been altered from |
---|
1039 | its original form. |
---|
1040 | |
---|
1041 | @subheading Development Comments: |
---|
1042 | |
---|
1043 | The routine calls a customized getdents() function that is provided by the |
---|
1044 | user. This routine provides the filesystem specific aspects of reading a |
---|
1045 | directory. |
---|
1046 | |
---|
1047 | It is layered on the read() function in the directory handler table. This |
---|
1048 | function has been mapped to the Imfs_dir_read() function. |
---|
1049 | |
---|
1050 | @c @page |
---|
1051 | @section unmount |
---|
1052 | |
---|
1053 | @subheading File: |
---|
1054 | |
---|
1055 | unmount.c |
---|
1056 | |
---|
1057 | @subheading Processing: |
---|
1058 | |
---|
1059 | This routine will attempt to dismount a mounted filesystem and then free |
---|
1060 | all resources that were allocated for the management of that filesystem. |
---|
1061 | |
---|
1062 | @subheading Development Comments: |
---|
1063 | |
---|
1064 | @itemize @bullet |
---|
1065 | |
---|
1066 | @item This routine will determine if there are any filesystems currently |
---|
1067 | mounted under the filesystem that we are trying to dismount. This would |
---|
1068 | prevent the dismount of the filesystem. |
---|
1069 | |
---|
1070 | @item It will test to see if the current directory is in the filesystem |
---|
1071 | that we are attempting to dismount. This would prevent the dismount of the |
---|
1072 | filesystem. |
---|
1073 | |
---|
1074 | @item It will scan all the currently open file descriptors to determine is |
---|
1075 | there is an open file descriptor to a file in the filesystem that we are |
---|
1076 | attempting to unmount(). |
---|
1077 | |
---|
1078 | @end itemize |
---|
1079 | |
---|
1080 | If the above preconditions are met then the following sequence is |
---|
1081 | performed: |
---|
1082 | |
---|
1083 | @enumerate |
---|
1084 | |
---|
1085 | @item Call the filesystem specific unmount() function for the filesystem |
---|
1086 | that contains the mount point. This routine should indicate that the mount |
---|
1087 | point no longer has a filesystem mounted below it. |
---|
1088 | |
---|
1089 | @item Call the filesystem specific fsunmount_me() function for the mounted |
---|
1090 | filesystem that we are trying to unmount(). This routine should clean up |
---|
1091 | any resources that are no longer needed for the management of the file |
---|
1092 | system being un-mounted. |
---|
1093 | |
---|
1094 | @item Extract the mount table entry for the filesystem that was just |
---|
1095 | dismounted from the mount table chain. |
---|
1096 | |
---|
1097 | @item Free the memory associated with the extracted mount table entry. |
---|
1098 | |
---|
1099 | @end enumerate |
---|
1100 | |
---|
1101 | @c @page |
---|
1102 | @section eval |
---|
1103 | |
---|
1104 | @subheading File: |
---|
1105 | |
---|
1106 | XXX |
---|
1107 | |
---|
1108 | @subheading Processing: |
---|
1109 | |
---|
1110 | XXX |
---|
1111 | |
---|
1112 | @subheading Development Comments: |
---|
1113 | |
---|
1114 | XXX |
---|
1115 | |
---|
1116 | @c @page |
---|
1117 | @section getdentsc |
---|
1118 | |
---|
1119 | @subheading File: |
---|
1120 | |
---|
1121 | XXX |
---|
1122 | |
---|
1123 | @subheading Processing: |
---|
1124 | |
---|
1125 | XXX |
---|
1126 | |
---|
1127 | @subheading Development Comments: |
---|
1128 | |
---|
1129 | XXX |
---|
1130 | |
---|