Re: VOP_PARSEPATH?

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sun, Apr 17, 2016 at 03:20:33AM +0000, David Holland wrote:
 > So:
 >    - Can anyone think of a magic alternative way to handle these cases
 > without making an extra vop call? (And without complexifying
 > VOP_LOOKUP as much of the point of the whole exercise is to simplify
 > it...)

I'm going to assume not -- this was/is more like "I wish there were a
better way to do this".

 >    - Is there a reasonable different way to do what etfs is doing? It
 > has long seemed to me that rump ought to attach etfs nodes to their
 > individual containing directories rather than hacking shortcuts into
 > the naming system, but pooka got quite annoyed with me for even
 > suggesting it. (this was some time back now though)

Even if it's the right thing, I don't think this is likely to happen.

 >    - There are reasonable other ways to do what hfs is doing, e.g.
 > using ":rsrc" instead of "/rsrc" as the magic suffix to access the
 > resource fork. (Since : isn't legal in hfs names, this doesn't cause
 > naming conflicts. However, it changes user-facing functionality.)

This doesn't work because "foo/rsrc" on an hfs volume appears to
netbsd as "foo:rsrc". Also, Linux seems to use the same hack so we
should probably keep it.

 >    - Is it reasonable to add a flag (to either vnodes or the whole fs)
 > saying that VOP_PARSEPATH is needed, and only call it in those cases,
 > or is the complexity overhead of this (which I'm not thrilled about)
 > worse than the cost of another vop call (which is not just an indirect
 > function call but a layer of marshalling goop too)?

Opinions please.

A patchset that doesn't (yet) include such flags is here:

   http://www.netbsd.org/~dholland/tmp/parsepath/

and is currently in testing.

Note that I'm not sure the hfs changes are satisfactory and I don't
have any way to test them... review would be helpful.

-- 
David A. Holland
dholland%netbsd.org@localhost