I have run into a problem fixing namei. First, background: VOP_LOOKUP is the per-fs vnode operation that takes a directory and a name and returns the vnode associated with that name. This currently has a horrific interface and the chief goal of the namei cleanup is to rectify this so all it needs is a vnode and a string.
However, I discovered today that rumpfs's VOP_LOOKUP implementation relies on being able to access not just the name to be looked up, but also the rest of the pathname namei is working on, specifically including the parts that have already been translated. (This is currently possible by misusing struct componentname; the patch I've been working on makes that impossible.) It appears that the rump code is assuming that the string it gets is an absolute or canonical path so it can use it as a lookup key. This is wrong -- the string it's using might be absolute but might not, and depends on the specific pathname given to namei and which symlinks have been traversed. This, as far as I can tell, makes the rump code wrong. Furthermore, it is just plain gross for the behavior of VOP_LOOKUP in some directory to depend on how one got to that directory. As a matter of design, the working path should not be available to VOP_LOOKUP and VOP_LOOKUP should not attempt to make use of it. When I asked pooka for clarification, I got back an assertion that portalfs depends on this behavior so I should rethink the namei design to support it. However, as far as I can tell, this is not true: there is only one unexpected/problematic use of the pathname buffer in question anywhere in the system, in rumpfs.c. Furthermore, even if it were true, I think it would be highly undesirable. So: (1) does anyone think that a correct namei design should provide the namei pathname scratch space to the FS for its inspection during lookup? (2) does anyone think that a correct namei design should provide a correct canonicalized full pathname for its inspection during lookup? (Note that this is free -- it would require splicing a getcwd into every namei call.) (3) Does anyone object if, as a way forward, I add an extra argument const char *partialpath to VOP_LOOKUP to provide the string that rump wants, until rump is fixed, and then revert it? (4) vermilion. -- David A. Holland dholl...@netbsd.org