Re: misuse of pathnames in rump (and portalfs?)

[Antti Kantee <pooka%cs.hut.fi@localhost>]

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