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".

• 1. What is eXpOS? What is its purpose?

  eXpOS stands for eXperimental Operating System. The eXpOS specification describes a very simple multi-user multi-tasking operating system.

  eXpOS is not intended to be used as a practical operating system. It is designed with the following intentions:

  1. To have a multi-tasking OS specification that can be comprehended by a junior undergraduate student in computer science who is undergoing a first course in Operating System such that he/she will be able to implement the OS in two or three months. This educational package comes with enough guidance and support tools as well as documentation to allow the student to achieve this goal without the supervision of a specialist teacher.
  2. The student will write the complete code for the OS from scratch. He/She will not be building the OS on top of a given code base. The only programming support provided will be a compiler for a programming language (called SPL) in which the OS kernel will be written.

• 2. Who will benefit by implementing eXpOS?

  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:

  1. Initally load the operating system from secondary storage to memory – Bootstrapping.
  2. Manage several processess in memory simultaneously – Process Management.
  3. Handle allocation and de-allocation of memory to processes – Memory Management (includes virtual memory management).
  4. Manage organization of data and program files in secondary storage – File Management.
  5. Implement a mechanism to allow multiple processes to share files/memory – Resource Sharing.
  6. Realize primitives that help application programs to avoid inconsistency when resources are shared by several processes executing concurrently – Process Sychronization.
  7. Handling multiple users with different privileges over resources shared among them – Multi-user Capability.

  
  

  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!)

• 3. What are the OS concepts that eXpOS will help me to comprehend better than – say just learning from a text book?

  Please see FAQ 2.

• 4. What are the prerequisites for doing the eXpOS project?

  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, run­time stack of application programs etc. are provided as reading material at appropriate places in the project roadmap.

• 5. Who must not be spending time on eXpOS?

  People who want to learn about operating systems, but who belong to the following category are not advised to proceed with eXpOS:

  1. You are a confident programmer comfortable with reading and understanding professionally written code – like the source code of linux. In this case, more sophisticated packages like Minix allow you to do real hard stuff. However, this is not for novices.
  2. You are not an expert; you want to try out the things listed in FAQ 2, but you do not want to do dirty work at a low level. (Although you can avoid assembly language programming in the eXpOS project, you still will have to get into quite a bit of “low level” architectural details). We suggest you to look for alternatives like NACHOS.
• 6. Can eXpOS be actually be used in a real application?

  Please see FAQ 2.

• 7. What are the important OS concepts I miss out when working with eXpOS?

  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:

  1. The XSM machine allows you to store a character string in a memory word. No real machine architecture permits you to do such stuff. This is made possible just because XSM is a software simulated. However, XSM makes your data manipulation job much simpler without getting bogged down by details of data formatting. It is in principle possible to implement eXpOS on “more real” machines like MIPS. However, this would involve considerably more time and effort.
  2. The project involves very little work involving input-ouput, device interfacing, security or networking. Moreover the file system and multi-user support are very primitive. The methods studied won't scale up when there is pre-emptive multitasking .
• 8. What are the system requirements for working on the eXpOS package?

  We expect you to have a Linux/Unix Machine with Lex/Flex and Yacc/Bison software packages installed. (For Flex/Bison installation on your Linux system, see link). Once you have these, you can download the eXpOS package by following instructions at Setting Up.

• 9. What are the contents of the eXpOS package?

  The eXpOS package available here comes with the following:

  1. A simulator for the Experimental String Machine (XSM) on which you implement eXpOS. The machine consists of a CPU, Memory and a disk and a small Input-Ouput subsystem.
  2. A compiler (into the XSM machine) for the System Programmer's Language (SPL) using which you will be writing all your code for implementing eXpOS. SPL is a simple programming language which essentially is an extended assembler for the XSM machine, specifically designed for the eXpOS package.
  3. A compiler (into the XSM machine) for the Experimental String Language (ExpL). This language is used for writing application programs that can run on top of eXpOS. You will be using this language for writing some of the user level programs of the OS including the shell. Test programs that are used to test your OS will also be written in ExpL.
  4. An interface tool called XFS-interface that allows you to transfer data files and executable programs from your Unix/Linux system into the hard disk of the XSM machine.
  5. You also download the source code of all the above tools and their formal specification documents, the sample test programs testing your OS, some help etc.
• 10. I have downloaded the eXpOS package. How can I get started with the work?

  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.

• 11. What differenciates eXpOS from other educational packages like NACHOS?

  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.

• 12. What is the difference between eXpOS and XOS?

  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.

• 13. How do I write OS code and load the OS in the eXpOS system?

  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.

• 14. How do I write application programs that run on eXpOS?

  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.

• 15. What is meant by user mode and kernel mode?

  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.

• 16. Why do you need two programming languages in the eXpOS package – the SPL and ExpL?

  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.

• 17. What is eXpOS Library?

  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.

• 18. What is XFS interface?

  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.

• 19. My friend has implemented eXpOS after downloading the package and following the roadmap. I want to write a program and test his implementation. How to do it?

  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.

• 20. I am a teacher and wants to use eXpOS for laboratory instruction. How should I proceed?

  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