~codeforger/michaelos/trunk

        \and Supervisor:\\ Martin Berger}

The overall aim for this project is to produce a simple Multitasking Operating System (herein called MOS) to study structure, allocation, and management of different classes of hardware resource. This section provides a brief introduction to Operating Systems, Discusses the project aims, and looks at the approach taken.

 

We live in a world surrounded and controlled by machines, and software is our way of telling those machines how to act. As our machines and needs become more complex, so must the software that runs them. An Operating System is a software package that allows for others to easily create complex behaviors by providing simple high level abstractions over the intricate low level hardware.

 

 

 

For an every day user, the Operating System turns complex tasks into seemingly trivial ones. Even running a program is a complex task for a computer to achieve, however to most users `launch your favourite browser' might seem like the simplest task to accomplish. Operating Systems make these tasks easy by providing graphical menus and windows to `disguise' the complexity beneath. It may also provide a number of built in programs like file browsers and settings managers to make common tasks even more straight forward.

 

An Operating system may also offer tailoring of a system to a specific user, like having certain programs start when the computer is turned on, or drawing the screen with a custom image as a background. To this extend, the Operating System can be seen as `anything that isn't a program' to the user.

 

Below is a screen shot of the popular Windows operating system, It shows a number of programs; a web browser `firefox', a test editor `notepad++', a file browser `explorer'. The programs each own and control their `window' however all other parts of the screen are controlled by the Operating System. On the right, the portions of the screen controlled by the programs is blacked out, showing only the parts of the screen controlled by the operating system.

The operating system is doing more than just running 3 programs though. Each program can have any number of `processes'. A process is a piece of a program that can perform one action at a time. If a program wants to do two things at a time, it must have two processes. Furthermore there may be more processes running that don't belong to a graphical program and are needed to keep the system running often referred to a system processes. The Operating System must make sure each of these processes gets a fair share of the computer, to make sure each program can run correctly.

 

Processes, whether they are program processes or system processes, need to access a number of resources to work. The most apparent are the screen, the keyboard, and the mouse. Operating systems gives the processes simple access to these resources to allow programs to show things to the user, and allows the user to interact with them. However, in the back ground, there are many other types or resources that the Operating System controls. Hard Drives are permanent storage services, they allow programs and users to create information that lasts even after a reboot. RAM is a temporary storage that allows programs to keep track of there current state (for example, storing the text and images for your current word document). Network devices such as ethernet cards and wifi cards allow programs to communicate with other programs on other computers and connect to the internet.

 

These resources are not infinite. Hard Drives, RAM, and screen space, are restricted by size. Whereas network cards, and printers, are restricted by throughput (actions per minute). An Operating System tries to allow access to all these resources by all processes simultaneously. By denying a process access to a specific resource, the program may not be able to perform its task correctly. However, to a program, fair may not mean equal. A web browser my heavily use network card, but never write to the Hard Disk, Alternatively, A Photo Editor may never require network access, but may write very large amounts to the Hard Disk.

 

An Operating System is higly a complex piece of software however all require 3 distinct sections:

The Bootloader is the code that is run first. It gets things that the kernel might need set up, for example, getting the CPU into the correct operation mode.

The kernels job is to both control the hardware and mediate the execution of processes. To begin with it will initialise its modules, each there to control one piece of hardware or provide one service to the kernel or user-space. Some of the more important task these modules perform are keeping track of which processes are currently executing, deciding which processes should go next, as well as ensuring that all processes think they have enough memory to operate correctly.

\subsection{The Bootloader}

The bootloader's job is to load the kernel. The CPU has to begin executing code somewhere, this is the boot loader.

 

The majority of the bootloader's job is to get the hardware ready for the kernel to take over. Tasks like detecting the available physical memory of a machine is up to the bootloader, once it has gathered such information, the loader will store it somewhere the kernel can find it.

 

The final steps of the bootloader are to get the CPU into the right mode. It does this by first setting up some important `tables' in memory. One of these tells the CPU what to do if an interrupt is produced. Another tells the CPU where it can find physical addresses in RAM when virtual addresses are looked up.

 

Finally the bootloader can start the kernel and it's job is finished.

\item Create a bootloader to boot a kernel.

\item Handle all common cpu interrupts and resolve them correctly.

\item \lbrack Complete\rbrack Create set of scripts for getting the source code, Building the project, and deploying it to a computer.

As this project falls within the bound of Computer Science, It will comply with the British Society of Computing (BSC) Code of Conduct \cite{CoC}. Although there is no contractual obligation to follow this code, it is important to recognize and comply with them to ensure the integrity of the project.

