Technical Overview

Note: All italic words in this document are for extra credits or design specific, and are not required for your work.

Shell Commands

Combinational Keys

File System

The 391OS-36 File System has a total size of 8MB, and is divided into 4KB blocks of one boot block, several inodes, and data blocks.
Each boot block can track up to 62 inodes and one root directory, and each inode can track up to 1023 data blocks.
Thus, the limitations are up to 62 files of 4092KB size and 32 characters name length. Also, it does not support hierarchy and is read-only.

File System Abstraction

The 391OS-36 treat any files, device (RTC), and directory as files (see File System Directory). Each process has a dynamic File Descriptor (FD) that supports 8 open files.
Each FD entry tracks inode, position, flags, and an operation jump table, according to the file type. They are directly utilized by system calls (see System Calls).

File System Directory

Unless specifically listed above, programs usually don't accept any argument.
The contents of the file system were provided by the ECE 391 staff.

Context Switch/Assembly Linkages

Whenever an interruption, exception, or system call happened, the processor jumps to a specific assmebly linkage in the kernel space.
This procedure is sometimes called a "context switch". It is almost constantly happening with the scheduler enabled, as it is based on PIT interrupts.
Assembly linkages for interruption, exception, and system calls are different, but they all construct a hardware context on the kernel stack for restoring or usage.
They will also push/pass through arguments accordingly, and call the corresponding handlers (see Exception Handlers, Interrupt Handlers, and System Calls).
When returning back from the handler, assembly linkage will resume the hardware context saved before by IRET, then go back to the user space.
Or, halt/execute/process switch (see Execute/Halt and Switch) constructs a custom context, then it will jump to the next program's Prgram Counter (PC) and stack.
When going back to the user space, it will also dispatches any pending signal (see Signals, this is optional).
Now, you see the reason why context switch is expensive. The assembly linkage really needs to deal with a lot of stuff.

Exception/Exception Handlers

An exception happens when the user program (or even worse, kernel) did something wild, such as dividing by zero or accessing illegal pages.
Exceptions are synchronised. When an exception was generated, the processor jumps to the specific assembly linkage (see Assembly Linkages).
The exception assembly linkage pushes information and calls an unified exception handler.
Then, the handler will display the error message, debug information, and send a signal to the process if recoverable (see Signals, this is optional).
If no handler was installed, the default behavior is killing the offending program. The 391OS-36 is still alive.
If an exception is detected in kernel mode, the exception is non-recoverable and 391OS-36 will halt. You will need to reset the emulator.

Interrupt/Interrupt Handlers

An interrupt happens when a piece of hardware needs processor's attention, such as keyboard input, RTC, and PIC.
The 391OS-36 only contains essential drivers (see Supported Devices/Drivers). Interrupt lines (IRQs) from non-supported hardware are masked and ignored.
The IRQ lines are managed by two i8259 PICs just like any other mainstream IBM-compatible PC.
Interrupts are non-synchronised. When an interrupt is raised and got processor's attention, it jumps to the specific assembly linkage (see Assembly Linkages).
The interrupt assmebly linkage pushes information and calls an unified interrupt handler.
Then, the handler will call the corresponding driver, and the driver will handle the remaining work (again, see Supported Devices/Drivers).

Supported Devices/Drivers

The 391OS-36 has drivers for the standard keyboard, Programmable Interval Timer (PIT), Real-Time Clock (RTC), and terminal.
Keyboard, PIT, and RTC drivers are for real devices and contains handlers for their interrupts (see Interrupt/Interrupt Handlers).
The standard keyboard driver is responsible servicing key presses, and it also has support for the capital letter and combinational key handling.
The PIT and RTC all generates interrupts periodically.
The PIT and PIT driver are used to handle the scheduling and can be turned off (see Process Switching/Scheduler). It is only accessible by the 391OS-36 kernel.
The RTC is user-level accessible and it is "virtualized" for each process by the RTC driver, so they all have its own instance and frenquency.
Now, you see why the OS should use PIT for its task scheduling only. You don't want an user program to tamper with the scheduler frequency.
The terminal driver is for standard input and output and works as a bridge with each terminal, keyboard driver, and system calls.
There are three terminals (see Background Switching/Multiterminals). The input buffer for each terminal is limited to 128-characters.

Memory Addressing

