I still don't quite understand what you are getting at.

I was focusing up on the linux interface (ie openat(int fd, char *path, int flags, ...)) mapping of open fd to path. I see now as well that openat specifies that the argument must be a fd to a directory , so the issue of walk not being able to use files is not relevant, but you still have the other walk(5) limitations on the source fid.

If you are instead just wanting something that has the interface of: openat(char *dir, char *file, mode) for the purpose of avoiding just the cd than open as you say. Than I don't see why you couldn't usually just combine the open path yourself before handing it to the kernel.

If we put aside the interface and just focus on it's ability to act as a method to cache a walk for reuse with multiple subsequent open's let's say than I still think the design of 9p gets in the way. The difference between walking first then being able to reuse the fid for further walks, and just always walking from the root is however many path elements being walked internally to the 9p server. So I imagine that the overhead of doing this partial walk first, pinging to the 9p server and back to userspace would only be cheaper if you were opening quite a large amount of files. Is that what you were getting at Ron?

I don't think it's just an easy win at all. As mentioned already the act of getting whatever handle you choose from the 9p server and back to userspace as a method of reuse to prevent a couple of internal walks within the 9p server I think are not going to be favorable in performance.

Thanks,
moody