[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to provide proxy nodes

From: olafBuddenhagen
Subject: Re: How to provide proxy nodes
Date: Wed, 6 Aug 2008 18:53:17 +0200
User-agent: Mutt/1.5.18 (2008-05-17)


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.

> 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 :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]