Hello, On Thu, Nov 20, 2008 at 10:27 PM, <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 19, 2008 at 10:33:51PM +0200, Sergiu Ivanov wrote: > > On Thu, Nov 13, 2008 at 7:01 AM, <[EMAIL PROTECTED]> 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... > Do you mean that we will have to proxy *each* control port? Regards, scolobb P.S. Sorry for the delay... I will try to make it so that my answers will be more prompt in the future.
