[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Filter design for nsmux
Re: Filter design for nsmux
Tue, 19 May 2009 08:07:37 +0300
On Fri, May 15, 2009 at 9:13 PM, <olafBuddenhagen@gmx.net> wrote:
> On Fri, May 01, 2009 at 10:45:15PM +0300, Sergiu Ivanov wrote:
>> On Fri, Apr 24, 2009 at 06:46:40AM +0200, olafBuddenhagen@gmx.net
>> > On Thu, Apr 23, 2009 at 04:29:40PM +0300, Sergiu Ivanov wrote:
>> > > <olafBuddenhagen@gmx.net> writes:
>> > > > 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...
>> 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 :-) )
> I don't think there will be one. That's not really what this blog was
> meant for. I fear I already drifted into technical details in some
> articles more than I should...
Ah... I see... OK, then I'll be waiting for a post on the ML :-)
>> Could you please point out what could be the problems about modifying
>> an existing interface?
> [...] The real problem is
> organisational: changing an existing interface is a very fundamental
> decision, and the current maintainer situation regarding the Hurd means
> that there is nobody to approve such fundamental changes... It would be
> very hard ever to merge it into the mainline :-(
Hm... Does this mean that we are somehow discouraged to do any changes
to things that already exist in the Hurd?.. I'm afraid I fail to see
in which way Zheng's changes are less fundamental than the changes we
are inclined to do to an existing interface :-)
>> > 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
> I have a hard time believing this... I'm sure there must be something
> wrong with you test setup.
There's something wrong with my attention... I dumbly forgot that when
nsmux is asked to lookup a regular file (i.e. not a dir), nsmux gives
off a port to the *real* filesystem :-( I've just tried a lookup of a
directory node and things went fine, which means that we can safely
forget about adding new RPC and focus on overloading the O_NOTRANS
functionality, just as you suggested.
>> So, we will probably have to add the new RPC anyway...
> I'm not a fan of the "can't get it to work, let's try something
> different" approach. If it's indeed impossible to do it like that, I at
> least want to know *why*.
Bugs in attention, you know...
>> > 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.
> Yeah, that's what "traditional" translator stacking is: One translator
> talks to another.
> However, I wouldn't call that "joining". They are technically and
> logically independent entities, even if they might work together (on the
> user's request) to achieve certain functionality...
It feels as if the word ``join'' has a different hue to me :-) But
that's no problem, since I can now understand what *you* meant :-)
>> 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.
> Right, that's the purpose of the "translator stacking framework":
> Optimize translator stacks by "merging" (in your terminology) several
> translators in a single process. Logically they are still independent
> entities, but technically they are combined in some way.
A fundamental (probably) question: when you say ``translator stacking
framework'', do you refer to the existing mechanism of stacking
translators or to some future possibility? (the one about fast
translator startup or something like this, probably?)
> (Actually, there are still two processes -- but the functionality of one
> of them is migrated over to the other, so one becomes an empty shell,
> and the other does all the work.)
Hm... Sounds great :-) How do we achieve that? ;-)