Paper Discussion - Fall 2008 - CS 736

PILOT: AN OPERATING SYSTEM FOR A PERSONAL COMPUTER

The paper introduces an operating system intended to be for a personal computer that provides more services than what is usually available in existing systems. Pilot is written in a high level system programming language called Mesa and the interdependency between them is very high. Pilot is organized in modules that implement Mesa interfaces.

The goal of this research is to design an operating system that is single-user, single language, that provides a flat file system, virtual memory and network communication protocols. All this features in order to provide a powerful system for personal computers.

As hardware becomes cheaper it makes sense to develop operating systems for personal computers, but communication protocols are essential in this system that is expected to interact with other system in the same network. Some of the contributions are the introduction of the concept of spaces in virtual memory, to avoid possible thrashing.

This system is totally dependent on Mesa, which is not a good characteristic considering that all the higher level software needs to be implemented in Mesa, reducing the portability and reusability of programs. Although they claim they want to provide client programs with lots of services, it is not clear what kind of higher level programs are expected to run on top of this operating system. Only minimal protection is provided by Pilot, that relays on client programs, and does not consider that programs can be maliciousness. Although one of the most important characteristics is the introduction of communication protocols, all the machines in the network need to be Pilot.

The fact that this is a single-language system makes the development of the system easier, but makes the development of client programs more complicated because they all need to be Mesa programs. The use of a “flat” file system is proposed, this is easier to implement in the operating system level than a hierarchical file system; but if the user needs a particular structure, higher level programs are expected to provide it.

In Pilot: An Operating System for a Personal Computer, researchers employed by Xerox highlighted an operating system designed to run on a single-user machine operating in a networked environment. Surprisingly, Pilot's features were similar to those of a modern PC operating system. These included virtual memory management, logical volume management, a flat file system, an extensible network stack, and the ability to record its own state (in support of debugging).

The design philosophy behind Pilot emphasized flexibility above all else. For example, many peripherals offered a Pilot developer both a high-level, streaming interface to program against in addition to a low-level API. Similarly, Pilot's network stack gave users the flexibility to either send unreliable datagrams or take advantage of more high-level, connection-oriented communication protocols. Even the virtual memory manager was able to take advice from running processes using it instead of (presumably) managing pages on its own.

Pilot's virtual memory manager operated on variable-size groups of continuous pages, organized into spaces. Spaces could in turn be mapped to a position within a file, presumably swapping the file's contents into memory (and swapping out pages changed within it). Users had as fine-grained control of the swapping mechanism as they wanted, being able to suggest any space be swapped in or swapped out to the manager. This (presumably) enabled program-specific memory optimizations, such as prefetching, that would otherwise have been difficult to implement.

Pilot had a variety of approaches to peripheral I/O. First, the memory-mapped files made it possible to implicitly write data to and read data from disk. Second, some peripherals could be talked with indirectly using a stream interface, much like the highly successful “device as a file” abstraction seen earlier in UNIX. Finally, each peripheral had a low-level driver implementation, likely harder to use than the stream interface but capable of finer-grained device manipulation. Any stream could be sent through a cascade of filters processing its data in pipeline-fashion, much like processes connected via pipes in UNIX.

Pilot offered essentially a TCP/IP stack with capabilities very close to those provided by modern operating systems. Machines had unique addresses, programs talked to each other via sockets, etc. Pilot understood the need to support development and use of loosely-connected processes, catering to them by efficiently implementing intra-machine communication between processes.

Another neat feature: Pilot uses reconstructible maps as an approach to maintaining data integrity. Pages with file data within them are tagged with metadata that is also noted in maps stored on each volume. If the maps become damaged, a rescan of all the metadata on the volume can be used to repair them. Apparently this rescan can apply custom integrity checking, though the details of that were not elaborated upon.

Unfortunately, the lack of interest in users starving each other of resources on the same machine got the Pilot developers off on the wrong foot in the world of security. Though such ideas were new at the time, network security mechanisms and fair use were not touched upon in their report.

With so many different interfaces presented to each system component (with varying degrees of abstraction), a lack of distinction between userspace/kernelspace, and modular system component design, ballooning complexity must have been a serious problem for the system designers.

Summary

The authors discuss the features provided by the Pilot operating system designed for single user systems. The main focus of the paper is to build a system that provides the users with a number of sophisticated features, but is not very secure. The system gives a lot of choices to the user without being rigid on policies.

Problem attempted

Pilot has been designed to be an operating system to to be run on personal computers and hence assumes that these are single user systems. The objective is to design a basic set of services that can be used by application programs

Contributions

1. The design offers flexibility to the user in interacting with the devices i.e. it allows the program to interact with the device either directly through the device driver or through the Pilot stream facility.

2. The presence of unique uids for files in space and time is a unique feature of this system. This policy is used by the system as a method to deal with ambiguity during inter system file transfers using removable volumes.

3. The interface 'Space' over the virtual address range has been put to goood use in reducing page swapping. User programs can create subspaces that contain pages which are to be accessed in quick successions thus exploiting spatial locality. Space.Deactivate item is very useful in removing unnecessary pages from physical memory.

4. The Space.ForceOut item and the facility given to a program to write back pages any time, gives the program the freedom to write back pages that it feels as immediate to be written back.

5. The Pilot operating system gives good support for reliable communication between two network addressees through the NetworkStream interface that is invoked by operations defined in standard Stream interface.

Flaws

