Scheduler

1 files changed, 8 insertions, 1 deletions

diff --git a/Scheduler-explained.txt b/Scheduler-explained.txt
index efaf2c0..f67fca6 100644
--- a/Scheduler-explained.txt
+++ b/Scheduler-explained.txt
@@ -1,3 +1,4 @@
+## Scheduler
 An operating system has to manage user processes. Our system only has one process right now, but usual actions, such as context saving or context restoring, are implemented anyways. The following few paragraphs contain information on how process management looks like in operating systems in general.
 
 Process might return control to the system by executing the svc (eariler called swi) instruction. System would then perform some action on behalf of the process and either return from the supervisor call exception or attempt to schedule another process to run, in which case context of the old process would need to be saved for later and context of the new process would need to be restored.
@@ -18,13 +19,19 @@ In our project, process management is implemented in src/arm/PL1/kernel/schedule
 
 A "queue" contains data of the only process (variables PL0_regs[], PL0_sp, PL0_lr and PL0_PSR).
 
+### Functions
 Function setup_scheduler_structures is supposed to be called before scheduler is used in any way.
+
 Function schedule_new() creates and runs a new process.
-Function schedule_wait_for_output() causes the current process to have it's context saved and get blocked waiting for UART to send data. It is called from supervisor call handler. Function schedule_wait_for_input() is simillar, but process waits for UART to receive data.
+
+Function schedule_wait_for_output() causes the current process to have it's context saved and get blocked waiting for UART to send data. It is called from supervisor call handler. Function schedule_wait_for_input() is similar, but process waits for UART to receive data.
+
 Function schedule() attempts to select a process (currently the only one) and run it. If process cannot be run, schedule() waits for interrupt, that could unblock the process. The interrupt handler would not return in this case, but rather call schedule() again.
+
 Function scheduler_try_output() is supposed to be called by IRQ handler when UART is ready to transmit more data. It can cause a process to get unblocked. scheduler_try_input() is simillar, but relates to receiving data.
 
 The following are assured in our design:
+
 1. When processor is in user mode, interrupts are enabled.
 2. When processor is in system mode, interrupts are disabled, except when explicitly waiting for the interrupt when process is blocked.
 3. When a process is waiting for input/output, the corresponding IRQ is unmasked. Otherwise, that IRQ is masked.