Hello, and welcome to THEYNIX! This is a brief guide to our implementation of
the Yalnix operating system.

------------------------------
                       FILES
------------------------------
CVar.c
    Implementation of helper methods for condition variable initiation and reclamation.

CVar.h
    Struct and function prototypes for condition variables.

Kernel.c
    Kernel startup function implementations (i.e. SetKernelData() and KernelStart()). Also
    contains code for kernel heap management (SetKernelBrk()) and context switching. Some helper
    function implementations found here are used both at kernel startup, in creating the init
    and idle processes, and forking.

Kernel.h
    Global variables for the kernel and prototypes for helper methods used throughout kernel.

List.c
    Linked list implementation of a list API used throughout the operating system for
    purposes such as process queues and synchronization data structure book keeping.

List.h
    Structs and function prototypes for the list API.

LoadProgram.c
    Adapted from template.c. Implementation of a function for initializing a process's user
    address space with the program text and arguments.

LoadProgram.h
    Function prototype for LoadProgram().

Lock.c
    Implemenation of helper methods for lock initiation and reclamation.

Lock.h
    Struct and function prototypes for locks.

Log.h
    Compiler definitions for kill signals, return values (i.e. SUCCESS), and logging levels.

Makefile
    Compilation scripts for the operating system.

PCB.c
    Function implementations for creating new PCBs with their internal data structures initialized
    and, optionally, the kernel stack frames allocated.

PCB.h
    PCB struct and function prototypes.

PMem.c
    Function implementation for managing physical memory, i.e. initializing the data structure
    for keeping track of frames and allocating/freeing these frames.

PMem.h
    Typedef and function prototypes for physical memory management.

Pipe.c
    Implementations of helper functions for initializing, destroying, writing to, and reading from
    pipes.

Pipe.h
    Struct and function prototypes for pipes.

README
    Did you mean "README"?

SystemCalls.c
    Implementation for all of the system call functions.

SystemCalls.h
    Prototypes for all of the system call functions.

Traps.c
    Function implementations for the different trap vector calls. Additionally, implementation of
    TrapTableInit() to initialize the trap table vector with pointers to these functions.

Traps.h
    Function prototype for TrapTableInit().

Tty.c
    Implementation for TTY init function.

Tty.h
    Structs and function prototype for TTYs.

VMem.c
    Implementations of helper functions for managing virtual memory, such as
    creating page tables, mapping new pages to allocated frames, unmapping pages and freeing
    the corresponding frames, and changing page protections.

VMem.h
    Function prototypes for managing virtual memory.

cs58_tests/
    Programs written by Team THEYNIX for testing our OS.

idle.c
    The idle program consisting of a Pause() loop. In Kernel.c, the compiled idle program is loaded
    into an idle process that is run when the ready queue is empty.

include/
    Header files provided in the Yalnix framework.

theynix_tests/
    Programs written by the CS58 staff to test our OS.


------------------------------
                    TESTING
------------------------------

Our implementation of the Yalnix operating system is tested thoroughly for functionality and
durability under stress by the programs implemented in the cs58_tests and theynix_tests
directories. In theynix_tests there is a README file describing the different functionalities
that we have tested and which programs test each case.

When running our tests, the output is designed to be most useful/distilled
with user trace level 0 and kernel trace level 1. When running the OS
not for testing purposes, one should specify kernel trace level 0 so that only problems
resulting in OS termination are printed.


Note: You may encounter assert statements throughout our codebase. We used these as
part of the development process to validate invariants that should always be true throughout
the execution of the operating system. Provided the OS implementation is correct, the assert
statements should have no effect on the OS regardless of what user code is executed. The OS
functionality should be unchanged by compiling without them.

Best,
Team THEYNIX
Jake Leichtling '14
Derek Salama '14