Hello, On Fri, May 15, 2009 at 9:13 PM, <olafbuddenha...@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, olafbuddenha...@gmx.net >> wrote: >> > On Thu, Apr 23, 2009 at 04:29:40PM +0300, Sergiu Ivanov wrote: >> > > <olafbuddenha...@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 >> netfs_S_dir_lookup... > > 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? ;-) Regards, scolobb
