Index: head/sbin/mount_null/mount_null.8
===================================================================
--- head/sbin/mount_null/mount_null.8	(revision 42002)
+++ head/sbin/mount_null/mount_null.8	(revision 42003)
@@ -1,235 +1,245 @@
 .\"
 .\" Copyright (c) 1992, 1993, 1994
 .\"	The Regents of the University of California.  All rights reserved.
 .\"
 .\" This code is derived from software donated to Berkeley by
 .\" John Heidemann of the UCLA Ficus project.
 .\"
 .\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that the following conditions
 .\" are met:
 .\" 1. Redistributions of source code must retain the above copyright
 .\"    notice, this list of conditions and the following disclaimer.
 .\" 2. Redistributions in binary form must reproduce the above copyright
 .\"    notice, this list of conditions and the following disclaimer in the
 .\"    documentation and/or other materials provided with the distribution.
 .\" 3. All advertising materials mentioning features or use of this software
 .\"    must display the following acknowledgement:
 .\"	This product includes software developed by the University of
 .\"	California, Berkeley and its contributors.
 .\" 4. Neither the name of the University nor the names of its contributors
 .\"    may be used to endorse or promote products derived from this software
 .\"    without specific prior written permission.
 .\"
 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
 .\"
 .\"     @(#)mount_null.8	8.6 (Berkeley) 5/1/95
-.\"	$Id: mount_null.8,v 1.8 1997/03/11 12:33:34 peter Exp $
+.\"	$Id: mount_null.8,v 1.9 1998/07/06 07:17:26 charnier Exp $
 .\"
 .Dd May 1, 1995
 .Dt MOUNT_NULL 8
 .Os BSD 4.4
 .Sh NAME
 .Nm mount_null
 .Nd mount a loopback filesystem sub-tree;
 demonstrate the use of a null file system layer
 .Sh SYNOPSIS
 .Nm mount_null
 .Op Fl o Ar options
 .Ar target
 .Ar mount-point
 .Sh DESCRIPTION
 The
 .Nm
 command creates a
 null layer, duplicating a sub-tree of the file system
 name space under another part of the global file system namespace.
 This allows existing files and directories to be accessed
 using a different pathname.
 .Pp
 The primary differences between a virtual copy of the filesystem
 and a symbolic link are that
 .Xr getcwd 3
 functions correctly in the virtual copy, and that other filesystems
 may be mounted on the virtual copy without affecting the original.
 A different device number for the virtual copy is returned by
 .Xr stat 2 ,
 but in other respects it is indistinguishable from the original.
 .Pp
 The
 .Nm
 filesystem differs from a traditional
 loopback file system in two respects: it is implemented using
 a stackable layers techniques, and it's 
 .Do
 null-node
 .Dc s
 stack above
 all lower-layer vnodes, not just over directory vnodes.
 .Pp
 The options are as follows:
 .Bl -tag -width indent
 .It Fl o
 Options are specified with a
 .Fl o
 flag followed by a comma separated string of options.
 See the
 .Xr mount 8
 man page for possible options and their meanings.
 .El
 .Pp
 The null layer has two purposes.
 First, it serves as a demonstration of layering by providing a layer
 which does nothing.
 (It actually does everything the loopback file system does,
 which is slightly more than nothing.)
 Second, the null layer can serve as a prototype layer.
 Since it provides all necessary layer framework,
 new file system layers can be created very easily be starting
 with a null layer.
 .Pp
 The remainder of this man page examines the null layer as a basis
 for constructing new layers.
 .\"
 .\"
 .Sh INSTANTIATING NEW NULL LAYERS
 New null layers are created with 
 .Xr mount_null 8 .
 .Xr Mount_null 8
 takes two arguments, the pathname
 of the lower vfs (target-pn) and the pathname where the null
 layer will appear in the namespace (mount-point-pn).  After
 the null layer is put into place, the contents
 of target-pn subtree will be aliased under mount-point-pn.
 .\"
 .\"
 .Sh OPERATION OF A NULL LAYER
 The null layer is the minimum file system layer,
 simply bypassing all possible operations to the lower layer
 for processing there.  The majority of its activity centers
 on the bypass routine, though which nearly all vnode operations
 pass.
 .Pp
 The bypass routine accepts arbitrary vnode operations for
 handling by the lower layer.  It begins by examining vnode
 operation arguments and replacing any null-nodes by their
 lower-layer equivalents.  It then invokes the operation
 on the lower layer.  Finally, it replaces the null-nodes
 in the arguments and, if a vnode is returned by the operation,
 stacks a null-node on top of the returned vnode.
 .Pp
 Although bypass handles most operations, 
 .Em vop_getattr , 
 .Em vop_inactive ,
 .Em vop_reclaim ,
 and
 .Em vop_print
 are not bypassed.
 .Em Vop_getattr
 must change the fsid being returned.
 .Em Vop_inactive
 and vop_reclaim are not bypassed so that
 they can handle freeing null-layer specific data.
 .Em Vop_print
 is not bypassed to avoid excessive debugging
 information.
 .\"
 .\"
 .Sh INSTANTIATING VNODE STACKS
 Mounting associates the null layer with a lower layer,
 in effect stacking two VFSes.  Vnode stacks are instead
 created on demand as files are accessed.
 .Pp
 The initial mount creates a single vnode stack for the
 root of the new null layer.  All other vnode stacks
 are created as a result of vnode operations on
 this or other null vnode stacks.
 .Pp
 New vnode stacks come into existence as a result of
 an operation which returns a vnode.  
 The bypass routine stacks a null-node above the new
 vnode before returning it to the caller.
 .Pp
 For example, imagine mounting a null layer with
 .Bd -literal -offset indent
 mount_null /usr/include /dev/layer/null
 .Ed
 Changing directory to 
 .Pa /dev/layer/null
 will assign
 the root null-node (which was created when the null layer was mounted).
 Now consider opening 
 .Pa sys .
 A vop_lookup would be
 done on the root null-node.  This operation would bypass through
 to the lower layer which would return a vnode representing 
 the UFS 
 .Pa sys .
 Null_bypass then builds a null-node
 aliasing the UFS 
 .Pa sys
 and returns this to the caller.
 Later operations on the null-node 
 .Pa sys
 will repeat this 
 process when constructing other vnode stacks.
 .\"
 .\"
 .Sh CREATING OTHER FILE SYSTEM LAYERS
 One of the easiest ways to construct new file system layers is to make
 a copy of the null layer, rename all files and variables, and
 then begin modifying the copy.
 .Xr Sed 1
 can be used to easily rename
 all variables.
 .Pp
 The umap layer is an example of a layer descended from the 
 null layer.
 .\"
 .\"
 .Sh INVOKING OPERATIONS ON LOWER LAYERS
 There are two techniques to invoke operations on a lower layer 
 when the operation cannot be completely bypassed.  Each method
 is appropriate in different situations.  In both cases,
 it is the responsibility of the aliasing layer to make
 the operation arguments "correct" for the lower layer
 by mapping an vnode arguments to the lower layer.
 .Pp
 The first approach is to call the aliasing layer's bypass routine.
 This method is most suitable when you wish to invoke the operation
 currently being handled on the lower layer.  It has the advantage
 the bypass routine already must do argument mapping.
 An example of this is 
 .Em null_getattrs
 in the null layer.
 .Pp
 A second approach is to directly invoked vnode operations on
 the lower layer with the
 .Em VOP_OPERATIONNAME
 interface.
 The advantage of this method is that it is easy to invoke
 arbitrary operations on the lower layer.  The disadvantage
 is that vnodes arguments must be manually mapped.
 .\"
 .\"
 .Sh SEE ALSO
 .Xr mount 8
 .sp
 UCLA Technical Report CSD-910056,
 .Em "Stackable Layers: an Architecture for File System Development" .
