CS 736 - Spring 2007 - Paper Discussion

Summary
This paper argues that operating system abstractions are unnecessary and harmful and that instead operating systems should only perform timesharing operations and expose the underlying hardware.

Problem
Operating system abstractions cannot by definition be optimal for all applications.

Contributions
The main contributions of this paper are an argument as to why operating system abstractions are unnecessary and then solutions to the problems created by a lack of abstractions. They solve the security problem by proposing "associating every resource usage or binding point with a guard that checks access privileges." They solve the problem of portability by pointing out that desired abstractions can still be implemented in user space.

Flaws
It is difficult to evaluate this paper for flaws at this point, in part because it is fairly recent and the problems they point out still exist. The biggest problem that I have with this is that I don't quite believe that application interfaces won't become fragmented when given the opportunity. It seems that applications will make modifications for slight performance increases and pretty soon every application will be implementing its own abstractions.

Relevance
This is very relevant today as operating system sizes have gotten very large and encompassed many many features. I don't know if this is every going to be that relevant to workstation level computing by it may be more so to small devices.

Summary:

The paper argues that Operating Systems abstractions of hardware resources are a poor design choice and such abstractions should be done away with. The idea is that the Operating System's job is to provide a way to safely multiplex resources and the OS interfaces lowered to the hardware level. Applications can use the hardware level interfaces for finer control and are no longer governed by the limitations of the current high-level abstractions. Provide the mechanism, let the application decide the policy.

Problem:

It is extremely difficult to abstract hardware resources that is efficient or convenient for all types of applications. Kernel architects aim to solve the common case while providing abstractions leaving room for improvement in the feasibility and performance for a variety of applications. "One size doesn't fit all"

Contributions:

Operating Systems have become unwieldly due to the large amount of code providing abstractions for hardware interfaces. The crucial idea here is to do away with such abstractions at an Operating System level (privileged code), provide a safe way to multiplex resources and let user-level libraries provide standard abstractions for most common applications. Applications which require fine-grained control over the hardware can use the lower level interfaces. The operating system kernel becomes small enough to incorporate new ideas quickly. The contribution being: Provide the mechanism, let the application decide the policy. Criticism of micro-kernels is interesting as their shortcomings seem to be the difficulty in implementation rather than the design goals which are similar in the intention. The exokernel idea derives from the failure of micro-kernels meeting the objectives of application enforced policy. Overall the "clean-slate" approach appears to have been the prevailing trend of the time.

Flaws:

This is a position paper, so technical details are not presented, still security issues arising from such low level access to hardware should have been briefly addressed. (Probably covered in Engler[10]).
The code complexity shifts from the kernel space to the user space, which may not lead to any more reliability than the current model of monolithic kernels. The kernel itself may be more reliable but the whole system taken together with the applications again suffers from the reliability issues. Provided standard high-level abstractions in the user space, for most general applications there is status quo. The average application programmer may find it too hard to deal with such fine-grained access. The current kernel-patch/module/driver approach is used by special applications, this code shifts to the user space, while the programming complexity remains similarly non-trivial. There appears to be very less incentive in terms of programming simplicity in the exokernel model. Performance gains by the system were not presented effectively (Probably covered in Engler[10]).

Relevance:

Such class of operating systems can be used for specialized hardware (say TCAMs vs. general purpose memory) where the whole notion of hardware abstraction doesn't make sense (For example Internet routers have their own operating system).

Summary:
This paper mainly concerns itself with debunking the idea that abstractions work in all situations. This idea is similar to our in class discussion on where Unix's abstractions break down. The authors of this paper pursue this idea much further, eventually leading them to conclude that an OS should only multiplex resources, and not even attempt to abstract them.

Problem:
The problem, stated wonderfully, was that despite "numerous assaults," operating systems were still largely regarded as inadequate. The authors suggest that this persistent state of inadequacy should merit a re-examination of the concept of the operating system. It's then suggested that the author's re-examination of the concept has resulted in the viewpoint that abstracting physical resources simply does not work.

Contributions:

• Abstractions are bad! The argument is mainly four pronged. Abstracting resources leads to reliability losses due to the complexity of the code; abstractions make the OS difficult to modify and therefore adapt; similarly, implementing new abstractions must be done in the context of the system abstraction, which limits flexibility; finally, overly general abstractions only serve as unnecessary overhead.
• Concept of an exokernel. All an exokernel does is allocate, deallocate, and multiplex resources securely. This is all the kernel needs to do after having eliminated needless abstractions.
• Pervasive applications of KISS principle: address spaces only provide a select few table mappings; processes are provided with address space and exception counters, and that's pretty much it; simplistic and fast implementation of IPC.

