This FAQ is about the educational package involving the eXpOS operating system and its supporting tools – the XSM machine simulator, the xfs-interface tool and the SPL and ExpL programming languages, collectively referred to as the "eXpOS package".
eXpOS stands for eXperimental Operating System. The eXpOS specification describes a very simple multi-user multi-tasking operating system.
eXpOS is not intented to be used as a practical operating system. It is designed with the following intentions:
If you are a non-expert in computer science – like an undergraduate student or some non-specialist systems enthusiast – and you have a basic understanding of programming, and computer organization, implementing eXpOS will help you to get a feel of some of the core ideas involved in implementing a multi-tasking operating system on a single processor. You will learn how to:
The experiment is akin to guiding a third year aerospace engineering student to build a small unmanned flight in two months. (The flight will not be usable outside the laboratory!)
Please see FAQ 2.
The project presumes that the student has undergone a basic sophomore course in computer organization and data structures and has either completed or is currently undergoing a theory course in operating systems. The project does not require the student to be familar with the principles of compilers. It is not expected that the student has a high level of proficiency in programming or computer hardware. The required background on paging hardware, interrupts, runtime stack of application programs etc. are provided as reading material at appropriate places in the project roadmap.
People who want to learn about operating systems, but who belong to the following category are not advised to proceed with eXpOS:
Please see FAQ 2.
What you learn is very little compared to what is needed to become an OS expert. So, listing out everything is impossible. But here are some important misses:
The eXpOS package available here comes with the following:
The best way is to follow the eXpOS roadmap. It is a journey taken one simple step at a time. You will be provided with links to learn the concepts on a “learn when needed” way. Just go ahead following this link.
It is difficult to answer this question for all similar packages available elsewhere, but here is a comparison with NACHOS.
NACHOS learning system asks you to implement OS software that allows application programs in the noff executable format, running on a the software simulation of a MIPS machine, to invoke system calls. However, the OS code you write really doesn't run on the MIPS machine! Your code is actually C code running on your Linux/Unix machine. When an application program invokes an OS system call, the MIPS simulator transfers control to a corresponding “stub” function in the simulating environment. You must write C code in the stub to do “whatever is expected from the OS” to satisfy the calling application program invoking the system call. Since the MIPS machine is simulated, your code has access to its memory, registers etc. Thus you can implement the system call, put return values in appropriate memory locations on the simulated MIPS machine and transfer control back to the calling program.
In eXpOS, the OS and the application programs run in the same machine as is the case in real systems. The compromise made in achieving this goal was to make the machine “unreal” and the OS simple enough so that additional complexity is manageable for a short term project.
XOS is an earlier version of this project. XOS did not support blocking system calls.
This means that a process will never do a context switch while it is running in the kernel mode. However eXpOS, system calls may block in the kernel mode and other processes could be scheduled. The version of XSM provided with eXpOS has the necessary hardware support for doing this.
The addition of this single feature makes the eXpOS substantially more complex than XOS. This is because a blocked process might have made partial updates to some OS data structures before blocking and a newly scheduled process, while executing in the kernel mode, must be careful not to modify these data structures and leave the OS in an inconsistent state.
Apart from the above feature, eXpOS adds support for semaphores, shared memory, file locking etc. There is also limited multi-user support. However, the additional complexity introduced by these features is minor.
You have to write your OS code from your Linux/Unix system in a custom programming language called SPL that comes with the eXpOS package, compile the code and install the target code into the hard disk of the XSM machine. The xfs-interface tool allows you to do this pre-loading. Your OS code must include set up code that will be executed when the system is started. This code must load the rest of the OS into memory during bootstrap.
Application programs must be compiled in the Linux/Unix environment outside and pre-loaded into the XSM machine's disk. The ExpL language allows applications to be written and compiled into the eXpOS executable format called the XEXE format.
In a multitasking OS like Linux, there are two types of programs running. Firstly, there are application programs that users write. These are called "user mode programs". Secondly, there are "kernel mode programs" which constitute the OS code. These routines implement the system call interface for application programs and other OS functions like process, memory, file and device management etc.
User mode programs can execute only a restricted instruction set and has access only to a limited memory (called the virtual address space). These programs must invoke OS system calls to do tasks which involve capacity beyond their limited instruction set. Kernel mode programs on the other hand have full access to the machine instruction set.
Any machine supporting eXpOS needs to recognize and support two modes of program execution. The OS must be designed such that the machine switches to kernel mode when a user mode program invokes a system call and goes back to user mode when the system call returns. This requires architecture support. XSM machine is equipped with the necessary hardware support.
We need separate programming systems for writing user mode programs and kernel mode programs because these languages serve different purposes. The high level language - ExpL provided with the package can be used for writing application programs that run on top of the operating system. However, ExpL does not support low level programming necessary to write the OS. The SPL language (which is essentially an enriched XSM assembly language) must be used to write the OS modules.
The ExpOS library is a piece of code that provides a generic interface for application programs to access OS services like system calls and dynamic memory management routines.
ExpL permits applications to invoke OS routines only through the library interface. The compiler simply translates the library call to a low level library call. However, ExpL compiler will not attach the library to the application at compile time. The OS loader must attach the library to the application at run time.
XFS interface is a tool that permits you to transfer programs and data files between your host system and the XSM machine's simulated hard disk. The tool is capable of handling various eXpOS file types (like OS modules, application programs, data files, library etc.) and store them in the XSM disk, updating the disk data structures appropriately.
You must write your code in ExpL language in your Unix/Linux machine, compile it using the ExpL compiler that comes with the eXpOS package and load the target executable file into the XSM machine's disk using the xfs-interface tool. Now start the machine (assuming that your friend has already written his OS routines in SPL, compiled it using the SPL compiler and loaded it into the disk) so that her OS boots up and runs the shell program. From the shell, you will be able to type in the name of your executable program and execute it, just like in bash.
You are welcome use eXpOS. You may also fork the project on GitHub and customize the project to your own needs subject to the Creative Commons license conditions.
Pro Tip: Suppose your institution has the name ABC University, to host your project on GitHub as exposabc.github.io, create a GitHub account by the name eXpOSABC, fork this project, rename your repository to exposabc.github.io, and host your website using GitHub Pages