During the Fall of 1995, Acados development was not funded, but student interest continued.
During the Summer of 1995, Acados development continued with the hiring of
ACADOS began as a class project in the spring 1995 offering of 22C:216, Seminar on Operating Systems, at the University of Iowa. The students involved in this project were:
The development of ACADOS was motivated by three factors. First, we note that the dominant operating system today is Unix, a system designed over 20 years ago. Other academic operating systems such as Minix and Xinu are designed to look like Unix, and other commercial products, ranging from MS/DOS and OS/2 to Mach and Amoeba are also largely motivated either by Unix compatability or by the desire to emulate Unix.
Much has happened in the years since Unix was developed, and it is a credit to the design of Unix that the design of Unix has been able to accomodate so much of this, but as Christopher Marlin said about programming languages, it is occasionally necessary to step back and make a fresh start.
Our second motivation is the fact that the fundamental mechanisms discussed by most operating system texts are not readily apparent in most real operating systems. Where are semaphores or other elementary interprocess communication mechanisms in UNIX, for example? To the extent you can find them, they are afterthoughts, cobbled into the system, and as such, they make poor examples.
Our final motivation is the fact that students need more exposure to the problems of designing (and if time permits) prototyping operating systems and programming languages. As a class exercise, we hope this project will be a wonderful opportunity for serious lessons in practical software engineering.
All of the interesting microprocessors now on the market now support paged virtual addressing. Therefore, unlike UNIX, we decided to support a separate paged virtual address space on behalf of each process. Furthermore, we decided that this makes sharing of pages between address spaces natural, and therefore, that the primary means of communication between protection domains should be through shared pages. This allows efficient use of uniprocessors and MIMD processors, without requiring copying of data between address spaces and without imposing major limitations on message based communication in a networked environment.
All objects a process may manipulate are represented in its address space. Page objects are the most common, but other objects are also allowed; for example, semaphores, the right to manipulate processes, and so on may all be included in the address space of a process. Non-page objects are implemented as invalid page-table entries, in exactly the same way that pages currently on secondary memory are implemented. The advantage of this approach is that the same mechanism allows sharing of pages, semaphores, and processes. The disadvantage is a slight increase in the complexity of the page-fault service routine -- it must detect and abort attempts to perform invalid operations on non-page objects.
The kernel does not impose any segmenting or sharing relationships on the organization of pages in a program's address space. However, by convention, pages containing code should be organized into contiguous logical segments and code pages should be read-only and shared by all processes executing the same code.
Although non-mandatory, page zero of a process's virtual address space should be permanently invalid, to simplify catching attempts to follow null pointers. Similarly, at least one permanently invalid page should separate a program's logical segments.
The state of a stopped process is contained in a page. The contents of this page are undefined when the process is in any state other than stopped. The layout of the data in this page depends on the system, but with each system and each standard language, there should be something like a header file containing a declaration of the data structure of this page, with certain fields named in standard ways, for example, if the program counter is stored on this page, it should be in a field named PC, and if there is a stack pointer stored on the page, it should be in a field named SP. Additional software defined fields must be provided in this page to hold error codes and additional diagnostics.
A process holding the right to manage another process may start and stop that process, it may peek and poke entries in the process's page table, and it may kill the process. If the manager has access to the process state page, it may inspect or modify the state. In combination, these rights allow the process that manages another process to load and run programs in it, and they allow the manager to act as a debugger.
When a process fails, for example, because of an attempt to address an invalid location in the process's memory address map, or because of an illegal instruction, the process is stopped and a signal is sent to the process's exception handler. If possible, the saved process state should always reflect the state immediately prior to the execution of the instruction that caused the fault. An exception handler may use management rights to correct an exception and restart the stopped process, for example, in order to implement demand paged virtual memory.
The primary breakdown of the work was between a kernel design group and a group representing the eventual users of the kernel, responsible for evaluating the sufficiency of any product produced by the design group. While the design group works on producing a preliminary kernel specification, the evaluation group is charged with studying other system kernels in order to prepare for the evaluation process.
An orthogonal committee structure was also established, with six committees devoted to sub-problems that an operating system must solve. These are the problem of supporting process and memory managers, supporting a file system, supporting a window manager, supporting real-time applications, supporting a network, and resisting attack by crackers.
The initial committee memberships were assigned so that each person was on three committees, to ensure good communication; each person was on either the Kernel or Evaluation committee, and in addition on two fo the orthogonal committees, as follows:
Net Memory Timer Attack Windows Files Net
\ / \ / \ / \ / \ / \ /
| | | | | | |
KERNEL |Kingery| Gupta | Hunt |Henning|Bubpha |Willemsen
| | | | | | |
-------+-------+-------+-------+-------+-------+-------|
| | | | | | |
EVAL |Damian | Rathi | Noble | Zheng |Legawa |Kavuri |
| | | | | | |