bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What shall the filter do to bottommost translators


From: Sergiu Ivanov
Subject: Re: What shall the filter do to bottommost translators
Date: Thu, 4 Dec 2008 18:49:12 +0200

Hello,

On Wed, Dec 3, 2008 at 3:40 AM, <olafBuddenhagen@gmx.net> wrote:
On Tue, Nov 25, 2008 at 07:49:18PM +0200, Sergiu Ivanov wrote:
> On Thu, Nov 20, 2008 at 10:27 PM, <olafBuddenhagen@gmx.net> wrote:
> Do you mean that we will have to proxy *each* control port?

Well, we need to make sure that the user doesn't get a real control
port -- so we need to proxy every time we return a control port to the
user.

By proxying control ports do you mean creating shadow nodes containing
ports to the real control ports? If I understand your idea correctly,
than the problem that bothers me is that each step in traversing the
translator stack will require additional switch to nsmux. However, I
do not really see another viable solution indeed.

I'm not sure what to do for normal lookups, though. There are two
possibilities: Either, when a user does a lookup on the virtual tree
exported by nsmux, nsmux could do the lookup on the real tree it mirrors
in one go, handling any necessary retries internally, and returning only
(a proxy of) the requested final node to the user.

The other possibility would be to actually forward any retries, so the
user has to handle them, just as if accessing the real tree directly. In
the latter case we would have to return control ports when forwarding
retries AIUI, which we would have to proxy too.

The first variant is simpler and more efficient, and I think it should
work well in standard situations. (libc abstracts the retries anyways.)
I wonder though whether in some special cases it might cause
anomalies...

You know, right now the nsmux does forward the retries and the user
sees the mirrored tree as a real filesystem. This is the standard
behaviour of netfs_S_dir_lookup and my modifications to this routine
did not touch this region. For an example of retry forwarding see, for
instance, http://github.com/scolobb/nsmux/tree/master/nsmux.c, line
1002.

It seems to me that we should anyway leave these things like they are,
especially as you don't seem to remark anomalies in special cases for
this approach :-)

BTW, could you give an example of an anomaly with the first approach?
I fail to strain my imagination sufficiently to see any...

> 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).

I think I see now where the confusion comes from: Every dynamic
translator gets its *own* shadow node to sit on. When dynamic
translators are stacked, each new one gets a shadow node mirroring the
underlying translator. Each dynamic translator is only seen by its own
clients, but never by an underlying dynamic translator, just as it is
never seen by an underlying static translator...

Yes, this is the main problem about traversing both static and dynamic
translator stacks.
 
Setting a dynamic
translator on top of another dynamic translator is not really different
from setting it on a static one.

You mean that setting a dynamic translator on a dynamic translator is
similar to setting a static translator on a static translator, do I
get it right?
 
> 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).

I don't quite remember what we said back then, but I wonder now: Why
would you open the mirrored node already at the time the shadow node is
created? Why not simply open it only the moment the shadow node is
opened, i.e. when the dynamic translator gets its underlying node?

Yes, indeed... I've just never thought of this possibility, although
it looks very nice and should work much better than the existing
implementation. I'll modify the code accordingly.
 
At that time we know what flags are really asked for. (Using the flags
from the client doing the magic lookup is just wrong -- although many
translators will open the underlying node with the same flags as the
translated node, other cases are perfectly valid too.)

Yes, I understand this issue... It seems to me that when I was
implementing shadow nodes I was too busy with shadowing itself to
notice this problem.
 
If we find it desirable after all to open the mirrored node immediately
for some reason, there is yet another possible variation I think: The
shadow node could get only an unauthenticated port to the mirrored node
on creation, and do the proper open only once it gets an actual client
request.

I'm not sure it is possible to make it like that, because when I tried
reopening ports to files using file_name_lookup* and dir_lookup using
different flags, I only got a copy of the same port; there seemed to
have been no actual reopening.
 
If there is anything we need to sort out urgently, because it blocks
further work, we probably should try to discuss it on IRC instead...

Since things start to get clearer now, I feel we could continue
discussing mainly on the ML, while I'll be implementing the necessary
changes. True, little have I coded recently, but now that we've
already figured out several important things, I think I have
sufficient base to come back to coding and moving things forwards.

Regards,
scolobb


reply via email to

[Prev in Thread] Current Thread [Next in Thread]