The 391OS-36 has bypassed segmentation just like any mainstream modern operation systems. Only paging was used for the memory addressing.
The memory layout 391OS-36 used is fixed (see Physical Memory Layout and Virtual Memory Layout).

Physical Memory Layout

From low to high, the 391OS-36 has utilized the following 32MB physical memory:

• 4MB space with five 4KB space for the VRAM for the active terminal, 3 terminal backups, and an extra backup space (see Multiterminals)
• 4MB space for the kernel data (mostly Process Control Blocks (PCBs) and Terminal Info (TI) blocks) and kernel stack (see Process Control and Multiterminals)
• Six 4MB spaces for user applications' binary and stack (see Process Control)

Virtual Memory Layout

From low to high, the 391OS-36 has mapped the 4GB virtual memory space for each user program as following:

• 4MB managed by a superviser Page Table (PT), with five 4KB superviser pages, going through from the physical memory (see Physical Memory Layout)
• 4MB superviser jumbo page for the kernel, going through from the physical memory (see Physical Memory Layout)
• 4MB user page at address address 128MB, for the current running program only (see Process Control)
• 4MB managed by a user PT, with a 4KB vidmap page for the current active program, controlled by the vidmap (see System Calls and Multiterminals)

System Calls

Please note that the last two system calls are for extra credit; they are not required.
System calls are generated deliberately by user programs by generating a "soft interrupt," INT x80 on x86 systems.
When a system call was generated, the processor jumps to the system call assembly linkage (see Context Switch/Assembly Linkages).
Arguments for system calls are carried by %EAX, %EBX, %ECX, and %EDX registers.
The linkage will check if the arguments are valid, and then hand the job to the corresponding system call handler.

Process Control/Execute/Halt

The 391OS-36 supports up to 6 processes. In the kernel space, each process holds a kernel stack and a Process Control Block (PCB).
In the user space, each process holds their own user page (see Virtual Memory Layout) which contains the executable binary and a user stack.
By having their own kernel and user stacks, their hardware context and user stack data won't be overwritten by other programs.
Each PCB tracks the allocated process ID (PID), parent PID, terminal ID, kernel/user stacks, FD, signals and its handlers, etc.
The kernel manages the PCB allocation by a custom design called PCB pool.
This custom design allows the 391OS-36 to allocate and free the PCB resources freely.
When creating a new process (execute system call, see System Calls), the OS will first run a sanity check, extract the program name and argument.
Then, it will try to allocate a PCB, create the user page and copy the binary for the program, initialize the FD, and do the bookkeeping.
Finally, it will switch the kernel stack, build a custom hardware context with the new PC and user stack, and return to the linkage (see Assembly Linkages).
When halting a process (halt system call, see System Calls), the OS will first free the resources, which will tear down the user page, vidmap, and purge the FD.
Then, it will free the PCB, build the context with the parent process's information and return to the linkage. Current context will be discarded.

Process Switching/Scheduler

The 391OS-36 supports a round-robin scheduler based on the PIT interrupt (see Supported Devices/Drivers) that can be turned off.
While 6 processes are supported, only 3 of them are actually multitasking, and 1 at each time is running/scheduled.
The scheduler schedules 3 processes that is shown on each terminal, called active processes, so they are constantly switching, and thus can multitask.
But only one program is "actually" running, called running process, as there are only one processor supported.
The program switching begins in the kernel with the hardware context saved. It is pretty like a halt call, but it will preserve the current resources and context.
Then, it will switch the kernel page, kernel and stack, build the context with the next scheduled process's information and return to the linkage (see Assembly Linkages).
Turning off scheduler (CTRL+S) will disable the multitasking, but it mimics the environment for your work prior to CP5.
In that case, program switching only happens when the user is switching the terminal in the foreground, thus limiting the multitasking features.

Background Switching/Multiterminals

The 391OS-36 supports up to 3 terminals. Each terminal holds a custom design called terminal info (TI) block in the kernel.
Each TI block tracks the current active program, PCB pointer, coordinations, etc. Scheduler works on active programs, so it relys on these information.
When switching the running program in the background, a lot of extra works were done. One of the big challenge is to do a switch with separate VRAMs.
The background running process only prints to its terminal even it is not active. For 391OS-36, this is done by having 5 individual VRAM pages (see Physical Memory Layout).
When switching the active terminal, 391OS-36 will backup the current VRAM, copy the corresponding VRAM to the display, and remap the vidmap if necessary.