1 |
1026 |
ivang |
@c
|
2 |
|
|
@c COPYRIGHT (c) 1988-2002.
|
3 |
|
|
@c On-Line Applications Research Corporation (OAR).
|
4 |
|
|
@c All rights reserved.
|
5 |
|
|
@c
|
6 |
|
|
@c patheval.t,v 1.7 2002/01/17 21:47:45 joel Exp
|
7 |
|
|
@c
|
8 |
|
|
|
9 |
|
|
@chapter Pathname Evaluation
|
10 |
|
|
|
11 |
|
|
This chapter describes the pathname evaluation process for the
|
12 |
|
|
RTEMS Filesystem Infrastructure.
|
13 |
|
|
|
14 |
|
|
@example
|
15 |
|
|
XXX Include graphic of the path evaluation process
|
16 |
|
|
@end example
|
17 |
|
|
|
18 |
|
|
@section Pathname Evaluation Handlers
|
19 |
|
|
|
20 |
|
|
There are two pathname evaluation routines. The handler patheval()
|
21 |
|
|
is called to find, verify privlages on and return information on a node
|
22 |
|
|
that exists. The handler evalformake() is called to find, verify
|
23 |
|
|
permissions, and return information on a node that is to become a parent.
|
24 |
|
|
Additionally, evalformake() returns a pointer to the start of the name of
|
25 |
|
|
the new node to be created.
|
26 |
|
|
|
27 |
|
|
Pathname evaluation is specific to a filesystem.
|
28 |
|
|
Each filesystem is required to provide both a patheval() and an evalformake()
|
29 |
|
|
routine. Both of these routines gets a name to evaluate and a node indicating
|
30 |
|
|
where to start the evaluation.
|
31 |
|
|
|
32 |
|
|
@section Crossing a Mount Point During Path Evaluation
|
33 |
|
|
|
34 |
|
|
If the filesystem supports the mount command, the evaluate routines
|
35 |
|
|
must handle crossing the mountpoint. The evaluate routine should evaluate
|
36 |
|
|
the name upto the first directory node where the new filesystem is mounted.
|
37 |
|
|
The filesystem may process terminator characters prior to calling the
|
38 |
|
|
evaluate routine for the new filesystem. A pointer to the portion of the
|
39 |
|
|
name which has not been evaluated along with the root node of the new
|
40 |
|
|
file system ( gotten from the mount table entry ) is passed to the correct
|
41 |
|
|
mounted filesystem evaluate routine.
|
42 |
|
|
|
43 |
|
|
|
44 |
|
|
@section The rtems_filesystem_location_info_t Structure
|
45 |
|
|
|
46 |
|
|
The @code{rtems_filesystem_location_info_t} structure contains all information
|
47 |
|
|
necessary for identification of a node.
|
48 |
|
|
|
49 |
|
|
The generic rtems filesystem code defines two global
|
50 |
|
|
rtems_filesystem_location_info_t structures, the
|
51 |
|
|
@code{rtems_filesystem_root} and the @code{rtems_filesystem_current}.
|
52 |
|
|
Both are initially defined to be the root node of the base filesystem.
|
53 |
|
|
Once the chdir command is correctly used the @code{rtems_filesystem_current}
|
54 |
|
|
is set to the location specified by the command.
|
55 |
|
|
|
56 |
|
|
The filesystem generic code peeks at the first character in the name to be
|
57 |
|
|
evaluated. If this character is a valid seperator, the
|
58 |
|
|
@code{rtems_filesystem_root} is used as the node to start the evaluation
|
59 |
|
|
with. Otherwise, the @code{rtems_filesystem_current} node is used as the
|
60 |
|
|
node to start evaluating with. Therefore, a valid
|
61 |
|
|
rtems_filesystem_location_info_t is given to the evaluate routine to start
|
62 |
|
|
evaluation with. The evaluate routines are then responsible for making
|
63 |
|
|
any changes necessary to this structure to correspond to the name being
|
64 |
|
|
parsed.
|
65 |
|
|
|
66 |
|
|
@example
|
67 |
|
|
struct rtems_filesystem_location_info_tt @{
|
68 |
|
|
void *node_access;
|
69 |
|
|
rtems_filesystem_file_handlers_r *handlers;
|
70 |
|
|
rtems_filesystem_operations_table *ops;
|
71 |
|
|
rtems_filesystem_mount_table_entry_t *mt_entry;
|
72 |
|
|
@};
|
73 |
|
|
@end example
|
74 |
|
|
|
75 |
|
|
@table @b
|
76 |
|
|
|
77 |
|
|
@item node_access
|
78 |
|
|
This element is filesystem specific. A filesystem can define and store
|
79 |
|
|
any information necessary to identify a node at this location. This element
|
80 |
|
|
is normally filled in by the filesystem's evaluate routine. For the
|
81 |
|
|
filesystem's root node, the filesystem's initilization routine should
|
82 |
|
|
fill this in, and it should remain valid until the instance of the
|
83 |
|
|
filesystem is unmounted.
|
84 |
|
|
|
85 |
|
|
@item handlers
|
86 |
|
|
This element is defined as a set of routines that may change within a
|
87 |
|
|
given filesystem based upon node type. For example a directory and a
|
88 |
|
|
memory file may have to completely different read routines. This element
|
89 |
|
|
is set to an initialization state defined by the mount table, and may
|
90 |
|
|
be set to the desired state by the evaluation routines.
|
91 |
|
|
|
92 |
|
|
@item ops
|
93 |
|
|
This element is defined as a set of routines that remain static for the
|
94 |
|
|
filesystem. This element identifies entry points into the filesystem
|
95 |
|
|
to the generic code.
|
96 |
|
|
|
97 |
|
|
@item mt_entry
|
98 |
|
|
This element identifies the mount table entry for this instance of the
|
99 |
|
|
filesystem.
|
100 |
|
|
|
101 |
|
|
@end table
|
102 |
|
|
|
103 |
|
|
|
104 |
|
|
|
105 |
|
|
|
106 |
|
|
|
107 |
|
|
|
108 |
|
|
|
109 |
|
|
|