On Wed, Nov 24, 2010 at 07:32:42PM +0200, Antti Kantee wrote: > > 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. > > You wrote that the whole path will no longer be available. As you > say yourself, it doesn't make sense for a file system to care about > the previous components, so don't be shocked that I took this to > mean the whole remaining path. If the whole remaining path is > available, portalfs should be fine.
I don't remember exactly what I wrote, but I'm pretty sure I explicitly said it was using the whole namei work buffer. Perhaps it could have been clearer. I don't see that exposing the whole remaining path is desirable either, but that's a different argument. > As for etfs, as you might be able to see from the code, it's only used > for root vnode lookups. I cannot think of a reason why we cannot define > the key to start with exactly one leading '/'. Some in-tree users may > not follow that rule now, but they should be quite trivial to locate > with grep. That should make it work properly with your finally-nonbroken > namei and also take care of all symlink/.. concerns you might have. I think it makes more sense for doregister to check for at least one leading '/' and remove the leading slashes before storing the key. Then the key will match the name passed by lookup; otherwise the leading slash won't be there and it won't match. (What I suggested last night is broken because it doesn't do this.) All users I can find pass an absolute path. -- David A. Holland dholl...@netbsd.org