+.Sh BUGS
+
+THIS FILESYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK) 
+AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM.  USE AT YOUR
+OWN RISK.  BEWARE OF DOG.  SLIPPERY WHEN WET.
+
+This code also needs an owner in order to be less dangerous - serious
+hackers can apply by sending mail to hackers@freebsd.org and announcing
+their intent to take it over.
+
 .Sh HISTORY
 The
 .Nm
 utility first appeared in
 .Bx 4.4 .
Index: head/sbin/mount_nullfs/mount_nullfs.8
===================================================================
--- head/sbin/mount_nullfs/mount_nullfs.8	(revision 42002)
+++ head/sbin/mount_nullfs/mount_nullfs.8	(revision 42003)
@@ -1,235 +1,245 @@
 .\"
 .\" Copyright (c) 1992, 1993, 1994
 .\"	The Regents of the University of California.  All rights reserved.
 .\"
 .\" This code is derived from software donated to Berkeley by
 .\" John Heidemann of the UCLA Ficus project.
 .\"
 .\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that the following conditions
 .\" are met:
 .\" 1. Redistributions of source code must retain the above copyright
 .\"    notice, this list of conditions and the following disclaimer.
 .\" 2. Redistributions in binary form must reproduce the above copyright
 .\"    notice, this list of conditions and the following disclaimer in the
 .\"    documentation and/or other materials provided with the distribution.
 .\" 3. All advertising materials mentioning features or use of this software
 .\"    must display the following acknowledgement:
 .\"	This product includes software developed by the University of
 .\"	California, Berkeley and its contributors.
 .\" 4. Neither the name of the University nor the names of its contributors
 .\"    may be used to endorse or promote products derived from this software
 .\"    without specific prior written permission.
 .\"
 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
 .\"
 .\"     @(#)mount_null.8	8.6 (Berkeley) 5/1/95
