Annotation of src/sys/miscfs/nullfs/null_vnops.c, Revision 1.20
1.20 ! wiz 1: /* $NetBSD: null_vnops.c,v 1.19 2001/06/07 13:44:47 wiz Exp $ */
1.2 cgd 2:
1.1 mycroft 3: /*
1.16 wrstuden 4: * Copyright (c) 1999 National Aeronautics & Space Administration
5: * All rights reserved.
6: *
7: * This software was written by William Studenmund of the
1.19 wiz 8: * Numerical Aerospace Simulation Facility, NASA Ames Research Center.
1.16 wrstuden 9: *
10: * Redistribution and use in source and binary forms, with or without
11: * modification, are permitted provided that the following conditions
12: * are met:
13: * 1. Redistributions of source code must retain the above copyright
14: * notice, this list of conditions and the following disclaimer.
15: * 2. Redistributions in binary form must reproduce the above copyright
16: * notice, this list of conditions and the following disclaimer in the
17: * documentation and/or other materials provided with the distribution.
1.17 soren 18: * 3. Neither the name of the National Aeronautics & Space Administration
1.16 wrstuden 19: * nor the names of its contributors may be used to endorse or promote
20: * products derived from this software without specific prior written
21: * permission.
22: *
23: * THIS SOFTWARE IS PROVIDED BY THE NATIONAL AERONAUTICS & SPACE ADMINISTRATION
24: * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
25: * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
26: * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE ADMINISTRATION OR CONTRIB-
27: * UTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
28: * OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
29: * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
30: * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
31: * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
32: * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
33: * POSSIBILITY OF SUCH DAMAGE.
34: */
35: /*
1.1 mycroft 36: * Copyright (c) 1992, 1993
37: * The Regents of the University of California. All rights reserved.
38: *
39: * This code is derived from software contributed to Berkeley by
40: * John Heidemann of the UCLA Ficus project.
41: *
42: * Redistribution and use in source and binary forms, with or without
43: * modification, are permitted provided that the following conditions
44: * are met:
45: * 1. Redistributions of source code must retain the above copyright
46: * notice, this list of conditions and the following disclaimer.
47: * 2. Redistributions in binary form must reproduce the above copyright
48: * notice, this list of conditions and the following disclaimer in the
49: * documentation and/or other materials provided with the distribution.
50: * 3. All advertising materials mentioning features or use of this software
51: * must display the following acknowledgement:
52: * This product includes software developed by the University of
53: * California, Berkeley and its contributors.
54: * 4. Neither the name of the University nor the names of its contributors
55: * may be used to endorse or promote products derived from this software
56: * without specific prior written permission.
57: *
58: * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
59: * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
60: * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
61: * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
62: * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
63: * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
64: * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
65: * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
66: * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
67: * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
68: * SUCH DAMAGE.
69: *
1.13 fvdl 70: * @(#)null_vnops.c 8.6 (Berkeley) 5/27/95
1.1 mycroft 71: *
72: * Ancestors:
73: * @(#)lofs_vnops.c 1.2 (Berkeley) 6/18/92
1.20 ! wiz 74: * $Id: null_vnops.c,v 1.19 2001/06/07 13:44:47 wiz Exp $
1.1 mycroft 75: * ...and...
76: * @(#)null_vnodeops.c 1.20 92/07/07 UCLA Ficus project
77: */
78:
79: /*
80: * Null Layer
81: *
82: * (See mount_null(8) for more information.)
83: *
84: * The null layer duplicates a portion of the file system
85: * name space under a new name. In this respect, it is
86: * similar to the loopback file system. It differs from
87: * the loopback fs in two respects: it is implemented using
1.20 ! wiz 88: * a stackable layers technique, and its "null-nodes" stack above
1.1 mycroft 89: * all lower-layer vnodes, not just over directory vnodes.
90: *
91: * The null layer has two purposes. First, it serves as a demonstration
1.20 ! wiz 92: * of layering by providing a layer which does nothing (it actually
1.1 mycroft 93: * does everything the loopback file system does, which is slightly
1.20 ! wiz 94: * more than nothing). Second, the null layer can serve as a prototype
1.1 mycroft 95: * layer. Since it provides all necessary layer framework,
1.19 wiz 96: * new file system layers can be created very easily by starting
1.1 mycroft 97: * with a null layer.
98: *
1.19 wiz 99: * The remainder of this comment examines the null layer as a basis
1.1 mycroft 100: * for constructing new layers.
101: *
102: *
103: * INSTANTIATING NEW NULL LAYERS
104: *
105: * New null layers are created with mount_null(8).
1.19 wiz 106: * mount_null(8) takes two arguments, the pathname
1.1 mycroft 107: * of the lower vfs (target-pn) and the pathname where the null
108: * layer will appear in the namespace (alias-pn). After
109: * the null layer is put into place, the contents
110: * of target-pn subtree will be aliased under alias-pn.
111: *
112: *
113: * OPERATION OF A NULL LAYER
114: *
115: * The null layer is the minimum file system layer,
116: * simply bypassing all possible operations to the lower layer
117: * for processing there. The majority of its activity centers
1.19 wiz 118: * on the bypass routine, through which nearly all vnode operations
1.1 mycroft 119: * pass.
120: *
121: * The bypass routine accepts arbitrary vnode operations for
1.19 wiz 122: * handling by the lower layer. It begins by examining vnode
1.1 mycroft 123: * operation arguments and replacing any null-nodes by their
1.19 wiz 124: * lower-layer equivalents. It then invokes the operation
1.1 mycroft 125: * on the lower layer. Finally, it replaces the null-nodes
1.19 wiz 126: * in the arguments and, if a vnode is returned by the operation,
1.1 mycroft 127: * stacks a null-node on top of the returned vnode.
128: *
1.13 fvdl 129: * Although bypass handles most operations, vop_getattr, vop_lock,
130: * vop_unlock, vop_inactive, vop_reclaim, and vop_print are not
1.19 wiz 131: * bypassed. vop_getattr must change the fsid being returned.
132: * vop_lock and vop_unlock must handle any locking for the
1.13 fvdl 133: * current vnode as well as pass the lock request down.
1.19 wiz 134: * vop_inactive and vop_reclaim are not bypassed so that
135: * they can handle freeing null-layer specific data. vop_print
1.13 fvdl 136: * is not bypassed to avoid excessive debugging information.
137: * Also, certain vnode operations change the locking state within
138: * the operation (create, mknod, remove, link, rename, mkdir, rmdir,
139: * and symlink). Ideally these operations should not change the
140: * lock state, but should be changed to let the caller of the
141: * function unlock them. Otherwise all intermediate vnode layers
142: * (such as union, umapfs, etc) must catch these functions to do
143: * the necessary locking at their layer.
1.1 mycroft 144: *
145: *
146: * INSTANTIATING VNODE STACKS
147: *
148: * Mounting associates the null layer with a lower layer,
1.19 wiz 149: * in effect stacking two VFSes. Vnode stacks are instead
1.1 mycroft 150: * created on demand as files are accessed.
151: *
152: * The initial mount creates a single vnode stack for the
153: * root of the new null layer. All other vnode stacks
154: * are created as a result of vnode operations on
155: * this or other null vnode stacks.
156: *
1.19 wiz 157: * New vnode stacks come into existence as a result of
1.1 mycroft 158: * an operation which returns a vnode.
159: * The bypass routine stacks a null-node above the new
160: * vnode before returning it to the caller.
161: *
162: * For example, imagine mounting a null layer with
163: * "mount_null /usr/include /dev/layer/null".
164: * Changing directory to /dev/layer/null will assign
165: * the root null-node (which was created when the null layer was mounted).
166: * Now consider opening "sys". A vop_lookup would be
167: * done on the root null-node. This operation would bypass through
168: * to the lower layer which would return a vnode representing
1.19 wiz 169: * the UFS "sys". null_bypass then builds a null-node
1.1 mycroft 170: * aliasing the UFS "sys" and returns this to the caller.
171: * Later operations on the null-node "sys" will repeat this
172: * process when constructing other vnode stacks.
173: *
174: *
175: * CREATING OTHER FILE SYSTEM LAYERS
176: *
177: * One of the easiest ways to construct new file system layers is to make
178: * a copy of the null layer, rename all files and variables, and
1.19 wiz 179: * then begin modifying the copy. sed(1) can be used to easily rename
1.1 mycroft 180: * all variables.
181: *
182: * The umap layer is an example of a layer descended from the
183: * null layer.
184: *
185: *
186: * INVOKING OPERATIONS ON LOWER LAYERS
187: *
188: * There are two techniques to invoke operations on a lower layer
189: * when the operation cannot be completely bypassed. Each method
190: * is appropriate in different situations. In both cases,
191: * it is the responsibility of the aliasing layer to make
192: * the operation arguments "correct" for the lower layer
1.19 wiz 193: * by mapping any vnode arguments to the lower layer.
1.1 mycroft 194: *
195: * The first approach is to call the aliasing layer's bypass routine.
196: * This method is most suitable when you wish to invoke the operation
197: * currently being hanldled on the lower layer. It has the advantage
198: * that the bypass routine already must do argument mapping.
199: * An example of this is null_getattrs in the null layer.
200: *
1.19 wiz 201: * A second approach is to directly invoke vnode operations on
1.1 mycroft 202: * the lower layer with the VOP_OPERATIONNAME interface.
203: * The advantage of this method is that it is easy to invoke
204: * arbitrary operations on the lower layer. The disadvantage
1.19 wiz 205: * is that vnode arguments must be manually mapped.
1.1 mycroft 206: *
207: */
208:
209: #include <sys/param.h>
210: #include <sys/systm.h>
211: #include <sys/proc.h>
212: #include <sys/time.h>
213: #include <sys/types.h>
214: #include <sys/vnode.h>
215: #include <sys/mount.h>
216: #include <sys/namei.h>
217: #include <sys/malloc.h>
218: #include <sys/buf.h>
1.16 wrstuden 219: #include <miscfs/genfs/genfs.h>
1.1 mycroft 220: #include <miscfs/nullfs/null.h>
1.16 wrstuden 221: #include <miscfs/genfs/layer_extern.h>
1.1 mycroft 222:
223: /*
224: * Global vfs data structures
225: */
1.5 christos 226: int (**null_vnodeop_p) __P((void *));
1.18 jdolecek 227: const struct vnodeopv_entry_desc null_vnodeop_entries[] = {
1.16 wrstuden 228: { &vop_default_desc, layer_bypass },
1.1 mycroft 229:
1.16 wrstuden 230: { &vop_lookup_desc, layer_lookup },
231: { &vop_setattr_desc, layer_setattr },
232: { &vop_getattr_desc, layer_getattr },
233: { &vop_access_desc, layer_access },
234: { &vop_lock_desc, layer_lock },
235: { &vop_unlock_desc, layer_unlock },
236: { &vop_islocked_desc, layer_islocked },
237: { &vop_fsync_desc, layer_fsync },
238: { &vop_inactive_desc, layer_inactive },
239: { &vop_reclaim_desc, layer_reclaim },
240: { &vop_print_desc, layer_print },
241:
242: { &vop_open_desc, layer_open }, /* mount option handling */
243:
244: { &vop_strategy_desc, layer_strategy },
245: { &vop_bwrite_desc, layer_bwrite },
246: { &vop_bmap_desc, layer_bmap },
1.1 mycroft 247:
1.13 fvdl 248: { (struct vnodeop_desc*)NULL, (int(*)__P((void *)))NULL }
1.1 mycroft 249: };
1.18 jdolecek 250: const struct vnodeopv_desc null_vnodeop_opv_desc =
1.1 mycroft 251: { &null_vnodeop_p, null_vnodeop_entries };
CVSweb <webmaster@jp.NetBSD.org>
![[BACK]](/icons/back.gif){kind=icon}
Return to null_vnops.c CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [cvs.NetBSD.org] / src / sys / miscfs / nullfs