On Wed, Aug 6, 2008 at 7:53 PM,
<olafBuddenhagen@gmx.net> wrote:
On Wed, Aug 06, 2008 at 02:17:34PM +0300, Sergiu Ivanov wrote:
> On Tue, Aug 5, 2008 at 4:16 AM, <
olafBuddenhagen@gmx.net> 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 :-)