Subject: Re: Possible VOP_LOOKUP() interface change
To: Bill Studenmund <firstname.lastname@example.org>
From: Charles M. Hannum <email@example.com>
Date: 09/04/1999 21:19:32
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.
a) it's a backdoor interface that explicitly violates the file system
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
I can't believe that anyone is actually arguing in favor of this