Paper Discussion - Fall 2008 - CS 736

Summary:

The paper discusses a minimalistic multi-programming system that makes no rigid assumption and allows for flexible and dynamic expansion by a hierarchy of operating systems that implement more complex requirements for program scheduling and resource allocation. The multi-programming system clearly defines external processes as those dedicated for I/O and the rest as internal processes. It uses a managed message buffer pool with per process message queues as the primary method of communication and sharing of resources between any two processes which is more secure and efficient compared to semaphores.

Description of the problem:

To design the nucleus of a multiprograming system that allows:
a) a user to extend the basic system with one or more operating systems hierarchically that meet his complex requirements like real-time scheduling etc.
b) dynamic creation , control and removal of processes.

Contributions of the Paper:

a) Introduces a inter process communication method using managed message buffer pool and per process message queues. Limits on the number simultaneous messages that can be sent by a single process guarantees that the buffer pool will not be depleted as long as there are non-ignorant receiver processes in the System. This way the System is unaffected by a malicious or buggy program. Also, the IPC is used to share resources and this approach is efficient over using semaphores because when a program needs to write some data to a display and the display is in use then instead of waiting for the display to become free , the process just sends a message to the display external process and continues. Also, primitives to reserve and release resources ( semaphores ) co-exist to provide exclusive control in sharing resources.
b) Assigning a process for every I/O device ( called external process ) allows the interaction between program and I/O devices also to fit into generic communication model described above thereby easing the implementation and development of the System.
c) The concept of Process hierarchy for parent/child relationship between processes and a method of process control and resource allocation between processes based on this hierarchy is neat.
d) Flexibility to dynamically load and unload one or more operating Systems as needed on top of the minimalistic multiprogramming core is a big win for users who have complex custom requirements.

Flaws in the Paper:

a) The storage allocation needs to be more clear. It looks like as processes get created, the storage allocation gets more uneven because at any point in time, we would not know how many child processes will be created in future.
b) Since the CPU resource is shared between all active process in a round robin fashion, a process can get more processing power by creating child processes to do its work.

Relevance of the Paper today:

a) The concept of external processes for I/O has matured into devices drivers that we find in modern operating systems.
b) The process hierarchy along with parent/child relationship is found in modern operating systems too.
c) The Pipes that we find in modern operating system for inter-process communication is similar to the message queues in this paper.

In The Nucleus of a Multiprogramming System, Brinch Hansen lamented the seemingly endless overhauls of existing operating system code required to meet specific scheduling and resource management needs of different users. To solve this problem, he proposed a new, flexible operating system, or “nucleus”, that could accommodate extreme diversity in user needs through the use of resource compartmentalization and the relaxation of assumptions about what functionality a core operating system should provide.

Hansen's system put forward a nucleus that provided a core set of primitives to programs, allowing them to carve up their memory space as well as create and destroy programs within that space. He also presented an IPC system, managed by the nucleus, that allowed processes to work together and synchronize their actions.

Hansen drew a distinction between the programs loaded into a memory space and the spaces themselves, which were (unfortunately) referred to as processes. When a program created a new process within its own process space, the newly-created process was referred to as a child process. The program associated with a parent process was then granted the power to load and unload programs into its child processes, which in turn had the ability to control their own children. In this manner, a process tree was created where the root process served as basic operating system that had dominion over all processes.

Surprisingly, the nucleus performed round-robin scheduling between all programs loaded into processes (regardless of their position in the tree), and any process could send a message to any other process. In this sense, the nucleus was more like a traditional modern kernel than a hypervisor. Yet, each process had the ability to load and unload programs into its children, and therefore could implement sub-scheduling by virtue of removing or adding them into the nucleus's scheduling policy.

The paper was not without flaws: for one, it did not fully justify the use of message-passing over shared memory, though hinted at weaknesses in naïve approaches like Dijkstra proposed in The Structure of the “THE”-Multiprogramming System. It also proposed four fundamental functions to accomplish IPC with; however, the need for both send/wait message and send/wait answer functions was not made clear. Finally, it did not expand upon the additional burden placed upon the user to implement functionality needed to interface with peripherals, manage memory, etc.

