search

LouisJenkinsCS / MoltarOS

A minimal implementation of an Operating System implemented in (mostly) C and (sparse) Assembly
BSD 3-Clause "New" or "Revised" License
4 stars 2 forks source link

Process Management and Scheduling and Creating a New Stack for Tasks #3

Open LouisJenkinsCS opened 7 years ago

LouisJenkinsCS commented 7 years ago

Right now, Tasks must clone their stack from their parent... for pretty much no reason besides the complexity. Get this out of the way now. As well, processes can easily be extended on the current model by creating a new page directory on an identity mapped block of virtual memory. Which also brings up the need to create a zone allocator, which I started but stopped earlier. After this, the need to move stacks is moot, since each new process will just have the same virtual addresses but different physical frames that they are mapped to.

Afterwards, I can definitely see having a process for handling keyboard, one for VGA, one for HDD, etc. I would be able to abstract the entire model to processes, like UNIX. However, I'd need IPC and some shared memory synchronization, so that'll be a lot of fun.

LouisJenkinsCS commented 7 years ago

Plan

Things that need to be done to implement process management...

  1. Reserve a 4MB page that is identity mapped (needed because CR3 register requires physical address)
  2. Create a zone allocator that will keep track of all identity mapped 4KB chunks of various pages in the aforementioned reserved 4MB page. This zone allocator should ALSO be able to keep track of 4KB chunks from arbitrary memory as well for smaller executable stacks. (Doing the math, for 4MB stacks per thread/process, I would only have enough 64 of either. Having 4KB stacks means 65,536. No brainer.)
  3. Use a 4KB chunk to create the page directory for the new process. This page directory needs to ensure that it links (I.E: Reuses the same physical frame) for the kernel specific areas of memory (meaning 0xC0000000, 0xC0400000, and 0x00400000 which will be original reserved mmap'd devices, the kernel heap, and the reserved identity mapped page respectively). The kernel's new stack should be moved to an arbitrary location of memory, so when we need to copy the other in-use physical frames, we also copy the stack by value.
  4. Both linked and copied physical frames should map to the SAME virtual address, this is so that I do not need to do any tricky and dodgy stack-content redirection.
  5. When I task switch, I need to swap out the actual page directories, this way the address spaces can be adequately changed out.

Notes

Its possible that given that the reserved area for allocation page directories are, we can only have 1024 potential processes in memory at once. However, hopefully by the time this becomes an issue I'll have implemented a swap space for it.

Following this model, we can see that now it will be easy for each process to have it's own threads. The threads themselves will just allocate their own 4KB stack from the process specific zone. The POSIX standard dictates that forking while having multiple threads result in undefined behavior if using shared-memory because the other threads (besides the one that called fork) no longer exist. Hence, I'll handle forking as a simple copy of address space, with no regard to threads.