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

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 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.

"Eww."  The rest of the path to the right, that makes some sense
(though I'd prefer the filesystem handle it using vnodes for the
intermediate directories).  The rest of the path to the left, that
makes no sense.  Not to me.

> 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.

If so, I believe portalfs is critically broken and should be pulled
until it's fixed.

> (1) does anyone think that a correct namei design should provide the
> namei pathname scratch space to the FS for its inspection during
> lookup?

Not me.

> (2) does anyone think that a correct namei design should provide a
> correct canonicalized full pathname for its inspection during lookup?

Not me.

> (Note that this is free -- it would require splicing a getcwd into
> every namei call.)

_Not_ free, I assume you mean?

> (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?

Well...I don't like it; such "temporary" hacks have a way of becoming
rather less temporary than they should.  Personally I think the right
fix is to fix the interface and, if this breaks rump, and let it stay
broken until someone fixes it to not abuse the interface.

But I'm hardly the arbiter of such things.

> (4) vermilion.

Dead jackal brown.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B