1. The paper claims that the system features do not ensure fair distribution of scarce resources as this is a single user system. But memory cannot be handled this way. The OS should ensure fair distribution of memory even in a single user system.

2. Ignoring malicious code for single user system is not a valid assumption, particularly given that the sysetm was designed keeping in mind a network of computers running Pilot.

What it makes easier

1. The facility to store the entire state of the machine and debug it with an altogether different system (CoPilot) is a very convenient and powerful method to debug the system

2. The Space interface gives good freedom to programs in deciding which pages need to be retained in memory and what needs to be swappped out.

What it makes harder

1. Virtual memory databases like page tables are not stored in physical memory and in tackling this problem, the system has become very complicated. In contrast, today we have that page tables are not pageable !!

2. The Space interface has made the virtual memmory database bigger, and part of the inability to store virtual memory databases in memory is due to this fact. I believe that when it comes to the question of retaining page tables in memory without providing the Space interface vs. not retaining in memory with Space interface, the earlier option is better as it keeps the design simple.

Pilot: An Operating System for a Personal Computer

Summary

The paper discusses the design and implementation of the Pilot operating system kernel targeted for single-user purposes on powerful personal computers that can be inter-networked for distributed system applications. Features like security , protection and fair resource allocation were ignored citing that they are not serious concerns in a single-user environment.

Description of the problem being solved

They are trying to build the next generation of operating system kernel and client applications that will meet the next decade of Xerox business needs. They also had ambitious goals like, incorporate the most recent advances in Computer Science on building operating systems, do the right things by learning from successes and failures from the past building the Alto Computer.

Contributions of the paper

a) The concept of "World Stop Debugging" which provides strong isolation between the debugger and the program being debugged is innovative ( Details on World Stop debuggers and Time stop debuggers is at http://www.ece.ubc.ca/~gillies/note1.html ).

b) The innovation of "Advice taking from client programs for managing virtual memory efficiently" is definitely an optimization for the system they built but it is not an advancement in the field of operating systems. This was needed partly because of the lack of good page replacement algorithms and partly because of their complex but unnecessary concept of dividing the virtual memory into Space and Space suballocations with containment constraint.

c) Have concepts very similar to Domain Name System ( DNS ) : The authors say they use a network-based database called "clearing house" to bind names of resources to their addresses on the network. This definitely looks like the initial attempts leading to the DNS concept. Also, the wikipedia says DNS was invented in 1983 ( http://en.wikipedia.org/wiki/Domain_name_system#History ) and before that the hosts mapping file was replicated on each machine.

I am not listing features like File scavenger , network stack because they pre-existed.

Flaws in the paper

1) Virtual memory allocations through space hierarchies proved to be unnecessary and the client programs developed the trend of allocating spaces for needed portions of file that fell right under the primordial space for the whole virtual memory as noted in the second paper.

2) Also, the feature of using a pipeline of filters before transducing the I/O to a device proved to be less useful in the real world. Clients instead started using the interface facilities in Mesa with which they can implement a stream that provided a queue of objects from the Stream instead of parsing the stream data from the filter.

(1) and (2) above indicate that the designers were too ambitious and over engineered Pilot

3) The designers left out important aspects of an operating system like privacy & security , directory structure for file systems, fair resource allocation methods outside the kernel and expected client programs to implement it. This meant that client applications needed to be developed and also distributed to most installations later because users will obviously need these features.

4) Achieving File System robustness by storing redundant copies of the data needed for file system metadata re-construction and thereby wasting storage space instead of writing a better File System implementation is a bad idea. But given the time pressures for delivering the system , this was an easy way out.

5) The system was tightly coupled with a single high level language called Mesa and therefore did not support client applications in other languages.

The proposed organization of the operating system

Tight coupling with Mesa , Management of virtual memory with space hierarchy and space suballocations, good inbuilt networking stack and the concept of Streams that helps build distributed systems, development of hardware and software together thereby building a optimized computer, no inbuilt features for fair resource allocation or security.

What is made easier?

1) Debugging of programs is made easier because of the strong isolotion between the debugger program and the program being debugged. This helped in debugging of newer versions of the operation system itself because the debugger will run from the stable version of the operating system and will debug the newer version.

2) Building distributed systems / applications is made easier because of the network communication support provided by the Operating system.

3) Programming client applications in the Mesa language is made easier because of the extensive support provided by the Operating system.

What is made harder?

1) Portability to other processors not built by Xerox is made harder because the design of the system took advantages of the special processor they designed with Pilot and Mesa in thoughts. ( The second paper says "they chose to design the software and hardware together" in Para 1 , end of line 4 ).

2) Writing efficient programs is made harder because of the drawbacks in the operating system itself. For example , a) the operating system lacked fair resource allocation methods b) additional datastructures like the "projections", and memory resident space cache for allocating virtual memory through spaces took time for book-keeping.

NOTE: second paper refers to "Observations non the Development of an Operating System" by Hugh C.Lauer

In this paper, the authors present Pilot, a single-user operating system implemented in MESA ,a high-level language. Specifically, the authors give emphasis on the file system, virtual memory, I/O and communication.

The problem is to create an operating system for a personal computer, which will provide the user with powerful facilities.

