Lines Matching +full:layer +full:- +full:base +full:- +full:offset
32 \s-1UNIX\s0\\$1\(dg
34 \(dg \s-1UNIX\s0 is a registered trademark of AT&T.
66 Each design attempts to isolate filesystem-dependent details
102 AT&T's recently-announced Remote File Sharing, RFS [Rifkin86],
108 system [Weinberger84] and two different filesystems used at Carnegie-Mellon
122 with carefully-defined entry points to separate the filesystem from the rest
130 A clean, well-defined interface to the filesystem also allows a single
135 The best-known of these are Sun Microsystems' Virtual File System interface,
155 Each attempts to divide the filesystem into a filesystem-type-independent
156 layer and individual filesystem implementations.
161 at the user-process level, each attempts to be completely transparent
162 except for a few filesystem-related system management programs.
164 system interfaces, and even to retain object-file-level binary compatibility
168 or source-code modification.
177 Most system calls that descend into the file-system dependent layer
179 to the higher-level kernel calling routines.
180 Instead, the filesystem-dependent code completes the requested
181 operation and then executes a non-local goto (\fIlongjmp\fP) to exit the
183 These efforts to avoid modification of main-line kernel code
189 of filesystem-independent and -dependent data structures and operations.
206 No locking may be done in the filesystem-independent layer,
207 and locking in the filesystem-dependent layer may occur only during
208 a single call into that layer.
237 and \fIiget\fP, which locates an inode by number and installs it in the in-core
255 attempt to preserve the inode-oriented interface.
257 for different filesystem types by separating the filesystem-dependent
261 of the old filesystem to be performed in the filesystem-independent
262 layer, with entry points to the individual filesystem implementations to support
263 the type-specific parts of these operations. Implicit in this interface
272 The vnode contains no filesystem-dependent fields except the pointer
275 permissions, size and timestamps, are maintained by the lower layer.
278 as they may not be up-to-date later on.
290 pathname-to-internal-representation translation.
301 such as the offset in the directory at which the modification will be made.
307 this information is stored in the per-process \fIuser\fP structure
308 by \fInamei\fP for use by a low-level routine called after performing
323 The filesystem-specific routine translates the name, component by component,
341 A pathname-oriented request other than open may be completed
348 This routine simply calls a new pathname-handling module to allocate
355 Per-filesystem \fIlookup\fP routines may translate only one component
369 A system-wide cache of recent translations is maintained.
375 A per-process cache is kept of the directory and offset
388 The generalization of the structure may otherwise make an already-expensive
391 from the beta-test version of 4.3BSD.
392 The Sun system uses a name-translation cache generally like that in 4.3BSD.
393 The name cache is a filesystem-independent facility provided for the use
394 of the filesystem-specific lookup routines.
413 by a multi-component name lookup is dramatically larger
462 Use of per-file cache description does not easily accommodate
480 to satisfy fill-on-demand page faults.
494 remains, the data would have to be copied (``copy-on-write'').
500 memory system by performing logical-to-physical block number translation
501 when setting up a fill-on-demand image for a process.
518 The buffer-style interface is the same as that used by disk drivers internally.
534 the implicit use of user-structure global context,
543 It is also the most general of the three, in that filesystem-specific
544 data and operations are best separated from the generic layer.
560 but, like GFS, uses a 4.3BSD-style name lookup interface.
564 This is especially desired in any system where kernel-mode servers
565 operate as light-weight or interrupt-level processes,
570 and they may be accessed using short offsets from a base pointer
582 to pass these same parameters to filesystem-specific lookup routines,
597 * and to retain per-process context.
647 by storing the new directory entry and its offset in the directory
649 This is intended to be opaque to the filesystem-independent levels.
652 may be read-only, etc.
664 For the local filesystem, the per-process directory offset cache
666 A file server could leave the directory offset cache empty,
694 gid_t cr_svgid; /* saved set-group id */
713 * involves scatter-gather, with individual sections
735 * If iov_op is non-null, it is called to implement the copy
740 * treating base as a user or kernel virtual address
769 The structure describing the externally-visible features of a mounted
812 The operations supported by the filesystem-specific layer
844 long f_bavail; /* free blocks avail to non-superuser */
865 (NFS does not allow remotely-mounted file trees to span physical filesystems
980 A file offset of type \fIoff_t\fP.
982 A pointer to file offset of type \fIoff_t\fP.
1024 the file offset and buffer locations.
1027 to return a new file offset token for its current location.
1030 The first, \fIvn_seek\fP, is a concession to record-oriented files
1033 offset, or to return a new offset token relative to an earlier one.
1054 * Vnode attributes. A field value of -1
1083 between the filesystem-independent and -dependent layers and data structures.
1106 \fISoftware\- Practice and Experience\fP, Vol. 12, pp. 1147-1162, 1982.
1112 pp. 131-150, June, 1985.
1117 pp. 238-247, June, 1986.
1122 \fIUsenix Conference Proceedings\fP, pp. 237-252, June, 1984.
1127 Vol. 2, pp. 181-197,
1133 \fIUsenix Conference Proceedings\fP, pp. 519-531, June, 1985.
1138 pp. 248-259, June, 1986.
1141 Ritchie, D.M. and K. Thompson, ``The Unix Time-Sharing System,''
1142 \fICommunications of the ACM\fP, Vol. 17, pp. 365-375, July, 1974.
1147 pp. 260-269, June, 1986.
1153 pp. 119-130, June, 1985.
1158 \fIProc. 10th Symposium on Operating Systems Principles\fP, pp. 35-50,