Just checking...

[rspencer]

Hi, so I am about to start what I believe is the final hurdle in making a simple kernel: loading and executing an application, and I just want to check a few things before I head right in and get lost in page faults (hopefully not )

Firstly, am I correct in thinking that, according to the kernel, memory (possibly) looks a bit like this:

Code: Select all

+--------------------------------------------------------------+
|Kernel code|Kernel heap|Alloced to A|Alloced to B|Alloced to A|
+--------------------------------------------------------------+

where A and B are applications. But according to some application A, it looks like this (thanks to paging):

Code: Select all

+-------------------------------------------------------------+
|Kernel code|Kernel heap|Alloced to A|Alloced to A|Blank      |
+-------------------------------------------------------------+

Then is it correct that to start running an application I should:
1 ) Fork to make a new thread
2 ) Allocate some memory for and load my application, possibly putting .text and .data sections where the file format asks.
3 ) Allocate a new, blank stack
4 ) Push onto the new stack the addr of a kill_thread() function
5 ) Push onto the new stack the arguments sent to the application
6 ) Switch to new stack
7 ) Enter user mode
8 ) jmp to the beginning of the process code.

Many thanks,

[AJ]

Hi,

Assuming that you are using hardware process isolation (and from your diagrams, what looks like a lower half kernel, then linear memory will look much like your second diagram for the application and for your kernel. The difference is that the kernel can switch between task spaces by switching CR3.

Your first diagram, for exampl, implies that Process A is liked to a different address to Process B. Most likely, you want them all linked to the same virtual address.

Cheers,
Adam

[Edit: Oh - and as for that "final hurdle" bit. It depends how far you want to take it. The next step will be providing a system API for your user mode applications]

[rspencer]

Your first diagram, for exampl, implies that Process A is liked to a different address to Process B. Most likely, you want them all linked to the same virtual address.

Ah, maybe I should also say that from B's perspective memory looks like this:

Code: Select all

+-------------------------------------------------------------+
|Kernel code|Kernel heap|Alloced to B|Blank                   |
+-------------------------------------------------------------+

But that would mean a different page directory for each process... Is this a good practice?

Edit: Oh - and as for that "final hurdle" bit. It depends how far you want to take it. The next step will be providing a system API for your user mode applications

I know, I know I just don't want to think too far ahead ... One task at a time. Otherwise I would have ended up designing the GUI before paging!

[AJ]

Hi,

But that would mean a different page directory for each process... Is this a good practice?

That's standard practice with hardware process isolation. It means that Process A cannot interfere with Process B's memory. In addition to this, the kernel areas you show on your diagrams will be in supervisor pages, so the user mode tasks cannot actually "see" them.

Basically (assumption again - 32 bit, no PAE), your page directory for each task contains exactly the same entries for the kernel (meaning that you create page tables (but not necessarily PTE's) for the whole of kernel space. This means that as you create and remove kernel-level PTE's, each process sees the same kernel address space. Your "user area" will be different in each PD. To switch task spaces, reload CR3.

Of course, on 64 bit or PAE, this is a bit different. If you want software isolation (managed code / bytecode), then this is very different.

Cheers,
Adam

[rspencer]

Thanks! Lets go code!