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