Something's been bothering me about this (more than the hanging references
issue I mentioned earlier), and I think I've realized what it is:
null_lock used to be a pass-through---which would have much the same
effect as what you're suggesting.  But it was changed to the current (also
broken) state because of locking problems.

Consider this scenario (a variation of PR #777):

	/dev/sd0a on /     type ffs
	/dev/sd0e on /usr  type ffs
	/usr/src  on /a    type null
	/usr/src  on /c    type null

Touch a file Makefile (vnode A) in /a, with lower vnode B in /usr.
Then touch Makefile in /c (vnode C).  Now both A and C have the same
lower vnode.  This is fine, unless during the creation of C,
the vnode that getnewvnode() finds to make it is A.  Then you either
have:

	VOP_LOCK(A)  (in vgone: also locks B)
	VOP_LOCK(B)  (in null_node_create: panic, oops)
or
	VOP_LOCK(B)
	VOP_LOCK(A)  (also locks B, panic, oops)
or
	VOP_LOCK(A)
	(don't lock B ... bad idea)

None of which are really what you want.  A workaround might be to
implement the unified lock as a semaphore, and manipulate the semaphore
rather than panicking if it is "locking against myself"...but I'm not
sure that squashing the "locking against myself" diagnostic message is
such a good idea either.

Hope this was more coherent than my last message on this subject....

						Konrad Schroder
						perseant@hhhh.org