Hello, On Tue, Aug 5, 2008 at 4:16 AM, <[EMAIL PROTECTED]> 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. scolobb
