Hello, On Wed, Aug 6, 2008 at 7:53 PM, <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 06, 2008 at 02:17:34PM +0300, Sergiu Ivanov wrote: > > On Tue, Aug 5, 2008 at 4:16 AM, <[EMAIL PROTECTED]> wrote: > > > > The last step is to return the resulting translated node to the > > > client. Now I see two options for that: Either we do the lookup with > > > the remaining file name components on the newly started translator, > > > and return the resulting port to the client. Or we just return the > > > translator port, along with an appropriate retry notification... Not > > > sure which is more correct. > > > > As far as I can see from hurd/hurd_types.h, if we just return the > > translator port with some retry notification, the caller will anyway > > call us again to continue the lookup on the newly started translator. > > Yes, that is what should happen. That's why I wonder whether we should > do the further lookup in nsmux, or just let the client continue. > > I'm not sure about the exact implications. I think one case where there > would be a difference is when the client does a lookup with O_NOTRANS... > And I'm not sure which variant behaves more correcly in this case. This > needs some consideration. > It somehow seems to me that doing the further lookup in nsmux will be more appropriate... The situation about starting the translator could possibly be handled similarly to the way netfs_S_dir_lookup handles symlinks. In case a symlink is found, whose target is stated as a relative path, netfs_S_dir_lookup just prepends the already existent path with the path to the target of the symlink. It gives the client a retry notification only when the path to the target of the symlink is absolute. We should probably follow a similar idea, what do you think? > What makes me think so is that the retry notification does not seem to > > be FS_RETRY_MAGIC, because this one is mainly used when we encounter a > > symlink, whose target is stated using the absolute path (of course, we > > are not interested in ttys or file descriptors -- things also stated > > in hurd/hurd_types.h for FS_RETRY_MAGIC). FS_RETRY_REAUTH and > > FS_RETRY_NORMAL will both make the caller to invoke us again, > > FS_RETRY_REAUTH will just urge them to reauthenticate the retry port > > at first. > > Well, thanks for the explanation... I don't think it's really relevant > here, but I learned something new -- I might need it one day ;-) I hope it wasn't really annoying... I just showed what my thoughts are, just in case they are wrong :-) > As far as I understand, we will need to create *two* special nodes for > > each lookup with special syntax > [...] > > and the second being the node returned by netfs_attempt_lookup and > > containing the port to the first (proxy) node. > > No idea what you mean here :-( > > The second node is created after starting the translator: it mirrors the > target node provided by the translator. We give it to libnetfs as the > final result of the (magic) name lookup, and consequently a port to it > is returned to the client. > Yes, this was what I meant. Sorry for being messy again :-) > In this case, do you mean that for directories, both nodes will be > > needed? > > Yes, for directories we always need to mirror the node (both for > directory nodes resulting from a magic lookup, and for ordinary > directory nodes), as further lookups may take place, which we need to > proxy again. OK, it seems to me I'm getting the overall picture quite right. > > > So, it looks like with some trickery, it may be possible to > > > implement it with what libnetfs provides us; but in the long run, > > > for a proper solution to both mentioned issues, we will really have > > > to replace the dir_lookup() implementation by a custom one doing > > > exactly what we need... > > > > Yes, I do agree. Actually, I almost managed to understand the details > > of the standard implementation of netfs_S_dir_lookup. Now I'll try to > > implement the "icky" solution and see what we get. This should also > > show me the way how to customize netfs_S_dir_lookup for us. > > Well, I just wonder whether this won't turn out more tricky than doing > it manually right away -- recursion is always confusing :-) I very much hope it won't be too tricky... Usually, the recursion is quite friendly with me, I hope the tradition won't change in this case. One is simply to append or to prepend some magic token to the file name > of the node we need shadowed, e.g. "file,,\33" or ",,\33file" (whichever > is easier to parse). I will probably implement the first variant: I think such syntax will be easier to parse. The second variant (less ugly I think), is not to do the lookup on the > normal root port of the translator, but rather on some special port. Of > course, this means we need a way to create this special port... Which > probably defeats the object :-) > Probably, knowing how to create such special ports, we could immediately accept the custom port management technique :-) Thanks for some extra explanation! It helped me a lot! scolobb
