In response to Ron's mail. Still can not reply from my mail server.

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?

In response to Bakul:

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


------------------------------------------
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M3c21a5ee93f83ca1650b537c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Reply via email to