Page directory for a new process

[Andy1988]

Hi all,
I'm currently trying to get my paging right and I'm standing in front of a wall right now.

When I spawn a new process later, I don't know how to set up a page directory for this process. All other OSs I've looked at just clone the kernel directory and use that clone as a first directory. I think this is too complicated and perhaps even wasted address space for the userspace programs and a security problem as well. Why do all userspace programs need to see the whole kernel stuff?
The other thing is, that the kernel directory might change during operation. Let's say you spawn a process just after the startup of the Kernel. The kernel does some heavy work and needs a few more frames for its heap or things like that. If I want that the userspace programs have the same kernel space in the upper GB (if I choose a 3/1 layout), I would need to keep this for all running directories in sync.

And what for? Just for an entry point for syscalls?
OK then I will put my syscall entrypoints at 0xFFFFE000 or something like that. Directly under the identity paging.
All this stuff does is switching to the kernel directory and jump then to the real syscall handler. Of course, this code needs to know the physical address of the kernel directory, but I could pass it to this trampoline code on startup-
One frame would be enough space for this realtively small piece of code.
After handling the syscall, I need to restore the old, and now perhaps modified, page directory again to the one the process used before.
I wouldn't need the whole upper GB.

Am I thinking right or is this totally wrong?
Thanks,
Andreas

[Combuster]

You can preallocate all kernel pagetables, and then map the same tables into all address spaces. That way, if you change the kernel space in one location, it will change everywhere else as well.

[Andy1988]

But what would I need this kernel stuff in userspace programs for? Sure, the syscalls and interrupts. But I can handle those with my little trampoline. But for what else?
I don't see any advantage in mapping the kernel stuff into userspace.

The things the kernel will handle via syscalls are only:

• Creation of a new pagedirectory for a new process with a fixed memory layout
• Mapping some physical address to some virtual address for a given page directory
• Allocation and freeing of a frame
• Spawning a new thread with an entry point and a page directory

All the other stuff like executable parsing, heaps, dynamic linking etc. are done in usermode by a system daemon.
So these calls are the only things I need for process management in the kernel. And these can be called with my "switch-to-kernel-directory-for-syscall-or-interrupt-handling-trampoline" at a fixed address in every userspace program's address space.

[frank]

Every time you switch page directories you incur a cost. The TLB must be flushed, then the new page directory located and the new addresses looked up. Its a time consuming task.

Applications cannot access kernel level data. The page table supervisor and user bits prevent that from happening.

Also if you change page directories, then addresses passed to the kernel are no longer valid and you would have to perform a lookup from the process page directory to even know where the address is.

So the question becomes do you want to do 2 page directory switches and then have to look up every address that the application sends the kernel or do you want cheap quick syscalls that can operate directly on the data of the process.

[Andy1988]

Oh... I dind't rhought of that.
I think I'll choose the cheap and fast syscalls

Thanks for your opinions.