Running Processes

[brodeur235]

In order to run a 3rd party process (say a flat binary) what are the steps to take? I've never gotten to the point where I have to start thinking and coding for this, so I only have a rough idea but I want to make sure that I understand everything. Am I correct in saying that when I run a process and give it its own virtual address space, I don't have to keep the kernel mapped into the process's virtual memory because if a kernel function is needed (like malloc) by the application, then the process can reach it though a system call (or interrupt), in which the ISR will switch to the kernel's page directory? I feel like I am correct in saying that, but I want to be certain. Also, here is my draft of steps for running a 3rd party flat binary:

1.) Create a new virtual address space.
2.) Write the binary file to offset 0x00 of the new address space, allocating and mapping new pages as needed.
3.) Switch Page Directories

Actually, I see a problem with this, because if my kernel code at say address 0x100000 does these three things, and then switches page directories, the EIP is at 0x100000 when it needs to be at 0x0000. How can I fix this?

Any help is greatly appreciated,

Brodeur235

[piranha]

Create the address space, make sure theres a valid stack, have the kernel ID mapped in all address spaces, load the binary file to a known offset, prepare any other last minute things, and switch address spaces, stacks and jump to the start of the file.

-JL

[gerryg400]

Am I correct in saying that when I run a process and give it its own virtual address space, I don't have to keep the kernel mapped into the process's virtual memory because if a kernel function is needed (like malloc) by the application, then the process can reach it though a system call (or interrupt), in which the ISR will switch to the kernel's page directory?

No. You do need the kernel mapped into the address space of every process. (Actually it would be possible to just have part of the kernel mapped but this was discussed recently and there didn't seem to be any clear advantage to this approach.) Many O/S developers move their kernel to one end, typically the upper end, and allow processes to run at the lower end of the address space.

Oh and best not to use address 0. Leave that page unmapped and you can catch null pointers.

[NickJohnson]

Also, malloc shouldn't be a system call: the malloc in the kernel and the malloc used by a program have to be different, otherwise the program would have to be able to modify kernel data as well (unless you jumped through a lot of hoops), not to mention that it would be really slow to do a context switch for every allocation. What you do want as a system call is something for low level memory allocation, like sbrk or mmap or something similar.

[egos]

1. Create process structure (PS). Create address space and map the kernel to its upper part saving some space for kernel local data and 4 M for page table at the end.
2. Create starting thread structure (TS) with kernel stack and save basic process parameters (exename, workdir, paramstr and some flags) at the bottom of the stack.
3. Insert TS in "runqueue".

That's all.

[gerryg400]

In a microkernel I'm currently implementing this, designing as I go.

In the memory manager context
==========================
1. Open exe and read header info.
2. Create mm structures.
3. mmap exe image
4. Close exe
5. Kernel call to register mm structs as a new mem context and create thread in new context.

New thread running in the context of the new process
===========================
1. setup args, environment
2. jmp to entry point
3. Lots of expected page faults
4. Probably lots of bugs too.

I should add that the mm, even though it's a process, is mapped into every memory context. Same as kernel.

The big issue is implementing mmap. The rest is pretty easy. Deciding how to do mmap the 'proper' way in a microkernel, when the memory manager and filesystem are separate processes has been, for me, non-trivial.