A contribution of the system is the unification of the file system and the virtual memory into one system. Virtual memory is the only access path to files and files are the only backing store for the virtual memory (mapping approach). A very interesting idea is the use of logical volumes. By using them, applications overcome problems of limited hardware capacity. The idea of hierarchical virtual memory which consists of spaces is also introduced. A significant contribution is that operations are provided, so that users can make adjustments to optimize the behavior of their programs. As far as it concerns the I/O, Pilot is very flexible. Users can access a device either directly by a low-level device driver or by using the stream interface. They can also form a pipeline by using filters and transducers which write on their own. Another important contribution is the way of interprocess communication via packet communication protocols. In this way, clients in different machines communicate with each other. Today, almost the same features are used (network addresses e.t.c). Many other ideas are introduced, like the “world swap”, file capabilities, and the reconstructable maps among others.

In my opinion, one of the flaws of the system is that the protection mechanism is not sufficient. As the authors say, the system is not designed to withstand attack by malicious programmers. It focuses on providing protection against errors. The computer may be connected to a network so an efficient protection mechanism is required. As far as it concerns the file system, the fact that there are no hierarchies makes it difficult for the user to manage his files efficiently. Finally, the interdependence between the OS and MESA may cause problems to the users, as MESA is the only language supported by the system.

The system consists of several subsystems (file system, virtual memory, e.t.c) and support many features. Although, the coupling between the file system and the virtual memory may seem complicate (circularities, e.t.c), the tools provided by the system facilitate the users. In conclusion, I believe that despite some flaws in the system, the authors accomplished their goal.

Summary:
This paper presents a single-user operating system which provides a basic set of services for a personal computer, typically associated with the kernel. Notable features of Pilot OS are its network communication model, heirarchical virtual memory which is tightly coupled with the file system and concurrent programming support.

Problem:
Like the last paper on UNIX, this paper also presents a solution to a combination of problems by developing a single-user operating system, called Pilot. Following are some major contributions -

Contributions:
- Heirarchical virtual memory, with the idea of spaces, which avoids fragmentation and thrashing.
- Inspite of being a single-user system, it provides communication capabilities using layered network stack and traditional socket interfaces.
- Implicit (virtual memory), direct (low level device driver) and indirect (streams) access of IO devices. Filters and transducers act as custom IO interfaces.
- Careful integration of ideas such as permanence, capabilities, file flags and types add extra robustness to the file system.
- Scavenger and world-swap give additional benefits for crash recovery.

Flaws:
- Single language support. Pilot is tightly coupled with Mesa, even the protection mechanisms for Pilot rely solely on the type-checking provided by Mesa.
- World-swap facility to gracefully exit to CoPilot debugger is implemented in a totally weird, illogical way. Instead of isolating the current program for debugging, the whole system state is copied to a boot-file and the machine is again bootstrapped. Ideas such as using Software Isolated Processes solve the same problem, but much more efficiently \cite{singularity}.

What it makes easier?
- Networking capabilities are explored using the well-known TCP and protocol stacking principles. Socket interfaces are made available to clients for communication.
- Fragmentation is avoided by the use of spaces, which was unavailable in UNIX 4.

What it makes harder?
- Single-language support is a major drawback, thereby nullifying its portability.
- Many-a-times, common case solution is proposed (just forgetting about the completeness). One of the many examples is defensive protection instead of absolute (ignoring problems such as "Trojan Horse"), etc.

Summary:
The paper proposes a pilot operating system with a single-user, single-language environment developed by Xerox by using Mesa programming language. It is a more powerful personal computer system compared with some previous one by providing some new features such network communication facilities, concurrent programming controls and so on.
The problem the paper was trying to deal with:
The authors try to implement a single user Operating System for Personal Computer with goals different from those underlying most time-sharing systems, although the system has features including virtual memory, a large “flat” file system, streams, network communication facilities, and concurrent programming support.
Contributions
1． The authors propose the implementation of Virtual Memory using spaces with three fundamental roles including Allocation Entity, Mapping Entity and Swapping Entity which make the system more powerful to the users.
2． The system proposed in the paper can handle files with a better than the previous personal computers, such as the space of files is “flat” and there are no directory hierarchy among files.
3． The Socket Interface and the implementation of the sequenced packet protocol make the network communication easier and more reliable between different person computers in the network.
4． The authors introduce Kernel/Manager model for the system, in which kernel is built for basic functions, and the basic functions are then extended by higher level manager.
Flaws:
Compared with multi-user time sharing computers, Pilot, the singer user operating system pays less attention on security and protection from an attack by a malicious programmer. And the implementation of Virtual Memory makes the system more complicated because larger amount of data needs to be maintained and swappable.
What it makes easier:
The Socket Interface and the implementation of the sequenced packet protocol make the network communication easier and more reliable between different person computers in the network.
What it makes harder:
Since the authors introduce kernel/manager model, which makes the design of the system more complicated and harder.

Summary:
The paper proposes a pilot operating system with a single-user, single-language environment developed by Xerox by using Mesa programming language. It is a more powerful personal computer system compared with some previous one by providing some new features such network communication facilities, concurrent programming controls and so on.
The problem the paper was trying to deal with:
The authors try to implement a single user Operating System for Personal Computer with goals different from those underlying most time-sharing systems, although the system has features including virtual memory, a large “flat” file system, streams, network communication facilities, and concurrent programming support.
Contributions
1． The authors propose the implementation of Virtual Memory using spaces with three fundamental roles including Allocation Entity, Mapping Entity and Swapping Entity which make the system more powerful to the users.
2． The system proposed in the paper can handle files with a better than the previous personal computers, such as the space of files is “flat” and there are no directory hierarchy among files.
3． The Socket Interface and the implementation of the sequenced packet protocol make the network communication easier and more reliable between different person computers in the network.
4． The authors introduce Kernel/Manager model for the system, in which kernel is built for basic functions, and the basic functions are then extended by higher level manager.
Flaws:
Compared with multi-user time sharing computers, Pilot, the singer user operating system pays less attention on security and protection from an attack by a malicious programmer. And the implementation of Virtual Memory makes the system more complicated because larger amount of data needs to be maintained and swappable.
What it makes easier:
The Socket Interface and the implementation of the sequenced packet protocol make the network communication easier and more reliable between different person computers in the network.
What it makes harder:
Since the authors introduce kernel/manager model, which makes the design of the system more complicated and harder. Then implementation of Virtual memory also makes the system more complicated.