-.\"	$Id: mount_null.8,v 1.8 1997/03/11 12:33:34 peter Exp $
+.\"	$Id: mount_null.8,v 1.9 1998/07/06 07:17:26 charnier Exp $
 .\"
 .Dd May 1, 1995
 .Dt MOUNT_NULL 8
 .Os BSD 4.4
 .Sh NAME
 .Nm mount_null
 .Nd mount a loopback filesystem sub-tree;
 demonstrate the use of a null file system layer
 .Sh SYNOPSIS
 .Nm mount_null
 .Op Fl o Ar options
 .Ar target
 .Ar mount-point
 .Sh DESCRIPTION
 The
 .Nm
 command creates a
 null layer, duplicating a sub-tree of the file system
 name space under another part of the global file system namespace.
 This allows existing files and directories to be accessed
 using a different pathname.
 .Pp
 The primary differences between a virtual copy of the filesystem
 and a symbolic link are that
 .Xr getcwd 3
 functions correctly in the virtual copy, and that other filesystems
 may be mounted on the virtual copy without affecting the original.
 A different device number for the virtual copy is returned by
 .Xr stat 2 ,
 but in other respects it is indistinguishable from the original.
 .Pp
 The
 .Nm
 filesystem differs from a traditional
 loopback file system in two respects: it is implemented using
 a stackable layers techniques, and it's 
 .Do
 null-node
 .Dc s
 stack above
 all lower-layer vnodes, not just over directory vnodes.
 .Pp
 The options are as follows:
 .Bl -tag -width indent
 .It Fl o
 Options are specified with a
 .Fl o
 flag followed by a comma separated string of options.
 See the
 .Xr mount 8
 man page for possible options and their meanings.
 .El
 .Pp
 The null layer has two purposes.
 First, it serves as a demonstration of layering by providing a layer
 which does nothing.
 (It actually does everything the loopback file system does,
 which is slightly more than nothing.)
 Second, the null layer can serve as a prototype layer.
 Since it provides all necessary layer framework,
 new file system layers can be created very easily be starting
 with a null layer.
 .Pp
 The remainder of this man page examines the null layer as a basis
 for constructing new layers.
 .\"
 .\"
 .Sh INSTANTIATING NEW NULL LAYERS
 New null layers are created with 
 .Xr mount_null 8 .
 .Xr Mount_null 8
 takes two arguments, the pathname
 of the lower vfs (target-pn) and the pathname where the null
 layer will appear in the namespace (mount-point-pn).  After
 the null layer is put into place, the contents
 of target-pn subtree will be aliased under mount-point-pn.
 .\"
 .\"
 .Sh OPERATION OF A NULL LAYER
 The null layer is the minimum file system layer,
 simply bypassing all possible operations to the lower layer
 for processing there.  The majority of its activity centers
 on the bypass routine, though which nearly all vnode operations
 pass.
 .Pp
 The bypass routine accepts arbitrary vnode operations for
 handling by the lower layer.  It begins by examining vnode
 operation arguments and replacing any null-nodes by their
 lower-layer equivalents.  It then invokes the operation
 on the lower layer.  Finally, it replaces the null-nodes
 in the arguments and, if a vnode is returned by the operation,
 stacks a null-node on top of the returned vnode.
 .Pp
 Although bypass handles most operations, 
 .Em vop_getattr , 
 .Em vop_inactive ,
 .Em vop_reclaim ,
 and
 .Em vop_print
 are not bypassed.
 .Em Vop_getattr
 must change the fsid being returned.
 .Em Vop_inactive
 and vop_reclaim are not bypassed so that
 they can handle freeing null-layer specific data.
 .Em Vop_print
 is not bypassed to avoid excessive debugging
 information.
 .\"
 .\"
 .Sh INSTANTIATING VNODE STACKS
 Mounting associates the null layer with a lower layer,
 in effect stacking two VFSes.  Vnode stacks are instead
 created on demand as files are accessed.
 .Pp
 The initial mount creates a single vnode stack for the
 root of the new null layer.  All other vnode stacks
 are created as a result of vnode operations on
 this or other null vnode stacks.
 .Pp
 New vnode stacks come into existence as a result of
 an operation which returns a vnode.  
 The bypass routine stacks a null-node above the new
 vnode before returning it to the caller.
 .Pp
 For example, imagine mounting a null layer with
 .Bd -literal -offset indent
 mount_null /usr/include /dev/layer/null
 .Ed
 Changing directory to 
 .Pa /dev/layer/null
 will assign
 the root null-node (which was created when the null layer was mounted).
 Now consider opening 
 .Pa sys .
 A vop_lookup would be
 done on the root null-node.  This operation would bypass through
 to the lower layer which would return a vnode representing 
 the UFS 
 .Pa sys .
 Null_bypass then builds a null-node
 aliasing the UFS 
 .Pa sys
 and returns this to the caller.
 Later operations on the null-node 
 .Pa sys
 will repeat this 
 process when constructing other vnode stacks.
 .\"
 .\"
 .Sh CREATING OTHER FILE SYSTEM LAYERS
 One of the easiest ways to construct new file system layers is to make
 a copy of the null layer, rename all files and variables, and
 then begin modifying the copy.
 .Xr Sed 1
 can be used to easily rename
 all variables.
 .Pp
 The umap layer is an example of a layer descended from the 
 null layer.
 .\"
 .\"
 .Sh INVOKING OPERATIONS ON LOWER LAYERS
 There are two techniques to invoke operations on a lower layer 
 when the operation cannot be completely bypassed.  Each method
 is appropriate in different situations.  In both cases,
 it is the responsibility of the aliasing layer to make
 the operation arguments "correct" for the lower layer
 by mapping an vnode arguments to the lower layer.
 .Pp
 The first approach is to call the aliasing layer's bypass routine.
 This method is most suitable when you wish to invoke the operation
 currently being handled on the lower layer.  It has the advantage
 the bypass routine already must do argument mapping.
 An example of this is 
 .Em null_getattrs
 in the null layer.
 .Pp
 A second approach is to directly invoked vnode operations on
 the lower layer with the
 .Em VOP_OPERATIONNAME
 interface.
 The advantage of this method is that it is easy to invoke
 arbitrary operations on the lower layer.  The disadvantage
 is that vnodes arguments must be manually mapped.
 .\"
 .\"
 .Sh SEE ALSO
 .Xr mount 8
 .sp
 UCLA Technical Report CSD-910056,
 .Em "Stackable Layers: an Architecture for File System Development" .
