On Tue, Aug 5, 2008 at 4:16 AM,
<olafBuddenhagen@gmx.net> wrote:
On Mon, Aug 04, 2008 at 12:54:19PM +0300, Sergiu Ivanov wrote:
> [...] To provide a response to requests of this type, nsmux has to
> create *virtual* nodes, mirroring the nodes in the real filesystem,
> and stack translators upon these virtual nodes.
[...]
> The main problem is how to create and handle such virtual nodes. It is
> not very difficult to create several libnetfs nodes, which will
> contain ports to the same real file and will thus be all mirroring the
> same file (this is what is required). However, when starting
> translators using fshelp_start_translator and file_set_translator, I
> have to feed some *ports* to these routines. Is it possible to create
> ports pointing to virtual libnetfs nodes? Or, maybe, there is a
> different way to implement such functionality?
As I understand it, when a lookup on a magic filename like "file,,x"
comes in, we first need to create a shadow node that mirrors the real
"file" node, forwarding most requests to it, but not attached to the
ordinary directory hierarchy: so other name lookups will never find this
node -- we use it only to start the "x" translator on it.
Yes, my understanding is the same.
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. 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.
A somewhat icky but maybe possible approach would be for us (nsmux) not
to create the shadow node directly, but rather to invoke dir_lookup()
again on ourselfs (recurse), with some special parameters, which
indicate that we want a shadow node to be created. A port to the shadow
node would be the result, and we could then set the translator on it.
The other problem is: once the translator is started, how to return the
port to the client. From what you told me, I understand that libnetfs's
implementation of dir_lookup() always wants a netfs node, and creates a
port to that -- that there is no way to directly return an arbitrary
node (perhaps along with a retry notification) to the client.
Of course it would be possible instead of returning the port directly,
to create another proxy node, that forwards to the translator; and give
that proxy node as the result to libnetfs. This wouldn't be optimal, but
AIUI, it's the same as what you presently do when looking up normal,
non-magic files through nsmux.
OK, I'll now try this idea and will tell you the result as soon as I
have something. Sounds quite feasible, and not very much to change in
my code.
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: one being the proxy node, mirroring
the real file, and the second being the node returned by
netfs_attempt_lookup and containing the port to the first (proxy)
node. Is this right?
In this case, do you mean that for directories, both nodes will be
needed? (It seems to me that it is so, I'm asking to check my
understanding).
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.