Summary

The author gives the design of the nucleus of a multiprogramming system by describing and justifying which features should be implemented in the nucleus and which features should be left to the freedom of users to decide

Problem attempted

The paper aims to build the core functionalities of a multiprogramming system, that attempts to be as less restrictive as possible, such that its functionalities can be extended in any desired way.

Contributions

1.The nucleus of the multiprogramming system is similar to what is termed as micro kernel today. The nucleus implements just the essential features - simulation of processes, communication among processes, creation, control and removal of processes. The author prefers to call it a software extension to hardware, rather than an independent process
2.With the help of the nucleus, it is possible that the same installation runs several modes where each mode is probably implemented by a separate operating system and we could replace operating systems dynamically as per necessity
3.The paper identifies the inability of semaphores to deal with processes that don't obey the rules of the game. It fixes this problem by introducing message buffering within system nucleus for process communication. The four primitives defined are Send Message, Wait Message, Send answer and Wait answer.
4.The author points out that programs should have freedom for their own algorithm for scheduling and accordingly relieves the nucleus of the related tasks of program loading and swapping.
Flaws

1.Though the author states that nucleus is meant to do just the bare minimum functionalities, the functionalities supported seem to be too rudimentary. The contribution can be summarized as the creation of primitives for creation, control and removal of internal/external processes and primitives for inter-process communication
2.The idea of having buffers for inter process communication is not viable when there are too many processes, particularly when the intent is malicious – sending messages to non responsive processes to hog buffers
What it made easier

The concept of an extensible operating system has made the design of the nucleus manageable as against designing a giant monolithic operating system. This means that ensuring much lesser bugs in the nucleus is possible

What it made harder

It made the routine user's life hard !! He is now forced to add so many functionalities that would have otherwise come with a normal OS.

This paper introduces the structure of a multiprogramming system. The system is defined as a set of parallel independent (external and internal) processes identified by names. It also introduces a set of primitives to manage the processes such as creation, removal, control and communication.

The goal of this research is to create a system that can be extended with a hierarchy of operating systems with different program scheduling and resource allocation requirements.

This paper introduces a interesting separation of processes depending on whether they are the execution of a program (internal process) or the input/output of a document (external process). It also presents a new way of synchronization between parallel processes based on messages.

Some time results are shown in part 8, but it is not stated what programs were used for those results or any other way of testing. It is also never tested how the system can be extended to modify some of the requirements.

A simple and effective process hierarchy is introduced. The definition of communication primitives presented in this paper seems more complicated that the previous studied semaphores, but at the same time they provide extended functionality.

This paper describes a multiprogramming system in which multiple sequential processes coexist. The structure of the system is described as a hierarchy of 6 levels and semaphores are introduced as the way of synchronizing the communication between the processes.

The goal for this research is to process a continuous flow of user programs as a service to the University. The look for a reduction in turn-around time for programs of short duration, economic use of peripheral devices and central processor.

This paper contributes with a hierarchy for the operating system and the introduction of synchronization primitives (semaphores) as way of synchronizing communications between different sequential processes.

The paper talks about the debugging of the system, and how the testing was performed exhaustively level by level from the lower one to the top level. They talk about how a set of relevant test cases should be used for this purpose, but they do never specify what programs are used.

This paper presents a simple and valid hierarchy and a synchronization mechanism that are still valid nowadays.

Summary
The paper presents a flexible system nucleus for a multiprogramming system, implementing a small number of fundamental concepts regarding control of and communication among processes.

Problem
The problem is that contemporary operating systems tended to make fairly inflexible assumptions, operating in a single mode of operation. Old operating systems may be needed to support existing software, whereas new systems are needed to overcome the limitations of existing systems.