+.Sh BUGS
+
+THIS FILESYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK) 
+AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM.  USE AT YOUR
+OWN RISK.  BEWARE OF DOG.  SLIPPERY WHEN WET.
+
+This code also needs an owner in order to be less dangerous - serious
+hackers can apply by sending mail to hackers@freebsd.org and announcing
+their intent to take it over.
+
 .Sh HISTORY
 The
 .Nm
 utility first appeared in
 .Bx 4.4 .
Index: head/sbin/mount_umap/mount_umap.8
===================================================================
--- head/sbin/mount_umap/mount_umap.8	(revision 42002)
+++ head/sbin/mount_umap/mount_umap.8	(revision 42003)
@@ -1,130 +1,140 @@
 .\" Copyright (c) 1992, 1993, 1994
 .\"	The Regents of the University of California.  All rights reserved.
 .\" All rights reserved.
 .\"
 .\" This code is derived from software donated to Berkeley by
 .\" Jan-Simon Pendry and from John Heidemann of the UCLA Ficus project.
 .\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that the following conditions
 .\" are met:
 .\" 1. Redistributions of source code must retain the above copyright
 .\"    notice, this list of conditions and the following disclaimer.
 .\" 2. Redistributions in binary form must reproduce the above copyright
 .\"    notice, this list of conditions and the following disclaimer in the
 .\"    documentation and/or other materials provided with the distribution.
 .\" 3. All advertising materials mentioning features or use of this software
 .\"    must display the following acknowledgement:
 .\"	This product includes software developed by the University of
 .\"	California, Berkeley and its contributors.
 .\" 4. Neither the name of the University nor the names of its contributors
 .\"    may be used to endorse or promote products derived from this software
 .\"    without specific prior written permission.
 .\"
 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
 .\"
 .\"	@(#)mount_umap.8	8.4 (Berkeley) 5/1/95
-.\"	$Id$
+.\"	$Id: mount_umap.8,v 1.8 1998/07/15 06:12:31 charnier Exp $
 .\"
 .Dd May 1, 1995
 .Dt MOUNT_UMAP 8
 .Os BSD 4.4
 .Sh NAME
 .Nm mount_umap
 .Nd sample file system layer
 .Sh SYNOPSIS
 .Nm mount_umap
 .Op Fl o Ar options
 .Fl u Ar uid-mapfile
 .Fl g Ar gid-mapfile
 .Ar target
 .Ar mount-point
 .Sh DESCRIPTION
 The
 .Nm
 command is used to mount a sub-tree of an existing file system
 that uses a different set of uids and gids than the local system.
 Such a file system could be mounted from a remote site via NFS or
 it could be a file system on removable media brought from some
 foreign location that uses a different password file.
 .Pp
 The
 .Nm
 command uses a set of files provided by the user to make correspondences
 between uids and gids in the sub-tree's original environment and
 some other set of ids in the local environment.  For instance, user
 smith might have uid 1000 in the original environment, while having
 uid 2000 in the local environment.  The
 .Nm
 command allows the subtree from smith's original environment to be
 mapped in such a way that all files with owning uid 1000 look like
 they are actually owned by uid 2000.  
 .Pp
 The options are as follows:
 .Bl -tag -width indent
 .It Fl o
 Options are specified with a
 .Fl o
 flag followed by a comma separated string of options.
 See the
 .Xr mount 8
 man page for possible options and their meanings.
 .It Ar target 
 Should be the current location of the sub-tree in the
 local system's name space.  
 .It Ar mount-point 
 Should be a directory
 where the mapped subtree is to be placed.  
 .It Fl u Ar uid-mapfile 
 .It Fl g Ar gid-mapfile 
 Describe the mappings to be made between identifiers.
 Briefly, the format of these files is a count of the number of
 mappings on the first line, with each subsequent line containing
 a single mapping.  Each of these mappings consists of an id in
 the local environment and the corresponding id from the original environment,
 separated by white space.  
 .Ar Uid-mapfile 
 should contain all uid
 mappings, and 
 .Ar gid-mapfile 
 should contain all gid mappings.
 Any uids not mapped in 
 .Ar uid-mapfile 
 will be treated as user NOBODY,
 and any gids not mapped in 
 .Ar gid-mapfile 
 will be treated as group
 NULLGROUP.  At most 64 uids can be mapped for a given subtree, and
 at most 16 groups can be mapped by a given subtree.
 .El
 .Pp
 The mapfiles can be located anywhere in the file hierarchy, but they
 must be owned by root, and they must be writable only by root.  
 .Nm Mount_umap
 will refuse to map the sub-tree if the ownership or permissions on
 these files are improper.  It will also balk if the count of mappings
 in the first line of the map files is not correct.
 .Pp
 The layer created by the
 .Nm
 command is meant to serve as a simple example of file system layering.
 It is not meant for production use.  The implementation is not very
 sophisticated.
 .Sh SEE ALSO
 .Xr mount 8 ,
 .Xr mount_null 8
