Re: mapping pages into new address spaces

Whats the advantage of "your" approach to sending a startup ipc and then
having an IPC with a receive window pointing to the complete address space
and thus being able to map any page wherever you want in the thread's
address space ?

-Bernhard

On 9/8/06, Joshua Haberman <[email protected]> wrote:
>
> > Hi Josh,
> >
> >> Here's the only solution I can see: start the new thread executing on
> >> a page that I *know* is unmapped, let it page fault on the first
> >> instruction, and then map the page on demand.  Is this the right way
> >> to do it?  Am I thinking about this in the right way?
> >
> > Yes, you're right (except that I don't understand why you want a page of
> > which you know that it's not mapped, in a newly created address space,
> > this should be the case for every (user) page, I think).
> > Once the new thread's state is set to active, it waits for a startup IPC
> > from its pager. This IPC contains IP and SP for the thread. Upon
> receiving
> > the IPC, the thread will start running at the specified IP and raise a
> > page fault. The pager can now reply with the needed page.
>
> Thanks for the replies -- I 'm glad to know I'm thinking about this right.
> My next question would be: why couldn't the kernel automatically accept
> any maps/grants that a thread receives from its pager, like it does with
> maps/grants that are sent in reply to page faults?  It seems a bit
> roundabout that a pager can't proactively map pages into a thread's
> address space without cooperation from the thread in question.
>
> It seems logical that the maps sent in response to page faults should
> behave like unsolicited maps from a thread's pager.
>
> Josh
>
>
>