OSDev.org

I've put together a small document about how my task unit will work, I wonder if you have any tips etc?
I haven't checked it through, and it was written at 3 AM
Task Unit

* Physical Memory
o Setup segments
o Page Stack, allocate and free
* Virtual Memory
o Memory Regions
o Memory Objects
o Stack Allocation
* Scheduler
* Threads
* Processes



Process creation
In kernel space, no page dir change during operation.

1. Allocate physical memory one page for the page dir
2. Allocate virtual memory one page and map it to 1.
3. Map a fixed address to 1. (the mapper has to check whether the page table is loaded or not, if it isn't, it has to allocate a phys. page for a new one)
4. Allocate virtual memory for the process data
5. Set the process data (causing a page fault, mapping the virtual address to a new page)
6. Attach memory regions to the process (rules for the page fault handler on how to map data)
7. Insert the process into the global process list

Thread creation
In a process.

1. Change page dir to the kernel process' page dir
2. Allocate virtual memory for the thread datastructure
3. The thread base address should already be mapped in the current process, if it isn't, it has to map the whole code
4. Allocate virtual memory for the stack
5. Insert the thread into the process

Page Fault
In a process.

1. Check the address against all memory regions in the process
2. If there is no region overlapping that address, allocate a new page and map
3. If there is a region overlapping, map as said by that object, like "allocate new page" or "use this page" or if the page is in the object's mapping list, it will use that address to map to

Syscall (or any other interrupt/IRQ/exception)
In a process.

1. Program calls int 0x80
2. int handler 0x80 is at the same address in all processes (mapping rule, first 2 MiB mapped 1:1, read only)
3. int handler switches page dir to the kernel process page dir, no write to RAM needed. Gained writable memory.
4. Executes the interrupt as usual, it's now in kernel space.
5. Switch back to the process' page dir
6. iret

What the ****? Something's wrong with the subject. Possibly I typed garbage by mistake, sorry! :-[

ohboy wrote: What the ****? Something's wrong with the subject. Possibly I typed garbage by mistake, sorry! :-[

if you were a registered user, you could've modified the title. Candy did it for you

You can avoid a lot of those switching page dirs (probably the single slowest part of any context switch) if you map the kernel process globally. I shudder to think of switching page dirs on every syscall...

I'm not going to map the kernel as writable outside of the kernel space, so I will have to switch page dir if I want to write something. Or would it be better to change the attribute of the kernel pages to writable when needed, and then change the attribute back to read only?


Hmmm, did I post in the wrong forum too? ;D

If you mark a page as a kernel page (or, more accurately, don't mark it as a user page), is won't be writable except by supervisor processes. In fact, it won't be readable either...

If for some reason you did need to change attributes on the fly (you shouldn't need to in this case but there might be other cases when you want to), then yes, quite definately yes, you would be better off modifying the attributes and invalidating the individual pages rather than switching page dirs (which flushes you caches entirely [except of pages marked global on processors that support that]).

About the only reason you would want to mark a page readonly is to keep track of which pages have been written to for virtual memory management, or for "copy on write" forking...