Hi, 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. > 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 ;-) > > We really want to avoid the unnecessary proxy node in *both* cases > > -- and the solution for both will probably be the same. (Note that > > this only applies to *files*; when looking up directories, the proxy > > node *is* needed, as further lookups might follow.) > > As far as I understand, we will need to create *two* special nodes for > each lookup with special syntax: With the hacky implementation, yes. > one being the proxy node, mirroring the real file, Yes, the shadow node as I called it. > 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. This is the node that is not really necessary (unless we are dealing with a directory), as no further lookups will happen on it, so the proxy has no need to interfere -- just like non-magic files don't really need to be mirrored after lookup. (In fact, once we started the translator, the further lookup is completely ordinary, and returns the result just like any other lookup. It should probably take the same code path.) > 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. > > 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 :-) BTW, I vaguely mentioned using special parameters to dir_lookup() to indicate that we want to obtain a shadow node instead of a normal lookup result. I actually have two specific ideas how it might be done. 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). 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 :-) -antrik-
