Hello, On Thu, Nov 13, 2008 at 7:01 AM, <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 01, 2008 at 10:57:37PM +0200, Sergiu Ivanov wrote: > > > When nsmux is asked to do a magic lookup, it creates a new mirror node > > and sets the requested translator(s) on it. > > Well, let's be exact: It creates an new *shadow* node, i.e. a node that > is visible only as the underlying node of the dynamic translator set on > it, but never appears in the global namespace. > Sorry :-) I guess I'll never have the patience to fully comply with the terminology... > > Note that the only sensible use for a filter is placing it at the > > bottom of the dynamic translator stack. > > I don't think this is entirely true. We haven't talked much about > applying dynamic translators recursively yet, and I haven't thought > about it very much either, so I'm not sure about the exact implications > here. However, having a recursive translator on a parent directory, and > then disabling it on some subdirectory or file, is a perfectly desirable > use case -- and while I don't know how this would work exactly, it might > very well be that it would involve setting the filter on top of existing > dynamic translators... > > But even in the non-recursive case, such a situation is quite probable: > All kinds of scripts might want to invoke filters, without caring what > is already present on the node. Hm, I totally forgot about recursive propagation of translators while thinking about this issue... It seems to me that in this case the filter will have to be smart enough to look through the static translator stack at first and then through the dynamic translator stack. What do you think? > When a filter is launched, it requests the underlying node with > > O_NOTRANS flag. > > Right, that is the initial step. As a result, nsmux returns a proxy node > of the untranslated underlying node. (A "normal" proxy node -- not a > shadow node -- this time...) > Here the problem lies: nsmux does *not* know the flags with which the translator requests the underlying node. Right now when a shadow node is created, nsmux stores two ports to the real filesystem in it -- one opened with flags requested by the client requesting the magic lookup and the other one opened with O_NOTRANS. Ugly, in my opinion. The only solution I can see at the moment is creating a custom version of file_start_translator_long so that nsmux knows what flags the translator being started requests, not only the flags specified by the client requesting the magic lookup. > > It then invokes file_get_translator_cntl on this port. Upon receiving > > this RPC, nsmux returns the control port to the bottommost translator > > in the *static* translator on the real filesystem node. > > More precisely, a *proxy* of the control port: nsmux needs to be remain > in control, so further magic lookups are possible. > > > Since a filter always sits at the bottom of the dynamic translator > > stack, such behaviour is quite reasonable > > I must be missing something here: Why does it matter whether it's at the > bottom of the dynamic translator stack or not?... > For me this fact served as an argument to the fact that the filter will never have to filter any dynamic translator stack. However, in the view of the things I mentioned WRT recursive translator propagation, this is no longer a valid argument. > > Having the control port to the bottommost translator in the *static* > > translator stack, the filter starts traversing the stack upwards until > > it finds a translator whose name matches the supplied target name. > > Right. > > > It then returns the port to the translator located just *beneath* this > > matching translator. > > Well, the port to a proxy of the translator to be exact :-) > What do you mean by saying: "a proxy of the translator"? > However, when the client will try to read from this port, their > > request will be processed in nsmux and the information will be read > > from the top of the static translator stack, > > Sorry, why? The node that the filter got here, and then passed on to the > client, was a proxy of the *untranslated* underlying node! > > So I must admit that I fail to see a problem here... Am I missing > something? > I guess we should first sort out the ideas I've mentioned in this letter before we pass on to discussing this question. Regards, scolobb