Summary:
The paper proposes a pilot operating system with a single-user, single-language environment developed by Xerox by using Mesa programming language. It is a more powerful personal computer system compared with some previous one by providing some new features such network communication facilities, concurrent programming controls and so on.
The problem the paper was trying to deal with:
The authors try to implement a single user Operating System for Personal Computer with goals different from those underlying most time-sharing systems, although the system has features including virtual memory, a large “flat” file system, streams, network communication facilities, and concurrent programming support.
Contributions
1． The authors propose the implementation of Virtual Memory using spaces with three fundamental roles including Allocation Entity, Mapping Entity and Swapping Entity which make the system more powerful to the users.
2． The system proposed in the paper can handle files with a better than the previous personal computers, such as the space of files is “flat” and there are no directory hierarchy among files.
3． The Socket Interface and the implementation of the sequenced packet protocol make the network communication easier and more reliable between different person computers in the network.
4． The authors introduce Kernel/Manager model for the system, in which kernel is built for basic functions, and the basic functions are then extended by higher level manager.
Flaws:
Compared with multi-user time sharing computers, Pilot, the singer user operating system pays less attention on security and protection from an attack by a malicious programmer. And the implementation of Virtual Memory makes the system more complicated because larger amount of data needs to be maintained and swappable.
What it makes easier:
The Socket Interface and the implementation of the sequenced packet protocol make the network communication easier and more reliable between different person computers in the network.
What it makes harder:
Since the authors introduce kernel/manager model, which makes the design of the system more complicated and harder. Then implementation of Virtual memory also makes the system more complicated.

The paper describes "Pilot" from XEROX PARC which is a single-user, single-language, multi-processing operating system designed for use on personal computers.

With the advent of personal computers, each user has a system to himself. In such an environment, the authors argue that many of the design considerations of contemporary multi-user systems (like fairness in resource allocation) do not hold, and they attempt to build a system tuned to single-user operation on a personal computer.

The system organization is described in detail. Clear differentiation between interface and implementation is made through definition modules and program modules. Closely coupled file-system and virtual memory system are provided. Filesystem access is by mapping a region of the file onto a virtual memory "space". Space is an aggregation of pages, and can be organized into a hierarchy. And swapping happens at leaf-space granularity. Devices are interfaced through streams. Advanced networking support akin to arpanet and TCP is provided.

The filesystem organization makes access to small files faster, but access to large files can potentially be difficult as a space needs to be found to map it onto. The hinting facilites make possible to use the virtual memory more efficiently. The stream concept and cascaded filters allows for easy enhancement of device capabilites.

Among the key conributions of Pilot,
- there is an attempt to differentiate functionality required off a personal computer against those required of multi-user systems.
- the hinting mechanism for the virtual memory allows for potentially efficient decision making.
- the stream inteface and filters which develop streams further assist in simplifying the view of devices from the program perspective, and aids in enhancing device capabilities easily.
- the elaborate communication system, and routing capabilites built into the OS could have been seminal.
- the world-swap debugger serves as an ingenious debugging mechanism for the system, and shows that consideration was duly vested on debuggability.

On the side of flaws/limitations of the paper
- what happens with the universally unique identifier for files if the hardware clock of the system gets reset/changed ?
- No evaluation is furnished of how effective scavenger hooks to handle different file-types are. The restoration of metadata alone in such a simplistic filesystem does not fully insure robustness.

Pilot is an operating system clearly designed with the Do the Right Thing™ mentality, including beautiful interfaces and semantically-sound utilities at the expense of complexity and even impurity at the implementation level. The purpose of the system, from a research standpoint, is to address the needs of a personal computer rather than a central time-sharing machine, motivating some unusual decisions about security, in particular. The result is a platform with some good ideas that would never survive in today's computer environment (and, in fact, has not lived to discover this).

The advanced and unusual features of Pilot are numerous and technically impressive. A clean concept of Spaces over paged virtual memory, coupled with a hinting system, allows an extraordinarily high degree of control over the memory resources of the system. Furthermore, in contrast with the Nucleus concept, it does this without burdening the programmer: He has the option, instead, of hinting his desires for the system, and Pilot is therefore afforded the opportunity to make adjustments if it is possible and economical. Short of the inconsistent ForceOut feature (the only listed capability that is not a suggestion, but a command), this design elegantly addresses some key desires of systems. The flat file space, too, is an interesting concept, and is especially unique where the unique identifier is introduced. Other features related to the base file system, such as logical volumes vs. devices, are both well-thought and have indicated themselves thus by their continuing presence in modern systems. We do note, however, and this is confirmed by "Observations", that the implementations of these features is difficult perhaps to the point of being an unreasonable engineering decision.

