What shall the filter do to bottommost translators

[Sergiu Ivanov]

Hello!

I've just encountered a problem in developing the filter for static
translator stacks for nsmux. Let me explain the current architecture
so that my question becomes clear.

When nsmux is asked to do a magic lookup, it creates a new mirror node
and sets the requested translator(s) on it. When somebody tries to
read from this mirror node, nsmux reads from the real filesystem and
passes the information to the client. nsmux does not know whether it
launches a normal translator or a filter.

Note that the only sensible use for a filter is placing it at the
bottom of the dynamic translator stack. That is, we further will
consider only possibilities like 'file,,<filter>,...'.

When a filter is launched, it requests the underlying node with
O_NOTRANS flag. 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. Since a filter always sits at the bottom of the
dynamic translator stack, such behaviour is quite reasonable
(otherwise the filter would receive a control port to itself, which is
useless).

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. It
then returns the port to the translator located just *beneath* this
matching translator.

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. 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, as it
happens for all other translators.

A solution that looks quite good to me is to make nsmux return the
port to the untranslated node in the real filesystem upon receiving
file_get_translator_cntl RPC instead of returning the control port to
the bottommost translator in the static translator stack. Anyway, only
the filter translator will ever invoke this RPC on its underlying
node, and it will only need it to trace the static translator
stack. Indeed, the results of this call will not really correspond to
its name, but the caller can always obtain the control port to the
bottommost translator in the static translator stack by invoking
file_get_translator_cntl once more. A more conceptually good solution
is to create a new RPC, but I'm not sure whether it's worth it, since
we have a not-quite-often-used RPC which we can replace by a kind of
extended version.

What do you think?

Best wishes,
scolobb