+.Sh BUGS
+
+THIS FILESYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK) 
+AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM.  USE AT YOUR
+OWN RISK.  BEWARE OF DOG.  SLIPPERY WHEN WET.
+
+This code also needs an owner in order to be less dangerous - serious
+hackers can apply by sending mail to hackers@freebsd.org and announcing
+their intent to take it over.
+
 .Sh HISTORY
 The
 .Nm
 utility first appeared in
 .Bx 4.4 .
Index: head/sbin/mount_umapfs/mount_umapfs.8
===================================================================
--- head/sbin/mount_umapfs/mount_umapfs.8	(revision 42002)
+++ head/sbin/mount_umapfs/mount_umapfs.8	(revision 42003)
@@ -1,130 +1,140 @@
 .\" Copyright (c) 1992, 1993, 1994
 .\"	The Regents of the University of California.  All rights reserved.
 .\" All rights reserved.
 .\"
 .\" This code is derived from software donated to Berkeley by
 .\" Jan-Simon Pendry and from John Heidemann of the UCLA Ficus project.
 .\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that the following conditions
 .\" are met:
 .\" 1. Redistributions of source code must retain the above copyright
 .\"    notice, this list of conditions and the following disclaimer.
 .\" 2. Redistributions in binary form must reproduce the above copyright
 .\"    notice, this list of conditions and the following disclaimer in the
 .\"    documentation and/or other materials provided with the distribution.
 .\" 3. All advertising materials mentioning features or use of this software
 .\"    must display the following acknowledgement:
 .\"	This product includes software developed by the University of
 .\"	California, Berkeley and its contributors.
 .\" 4. Neither the name of the University nor the names of its contributors
 .\"    may be used to endorse or promote products derived from this software
 .\"    without specific prior written permission.
 .\"
 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
 .\"
 .\"	@(#)mount_umap.8	8.4 (Berkeley) 5/1/95
-.\"	$Id$
+.\"	$Id: mount_umap.8,v 1.8 1998/07/15 06:12:31 charnier Exp $
 .\"
 .Dd May 1, 1995
 .Dt MOUNT_UMAP 8
 .Os BSD 4.4
 .Sh NAME
 .Nm mount_umap
 .Nd sample file system layer
 .Sh SYNOPSIS
 .Nm mount_umap
 .Op Fl o Ar options
 .Fl u Ar uid-mapfile
 .Fl g Ar gid-mapfile
 .Ar target
 .Ar mount-point
 .Sh DESCRIPTION
 The
 .Nm
 command is used to mount a sub-tree of an existing file system
 that uses a different set of uids and gids than the local system.
 Such a file system could be mounted from a remote site via NFS or
 it could be a file system on removable media brought from some
 foreign location that uses a different password file.
 .Pp
 The
 .Nm
 command uses a set of files provided by the user to make correspondences
 between uids and gids in the sub-tree's original environment and
 some other set of ids in the local environment.  For instance, user
 smith might have uid 1000 in the original environment, while having
 uid 2000 in the local environment.  The
 .Nm
 command allows the subtree from smith's original environment to be
 mapped in such a way that all files with owning uid 1000 look like
 they are actually owned by uid 2000.  
 .Pp
 The options are as follows:
 .Bl -tag -width indent
 .It Fl o
 Options are specified with a
 .Fl o
 flag followed by a comma separated string of options.
 See the
 .Xr mount 8
 man page for possible options and their meanings.
 .It Ar target 
 Should be the current location of the sub-tree in the
 local system's name space.  
 .It Ar mount-point 
 Should be a directory
 where the mapped subtree is to be placed.  
 .It Fl u Ar uid-mapfile 
 .It Fl g Ar gid-mapfile 
 Describe the mappings to be made between identifiers.
 Briefly, the format of these files is a count of the number of
 mappings on the first line, with each subsequent line containing
 a single mapping.  Each of these mappings consists of an id in
 the local environment and the corresponding id from the original environment,
 separated by white space.  
 .Ar Uid-mapfile 
 should contain all uid
 mappings, and 
 .Ar gid-mapfile 
 should contain all gid mappings.
 Any uids not mapped in 
 .Ar uid-mapfile 
 will be treated as user NOBODY,
 and any gids not mapped in 
 .Ar gid-mapfile 
 will be treated as group
 NULLGROUP.  At most 64 uids can be mapped for a given subtree, and
 at most 16 groups can be mapped by a given subtree.
 .El
 .Pp
 The mapfiles can be located anywhere in the file hierarchy, but they
 must be owned by root, and they must be writable only by root.  
 .Nm Mount_umap
 will refuse to map the sub-tree if the ownership or permissions on
 these files are improper.  It will also balk if the count of mappings
 in the first line of the map files is not correct.
 .Pp
 The layer created by the
 .Nm
 command is meant to serve as a simple example of file system layering.
 It is not meant for production use.  The implementation is not very
 sophisticated.
 .Sh SEE ALSO
 .Xr mount 8 ,
 .Xr mount_null 8