Proposed Organization
The system nucleus is regarded as sort of a “software extension of the hardware structure” allowing easier control of and communication among processes. A process is an abstraction which may be an internal or external process; both are handled the same when communicating among processes. Processes are scheduled using a round-robin scheduler and primitives are available for communication. An internal process refers to the execution of a collection of instructions, whereas an external process refers to I/O. In either case, a process may refer to another process by name rather than physical location. An external or internal process may be created by an internal process. The parent process has complete control over the scheduling (stop/start/remove) of the child process and its resources, which can be some subset of the parent’s resources. A hierarchy is created in which processes essentially own their children.

Contributions
The system nucleus implements only a set of primitives concerning processes which are to be shared among systems that use the nucleus, essentially a platform for multiprogramming, in general. In the way operating system is used here, any parent process is, in a very real sense, an operating system for its children processes. As such, a good deal of flexibility is achieved, allowing the system to be easily extended.

Flaws
The evaluation consists mostly of data concerning speed and size, values which are lacking comparisons and I'm not sure how they compare to other multiprogramming systems. Does the system work as its supposed to? What kinds of systems were implemented using this nucleus?

Summary

In this paper Hansen describes a multiprogramming system that allows the dynamic creation of a hierarchy of processes –operating systems which can support diverse strategies of program scheduling and resource allocation.

Problem

The main problem that the paper tries to solve is how to design a system with the appropriate degree of flexibility, so that users are not restricted to a single mode of operation.

Contributions

a) The construction of nucleus, the component which supports only basic functions (communication among processes, creation, control and removal of processes). All the other functions, like scheduling, were left to the programs. In this way the kernel is minimized. New operating systems can be implemented without modifying the system nucleous.
b) The paper suggests a new way of communication between internal and external processes (or only internal processes), by using message buffering. Among its other advantages, message buffering protects the processes from malicious processes.
d) Each parent process has complete control over its children. In this way, parent processes could be independent operating systems.

Flaws

a) The simplicity of nucleus makes difficult the writing of programs .Users have to implement several features which are not supported by nucleus.
b) There’s a limit to the number of messages a process can send simultaneously .
c) Memory protection is not mentioned in the paper.

Summary:
This paper presents the implementation of one of the first multiprogramming system with a clean distinction between nucleus (so-called kerenel). Full semantics of processes, I/O handled parallely with dynamic control over process control, creation and removal are implemented with a new message buffering mechanism is also presented for inter process communication.

Description:
A multiprogramming system is implemented over a RC4000 24-bit computer. A heirachy of processes is built with dynamic control. New process definitions (internal and external) are introduced to handle IO parallely.

Contributions:
- A system (nucleus) is implemented which represents a systematic and practical approach to the design of replacable operating systems.
- Concept of process (internal and external) is introduced with dynamic control.
- Evaluation shows that system nucleus performs much better than the basic operating system.
- Notion of malicious processes is introduced.

Flaws:

- A parent process can remove a child process in order to assign its storage area to other processes. So if a malicious process keeps sending messages to a process, it can cause other child processes to be killed.
- Single access system.

Proposed Organization:

- What it makes easier: Lays the foundations of message buffering mechanism for IPC. Process Heirachy concept is introduced with dynamic control.

- What it makes harder: Malicious processes can cause other processes to be killed. Common buffer pool - hence buffer management is needed.

Summary
The author in this paper has tried to design a bare-bone operating system that can be used for any mode of operation. He has moved most of the system functionalities into the individual processes thereby increasing the flexibility and also reducing the complexity of the system.

Problem
Operating systems are designed for a certain mode of operation and don't provide any flexibility in using other modes without totally redesigning the system. Changing the operating system with changing requirements is also not feasible, as each application is tightly bound to the original system.

Contributions
a. This paper introduces the concept of inter process communication using buffers from a pool. Also it introduces identifiers to prevent intrusion and rate limiting to prevent starvation by "black sheep" processes.
b. External processes provide an abstraction over the peripherals to allow any process to communicate with any peripheral as if its another process.
c. The author also talks about maintaining a hierarchy among processes and giving total control to parent for its child processes. This gives total flexibility to each of the parent processes and can thus even be independent OS's. This seems to be similar to the process trees seen in the current OS designs.