A central motivating perspective over the author's design decisions is that the system, being for "personal" computing, may assume that erroneous code is a much larger issue than malicious code. This makes their language of choice, Mesa (protection-wise, "... extremely reliable but by no means impenetrable"), appropriate. The authors make a tremendously naïve assumption, however, when they imagine that such a personal computer will exist without issue on a network of similar machines. Even at the time of its writing, when there was relatively little information available on a system, abuses on central time-sharing systems had brought malicious code to the authors' attention. With the imminent move to personal machines they would seem a likely next step for malware, and the authors plainly overlook this. Nevertheless, I believe that their pursuit of a hard-to-break platform reflected the realities of programming on increasingly available systems, and that this same pursuit is still valid today.

Perhaps the most dissatisfying aspect of Pilot is a key decision made for users of the system by the authors: that they should use Mesa exclusively to interact with the machine. The UNIX paper we have already read has made clear that the motivation for providing, "what the user wants," is incredibly valuable to the success of the system. The authors of Pilot choose to reject this reality and sacrifice it in favor of outward cleanliness (though as "Observations" indicates, cleanliness came at some great cost). It seems clear, based on this characteristic of Pilot, that it is designed with the authors' ideals in mind, rather than the ideals of the users they provide for. In making this choice, they inexorably doom the system.

Summary: The authors of this paper present Pilot: an operating system for the personal computer developed in Mesa. Unlike other operating systems, Pilot provided many valuable system features: virtual memory, network communication, etc, all in one single operating system to satisfy the needs of a diverse user group.
Problem to Solve: The authors of the paper attempt to tackle the challenge of writing a operating system for the personal computer and single user community, which previously didn’t really exist. With these new computers came the need for a communication protocol and a more efficient form of virtual memory.
Contributions: The authors introduced spaces as part of the virtual memory system; this helped decrease thrashing in the system therefore making it more reliable for users. Along with this they introduced space caches and other tables to help the swapper keep track of memory in use. By keeping small tables of this information, the system is able to quickly identify what memory is and is not in use by processes to help with concurrency and tracking the location of data. They introduce the socket to replace the datagram services, which allowed packets to be sent and received from a computer at anytime. Control over these packets remained at the receiver’s end though, so that the current network communication protocols required no updates.
Flaws: 1) Throughout the paper there is very few references to any type of security in place in the system besides that mention for resource allocation and the marking of files to read only. With the introduction of more effective network communications, but no security it seems that users were wide open targets for attacks. 2) The system was not only built with the Mesa language but relied on it heavily to the point it was restrictive. The debugger was in Mesa, everything simply relied on it and there seemed to be little to no support for other languages.
Advantages of Proposed OS: One advantage of this system was that it provided many features for the personal computer to be useful. For example, large file system allowed for users to store many files and introduced an abstract view of volumes so that users could have more than one physical disk. Another advantage was the communication structure allowing each computer to act as a router or client therefore allowing clients to send messages easily and connect to another machine based on a specified network address. Unlike some other early systems, Pilot allow for varying file sizes in increments of 512 bytes reducing the amount of wasted space.
Disadvantages: Pilot provided no real support for multiple users and access control. Therefore anyone with access to the one computer could do almost anything they wanted without regard to other user’s requests. Another disadvantage was the file that once a file was marked read-only there was literately no way to make it editable again there the file would need to be copied again.

Summary
Paper talks about the Personal Computer operating system Pilot . This is implemented in MESA programming language. Paper talks about various Interface of Pilot OS.

Problem
implement a Operating System for Personal Computer which support Flat File System , Virtual Memory,stream , Network Communication Facilities and concurrent Programming support .

Work Summary / Contribution
1. Stream Interface provide multiple way of accessing a Device driver . these multiple way provide lot of flexibility to client program in accessing different type of devices. Device which doesn't support Read ( like printer ) can be accessed differently from Device which support only read ( like keyboard ) . Using various combination of Filter desired stream format can be achieved .
2. Network stack like communication protocol allows client processes on different machine to communicate with each other . It is assumed that source , Destination and intermediate machine are Pilot machine .
3. Space interface of Virtual memory let client program manage their address space , map files to pieces in virtual memory and control the swapping between real memory and the backing file.
4. Pilot is developed on Kernel/Manager Pattern . In such approach kernel is built with basic core functions and higher level manager will extend basic functions .
for example File System has Filer as basic kernel and File Manager as the higher level Manager .

Flaws
1. By not keeping Resource allocation Management as one of the goal Pilot ignore the resource competition in Multi-programming environment on single system .
2. Virtual Memory implementation is too complicated that large data structure needs to maintained and they have to swappable. Due to this paging operation becomes slower.

Summary
In this paper, a new operating system Pilot is introduced for powerful personal computers. The entire operating system is designed using a high level language, Mesa and allows applications only written in Mesa language.

Problem
The authors feel that with the drop in hardware costs, everyone would be able to afford powerful personal computers which would also be connected over a network. They argue that the existing OS's designed for multi-programming systems wouldn't work that well on a system meant for a single person use where resources are no more a bottleneck.

Contributions
- Manager/Kernel model for inter-dependent modules such as Virtual Memory/File System
- A Virtual Memory implementation using the Spaces abstraction that allows dynamic size for the blocks read from memory.
- Facility to debug the OS using Co-Pilot after doing a world-swap.
- Stream interfaces for devices and networks coupled with filters provides the flexibility similar to the UNIX filters/pipes.
- Robust filesystem with cleanup/recovery using scavenger. It even allows each application to fix inconsistent files belonging to that application.
- Ability for applications to control which pages are swapped in/out/deleted from their memory.