Flaws:

• This pervasive simplicity simply offloads the complexity of other operating systems onto user code. Abstracting is a balancing act, and it seems as though the exokernel leans too far to one side.
• Similarly, all of the niceties of abstractions are not present. The polymorphism of modular designs makes it (theoretically) easy to swap out different components.

Relevance:
An exokernel would serve wonderfully in a resource-scarce system. As others have noted, the simplicity is a breath of fresh air with the kitchen sink approaches of Linux and Windows. However, there's no telling how complex applications must become in order to address the lack of functionality in the exokernel.

Summary:
This position paper talks about various problems with "current" operating systems, all of which authors attribute to their attempt to 'abstract physical resources', and also proposes a solution (to lower the abstraction to hardware level)

Problem:
All existing operating systems try to do do both multiplexing and abstraction of physical resources. The authors believe that the near-impossible task of abstracting physical resources make OS poor in reliability, adaptability, performance and flexibility.

Contributions:
The main contribution of this paper is the cutting down of OS abstractions to the bare minimum (almost the hardware level). That gives the application developer complete control over what he wants to do. He can choose from many existing (if the idea flies) implementations for conventional OS services, or choose to implement one of his own.
Another interesting point brought up is the size of the OS affecting the improvement on the OS. Though this is mostly true even with the modern systems, it doesnt always have to be - provided right amount of modularization in place.

Flaws:
The main idea on which the whole paper is built is that abstractions mean huge and inefficient systems. This is not necessarily true. It depends on the kind of abstractions you define.

Efficiency and flexibility dont mean just performance, it has various other facets - development effort, ease of debugging, cost applications development etc. The proposed system looks capable of achieving the performance part, but fails miserably on others. Or in other words, the system seems good as the basis for research systems and some dedicated (unbelievably)performance-critical applications, not for general purpose (read, "outside a lab").

The paper presents the ideas at very high-level, and no technical details are mentioned. There is no evaluation done. There is no mention of even a prototype system.

Relevance:
The paper presents some interesting thoughts (and some shortcomings of micro-kernel systems - which also try to solve the same problems as this system). It is also true that existing general purpose systems do not meet the requirements of some applications; but then they are "general-purpose"!! I guess the paper is also relevant (and correct) in its assessment of how complex most operating systems are today.

Summary:
The paper is a position paper arguing that the approaches taken by OS designers over the last decades were completely wrong, and the OS kernel should export a view of the raw hardware instead of significant abstractions.

Problem:
Monolithic operating systems are large, hard to modify or experiment with, slow, and unreliable.

Contributions:
This paper advocates somewhat of a sea change in how the operating system is viewed, even as compared to microkernels (which are already rather different than what we're used to). The paper was short so mostly discussed the ideas behind it, so was light on the technical details, but the ideas are pretty unique even compared to microkernels. (Both approaches are "move things traditionally considered part of the OS out of the core kernel", but go about doing it in rather different ways.)

Flaws:
Since this is a position paper, it's hard to properly evaluate the technical merits. There are a lot of questions that the paper leaves unanswered but that could be answered satisfactorily in Engler's thesis or a more detailed paper.
The concept itself is somewhat promising, but is at least largely untested in the real world with real workloads. Getting people to change their idea of what an OS is so drastically would be difficult, enhanced by the great difficulty in having to port existing applications and/or create compatibility layers with existing OS interfaces, so even if the idea would work well it seems unlikely to take hold without that evidence. Somewhat of a catch-22 even in the best case.

Relevance:
A lot of the problems that the paper mentions plague conventional OSs still. (It wasn't that long ago so this isn't terribly surprising.) The Linux kernel is on the order of 10 or 15 million lines of code. The development and delays of Windows Vista was a good demonstration that it is hard to change. The hardware requirements of Vista support the paper's position that OSs are too resource heavy. In other words, the problems that Engler tried to address with the exokernel are still present, and his solutions would be equally applicable.

Summary
This work proposes that the traditional thinking that operating systems must provide consistent and fairly high level abstractions for the underlying hardware is not the ideal case since it forces the operating system to sacrifice performance for a general purpose interface. The authors propose removing all abstractions from the OS and lowering the OS interface to the hardware level.

Problems Addressed
The problems with traditional operating systems that are addressed in this paper are 1) Poor reliability due to complex kernel implementations. 2) Poor adaptability since its hard to modify a complicated piece of code. 3) Poor performance since an abstraction that the OS exports may not be appropriate for all applications and finally 4) Poor flexibility due to the high level nature of the exported abstractions.

