On Sat, 4 Sep 1999, Charles M. Hannum wrote:

> This discussion is going absolutely nowhere.

It's only "going absolutely nowhere" in that it's not going where you want
it to go.  :-) It's actually going somewhere. You've expressed a desire to
make VOP_LOOKUP routines more readable. We've discussed ways of doing
that. You (especially in this note) are expressing a desire to break
portalfs rather than fix it because you don't like it. I'm saying, "That's
bogus."  :-) 

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

You've said you _think_ what portal does is a kludge. :-) That doesn't
_make_ it a kludge. :-)

While it's nice that you don't want it to work, I object to you making
changes to how lookup calls VOP_LOOKUP with the main effect of breaking
it, without offering a replacement.

You're basically wanting to remove functionality (not change it) because
you disagree with it. That's not right. I doubt you'd really go along with
someone else doing such a thing, why are you doing it now?

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

This point is debaitable. It violates the idea that all the resolution
happens in VOP_LOOKUP routines to be sure (by defering the rest of it to
the OPEN routine), but that's its advantage - it's selling point. :-)

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

How is it stupid? You've said you don't like it, but that doesn't make it
stupid. :-) To me, it looks like Berkeley made an interface which can do
this (gobble up pathname components) as well as it does anything else. :-)

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

Charles, there's a difference between just ripping out something you don't
like, and "not maintaining" it. :-) We are not at a point where we HAVE to
break portal in order to get something else, so I don't see a NEED for
removing it (i.e. we can get readability without interfeering with
portal). In the past, given that situation (we wish something were
different, but it works now and isn't in the way of anything), the
tradition as I saw it was that the unhappy person would FIX whatever was
wrong rather than riping out something which worked. :-)

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

You are correct. I don't know if this will always be the case. I suspect
nothing else will, but I could be wrong. :-)

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

You missed the point there. I'm saying that the suggestion of hiding the
values of cn_nameiop and *PARENT from all but the last VOP_LOOKUP routine
make it difficult for the VOP_LOOKUP routine to decide that the component
it was asked to look up, which lookup didn't think was the last, was
infact the last.

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

I'm more arguing that if you don't like it, fix it rather than break it.
:-)

Take care,

Bill