This discussion is going absolutely nowhere.

> If you're concerned about portal_lookup() seeing the wrong cn_nameiop, why
> propose changing our lookup(), given that the former is a consequence of
> the latter? :-)

Because what it does is a kluge, and I *want* to make it not work any
more.  I'm pretty sure I made this clear.

> Also, why do we need another interface to get additional components? We
> have cn_consume which lets the VOP_LOOKUP() decide how much to eat.

Let's see:

a) it's a backdoor interface that explicitly violates the file system
   semantics, and

b) it causes the interface to work in a stupid fashion.

There is no point in maintaining such a hack.  If you want a backdoor
interface, write one that actually cooperates with the file system.

> Especially as the one customer of this ability (portal) is going to
> consume the whole remaining path?

And how do you know that will always be the case?

> The real problem is that your suggestion doesn't leave room for the
> VOP_LOOKUP routine to cleanly be able to decide that this was infact the
> last component of the pathname.

Excuse me?  If they really need to know, they can still look at
ISLASTCN.  There are, however, *exceptionally* few cases where this is
necessary.

I can't believe that anyone is actually arguing in favor of this
kluge.