Date: Mon, 5 May 1997 16:34:40 -0400
	From: "Charles M. Hannum" <mycroft@MIT.EDU>
	To: tech-kern@NetBSD.ORG
	Subject: namei() protocol

	While reworking namei(), to simplify it after the recent POSIX-induced
	changes, I've found a few oddities:

	1) I can't fathom why the unlocking of the parent for the |LOCKPARENT
	case isn't done in the VOP_LOOKUP() caller.  This would eliminate a
	fair bit of redundant code, and avoid extra locks and unlocks.

The locking needs to be majorly overhauled. Having the upper layer
lock something and the lower layer unlock causes untold headaches
when trying to write middle layer filesystems. This should be
rationalized as part of fixing the locking.

	2) It would make more sense in the !ISLASTCN case for cnp->cn_flags to
	always be LOOKUP.  This is the required effect, and it would eliminate
	lots of redundant tests.

True. History takes us in strange directions.

	3) The whole cn_consume idea is moderately a pain in the arse.  It
	would make considerably more sense to me to have a callback for the
	file system to request the next component from the path name --
	thereby keeping all the code for dealing with separators, etc., in
	vfs_lookup.c, where it belongs.

Filesystems like portals may want to do their own interpretation of
path names, not have Unix semantics imposed on them. They really just
want to get the remainder of the string.

	Comments?  Anyone?  Bueller?  Kirk?  B-)