+.Sh BUGS
+
+THIS FILESYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK) 
+AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM.  USE AT YOUR
+OWN RISK.  BEWARE OF DOG.  SLIPPERY WHEN WET.
+
+This code also needs an owner in order to be less dangerous - serious
+hackers can apply by sending mail to hackers@freebsd.org and announcing
+their intent to take it over.
+
 .Sh HISTORY
 The
 .Nm
 utility first appeared in
 .Bx 4.4 .
Index: head/sbin/mount_union/mount_union.8
===================================================================
--- head/sbin/mount_union/mount_union.8	(revision 42002)
+++ head/sbin/mount_union/mount_union.8	(revision 42003)
@@ -1,202 +1,212 @@
 .\" Copyright (c) 1994
 .\" The Regents of the University of California.  All rights reserved.
 .\" 
 .\" This code is derived from software donated to Berkeley by
 .\" Jan-Simon Pendry.
 .\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that the following conditions
 .\" are met:
 .\" 1. Redistributions of source code must retain the above copyright
 .\"    notice, this list of conditions and the following disclaimer.
 .\" 2. Redistributions in binary form must reproduce the above copyright
 .\"    notice, this list of conditions and the following disclaimer in the
 .\"    documentation and/or other materials provided with the distribution.
 .\" 3. All advertising materials mentioning features or use of this software
 .\"    must display the following acknowledgement:
 .\"	This product includes software developed by the University of
 .\"	California, Berkeley and its contributors.
 .\" 4. Neither the name of the University nor the names of its contributors
 .\"    may be used to endorse or promote products derived from this software
 .\"    without specific prior written permission.
 .\"
 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
 .\"
 .\"	@(#)mount_union.8	8.6 (Berkeley) 3/27/94
