On Fri, 3 Sep 1999, Charles M. Hannum wrote:

> > 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.

Ok. But then what are we gaining? The filesystems still need all the test
code, we just don't exercize it (which actually might let bugs linger
longer) :-) I thought the point was to help simplify things?

Perhaps a more-concrete explanation of your idea would help. Or maybe I
thought it was a more radical change than you'd proposed.

> > 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.)

The error routines are already there, and in -current they will do the
correct locking transitions. So what this change will mean is that renames
& deletes on a portal fs will die at the VOP_RENAME or VOP_DELETE stage
rather than earlier.

> 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.

:-) Charles, how would you react if I said something like that? :-) I
suspect you'd wail on me. :-) So why do you get to do what you wouldn't be
comfortable with others doing? :-) Especially as the fix isn't hard..

With this change, all that also has to happen is that lookup() will need
change what it does when cn_consume is > 0. Right now, it will set
ISLASTCN when it sees the whole name was consumed. With your change, we'd
just need to add a little more code to the "if (ndp->ni_next[0] == '\0')"
case (like do all the locking transitions).

Take care,

Bill