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