On Thu, Nov 13, 2008 at 7:01 AM,
<olafBuddenhagen@gmx.net> 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