Re: What shall the filter do to bottommost translators

[olafBuddenhagen]

Hi,

On Wed, Nov 19, 2008 at 10:33:51PM +0200, Sergiu Ivanov wrote:
> 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:

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

I would say this should actually be handled transparently to the filter.
This might mean quite complicated handling in nsmux, though...

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

Why not, and why does it matter?...

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

Why does it do that?...

I must admit that I'm quite confused here. Perhaps because I don't know
the details of how this mechanism works. Could you elaborate on it a bit
please?

> > > 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.
> >
> > Well, the port to a proxy of the translator to be exact :-)
> 
> What do you mean by saying: "a proxy of the translator"?

I'm not quite sure myself, to be honest... I don't know how the
traversing works exactly. You said something about a control port. Do I
get it right, that the get_translator call returns a control port to the
translator, which in turn is used to retrieve the translator's root
node?

If so, we probably need to proxy the control port as well, so nsmux
stays in control...

-antrik-