Crossing mount points is a good wrinkle.
I'd missed that. Good point, Bill.

The reasons why I can't retain all hints necessary
for VOP_REMOVE(c) at VOP_LOOKUP(c) time are well
beyond the scope of this mail list. Suffice to
say it's akin to trying to retain hints for NFS.
It's impractical to have the NFS client retain
directory search hints for the server.

Would changing the way VOP_LOOKUP/dirop works be
a good thing? Should we do it?

I suppose it's a real potayto potahto thing.
I wouldn't even try to make a case for changing VOPs.
By the same token, I wouldn't try to make a case for
changing the way REMOVE is done over NFS. The
two are different paradigms. Neither can
claim to be better than the other. I tend to
favor the NFS paradigm because it's what I
know best. Guess that makes me a potahto :)

This thread started with the comment that VOP_LOOKUP()
with all its modifiers is unnatural for something
Yamamoto Takashi is doing. Folks (potaytos) chimed
in that it was perfectly natural. Yamamoto offered
an alternative design for discussion that would be
more natural for what he's doing. I simply wanted
to weigh in that I also found it awkward and that
the alternative has merit. But, I don't think we
should make changes. It's healthy for the potaytos
and potahtos to see things the other way from
time to time.

FWIW.

Cheers,
	-gww

> -----Original Message-----
> From: tech-kern-owner@NetBSD.org [mailto:tech-kern-owner@NetBSD.org]On
> Behalf Of Bill Studenmund
> Sent: Tuesday, March 23, 2004 4:59 PM
> To: Gordon Waidhofer
> Cc: YAMAMOTO Takashi; wrstuden@NetBSD.org; jdolecek@NetBSD.org;
> martin@duskware.de; tech-kern@NetBSD.org
> Subject: Re: ufs-ism in lookup(9)
> 
> 
> On Tue, Mar 23, 2004 at 07:58:48AM -0800, Gordon Waidhofer wrote:
> > > 
> > > IMHO, eventually, VOP_REMOVE shouldn't take the vnode to be removed at all.
> > > the directory vnode and the name is enough and each filesystem code can
> > > deal with their issues.
> > 
> > I agree with this.
> 
> I'm not so sure. While I can see how it'd be nice for the file systems, 
> there are other issues that make this not work so well.
> 
> > rm a/b/c is currently done VOP_LOOKUP(a), VOP_LOOKUP(b),
> > VOP_LOOKUP(c) with lots of modifiers, VOP_REMOVE(c). It should
> > be VOP_LOOKUP(a), VOP_LOOKUP(b), VOP_REMOVE(c). The actual directory
> > search and cache management should be done below VOP_REMOVE() itself.
> 
> Ok, for the sake of arguement, how do you propose we arrange to skip the 
> lookup for "c" in general? Right now, the only code that knows about 
> tearing path names into components is in namei(9), so how do we get the 
> VOP_LOOKUP(c) to be skipped? Also, the right thing needs to happen for "rm 
> foo" too.
> 
> > File system implementers are compelled to squirrel away hints
> > at VOP_LOOKUP(c) time to keep things efficient. VOP_LOOKUP(c),
> > VOP_REMOVE(c) may seem natural (for UFS), but is awkward
> > in other situations (NFS, my work on OTFS). In the end, I
> > had to accept that remove(c) would result in two directory
> > searches: one for VOP_LOOKUP(c) and one for VOP_REMOVE(c).
> 
> Why did you need another lookup in VOP_REMOVE()? You could have done 
> everything in VOP_LOOKUP(c) and cached it. We also have VOP_ABORTOP() 
> which would let you clean up your cached info.
> 
> Also, think about the case where / and /usr are separate file systems. 
> Right now sys_unlink() handles that case. If we push the vnode lookup into 
> the file system, they each have to try and get the vnode, to see if 
> there's a file system mounted above it.
> 
> > Such a change will probably never be made. I wouldn't
> > even advocate such. But it is a VOP design goink worth note.
> 
> Well, if it's a good change, we should do it. :-)
> 
> Take care,
> 
> Bill
>