Flaws
- There is no security implemented in the system at all. They say that they rely on other mechanisms but don't explain what these are. E.g. They take advice from the process regarding memory allocation but a black sheep process may misuse this facility.
- Because of their manager/kernel interface, the design is very complicated. For e.g. many of the cache entries have to be kept in memory always to ensure the correct functioning.
- They enforce the client applications to use only Mesa language which is very restrictive for development.
- Many basic implementations are left to client applications which leaves the OS as such unusable without building supporting applications. e.g. building a hierarchical or any non-flat file system which is usable, is left to the user.

Design - Easier
- The OS design gives a lot of control to the client applications which can be used to build more intelligent applications. For e.g. applications can advice the OS what pages to pre-fetch or delete.
- It provides a easy interface for applications to interact with applications on other machines.

Design - Tougher
- The OS only allows applications in Mesa which hampers development.
- Any application that just wants to read a file, has to still deal with the spaces to map/swap in the pages. A simpler interface should have been provided.
- Since the Pilot OS is like a microkernel, an application may have to build up many basic functionalities for it to be usable.

Summary: The paper describes Pilot, a single user OS for a powerful (in those days) PC.

Problem: With the advent of increasingly powerful Personal Computers, yet not as powerful as time sharing machines, a need was perceived for a single user system with more powerful facilities. As opposed to Unix, Pilot was carefully planned and designed; the "Observations" paper says that Pilot specifications were supposed to "satisfy the corporate needs for the next 10-15 years".

Contributions: The system incorporated many already existing useful ideas: virtual memory, file system, streams, multitasking, monitors, networking. Possible novelties:
1) Access to files is done by mapping them in memory.
2) The 'space' concept: hierarchical organization of memory (with pages as leaves), functioning as (i) allocation entities, (ii) mapping entities, (iii) swapping entities.
3) Probably the powerful networking support was unusual in those days
4) Support for performance tunning using 'Space.([De]Activate,Kill)' family.

System integrity support:
5) Use of the scavager and redundancies for a more robust file system, and the ability to transport volumes between OS versions.
6) Callbacks/file types: the client software invoked when a file is scavaged after a system crash offers.

Software engineering:
7) The debugging 'world'

QUESTION: The nature of the the tight connection with Mesa is unclear: Was Mesa supposed to act as a shell? Maybe trying to fix some 'inefficiencies' of the Unix shell, such as a process for each component of a pipe?

Weaknesses: It is a bit awkward to support streams, but no read/write interfaces to files. File sizes in units of pages are prone to fragmentation.
The use of 'Space.([De]Activate,Kill)' family requires an OS-like style of thinking for client programmers and performance of such code is tied to the current state of OS on current machine. The redundancies require double-bookkeeping. Universal/unique identifiers for files also seem a source of problems.
In hindsight it seems that the only flaws are: "All computations ... (including Pilot itself) run in the same address spaces" -- it looks like any bad program can act as a bad driver for Windows; not enough friendliness for programmers; the flat file system; maybe a bit too over engineered.

Organization: Pilot was implemented entirely in Mesa and offers a programming environment for this high level language. It simplifies the design by using the the manager/kernel architecture, which, however, needs to pay attention to avoiding circular dependencies. IPC done via shared memory or networking. Mapped files seem to avoid file buffer management issues.

Introduction:
This paper describes the approach, design and implementation of the Pilot Operating system, a system developed at Xerox aimed at personal computers.

What were they trying to solve:
Prior to this, most operating systems were designed for large scale, multi-user, timesharing systems. As computers become cheaper, the notion of a "personal" computer became more pervalent. Knowing that the design assumptions behind these earlier systems would not hold up for personal computers, the authors decided to design an OS meant exclusively for such scenarios.

Contributions:
High level of abstraction over the device capabilities via the File,Space,NetworkStream interfaces. The interface is well defined, and decoupled from the implementation, which supports some level of virtualization of resources.
Abstracting secondary storage devices through logical Volumes, which can span multiple devices and also multiple volumes can share a single device.
The Space interface provides high level of control over portions of virtual memory.
Memory mapped I/O is used to provide a consistent, performant interface for file access.
A feature-rich, layered communication system, with abstractions like socket and Network stream providing a simple interface to other systems. Most of the features and design ideas in their netwrok stack implementation are still found in modern day systems.
The presense of a built-in kernel-level debugger, co-Pilot, to analyzie and possibly recover from system crashes.
A precursor to "hibernate" feature of modern systems, known as "world swap" here, where the whole memory image of the system is persisted, to be analysed for diagnostic purposes by co-Pilot.

Flaws:
The absense of a "real" directory system. While the paper mentions that the directory system is implemented at higher levels, it is not clear what advantages we get out of removing this feature out of the kernel.
While the idea of a globally unique file id has some advantages(e.g. hardlinks across devices), it has it's own share of problems. For example, when some program accesses a file with some uid, the system has to search every device to see if such a uid exists, since the uid doesn't have any device information in it, which isn't performant.
The biggest "flaw" in their design is that it is succeptible to abuse. In most cases, the authors identify a potential problem, but explicitly choose to ignore it(i.e. what they call "defensive" as opposed to "absolute" protection). With hindsight (which is 20-20), we know that that their central premise, that a single-user system need not have security features built in, is flawed and may cause significant amount of problems. This is exacerbated by the fact that system is connected to a network, so a malicious program can bring down the whole network.
The tight coupling between the Mesa programming language and the OS. Limiting development of applications to one language severely hinders porting of already existing applications to the system.

