Re: loader question.

[Bas Wijnen]

Hi,

On Tue, Aug 17, 2004 at 06:23:15PM -0400, Rian Hunter wrote:
> After reading the porting guide from Marcus I have some immediate
> questions:
> 
> Since all tasks will be self-paged (i don't know if this has changed)

I don't think this has changed, but if you have good reasons for it, it may
:-)

> given physical memory addresses, how will program loading be handled?

One problem of program loading is that tasks may not do thread creation
operations on other tasks (the task server will not allow that.)  To be able
to start a new task, the task server must provide a "start new task"
operation.  That would create a thread, create an address space around it,
set the pager to the calling thread and start it (it doesn't actually start
running until it receives its initial message from the pager.)

Then the calling program should send the new task the startup ipc, giving it a
stack pointer and instruction pointer.  It will immediatly pagefault at its
ip, because it doesn't have any memory yet.  The pager can map some memory
with startup code to it, which takes care of setting up its own pager and
jumping to the code that should be started.

Note that this is just my idea, not any "official hurd plan."

> My issues are with the conflicts between the memory already mapped
> virtually for the program, with physical memory pages requested from the
> memory server maybe having the same address (although this is unlikely).

I don't understand what you mean here.  If two pages have the same physical
address, then they are the same page.  In L4, if a page is mapped at the same
virtual address as an already mapped page, the old one is automatically
unmapped.  However, all this is not relevant here: the requesting task does
not get any new pages in the process.

> Another issue is if the pages used by the executing text (+data) will
> count as pages own by the task or not, if it is the task's
> responsibility to handle it's own code pages.

The physmem server owns all memory in the system.  At request, it will map
pages to other tasks.  After that, physmem still owns them (and can claim them
back using unmap), but the other task owns them as well.  Every task owns all
of its memory (code and data) in this way.  There should probably be a
meta-pager, which pages memory for pagers, but it is not needed as long as we
don't use swap (because there will be no unrequested unmappings, and therefore
the pager shouldn't have any pagefaults.)

> Also with the self-paging: Assuming a POSIX program is run, completely
> oblivious of the advantages it is offered with self-paging, how would a
> malloc be handled. Would there be a seperate simple pager thread,
> specific for each thread, started in the task to handle the malloc
> request and to initially request memory from the physical memory server.
> If so, this thread would have to be transparently started and loaded for
> each POSIX program, adding the issue of notifying the loader which
> programs are POSIX or not.

I think libc should handle POSIX things.  It will just start a pager for the
new task when it fork()s.  The program shouldn't notice anything about it.

> If POSIX programs are run not with local pager threads, but with a
> global pager task(server) for the POSIX personality, then some UNIX-like
> VM would have to be implemented in that server. That server of course,
> would use the real physical memory server. Also this would simplify
> things as malloc (which would only be called in POSIX programs) would
> always know to use this server, instead of some arbitrary local thread.

Libc can easily handle this, by using a variable to hold the id of the
"arbitrary local thread."  Note that this server is just some arbitrary
non-local thread anyway, so that variable would still be needed.

Thanks,
Bas

-- 
I encourage sending me encrypted e-mail.
Please send the central message of e-mails as plain text in the message body,
   not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
for more information, see http://129.125.47.90/e-mail.html

pgpz1uXcedtvJ.pgp
Description: PGP signature