Hi, On Tue Nov 23 2010 at 23:13:02 +0000, David Holland 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. 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. thanks, antti