OS Organization:
The OS consists of a number of Mesa modules, seperated into distinct (but not strict) layers. The File system and the Virtual Memory systems are closely interwined. The organization follows what is called a "manager/kernel" pattern. The network stack is also within the core system. The functionality of these layers are accessed via well defined interfaces.
Advantages:
The Space interface provides a very granular control over how virtual memory space is allocated and swapped. The flat file system with globally unique ids allow for path-independent file linkages, which means that you can move around the dependent files anywhere in the hierarchy and it would work well.
Disadvantages:
Specific to one language.

Pilot: An Operating System for Personal Computers

Summary
The paper stresses about the Pilot’s power for a single-user environment usage in Personal Computers.It speaks about its Interfaces and Implementation of virtual memory, a large “flat” file system, streams, network communication facilities, and concurrent programming controls. It is entirely implemented in Mesa High Level Language.

Description of Problem trying to solve:
An attempt is made to develop a highly efficient and powerful single user multitasking Operating System. The emphasis is made on full resource exploitation. This system includes many features which are normally part of kernel or nucleus. Pilot was designed as a single user system in a highly networked environment of other Pilot systems, with interfaces designed for inter-process communication (IPC) across the network. Pilot combined the virtual memory and file storage into one subsystem, and used the manager/kernel architecture for managing the system and its resources.

Contributions:
1. Pilot interfaces Files and volume define the storage of data. The File system is a one flat system with no hierarchy maintained. The implementation of file system is very simple with powerful primitives on accessing huge amount of information. Each file is assigned a unique identifier for accessibility in the entire system.
2. All computation on this system happens in a single address space. There’s no different address space for kernel and user programs. Each page is has three flags associated with it: Referenced, written and write-protected. The pages are structured into contiguous memory pages to a Space. This Space interface provides a huge range of functionality to clients. User is given the control over swapping.
3. A pilot client is given access to most I/O devices through lower level procedural calls. Pilot Stream is used to access the I/O devices and this brings on lot of flexibility to clients.
4. Network Communication is embedded in this architecture. It supports sockets, internetworking communication between different pilot machines or communication between users on a single machine. It supports Network protocol for error free delivery of messages.

Flaws:
Pilot system did not consider the safety and protection as one of the essential features.
Swapping/ Paging was made a part of client program, this might scare off the users as this implementation isn’t simple enough.

What it makes Easier
The functionality of paging/swapping in the hand of client might reduce data inconsistency in case of system failures. The client can commit data files at write or after sometime as desired and not wait for kernel to decide when to write the data.
The client can optimize the swapping behavior by swapping the least used subspaces together into a Space.
The OS provides direct access to input-output devices, thus client has more flexibility to access the same.

What it makes Harder
The Pilot system introduced its own set of complexities by introducing flat file system with Uid and Virtual Memory interface with Space interface. It just gave the basic functionality of files and Virtual Memory, most of the implementation is left up to Pilot client.
The pilot provides very limited protection. Considered Pilot is a single user Operating System but it does provide support for internetworking, and no support for protection is a serious issue.

The Pilot operating system was designed for a personal computing environment with a single user by focusing on services and features that are valuable to a single user and reducing multi-user features such as time-sharing and protection. This system was written in Mesa and contains virtual memory and file system with swapping, a run-time application debugger, and a networked communications.

The Pilot operating system was targeting a single user system, unlike most operating systems that were developed. The idea of powerful personal computers was beginning to be realized, and Xerox was looking for development of a single user operating system to use in their printer line.

The Pilot operating system contributes a modular system designed in a high-level programming language that has a virtual memory space with the page swapping, levels of caching, a stream interface, socket communications and network routing.

Robustness of the file system was an important property of the file system, however it seems flawed. With networking capabilities to offload tasks, additional security and protection should be added to protect the file system, rather than removed. Also, the paper states that the file capabilities are defensive against errors but not designed to withstand attacks by a malicious programmer. When developing software, it can be possible that a program has a bug and behaves similar to an attack causing the robustness of the file system to fail.

The system is organized to be tightly coupled and programmed in the Mesa programming language. With this language, the Pilot system exposes interfaces for communicating with the files, memory, streams, communications and processes. The file and memory interfaces exposed a virtual memory system that was split up into Spaces. These Spaces could be further subdivided for swapping to possibly reduce thrashing. Streams are an important part of the system that can be used for communicating with I/O devices such as the network communications. The network communication facility includes routing capabilities and uses a protocol level stack. It also utilized the idea of using sockets for inter-process communication and the ability to simply offload tasks to other machines. The run-time debugger is capable of stopping program execution and taking snapshots simplifying the task of debugging applications. However, the virtual memory system is complex in design requiring the application to split the space into usable size chunks and mark the spaces for swapping accurately for optimal performance. Although the Pilot code is only 24,000 lines, the underlying complexity of Mesa adds a large layer of complexity. Additionally, Mesa is the only supported language on this system.

Summary
Redell et. al describe Pilot, an OS designed for individual use on a personal computer. Notable features, such as the file storage system, the virtual memory, the I/O device interface, the communications system, and support for activities like swapping out the entire system are then described.

Problem
Operating systems work was generally done on larger systems with the intent of creating a system to manage vast, centralized resources, whereas Pilot was developed to provide an OS with reasonable features for an individual computer. Due to the machine having one primary user, many issues involving sharing the system that had to be dealt with on other systems could be downplayed. Instead, work was done on providing more facilities than were commonly associated with prior personal computers, even though those facilities were constrained to a more basic, single-user environment.

