l4-hurd
[Top][All Lists]
Advanced

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

Re: Getting Started with Hurd-L4


From: Marcus Brinkmann
Subject: Re: Getting Started with Hurd-L4
Date: Tue, 26 Oct 2004 02:08:30 +0200
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Mon, 25 Oct 2004 23:33:01 +0100,
Sam Mason <address@hidden> wrote:
> >(This way the server can be sure that the client
> >will not remove the container while it is filling it or corrupting it
> >before it takes a copy into its cache and allows the client to know
> >that it can get its resources back eventually.)
> 
> I would assume that a different API would be used for things like
> emulating "mmap" then?  How would this work for two mutually
> untrusting tasks here?

mmap() only will create an entry in the database of the pager that
indicates which file should be mapped at which place.  Only when a
page fault arises is an actual mapping established.  At that point
(and not earlier), the container stuff will happen.  The memory in the
container is then mapped from the physmem task with a generic
map-something-from-a-container interface.
 
> Is it possible to have several requests using the same "container"
> being processed (I would guess it would have to be the same task,
> because of the locking) at the same time?  I'm guessing (and hoping)
> the answer will be; that's up to the API that's layered on top of
> this, lower-level, abstraction.

You mean using the same container in several parallel RPCs?  I think
that way lies madness.  However, we could indicate for each operation
which window in the container to use for that operation... not sure if
this will always work well, but there are things you theoretically
could do here, I think.  Not sure it is really worth it.  I'd just use
one container per mapped file, I think (if I were to reuse them).
 
> I've just noticed that I'm coming with a lot of preconceived ideas
> about how I think this thing should be implemented.  Please tell me to
> be quiet if it's getting a bit over the top and I'll try and do a
> little more listening!

So far your ideas have been completely in line with ours, as far as I
understood them.  The danger of being preconceived is on our side,
given that we are pondering all this stuff over a time of two years
now, and have at some point stopped exploring radically different
strategies on many issues.  It doesn't hurt to get reminded of
different ways to tackle the issues, and the reasons we decided
against them (assuming we considered them at all).  So, keep it up.

Thanks,
Marcus





reply via email to

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