Flaws
a. The design doesn't handle cases where all the message buffers might get used up if a process stops responding to messages and uses up all buffers in its input queue.
b. In trying to make the design extremely flexible and minimal, the programs that are needed to run on this system need to be very complicated as they have to implement their own process scheduling, resource allocation etc.

Relevance
Present day inter process communication, process trees and micro-kernel design seems to be developed on the basis of this paper. It also seems to have introduced the modern day "device drivers" in the form of external processes. This design provides extreme flexibility to the programmers at the cost of complexity of programs needed to run on this system.

Hansen seeks, with this publication, to propose a multiprogramming system design which permits a system operator the flexibility he requires. The "nucleus" he describes includes the core set of features required by such a system, being only process creation/destruction, unified scheduling, and a message-passing system allowing inter-process communication. What he describes is not unrelated to the modern concept of a message-passing microkernel, and has some of the same advantages. It also suffers from some of the same drawbacks.
This design arrives two years since the publication of Dijkstra's THE system, and acknowledges a property of multiprogramming systems which Dijkstra did not discuss: that a general-purpose multiprogramming system must provide good performance to operators with different requirements. A particular file system, for instance, may be unsuitable for a class of programs, and so an operator may desire to replace it. In monolithic systems, this requires re-writing the system. In a vertically-layered system like THE, where (in theory) one could replace each layer independently, the system still does not allow different services to be made available to programs running concurrently. Hansen's system therefore rejects both monolithic and layered construction, and with an extremely general "nucleus" in place allows any number of system services to run concurrently as separate processes. Since communication with these services is regulated with the use of messages rather than shared semaphores, processes are given stronger guarantees of fair access.
Perhaps the most compelling feature of Hansen's system, its minimalist design, may also be considered its largest drawback. Consider a short list of features which we take for granted today: virtualized memory and a common I/O interface. Programmers on Hansen's system are obliged to implement such features themselves, and make their own communication protocols to support them. Flexibility in the implementation, therefore, may come at some great cost, because virtualization of the processor alone does not make the hardware an especially attractive resource to the programmer. Additionally, one is required to tolerate the overhead of message-passing to use a service. When Hansen wrote this, the pervasive use of unprotected memory systems made context switches (to deliver messages) a relatively small cost. In hindsight, however, fast context switches have been determined less interesting than memory protection, and this is one of the main reasons we don't use message-passing in most popular kernel designs today.
Hansen did spend a great deal of time describing his message-passing system, which is appropriate as it composes one-fifth of the nucleus in its entirety. The two largest contributions of message-passing are first, that processes may communicate easily and intuitively, and second that the system forces isolation upon processes, protecting them from other defective or malicious uses of system resources (such as shared semaphores). This second idea, independently of the rest of the nucleus concept, has survived. Modern OS services such as named semaphores, inter-process sockets, and remote procedure call libraries perform this task exactly. In fact, as Hansen's concept here is an OS essentially without common services, the ironic presence of a common message-passing service hints that perhaps Hansen just chose the wrong set of "vital" services to include.

Summary:

This paper describes the philosophy and structure of a multiprogramming system nucleus; it can be extended with new operating systems in an orderly manner and can dynamically achieve the creation, control, and removal of processes.

The problem the paper was trying to deal with:
The paper was trying to propose a system nucleus which can implement simulation of processes; communication among processes; creation, control, and removal of processes.

Contributions
1． Quite lot definitions were given in this paper, like internal process, program, peripheral device, external process and so on.
1． The author did not regard the system nucleus as an independent process, but considered it as a software extension of the hardware structure, which makes the computer more attractive for multiprogramming.
3． The author decided to use send message and wait answer for communication between internal and external processes, while originally the communication primitives were only designed for the exchange of messages between internal processes.
4． With the idea of system nucleus, A fundamental set of primitives allows the dynamic creation and control of processes as well as communication among them.
5． The paper proposed an implementation of a RC 4000, which makes multi-programming feasible with a minimum store of 16K-32K words backed by a fast drum or disk.

