> Ok, but how would we impliment the functionality these bits currently give
> us? Namely they let the namei caller request the parent dir be returned
> unlocked or locked. ?? For CREATE lookups, we really don't want the parent
> dir unlocked between the lookup and the VOP_CREATE.

This is only relevant for intermediate directories.  The last
component lookup would obviously still see the `true' cn_nameiop and
the {LOCK,WANT}PARENT bits.

> I don't think portal will suffer too much with this, [...]

Yes, it will.  It munches multiple components at once, without
cooperating with namei(), and thus will (with the suggested change)
only ever see cn_nameiop==LOOKUP.  This will cause some operations to
be confused.  (Although it's probably possible to kluge around this
with some dummy VOP routines in the portal code, if they're not
already there.)

Really, there should be a separate interface that portal can use to
get the next path name component, but I don't think it's worth my time
to implement that just for an unused (or at least *barely* used) and
not terribly interesting example file system.