Re: physmem, simple containers

[Marcus Brinkmann]

On Tue, Jan 27, 2004 at 10:43:18AM +0100, Niels Möller wrote:
> I tried to read that code, but I couldn't make sense of it.

I am sorry about that.  Certainly there should be more explanation.

> First, I
> couldn't find anything in the L4 spec that says that you're allowed to
> send several fpages in the reply to a page fault. Ah, perhaps this is
> how it works: You send one fpage per page fault. But then physmem will
> page fault again and again on the sama address, so that wortel gets as
> many page fault request as it needs. Clever.

Right.  I forgot about that detail.

> I think I would have understood this more quickly if the comment
> 
>     /* We want to grant all the memory for the physmem binary image
>        with the first page fault, but we might have to send several
>        fpages.  So we first create a list of all fpages we need, then
>        we serve one after another, providing the one containing the
>        fault address last.  */
> 
> mentioned that there will be several page faults for the same address.
> I read it as "one page fault, multiple fpages", and then the code
> seemed to do something quite different.

I agree the wording "with the first page fault" is misleading.

> > > , and it seems even more necessary if wortel
> > > is to make mmap-related calls to physmem.
> > 
> > No way!
> 
> Hmm. I thought the point of WORTEL_MSG_GET_CAP_REPLY was to return
> container capabilities to wortel, which wortel could then use for mmap
> (what else could you use a container for?). I must have miserably
> misunderstood that part of the wortel-physmem interaction.

Wortel passes the container to the newly created tasks, like the task
server.  Then the startup code in the new task creates mappings.

All memory that wortel needs is simply not passed to physmem in the first
place.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/