source: rtems/doc/filesystem/patheval.t @ 10c1bef

4.104.114.84.95
Last change on this file since 10c1bef was 10c1bef, checked in by Jennifer Averett <Jennifer.Averett@…>, on 10/26/99 at 15:42:10

Added information on the evaluate and evaluate for make routines.
Added details on how generic code starts the pathevaluation process.

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