-.\"	$Id$
+.\"	$Id: mount_union.8,v 1.4 1998/07/15 06:13:45 charnier Exp $
 .\"
 .Dd March 27, 1994
 .Dt MOUNT_UNION 8
 .Os BSD 4.4
 .Sh NAME
 .Nm mount_union
 .Nd mount union filesystems
 .Sh SYNOPSIS
 .Nm mount_union
 .Op Fl br
 .Op Fl o Ar options
 .Ar directory
 .Ar uniondir
 .Sh DESCRIPTION
 The
 .Nm
 command
 attaches
 .Ar directory
 above
 .Ar uniondir
 in such a way that the contents of both directory trees remain visible.
 By default,
 .Ar directory
 becomes the
 .Em upper
 layer and
 .Ar uniondir
 becomes the
 .Em lower
 layer.
 .Pp
 The options are as follows:
 .Bl -tag -width indent
 .It Fl b
 Invert the default position, so that
 .Ar directory
 becomes the lower layer and
 .Ar uniondir
 becomes the upper layer.
 However,
 .Ar uniondir
 remains the mount point.
 .It Fl o
 Options are specified with a
 .Fl o
 flag followed by a comma separated string of options.
 See the
 .Xr mount 8
 man page for possible options and their meanings.
 .It Fl r
 Hide the lower layer completely in the same way as mounting with
 .Xr mount_null 8 .
 .El
 .Pp
 To enforce filesystem security, the user mounting the filesystem
 must be superuser or else have write permission on the mounted-on
 directory.
 .Pp
 Filenames are looked up in the upper layer and then in the
 lower layer.
 If a directory is found in the lower layer, and there is no entry
 in the upper layer, then a
 .Em shadow
 directory will be created in the upper layer.
 It will be owned by the user who originally did the union mount,
 with mode
 .Dq rwxrwxrwx
 (0777) modified by the umask in effect at that time.
 .Pp
 If a file exists in the upper layer then there is no way to access
 a file with the same name in the lower layer.
 If necessary, a combination of loopback and union mounts can be made
 which will still allow the lower files to be accessed by a different
 pathname.
 .Pp
 Except in the case of a directory,
 access to an object is granted via the normal filesystem access checks.
 For directories, the current user must have access to both the upper
 and lower directories (should they both exist).
 .Pp
 Requests to create or modify objects in
 .Ar uniondir
 are passed to the upper layer with the exception of a few special cases.
 An attempt to open for writing a file which exists in the lower layer
 causes a copy of the
 .Em entire
 file to be made to the upper layer, and then for the upper layer copy
 to be opened.
 Similarly, an attempt to truncate a lower layer file to zero length
 causes an empty file to be created in the upper layer.
 Any other operation which would ultimately require modification to
 the lower layer fails with
 .Dv EROFS .
 .Pp
 The union filesystem manipulates the namespace, rather than
 individual filesystems.
 The union operation applies recursively down the directory tree
 now rooted at
 .Ar uniondir .
 Thus any filesystems which are mounted under
 .Ar uniondir
 will take part in the union operation.
 This differs from the
 .Em union
 option to
 .Xr mount 8
 which only applies the union operation to the mount point itself,
 and then only for lookups.
 .Sh EXAMPLES
 The commands
 .Bd -literal -offset indent
 mount -t cd9660 -o ro /dev/cd0a /usr/src
 mount -t union /var/obj /usr/src
 .Ed
 .Pp
 mount the CD-ROM drive
 .Pa /dev/cd0a
 on
 .Pa /usr/src
 and then attaches
 .Pa /var/obj
 on top.
 For most purposes the effect of this is to make the
 source tree appear writable
 even though it is stored on a CD-ROM.
 .Pp
 The command
 .Bd -literal -offset indent
 mount -t union -o -b /sys $HOME/sys
 .Ed
 .Pp
 attaches the system source tree below the
 .Pa sys
 directory in the user's home directory.
 This allows individual users to make private changes
 to the source, and build new kernels, without those
 changes becoming visible to other users.
 Note that the files in the lower layer remain
 accessible via
 .Pa /sys .
 .Sh SEE ALSO
 .Xr intro 2 ,
 .Xr mount 2 ,
 .Xr unmount 2 ,
 .Xr fstab 5 ,
 .Xr mount 8 ,
 .Xr mount_null 8
 .Sh BUGS
+
+THIS FILESYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK)
+AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM.  USE AT YOUR
+OWN RISK.  BEWARE OF DOG.  SLIPPERY WHEN WET.
+
+This code also needs an owner in order to be less dangerous - serious
+hackers can apply by sending mail to hackers@freebsd.org and announcing
+their intent to take it over.
+
 Without whiteout support from the filesystem backing the upper layer,
 there is no way that delete and rename operations on lower layer
 objects can be done.
 .Dv EROFS
 is returned for this kind of operations along with any others
 which would make modifications to the lower layer, such as
 .Xr chmod 1 .
 .Pp
 Running
 .Xr find 1
 over a union tree has the side-effect of creating
 a tree of shadow directories in the upper layer.
 .Sh HISTORY
 The
 .Nm
 command first appeared in
 .Bx 4.4 .
+It first worked in FreeBSD-(fill this in).
Index: head/sbin/mount_unionfs/mount_unionfs.8
===================================================================
--- head/sbin/mount_unionfs/mount_unionfs.8	(revision 42002)
+++ head/sbin/mount_unionfs/mount_unionfs.8	(revision 42003)
@@ -1,202 +1,212 @@
 .\" Copyright (c) 1994
 .\" The Regents of the University of California.  All rights reserved.
 .\" 
 .\" This code is derived from software donated to Berkeley by
 .\" Jan-Simon Pendry.
 .\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that the following conditions
 .\" are met:
 .\" 1. Redistributions of source code must retain the above copyright
 .\"    notice, this list of conditions and the following disclaimer.
 .\" 2. Redistributions in binary form must reproduce the above copyright
 .\"    notice, this list of conditions and the following disclaimer in the
 .\"    documentation and/or other materials provided with the distribution.
 .\" 3. All advertising materials mentioning features or use of this software
 .\"    must display the following acknowledgement:
 .\"	This product includes software developed by the University of
 .\"	California, Berkeley and its contributors.
 .\" 4. Neither the name of the University nor the names of its contributors
 .\"    may be used to endorse or promote products derived from this software
 .\"    without specific prior written permission.
 .\"
 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
 .\"
 .\"	@(#)mount_union.8	8.6 (Berkeley) 3/27/94