Contributions
In order to remove all abstractions from the kernel the authors propose using a very small kernel that exports only the physical resources of the machine in a secure manner. In this way different applications can create their own abstractions that are specific for that particular application. This set of application specific abstractions is referred to as an application-level OS and can be easily modified by the application developer to suit their needs. Protection is not as much of an issue since the application OS can trust the applications built on top of it and if there are errors in the OS they will only affect the single application. Also since there can exist more trust between the application and the application OS access checks on every memory reference and the like don't need to happen. The developed kernel, which the authors named the exokernel, simply is in charge of allocating, de -allocating and multiplexing physical resources. Security is enforced by using guards that check assess to resources before allocation.

Flaws
Though the paper makes a good argument for removing abstractions from the kernel the actual way in which that happens is not fully clarified. Its not clear how, for example, different applications can access a storage system at the physical level without affecting other applications using a different abstraction for accessing the same storage device.

Relevance
This is another paper that departs from traditional thinking about operating systems and proposes something quite different. It seems like its important to step back at times and assess the whole picture. Without understanding a bit more about the implementation of this idea its hard to say if it could be relevant in the future but all the same its an interesting perspective that potentially could improve performance.

Summary

In this paper, the authors propose the idea of making the operating system very simple by implementing only the basic primitives in the kernel. They suggest that the operating system should only export physical resources in a secure manner and it should not be required to present a pretty, machine-independent interface to the applications.

Problem Description

The authors claim that the widely accepted definition of an operating system i.e. a software that manages resources and abstracts physical layers has results in poor performance, poor reliability, poor adaptability and inflexibility of the operating systems. In order to avoid these problems, the authors sketch a very simple operating system structure that provides access to physical resource in a secure manner using guards and all the abstractions are implemented outside that operating system.

Summary of Contribution

The authors present a very unique idea of having a very simplified operating system which only multiplexes the resources. The idea appears to be quite neat because a simple operating system will result in very little overhead. Secondly, if the operating system is simple, it is quite easy to extend it and to make it more reliable as there will fewer things to worry about.
The authors suggest that an operating system should provide primitives rather than providing solutions. Resource management is put into application space. This means that application can implement their policies exploiting application-specific knowledge. This can significantly improve the performance of user level applications. This idea is somewhat similar to the extension concept provided in the SPIN paper. The only difference is that SPIN provided default policies for the application but “exokernel” does not implement any default policies. Each application has to implement its own event handlers.

Flaws

Some of the flaws in this paper are as follows.
1. The operating system is highly dependent on the underlying architecture of the machine. To solve portability problems, the authors suggest having a low level layer that hides machine dependence. This will add an extra overhead as the operating system will have to communicate to the hardware through this abstraction.
2. As the operating system does not implement any policies and each application has to implement its own event handlers, software development time will increase significantly. This means that even though the kernel will become simple but the applications will become more complex. Software developers might use shared libraries but they might not be optimized to their application.
3. There is no evaluation policy at all. The authors claim that the prototype “exokernel” is 10-100 times faster than a mature monolithic system but they do not present any data to support their claim.
4. The authors used various acronyms without defining them e.g. IPC. IPC might stand for “Inter-process communication”, “Instructions per cycle”, etc. But actually they meant “Instruction Program Counter”.
5. There were a few mistakes in the paper as well like “However, the approach taken to extensibility taken is different”. This statement can confuse anybody.

Relevance

The idea of a minimal operating system might be similar to the operating systems used in many embedded systems. An embedded system has very specific needs and running a minimal operating system on that system implements features to support those demands can be quite efficient. Secondly, the authors present a very useful idea of making the operating systems simple. The developers of Windows and UNIX should learn from this idea as these systems are becoming quite complex.

Summary
The authors take the position that Operating Systems research is headed in the wrong direction with complex abstractions. A system is proposed where the operating system is only responsible for managing resources.

Problem
The authors felt that operating systems consistently suffered from “poor performance, poor reliability, poor adaptability, and inflexibility” due to overly complex systems.

Contributions
The main contribution of the paper is the idea of a minimal operating system that simply multiplexes the resources. The user supplies the rest of the functionality of the operating system about the kernel. This significantly increases the optimizations that the end user can utilize. The idea flies in the face of the systems of the time, which are becoming more and more complex. I feel their analogy to the MIPS RISC transformation is an interesting one. Having everything at higher levels would allow for much more flexibility, but also many more places for errors

