Re: Filter design for nsmux

[Sergiu Ivanov]

Hello,

On Fri, Apr 24, 2009 at 06:46:40AM +0200, olafBuddenhagen@gmx.net wrote:
> On Thu, Apr 23, 2009 at 04:29:40PM +0300, Sergiu Ivanov wrote:
> > <olafBuddenhagen@gmx.net> writes:
> > > On Sun, Mar 22, 2009 at 09:37:55PM +0200, Sergiu Ivanov wrote:
> > >> <olafBuddenhagen@gmx.net> writes:
> > >> > On Sun, Feb 22, 2009 at 08:56:50PM +0200, Sergiu Ivanov wrote:
> 
> > > So the idea is to have only the first instance do a full translator
> > > startup. It would do as much common initialization as possible; and
> > > then some mystical lightweight mechanism would be used for launching
> > > the other instances from there -- something that is much cheaper
> > > than normal process creation...
> > 
> > Hm... This sounds very-very interesting... However, I'd think that
> > such functionality could not be implemented without doing some
> > extensions to GNU/Mach, what do you think?
> 
> Not necessarily, no. I think Mach task creation is actually rather
> cheap. It's loading shared libraries, setting up various standard ports
> etc. that makes POSIX process startup expensive. It seems quite possible
> to optimize that without changing the Mach task/thread concept.
> 
> But I really don't know for sure -- this is all *extremely* vague ideas
> still. There is a reason I called it "mystical" :-)

I see... All this makes the idea very-very interesting :-) I'm reading
through your blog now, and I'm waiting for another post on *this*
topic (if you haven't already made one :-) )

> > >> Another question now (probably, I'm repeating myself already...):
> > >> how problematic is that the filter should know about nsmux? After
> > >> all, the filter's main real use case is running in a dynamic
> > >> translator stack. I understand that having the filter capable of
> > >> running as a normal translator would be a nice option, but I fail
> > >> to find the absence of this feature a very bad thing.
> > >
> > > Actually, this doesn't prevent the filter from running outside
> > > nsmux. It only means that the filter must be aware when it is
> > > running on nsmux, and handle it specially. That's not really a big
> > > deal technically -- but it's not very elegant, as it means things
> > > are not as orthogonal as I'd like them to be. nsmux is not fully
> > > transparent -- certain kinds of other programs need to handle it
> > > specially to work correctly...
> > 
> > I see... So, do you think we should still try to pursue orthogonality,
> > or shall we stop at this design idea for now? (I mean adding a special
> > RPC for the filter to obtain the node without shadows).
> 
> I don't really think we have any other choice... I at least can't think
> of any different approach.

I see... This seems clear.

> > OK. To sum up: do I understand it right that we shall add the RPC for
> > retrieving the underlying node of a translator to fs.defs, and a
> > create a new special interface expressly for the RPC for getting the
> > non-shadowed version of a node?
> 
> Yes, that is what we *should* do. But as I have an irrational reluctance
> of touching the existing interfaces, I'm not yet really confident that
> this is really the ideal approach in practice. That's why I said that
> this decision is my major concern with creating the new RPCs.

Could you please point out what could be the problems about modifying
an existing interface? Anyways, we are just *adding* things :-)

> > > No. We can't obtain the untranslated version of a node we have. All
> > > we can do is reopen the same *file name* -- which is a totally
> > > different thing! The filter does *not* have the file name of the
> > > node it filters.
> > 
> > Yes, this is true. I wonder now, why one can reopen a node with
> > different O_READ/O_WRITE bits, but cannot do this with the O_NOTRANS
> > flag...
> 
> This is actually quite obvious: reopening with different read/write
> flags etc. just means obtaining a different handle for the same object.
> O_NOTRANS on the other hand would require actually obtaining a different
> object, served by a different translator!

I see... Never thought of this matter in this perspective. Thanks for
explanation :-)
 
> However, now that you mention it, I seriously wonder whether this isn't
> really what we should do. As reopening with O_NOTRANS has no meaning so
> far, I guess it wouldn't break anything if we overloaded it with the
> "obtain underlying node" operation. And it actually makes some sense
> semantically -- it wouldn't be too ugly a hack I think...

I'm afraid I must bring bad news: when I try to reopen the port to an
nsmux node with dir_lookup, control does not get inside
netfs_S_dir_lookup... So, we will probably have to add the new RPC
anyway...

> > > The hack with O_NOTRANS on translator startup to obtain the
> > > untranslated node, only works with special handling in nsmux. You
> > > can't do that when running the filter on a normal file system,
> > > implementing only the standard interfaces. It requires a new
> > > operation -- even if this new operation is hacked as a special case
> > > in an existing RPC.
> > 
> > I see... So, it is natural to implement this feature as a special RPC,
> > without hacking any existing one, do I understand everything right?
> 
> Well, see above: I just realized that actually we might get away without
> a new RPC :-) So no, that's not what I meant by natural.

And what if we cannot use the O_NOTRANS hack?.. (as it seems to turn
out now...)
 
> I think this is missing context now: The original point was that
> traversing top to bottom is not more natural than bottom to top, as both
> require a new operation. (For obtaining the node directly below the
> current for traversing top to bottom, or for obtaining the node at the
> very bottom of the stack for traversing bottom to top.)
 
> > >> >> I thought we could merge the functionality in a single node
> > >> >> because it seemed to me that another node would mean another
> > >> >> context switch...
> [...]
> > > What you wanted to do here is avoiding a context switch, by
> > > transparently stuffing the functionality of two logically distinct
> > > translators in a single process. This is *exactly* what translator
> > > stacking is about...
> > 
> > Yes, this was exactly what I meant to achieve by merging shadow and
> > proxy nodes together. Nevertheless, I am rather surprised to hear that
> > translator stacking is about stuffing the functionality of two
> > distinct translators in a single process... Actually, what I
> > understand under ``translator stacking'' is *joining* several
> > translator processes, not *merging* them.
> 
> Erm... I'm rather confused. What exactly do you mean by "joining"
> translators and by "merging" translators? It never occured to me that
> these terms could be used to describe different things...

By ``joining'' I mean connecting the process by means of some RPC
mechanism; exactly what happens in a translator stack: each translator
runs as a *separate* process, but they are functioning jointly due to
this connection.

By ``merging'' I mean what I understood from your words: putting
several translators in a *single* process. That is, the difference
between ``merging'' and ``joining'' in my interpretation is in the
physical location (and degree of separation) of translators.

> Maybe I should try to restate it: The idea of translator stacking is
> that we have two distinct translators, but at runtime, transparently,
> the functionality of one is migrated over to the other, so they run in a
> single process.

Hm... I'm afraid I understood the matter differently... Aren't
translators separate processes?.. (nsmux deals with them as with
separate processes...)

Regards,
scolobb

P.S. Sorry if I am consistent in this mail... I've written it in a
hurry...