In preparation of producing an Operating System, current generation systems were studied in detail. The features and interfaces of the systems were analysed to assist in the designing of MOS. Although It was known in advanced that MOS was not going to be complex enough to incorporate all features of the reference systems, it was important to study what current systems do, such that their most important features could be mimicked.

The Program Developers use an Operating System as a platform to create the programs the End User will use. To them, the Operating System is a Resource Manager and Scheduler and provides some crucial functionality for complex behaviours like creating new processes, Allocating dynamic memory, allocating screen space to the programs, and accesing the hard drive. Many of the complexities of the Operating System (especially hardware control) are abstracted away from the Program Developers, however it is expected that they have some awareness of how the system is structured to successfully integrate with the kernel.

The parts of the reference systems that were analysed from the end users perspective are; program launching, process management, and program interaction as these are the main sections that will be implemented in the MOS.

  \caption{Windows Program Launcher Interface}

  \caption{Linux Program Launcher Interface}

In each system, the process manager is very similar, as the tasks they perform are identical. Both systems provide a window that lists processes and some relevant information about each process like PID, cpu usage, memory usage, disk usage, and network usage. It was found that the majority of these fields are concerned with what resources a process is using. This is the case because an Operating System's purpose is to manage the physical resources available to the software.

Each system also provides the ability to change what information is provided for each process, these extra informations include many other physical resource usages (I.E. Nice value, or cpu time) as well as a more in depth view of the default informations (I.E. separating `memory usage' into: Virtual, Resident, Writeable, Shared, and Xserver memory.)

  \caption{Windows Program Manager Interface}

  \caption{Linux Program Manager Interface}

The Windows Operating System provides three buttons; The first Button allows the user to minimize the window to hide it from the work space. The second button is to maximize/un-maximize the window, this makes the window occupy the entirety of the screen. The final button exits the application.

\caption{Windows Title Bar Example}

\caption{Linux Title Bar Example}

On windows, There is a `task bar'. This is a portion of the screen, (often located at the bottom of the screen), that stores small icons for each running program. Clicking on one of these icons will bring that program to the front, un-minimize it, and make it the `active' program.

On Linux, Pressing the windows key, or pointing your mouse cursor to the corner of the screen shows you all of the open programs by `zooming out' and separating all the programs from each other. Selecting a program from this `exploded' view will un-minimize this window, bring it to the front, and make it the active window.

  \caption{Windows Program Navigation Interface}

  \caption{Linux Program Navigation Interface}

The parts of the Linux system that were analysed are the; Process management system, the memory management system, the windowing system, and Inter Process Communication.

Fork will spawn a new processes with a perfect copy of the calling processes memory and cpu state. This effectively means that fork will return twice, once into the caller and once into the child. It will return 0 to the child and the child pid to the parent.

Communication between processes is an important part of creating complex behaviours in user space programs. Linux provides some simple calls to create channels of communication between processes.

From the programmers perspective. The system API's or modern Operating Systems have been well thought out and have stood the test of time, however sometimes represent behaviours far more complex than that which MOS targets. The studied API's will be mimicked both to follow tried and tested ideas, and also so that program developers feel at home developing for MOS.

As with the Analysis, the Design phase was separated into End User and Program Developer sections. However here the structure of the kernel itself was also considered and planned. The designs presented here are the final designs for the system, some earlier versions can be found in TODO Link to apendix here.

Design for the end user focused on similar tools, looks, and controls to existing systems; The Linux CLI was referenced for a lot of the simple command line tools as MOS' text mode graphics share a common interface to Linux terminals. MOS programs also targeted a clean workspace, avoiding unnecessary ascii drawing and focussing on delivering the service provided in a quick and clean manner.

\subsection {Process Creations : MASH}

\subsection{Process Management : processes}

\subsection{File/Directory creation: mkdir and touch}

\subsection{File/Directory Management: rm and mv}

\subsection{File Editing: notes}

As program developers are very familiar with how to create programs for other systems, the API for the project system was designed to be very similar to that of the Linux kernel that was analysed.

MOS will provide a very similar set of system calls to Linux, however their behaviour may be simpler.

`fork()' will return the child pid to both the parent and the child, allowing for the processes to distinguish themselves by comparing this value to the value of the `get\textunderscore pid()' system call. On failure it will return -1.

`kill(pid)' will kill the target process, freeing all its memory and removing it from the scheduler.

`pause()' and `pause(pid)' will pause the target process until `wake()' is called. With `pause()' the current process will be paused and immediately revoke controls to the scheduler.

`wake(pid)' will wake the target process and allow it to be scheduled again. It will NOT cause the target process to be executed next.

The memory managemnt API will be identical to that of Linux. Therefore MOS will provide two system calls:

The File access functions will use a similarly idea to linux's however will be far simpler.

`fopen(name, \&file\_handle, create)' will open the file specified by the absolute path `name' and store the relelvent information into the file handle provided. If the file does not exist and the `create' parameter is true, the file will be created. If the directory does not exists, no action will be taken. If the file does not exist or any other error occurs, the type field of the file handle will be set to 2. The rest of the structure will be considered invalid.

`frename(oldname, newname)' will move and rename the file at oldname to newname. If either the source file doesn not exist or the target directory does not exist the function will take no action.

The kernel was split into a number of discrete modules, each performing one simple task, or over seeing the access to one peice of hardware. These modules were originally designed to be self contained, not relying on any other modules, however it was quickly realised that some modules could be brought `closer together' to help streamline the kernel. The most notable case of this is the scheduler and the terminal manger, the scheduler contains the process entries for each running application, including the io descriptors, these io descriptors are required by the terminal to operate, therefore the scheduler allows write access to these data structures `cross module'.

\includegraphics[width=400px]{images/Kernel_Modules}

\caption{Kernel Module Dependencies}

It has its own smaller Physical Memory Manager, IO Manager and XXX, To assist in its task. It then maps the kernel to the correct location in memory and jumps to the kernels entry point.

The program loaders job is to prepare a Program for execution; Loading the binary into memory in an appropriate manner, setting all process table fields to correct values, and ensuring all other system modules correctly reflect the execution of a new program.

The event managers job is to track timed events. It will allow for the registration of certain types of events with an event deadline. Once the deadline is passed the Event manager will perform the requested action. This module requires that its main function 'events()' be called with some frequency.

The IO manager will control all IO for user interaction with processes, as well as any outputting the kernel may do. It must maintain a current rendering of all running processes screen space, and deliver keyboard input to user space processes at the users command. It should also maintain different kernel space and user space windows, allowing for the user to switch between the kernel and user process view.

 

\subsection{Keyboard Driver}

The active process list contains all processes that either want CPU time, or are known to want CPU time in the future. The list is ordered in such that the process at the front is always the lest recent to have had CPU time.

The io part stores information about the processes IO, this information isused and managed by the IO manager which is discuessed next.

It then checks for any overlapping processes, these are processes that are in the `outputable' list who's screen area collides with the new request. For any overlapping processes, the IO manager first pauses that processes, giving it the is\_hidden flag. Then it uses malloc() to request a portion of the kernels heap space of the same size as the old processes screen space. It copies the current state of this screen space into the new memory and assigns the pointer into the `snapshot' section of the IO part of the process entry. It then moves the processes from the `outputable' list to the `hidden' list. Finally it wipes the process' portion of the screen blank.

The IO manager supports two output modes for processes; progressive and targeted. In progressive mode, the  IO Manager keeps track of the current position of each processes `caret'. Then, if a processes wants to print in this mode, the processes simply passes a character to the IO manager. The IO manager will use the column and row fields of the IO part of the process entry to place the character within the processes screen space. The IO manager will make sure to wrap when the end of the line is reached, and will also roll the entire process' terminal space up when the bottom is reached. This behavior is very similar to that seen in the Linux and Windows CLI's.

In targeted mode the process sends the IO manager both a character and a coordinate for that character. The IO manager will then check if the coordinate is within the bounds of the processes screen space and if so, draw it to the screen. This draw mode allows more sophisticated user-space applications to `draw' better gui's and update only portions of the screen space at a time.

\section{Event Manager}

\subsection{File System}

\caption{Example inode structure #TODO : give source to image.}

\section{Pager}

\section{Heap manager}

\section{Pipe Manager}

\section{Interrupts handler}

\section{Program Loader}

With further time and resources, a focus would be put on creating a larger set of builtin programs and creating a network interface for connecting to the internet.

 

Throughout the project I have gained a lot of knowledge about how computers function and how common structures and procedures are employed in modern operating systems. Furthermore I have gathered experience in using the C language to create powerful, reliable code.

\item Supervisor Meeting 1: This week we discussed the state of the project, some goals to hit in the upcoming weeks and the proposal report due in next week.

\item Supervisor Meeting 2: This week we discussed how process creation was handled in linux and other Operating Systems, and how to move forward with concurrency.

\item Supervisor Meeting 3: This week we discussed how IPC was handled on many different system and how I could think about going ahead with IPC.

\item Supervisor Meeting 4: This week we discussed how to continue work on IPC and the next steps of using the IPC to abstract general process I/O.

\item Added cpu time metric for all processes.

\item Added better testing for memory manager and file sytem.

\item Fixed many bugs with fork cycle and mrfs edge cases.

\item Code Refactor.