Flaws
I felt the paper was well written and did a good job of tackling the important questions a reader might have. I am not sure I agree with their argument that removing abstractions would decrease complexity. I agree it would decrease complexity in the kernel, but I feel this complexity will simply be moved into the user space. At the end of the day someone will need to write an operating system for the grandma’s of the world to use, so many of the abstractions will likely need to be implemented in user land.
I am also not certain of the need for a system like this. I agree the Oracles of the world would benefit greatly by the flexibility to control everything, but the small business who simply wants to run a webserver does not have the resources or desire to tweek low level code for extra performance.

Relevance
This article is very relevant with Vista shipping years behind schedule. Operating systems truly have grown very complex and very inflexible. Well beyond what any individual organization can optimize for themselves. I am not sure the market is strong enough for an operating system of like this.

Summary:
In this paper, authors re-define the Operating System that OS should have a very simple and strict secure resource sharing but nothing else (such as hardware abstraction) to provide a wide variety of services and applications on same machine and still ensuring safety.

Problem:
The authors addresses the problem of current OS is that they are trying to provide a abstracted service that could fit all kind of applications which is impossible and just making the system complex and large. Since there are so many kind of applications that has different requirements for the way to access resource, OS should get rid of trying to trap them into one interface and concentrate on Safe Resource Multiplexing which only OS can do.

Contributions:
They propose a new layer in the system that could be beneath the current OS system as a new “OS”. This enables to create variety of “applications” optimized for each designed users on one machine. And service that current OS provides could also be one of them. The way they go back and think about the real objective and key point of OS seems to be an interesting challenge to the current computing society.
It seems like this approach will enable to share huge powerful machines running several OS or optimized large scale Applications such as Database Management System on each of them.
This simple idea of sharing the resource might expand the possibility of sharing many kinds of data. But of course, all of the responsibility such as trusting is on applications.

Flaws:
This paper proposes the idea as a replacement of current OS and treats the current OS as a useless system, but it is true that common OS and high level API has been providing the convenience of writing applications and shipping it widely. I think it would be much comfortable if they could propose this idea as an new layer and not Operating System. It might be better if they could show how the current society could shift in to this system architecture since this idea seems to be very useful on some cases.

Relevance:
As it is mentioned in the article, the new OS has only one job multiplexing the resource and promise safety. In other words, this OS virtualizes a machine into multiple machines and allows applications or system on each machine to do anything and since all of them are separate machine, they will be independent and safe from the failure of other machine. I believe that this approach will fit to a powerful machine with huge resource in a company which has several type of demands but because the restriction of one OS, cannot provide a optimal service to each of the demands.

Paper Review: Exterminate All Operating System Abstractions [Engler & Kaashoek]

Summary:

This position paper proposes that operating systems should have just one
responsibility - protected resource sharing (or secure multiplexing),
rather than the two that systems have had historically: resource sharing
and hardware abstraction.

Problem:

The proposal addresses the fundamental problem that one OS can not
provide all the right abstractions, or extensibility, for all
applications or needs.

Contributions:

The authors respond to the common objections to their proposal. It is
certainly possible to implement any system today atop what they propose,
but whether or not it would be improved for all phases of a application
software's lifetime (including development, production performance, and
maintenance) is unknown.

Flaws:

The authors identify a persistent problem in computer science: that
researchers and practitioners continually find shortcomings in operating
system abstractions and strive to improve upon them. However, why they
suggest that one can eliminate this endeavor, given that there will be
continual discourse and always a current best compromise, is not clear.
There may not be a Grand Unified Theory for operating systems, an
artificial science.

The clear alternative to the proposal is simply to have multiple
operating systems matched to specific markets and applications. There
is no need for all computers to run a common, primitive low-level
operating system.

With their proposal, problematic aspects of the OS might just migrate to
another level. This is sometimes convenient (when there are more
degrees of freedom available to fix the problem) and sometimes
inconvenient (because it delegates responsibility) to developers and
users.

Relevance:

Their exokernel proposal seems particilarly relevant to at least two
niche endeavors: (1) host operating systems for virtual machine
environments (under which real operating systems run), and (2) embedded
operating systems for machines dedicated to special tasks. It seems
ill-fitting for time-sharing systems and home/work desktop workstations.

P.S. What is IPC? (Apparently not Inter-Process Communication, which is
how I know it.)