-.\"	$Id$
+.\"	$Id: mount_union.8,v 1.4 1998/07/15 06:13:45 charnier Exp $
 .\"
 .Dd March 27, 1994
 .Dt MOUNT_UNION 8
 .Os BSD 4.4
 .Sh NAME
 .Nm mount_union
 .Nd mount union filesystems
 .Sh SYNOPSIS
 .Nm mount_union
 .Op Fl br
 .Op Fl o Ar options
 .Ar directory
 .Ar uniondir
 .Sh DESCRIPTION
 The
 .Nm
 command
 attaches
 .Ar directory
 above
 .Ar uniondir
 in such a way that the contents of both directory trees remain visible.
 By default,
 .Ar directory
 becomes the
 .Em upper
 layer and
 .Ar uniondir
 becomes the
 .Em lower
 layer.
 .Pp
 The options are as follows:
 .Bl -tag -width indent
 .It Fl b
 Invert the default position, so that
 .Ar directory
 becomes the lower layer and
 .Ar uniondir
 becomes the upper layer.
 However,
 .Ar uniondir
 remains the mount point.
 .It Fl o
 Options are specified with a
 .Fl o
 flag followed by a comma separated string of options.
 See the
 .Xr mount 8
 man page for possible options and their meanings.
 .It Fl r
 Hide the lower layer completely in the same way as mounting with
 .Xr mount_null 8 .
 .El
 .Pp
 To enforce filesystem security, the user mounting the filesystem
 must be superuser or else have write permission on the mounted-on
 directory.
 .Pp
 Filenames are looked up in the upper layer and then in the
 lower layer.
 If a directory is found in the lower layer, and there is no entry
 in the upper layer, then a
 .Em shadow
 directory will be created in the upper layer.
 It will be owned by the user who originally did the union mount,
 with mode
 .Dq rwxrwxrwx
 (0777) modified by the umask in effect at that time.
 .Pp
 If a file exists in the upper layer then there is no way to access
 a file with the same name in the lower layer.
 If necessary, a combination of loopback and union mounts can be made
 which will still allow the lower files to be accessed by a different
 pathname.
 .Pp
 Except in the case of a directory,
 access to an object is granted via the normal filesystem access checks.
 For directories, the current user must have access to both the upper
 and lower directories (should they both exist).
 .Pp
 Requests to create or modify objects in
 .Ar uniondir
 are passed to the upper layer with the exception of a few special cases.
 An attempt to open for writing a file which exists in the lower layer
 causes a copy of the
 .Em entire
 file to be made to the upper layer, and then for the upper layer copy
 to be opened.
 Similarly, an attempt to truncate a lower layer file to zero length
 causes an empty file to be created in the upper layer.
 Any other operation which would ultimately require modification to
 the lower layer fails with
 .Dv EROFS .
 .Pp
 The union filesystem manipulates the namespace, rather than
 individual filesystems.
 The union operation applies recursively down the directory tree
 now rooted at
 .Ar uniondir .
 Thus any filesystems which are mounted under
 .Ar uniondir
 will take part in the union operation.
 This differs from the
 .Em union
 option to
 .Xr mount 8
 which only applies the union operation to the mount point itself,
 and then only for lookups.
 .Sh EXAMPLES
 The commands
 .Bd -literal -offset indent
 mount -t cd9660 -o ro /dev/cd0a /usr/src
 mount -t union /var/obj /usr/src
 .Ed
 .Pp
 mount the CD-ROM drive
 .Pa /dev/cd0a
 on
 .Pa /usr/src
 and then attaches
 .Pa /var/obj
 on top.
 For most purposes the effect of this is to make the
 source tree appear writable
 even though it is stored on a CD-ROM.
 .Pp
 The command
 .Bd -literal -offset indent
 mount -t union -o -b /sys $HOME/sys
 .Ed
 .Pp
 attaches the system source tree below the
 .Pa sys
 directory in the user's home directory.
 This allows individual users to make private changes
 to the source, and build new kernels, without those
 changes becoming visible to other users.
 Note that the files in the lower layer remain
 accessible via
 .Pa /sys .
 .Sh SEE ALSO
 .Xr intro 2 ,
 .Xr mount 2 ,
 .Xr unmount 2 ,
 .Xr fstab 5 ,
 .Xr mount 8 ,
 .Xr mount_null 8
 .Sh BUGS
+
+THIS FILESYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK)
+AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM.  USE AT YOUR
+OWN RISK.  BEWARE OF DOG.  SLIPPERY WHEN WET.
+
+This code also needs an owner in order to be less dangerous - serious
+hackers can apply by sending mail to hackers@freebsd.org and announcing
+their intent to take it over.
+
 Without whiteout support from the filesystem backing the upper layer,
 there is no way that delete and rename operations on lower layer
 objects can be done.
 .Dv EROFS
 is returned for this kind of operations along with any others
 which would make modifications to the lower layer, such as
 .Xr chmod 1 .
 .Pp
 Running
 .Xr find 1
 over a union tree has the side-effect of creating
 a tree of shadow directories in the upper layer.
 .Sh HISTORY
 The
 .Nm
 command first appeared in
 .Bx 4.4 .
+It first worked in FreeBSD-(fill this in).