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 dholl...@netbsd.org