Flaws:
In order to achieve high efficiency, the system nucleus used message buffering. However, message buffering would introduce resource problem because the common pool only contains a finite number of buffers. For instance, further communication within the system would be blocked if a process were allowed to empty the pool by sending messages to ignorant processes, which do not respond with answers.

Summary :
Professor Brinch Hansen proposed Nucleus System which makes the computer more attractive for multiprogramming by implementing fundamental concept of process simulation ,Inter-process Communication , creation,control and removal of processes.

Problem :
Operating Systems available at that time had made rigid assumption in its basic design about specific mode of operation and didn't allow information system/process change/control the mode of operation . Due to this restriction freedom of design was seriously limited.A new system is required which can be extended with new operating systems in orderly manner .

Work Summary/ Contribution :
1. New Opeating System can be developed without modifying the System nucleus .
2. New Message Buffering based process communication is proposed . four basic primitive for such communication are - send Msg,send answer , wait message and wait answer . Common pool of message buffer and message queue for each process .
Advantage of Message Buffering :
a. Malicious process can't interfere the communication between 2 process .
b. process need not be aware of existence of other process .
c. efficient as sender process can continue once msg is copied into buffer . need not wait until receiver process has finished .
e. system can remove the process which is engaged in communication so dynamic property of system is un -affected.

Disadvantage of Message buffering :
Resource problem as common pool has finite no of process has been resolved by putting ceiling on the no of message a process can send .

3. Explain communication between external process and internal process . Documents can be identified as external process and Internal process need not worry about device on which Document is mounted .

4. process has freedom to choose their own strategy of program scheduling . which is implemented by allowing dynamic creation and control of child process in their storage space .

Limitation :
1. This paper doesn't talk about the case in which malicious process can create many small child process ( which occupy less storage area ) and consume lot of processor time as computing time is shared by RR scheduling among active process regardless of their position in the process hierarchy .

OS Architecture Advantage :
Nucleus system Parent process gives complete control on scheduling and resource allocation . due to this kind of architecture strategy can be introduced at higher level by user program to execute their child/process in different priority .

Summary: The authors of this paper present an multiprogramming system that defines the way in which internal and external processes can efficiently communicate in a system whose hierarchy is based on a nucleus.
Problem to Solve: The goal of the authors was to create an environment (the system nucleus) in which parallel cooperating processes existed that allowed for simulation, communication and process management. In addition, this nucleus needed to be extendable such that new operating systems could be created from it.
Contributions: The authors define internal and external processes and the forms of communication possible between them via message passing. This creates a system similar to semaphores but prevents malicious and removed threads from adversely affecting the state of the system. Another contribution is the notion of a system hierarchy centered on a nucleus that contains all privileged functions. This hierarchy allows processes to control their own resources when it comes to creating and removing child nodes to facilitate effective process control and resource allocation.
Flaws: The authors indicate that one of the purposes of developing this system is to allow designers to develop OSes with multiple modes of operation and/or allow more freedom for different OS designs. Many things in the paper show the new choices the nucleus design allows for, but no formal evaluation is done. A detailed evaluation would help show some of the primary design choices this structure introduces.
OS Organization Advantages: All processes are controlled by the system nucleus, which is beneficial for multiprogramming because of the centralized controller. OS designers have the freedom to implement different policies for certain types of functionality based on their needs such as scheduling mechanisms, and resource application. The nucleus also helps with reusability because new operating systems can be implemented on top of it at anytime. The communication protocol allows processes to enter or leave at anytime without disrupting the remaining processes making the system more stable during dynamic changes.
Disadvantages: Since many of the primary components are contained within the nucleus, they must be adaptable to a variety of operating systems and testing of these components must be exhaustive (this is difficult because of the large number of possible states without a layer of abstraction being present).

