VOP_PARSEPATH?

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

The vnode interface has long had a misfeature where inside VOP_LOOKUP
the filesystem can choose to consume more of the pathname than the
next component.

We have two users of this functionality: hfs, which uses it to allow
addressing resource forks, and rump, which uses it as a shortcut hack
to allow lookups of etfs paths to happen directly from the root. Both
of these cases as it turns out always consume the entire remaining
path, or at least do so in cases that aren't errors; but this doesn't
seem to help much.

The issue is: the next step in cleaning up namei and lookup is to make
namei capable of stopping before the last directory component. (Then
directory ops can do this and pass the last component straight to the
filesystem, which allows vast simplification of a number of currently
awful things.) This is a bit of a problem if VOP_LOOKUP can
arbitrarily decide that it's going to consume the rest of the path
without warning.

I think the way to deal with this is to add a VOP_PARSEPATH that
decides how much of the pathname string to consume, and then in namei
call that first so it'll still be possible to decide whether to stop.
The default parsepath would be the current logic that finds the first
'/'.

There are two problems: (1) adding another vop is a pain and I don't
want to do it if there's a reasonable alternative; and (2) I don't
really want to add another indirect vop call to every component lookup
just to allow for a small number of fringe cases.

Note that it doesn't work to observe that neither use case of this
misfeature is intended to support directory ops: for sanity a full
namei really needs to be a call to the stopping-early namei plus an
additional lookup. Also in the long run some lookup-only operations
will need/want to use the stopping-early namei explicitly for various
reasons.

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

(On the plus side having VOP_PARSEPATH would allow supporting any
hypothetical file systems someone might want to write that use
different path syntax.)

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