parsepath op

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

Because we have at least one FS that may not want paths being looked
up to be split on '/', namely rump etfs, and arguably the most
important simplification to VOP_LOOKUP is to make it handle one path
component at a time, we need a way for a FS to decide how much of a
path it wants to digest at once.

After thinking about this for a while I think the best approach is to
add a parsepath op, which given a pathname returns the length of the
string to consume.

There are two major questions about how this should work: one is
whether it should be a vnode or fs operation, and the other is how
onionfs should handle it.

I'm currently leaning towards a vnode op and applying the restriction
that it must select either the first component (up to the first slash)
or the whole remaining path string. This makes it reasonably possible
for onionfs to deal with cases where its layers don't agree on the
length to consume. (Although I think for the time being I'll just let
such cases fail.) Making it a fs op instead would require that onionfs
always call the operation again on both layers inside lookup; this
would add a certain amount of overhead.

Unfortunately, because etfs requires that the choice depend on the
particular pathname given, I don't think this can be done just by
setting flags somewhere. However, I can't think of a credible use case
that requires more flexibility than selecting either one component or
the whole path. (This includes a moderately crazy research project I
proposed years ago.) So I don't think a more general operation is
needed.

I don't have a candidate patch yet (or even a draft patch); adding new
vops requires touching an unreasonably large number of places. But
this seems like the kind of thing where posting early is a good idea...

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