Introduction: This paper explains the motivation and approaches behind an
extensible and customizable multiprogramming system, which is flexible enough
to cater to wide variety of requirements.

What were they trying to solve: The core issue they are tackling in this
paper is the inflexible nature of earlier multiprogramming systems. Any operating
system design makes certain assumptions about the usage of the system, which
invariably is a problem to those situations where these assumptions are not met.

Contributions:
The biggest idea behind their approach to solve this problem
is modularization: break up the OS into chucks, giving the user full control
over how each of the chunks function with the Nucleus, the minimalist core
component being the only invariant. This is in essense an extreme form of what would
develop into the Microkernel Architecture (which academia loves and industry
hates).
The paper explicitly demarcates between program and process; Abstractizes
secondary storage in terms of Documents(files in modern systems); Recognizes the
importance of abstractizing certain device features via "external processes", something
which is done by device drivers in modern systems;
An asynchronous interprocess communication mechanism via messages, with
appropriate protection features.
The idea of a hierarchy among processes, with controlled sharing of resources
and parent processes bearing (some) responsibility of managing it's children
is almost ubiquitous in modern systems.

Flaws:
The problem of finite message buffer pool is somewhat migitated by the rate-limiting
of sender processes, but doesn't address the issue of a process receiving large number
of messages from different senders but not reading the messages.
It's unclear from the paper who exactly makes the scheduling decisions: On page
240 Section 6, they say "processes should have complete freedom to choose their
own strategy of program scheduling" but on page 241, Section 7 says "Computing time
is shared by round robin scheduling". I think this is a flaw in the paper not the
system itself.

OS Organization: The operating system is highly modularized, with a very small core
part which is unchanging. It even allows for dynamic switching of operating systems.
Advantages: The system is flexible to a high degree. Disadvantages: None

The nucleus multiprogramming system is a software extension of the hardware structure designed to give flexibility as operating systems evolve. The nucleus system implements the means to control processes, and perform communication between devices.

The problem this paper targets is how to extend the structure of a multiprogramming system for use with multiple operating systems. This paper enhances the idea of modularity and that the base system should be able to evolve. The author also explains a functional implementation on the RC4000 with data to show feasibility. This paper also delivers a sequence of design steps that defines the concept and structuring of a process and the means of communication between processes.

The paper develops the means of communication between processes, but does not address strong separation between the processes. For example, the internal process has the ability to change the names. If two operating systems built on top of the nucleus system had similar naming conventions for the processes, there could be resource conflict. Also to guarantee internal processes exclusive access to external processes, reservation and release exist, however if a rogue process calls reservation and never releases, the other internal process will not be able to get access to this external process.

The proposed organization of the nucleus system enhances the modularity to run multiple operating systems on one platform, has a defined message passing system for process to process communication, and incorporates the idea of abstracting the hardware through a common interface. Some disadvantages to this system is that the control strategies, operator communication, program scheduling and resource allocation will still need to be developed on top of this system. As security concerns and limitations arise, this system may become a bottleneck for future operating systems. Also, for embedded processors, the resources consumption and performance overhead for this additional layer could reduce its universal use.

Summary:
The paper describes a system that provides core functionalities of an Operating System and allows tuning of behaviour through a hierarchical organization.

Problem at Hand:
Brinch Hansen strives to create a core/nucleus which would furnish some basic operating system primitives and yet be flexible enough to tailor to specific user needs. To some extent, the idea is to separate strategy from function.

Key Contributions:
# The paper presents an advanced (for its time) form of Inter process communication with great detail on its implementation.
# The paper proposes the idea of minimizing the kernel of the operating system. This is achieved by delegating some of the responsibilities like process and memory management which traditionally were carried out by the OS to other processes which run over the Nucleus.
# The process hierarchy proposed allows for a parent process to manage a child process. Thus a single system can concurrently host diverse operating environments (the paper calls these "operating systems" but I find it a bit arguable) suited to different types of applications.
# The system allows named processes and dynamic creation and removal of processes which, for the time, seems novel.

