Hello! On Sun Sep 8, there was a discussion on #hurd between antrik and me (scolobb), in which several important points were spoken out. I will try to enumerate these points below:
* The nodes with translator stacks on them should not go away until there are clients using these translator stacks. * No specific node caching should be done in nsmux, but rather the nodes should be created on demand and destroyed, when they are not used already (the destruction should happen precisely when the port to the topmost translator in the stack will receive a no_senders notification) * In the current implementation of nsmux, the shadow nodes are maintained by nsmux, therefore all the translator stacks should be shut down *before* nsmux goes away when requested, lest the translators should become orphaned. * A netfs node cannot go away when all references to it are gone, but there are senders using the port to the topmost translator in the translator stack sitting on this node. To make this possible, there should be a way to keep this node alive, probably in a more explicit fashion, than a node cache might have done it. * Every shadow node should hold the information about the real filesystem node it is mirroring. This is currently done by storing a port to this real node in each shadow node. * A shadow node may go away in case the real filesystem node it is mirroring goes away. * In the current implementation of nsmux the filter will ask for the underlying port to be opened with O_NOTRANS. However, the port the filter will get will point to a netfs node, not to the real filesystem node. It means, that when the filter will try to trace the translator stack, it will find itself only (in the case of 'file,,-u', for instance). It will not see the static translator stack on the real filesystem. (This problem is, probably, only specific to the current implementation of nsmux). * A better implementation of nsmux should launch a separate process (the shadowing translator), which would do the shadowing. The translators requested by the users of nsmux should sit on the port provided by the shadow translator, instead of a port pointing to a netfs node maintained by nsmux. In this case nsmux can go away without killing shadow translators, thus allowing for the clients, still using their ports to dynamic translator stacks, to continue working even after nsmux has gone away. * A shadow translator is a normal translator. The only difference is that is should probably not be seen as a member of the translator stack. However, as far as I can tell, this functionality could probably be achieved using a standard translator library (like libnetfs) and some tricks, so we can roughly say that a shadow translator is indeed quite a normal one. * Starting a shadow translator might require a non-standard approach, i.e. a custom version of fshelp_start_translator_long might be needed. * The shadow translator will be sitting on a clone of the root node of nsmux. nsmux will clone its root node for each new shadow translator process. * The shadow translator will receive the path to the node it should mirror as a command line argument. The path will be relative to the root node of nsmux, which would be the underlying node of the shadow translator. Thus the shadow translator will have just sufficient information to open the node it should mirror. * Attention must be paid to race conditions which might occur at the startup of a shadow translator. Most probably, nsmux will not open the requested file on its own. Instead, it will blindly launch the shadow translator and stay awake to pass the possible errors returned by the translator to the user. * There will be no difference between shadow translators mirroring regular files and translators mirroring directory nodes. * The shadow translator will proxy name lookups on the shadowed node to the underlying filesystem, just as it will proxy most other requests. * The shadow translator will be sitting on a node provided by nsmux, therefore part of its functionality will be stripped off if nsmux goes away: mainly this will concern lookups. However, most translators won't do lookups after being started, so the disappearance of nsmux should not really affect the functioning of dynamic translator stacks. Right now the following questions have occurred to me: * Why does a shadow translator have to be invisible on the translator stack? I don't think a filter will ever want to ignore a shadow translator, since it is pretty useless. And nobody, save for a filter, will possibly ever require the underlying node opened in O_NOTRANS fashion. * Suppose nsmux is asked for 'file,,x'. It will set the shadow translator on a copy of its root node and will tell the shadow translator to mirror the file 'file'. Then it will set translator 'x' on top of the shadow translator. Do I understand everything right? Regards, scolobb
