[BACK]Return to null_vnops.c CVS log [TXT][DIR] Up to [cvs.NetBSD.org] / src / sys / miscfs / nullfs

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>