Contributions
• Despite being designed for less powerful systems, Pilot appears to do a good job weighing the costs and benefits of what it implements, providing a reasonably well-balanced set of features that would make for a usable personal computer.
• The implementation of logical volumes helps to ease the management of storage resources—it is possible to create one large volume that encompasses a variety of smaller physical devices or to create a variety of smaller logical volumes on one physical device.
• The virtual memory feature that was provided on a variety of earlier systems was also implemented. An interesting extension on this idea was providing facilities for user-level suggestions for moving spaces (logical paging areas) in and out of memory; however, the final decision resting with the OS prevents this facility from providing certain checkpoint-like facilities.
• A well selected set of prior work is slightly modified and applied that provides networking, file storage, and I/O related facilities.

Flaws
• Too little attention is given toward security, scalability, and robustness. Though the argument is made that a system is personal and security is thus not of high importance (because “such threats [are] to be coped with […] outside the system”), the networking features allow for distant, malicious users to cause problems for each personal computer. If it is desired for a larger network to exist, this lack of automatic security/scalability is likely to cause issues.

Organization
Pilot is organized with a variety of layers in mind. A variety of subsystems for dealing with memory and swapping are first implemented, with a file system layered on top of them. There is some overlap here as some of the data for the virtual memory is stored within the file system. Communication with devices is done with a structure that allows for devices to be accessed directly, indirectly (with a stream capability), or implicitly (through file accesses). For communication between processes, a communications facility is implemented that much resembles that of the current internet. The overall set of tools provided appear to make it easy to build programs upon this OS, unfortunately, the system is closely tied to the Mesa programming language, limiting the flexibility for a variety of programmers to easily write programs for the OS.

Summary
The paper introduces the interfaces and implementation of the Pilot operating system.

Problem
The problem is to provide an operating system for a comparatively powerful personal computer.

Proposed Organization
The organization of the Pilot operating system is in large part due its intended use on personal computers. To this end, a single user, single language system is provided and emphasis is placed on defending against errors rather than malicious intent. The authors provide an interface for files and an interface for virtual memory. Files are provided in a flat file system with unique identifiers based on the time and serial number for names. Virtual memory is divided into a hierarchy of swappable spaces. I/O devices may be accessed directly or they may be accessed through the stream interface, which provides for sequential access. A transducer maps the primitive driver interface onto a stream interface, resembling, but not the same as, pipes in Unix. Network access may be done through packets or through sequential access through the stream interface. While the system integrates a number of nice features and appears to be flexible, in general, the amount of coupling between Pilot and its programming language, Mesa, might be limiting.

Contributions
The file system made attempts at providing robustness. The system provides for logical volumes, either spanning multiple physical volumes or on the same physical volume. Also, as the file manager maps files into virtual memory and virtual memory relies on filing, the system uses what it calls a manager/kernel pattern, wherein low-level filing and swapping facilities are provided first, allowing the implementation of high-level file and virtual memory managers. The spaces interface provides for an amount of programmer control of swapping behavior. The system provides something resembling a network stack, with replaceable parts. The system also provided a “world-swap” facility that saves the state of the machine for resuming execution after debugging.

Flaws
There was little indication of how successful the system is in practice with crash-recovery and file system robustness, two apparent goals of the system.

This paper presents the operating system developed by Xerox for their personal computer line. It is a single-user, multi-tasking operating system, closely tied with the Mesa high-level language. The authors focus on the filesystem, the virtual memory subsystem and the communication subsystem.

A contribution of the system is the coalescence of the file and virtual memory subsystems: every file is accessed via memory-mapped I/O and every virtual memory access must be mapped to some file in the underlying file system. This adds some complexity, like the introduction of the "permanent" flag to differentiate between disk space that has to be reclaimed versus space that stores useful data after a crash. The authors also present a flexible memory management strategy, allowing the user to prefetch pages, to mark pages for eviction and to force a page to disk. A mechanism for marking pages as candidates for swapping is --as far as I know-- still missing from popular modern operating systems. Another important contribution is their network stack design, with systems today mostly preserving the same basic principles of the Pilot operating system, like the representation for network addresses and the programming interface for sockets. Perhaps this can be attributed to the eventual domination of the ARPA network stack. Finally, a part I found interesting is that the filesystem supports capabilities, but it is unclear whether they are just used for access control for files or they are first-class citizens as in IBM System/38, which supported capability-based addressing and was commercially available when this paper was published.

A flawed aspect of the system is the design of the disk repair utility. A regular bootup involves running the scavenger process to scan every page on the disk, construct a B-tree on the unique-id attribute for indexing and reclaim space that is not marked to belong to a permanent file. In an attempt to be complete, they also have hooks for executing a set of user-defined processes for each page to take care of the logical consistency of the pages. I strongly believe that booting up this system would take a lot of time.

I think that an unusual part of the design was integrating the Mesa language in the operating system. This tight coupling has certain advantages, like the ability to save the complete state of the applications and debug them in a different machine. However, this severely restricts the applications that can run on the system, at a time when languages like FORTRAN, PL/I and COBOL existed for more than a decade and had proved to be popular for certain application domains. Finally, it is hinted that Mesa is a language that requires a software virtual machine, for example in references to "microcode", that allow programs to remain portable between different computers. If this conjecture holds, this might impose an overhead which is unacceptable in the early 80's.