Re: What shall the filter do to bottommost translators

[olafBuddenhagen]

Hi,

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.

> When somebody tries to read from this mirror node, nsmux reads from
> the real filesystem and passes the information to the client.

Right. Note that "client" in this case is normally only the translator
sitting on the shadow node. (Though in some scenarios clients of the
dynamic translator might get to see the shadow node as well... But let's
not complicate matters here :-) )

> nsmux does not know whether it launches a normal translator or a
> filter.

Indeed.

> 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.

OTOH, the fact that dynamic translators might be part of the filtered
stack, probably doesn't give us any additional insight in the issue at
hand, so I guess we can ignore the possibility here :-)

> 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...)

> 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?...

> (otherwise the filter would receive a control port to itself, which is
> useless).

It can never receive a port to itself: Remember that it sits on a shadow
node, which is simply not visible from the underlying node, translated
or not!

> 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 :-)

> Now the problem: suppose the translator that is to be filtered out is
> exactly the bottommost translator in the static translator stack.
> Following its standard strategy, the filter will return the port to
> the translator which is exactly beneath the very first matching
> translator. It will therefore return the port to its underlying node.

Indeed. (Except that it is in fact again a *proxy* of the underlying
node...)

> 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?

-antrik-