On Thu, Nov 20, 2008 at 10:27 PM,
<olafBuddenhagen@gmx.net> wrote:
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...
In the current implementation it is impossible to do the handling in
nsmux without serious changes: when the filter calls
file_get_translator_cntl on its underlying node (which is currently
the port to the shadow node), nsmux responds by offering the filter
the port to the first translator in the real translator stack (as I
have already mentioned). Therefore, nsmux has no further control of
what the filter does. Taking into consideration that nsmux *always*
redirects file_get_translator_cntl to the real filesystem node, the
filter will never be able to list the dynamic translator stack it is
member of.
BTW, another important thing has just occurred to me: it seems to me
that we will have to implement a custom version of
fshelp_start_translator anyways. The problem is that the filter
normally requests its underlying node with O_NOTRANS. In this case,
file_start_translator will orphan the existing dynamic translator
stack on the given shadow node to make the filter be the bottommost
translator (IIRC, I told you about this problem by the end of August).
> > 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?...
Ah, I'm very sorry, nsmux *does* know what are the flags requested by
the translator being started... I must acknowledge that I've managed
to forget how nsmux works already :-(
However, this only solves around 20% the problem I'm trying to explain
to you. Let me try to dwell on this.
When nsmux is asked to do a magic lookup, it creates a shadow node. It
opens a port to the real file with the flags suggested by the client
and stores the port in the shadow node (this should be okay since
we've already discussed it). Then nsmux simply starts translators
specified in the magic file name upon the shadow node. It does not pay
attention to the flags requested by these translators.
Probably, nsmux could pay some heed to the flags requested by
translators being started in the following way: if the translator asks
for its underlying port with O_NOTRANS, nsmux will close the existing
port in the shadow node and reopen it with the flags required by the
translator at this time (instead of using the flags suggested by the
user). However, this will only work if the filter is started
immediately on the shadow node. If not, the first problem that happens
is the one about orphaning the dynamic translator stack. The second
problem is that we simply do *not* have the right to close the port
stored in the shadow node, because the bottommost translator in the
dynamic translator stack might receive unexpected garbage instead of
what it was designed for (this was most probably obvious to you from
the very beginning).
Now the question why nsmux has to know the flags requested by the
translator: consider the following two instructions:
cat file,,x
cat file,,-x
Both instructions will request the lookup of the file name with O_READ
flag. However, translator '-x' (a filter) will need the port to the
underlying node with O_NOTRANS, while 'x' will probably not. nsmux has
to know which of kind of port is required so that it could service the
requests normally.
> 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?
I very much hope that what I wrote in the previous section has offered
some useful details. Anyway, I'll try to put it a bit differently, so
that you can understand what embarrasses me.
If a filter is set on top of an existing dynamic translator stack, it
will ask for its underlying node with O_NOTRANS. At the same time,
there are normal translators in the translator stack, which expect
normal underlying ports. In other words, the translator sitting
immediately on the shadow node expects that it will read from the top
of the real translator stack (i.e. the dynamic translator stack is
conceptually residing on top the real translator stack). However, the
filter would expect that its file_get_translator_cntl be redirected to
the bottom of the real translator stack. It means that the shadow node
has to have the port to the top of the real translator stack (to
handle normal read requests) and the port to the untranslated version
of the underlying node (to handle requests by the filter).
> > > 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?
Yes, it is exactly how it works now.
If so, we probably need to proxy the control port as well, so nsmux
stays in control...