Limitations:
# The system nuclues does what it is supposed to do, but cannot be called a complete operating system. A lot of vital decisions like which process to create, how to manage memory etc are delegated to user level processes and left unaddressed.
# The terminorlogy of calling some of the user-level processes which decide strategy as "operating systems" is confusing if not misleading.

Relevance:
# The IPC mechanisim used in the nucleus is advanced and ressemble some present day ones like RPC (given the return path).
# The paper essentially proposes the ideas of micro-kernels and virtual machine monitors (In fact, wikipedia says the system was also known as "Monitor")

Summary
Hansen presents the basis for a system which allows for running of processes, communication among them, and their creation, control, and removal. On these processes a variety of programs could be run, of particular interest to Hansen was the ability to run new operating systems on top of this base system.

Problem
Prior multiprogramming systems were constrained in that they lacked choice in the use of the operating system. Here, Hansen designs what he believes to be a basis set of functions necessary for all operating systems—the “nucleus”—and allows for creation of processes upon this infrastructure that can each run a new operating system (or other program). This allows for considerably more flexibility for customization than was previously available by allowing for easy replacement of the operating system.

Contributions
• Freedom to (relatively) easily run a new operating system upon which new programs could be run, thus allowing for system flexibility.
• Uniformity in messaging: messages are used both for inter process communication and I/O, resulting in only one common framework that must be learned and used from the programmer’s viewpoint.
• Separation of resources (process control, resource allocation, and prevention of interference in messaging) in a fashion that allows for each process to run safely within its own space.

Flaws
• Issue with rouge processes in a locking-based system is raised and a solution is presented, but similar problems can arise with a rouge process on this system, for example, a process which creates a large amount of sub processes, which in turn all obtain an equal share of the processor due to the round-robin scheduling, causing the legitimate processes to obtain fewer time slices.

In this paper, Brinch Hansen describes the basic philosophy of extensible kernels.

The contribution is the idea of providing a minimalistic nucleus with only the very basic primitives, namely process creation and communication, and nothing more. He argues that user processes should provide the operating system functionality, instead of the nucleus. This is a contrast to the monolithic layered approach proposed at the same time by Dijkstra in the THE system. This paper appears to have inspired work in microkernels, and recently exokernels and virtual machines.

One of the flaws of the paper is that although the author mentions that in real systems some processes might be black sheep and not conform to the rules, the same rationale is not reflected in other design choices. For example, scheduling policy remains round-robin and no memory protection among processes processes is mentioned in the article. On a more philosophic level, restricting privileged functions to the system nucleus seems contradictory to the goal of extensibility.

The proposed architecture tremendously improves the versatility of the system. However, it raises significant security concerns as to whether user code can be trusted. Also, it makes system debugging more difficult: even the simplest bugs become distributed bugs.

Purpose of the Work:

The authors describes a system build with the philosophy of minimum support for running user programs, in order to allow more flexibility in terms of implementing polices for the operating system.

Contribution and relevance:

It defines clearly defines terms like, process as a program in execution with given storage area. It distinguishes between internal process and external process.
It introduces the concept of Inter Process Communication, with help of primitives like send message, wait message, send answer and wait answer. The system is modeled as asynchronous system for allowing better performance, but at the same time primitives like wait answer and wait message allows it to have blocking calls.
The concept of external process helps to have a layer abstraction on how different peripheral can be handled by internal processes.
The system also introduces the concept of dynamic process creation and stopping method widely followed in today’s OS. It also introduces the concept of process hierarchy based on process creation and how child processes share resources.

Possible Flaws:

In a situation when there is a process which is not receiving/ consuming message while other processes are sending messages to it, may unnecessarily hold important buffer pool resource and thus bog down the entire system.
The inter process communication that was described here is purely point to point in nature, without support for broadcasting or multicasting.
It seems in order to achieve too much of flexibility, the designer has left too many things to do for the programmer who is using the system. Even operation like processing scheduling is totally delegated to the user. May be it would have been better to have a default policy of scheduling, but user had the option of using or not using it.