General comments related to all the papers: Most of these position papers
discuss methods for creating and modifying OSs so that they are application
optimized.  The range of approaches described are almost diametrically
opposed  For example [1] and [4] suggest that the structure and mechanisms
to support application optimizations should be part of the deployed OS,
where as [5] suggests that an extensible structure should only be used to
test application optimizations and that lessons learned should then be use
to improve current/deployed OSs. [2] Suggest that there is no need for
additional OS baggage when creating an application specific OS, and suggest
a way of identifying only those OS components needed to support the task at
hand (for their application).  [3] Suggests that software methods be used
for fine grained protection mechanisms in an OS.

 [1] Small: Structuring the Kernel as a Toolkit of Extensible, Reusable
Components (1995)

The motivation for this paper is to reduce duplication of development effort
and improve application performance by creating re-purposable [is this a
word?] functionality in the kernel for use by applications.  The authors
propose to do this by creating a toolkit of classes that can be
incrementally specialized for application purposes.  These specializations
can split into three forms: modification of the kernels resource handling
policy to more closely fit the needs of the application; reuse of kernel
subsystems rather than redeveloping functionality for applications; the
ability of an application to extend the kernel by augmentation (grafting).

While allowing applications to have more control based on the assumption
that the application is more likely to know its system needs is a reasonable
idea for improving application performance, there are safeguards that
application developers may assume the OS is going to provide that must be
upheld. One worries about protection from errant or malicious applications.
The system proposed here addresses this issue by 'sandboxing' and time
slicing, but are these protections sufficient?

[2] Montz: Scout: a Communications-Oriented Operating System (1995)

The motivation for this paper is to design an application specific OS, in
this case for communications-oriented devices.  The authors describe four
tenets that describe and respond to the problems with (then) current OSs
when examined from the perspective of an application specific OS. The
(summarized) tenets are: the OS is configurable and only contains task
specific functionality; the concept of a path is fundamental to a
communications-oriented system; scalable and predictable OS performance;
leveraging compiler technology will help the OS track processor performance,
and help construction and portability.

The key idea here is thinking about the specialized OS design in an
abstraction that more easily models the problem.  In this case, partly
because of the communications centric design, they use a path abstraction
which represents the flow of data from I/O sources to sinks.  This allows
them to define the sequence of communications modules used and also the
system resources required to move the data from source to sink, which helps
select only those system components and resources needed for the job as
described by the path.

The idea of defining an abstraction which can be used to determine OS
components needed for a particular application is intriguing. The question
is, how difficult is it to come up with such an abstraction?

[3] Bershad: Protection is a Software Issue (1995)

The position taken by this paper is that software protection mechanisms have
inherent advantages over hardware in an OS.  The authors describe software
protection as being flexible, explicit, precise and generally optimizable.
In comparison they describe hardware protection as rigid, implicit,
imprecise and unoptimizable.

I'm not sure I entirely agree with this position.  Yes hardware protection
is more rigid, implicit and imprecise than software protection, however, I
feel (and the authors agree) that hardware protection mechanism can be
enablers for software protection mechanism.  Hardware provides a coarse
grain protection that enables finer grain protection in software at a
reasonable performance, i.e, software is used to optimize the protection
already offered by the hardware.

On the flip, as processors get faster, it does become feasible to implement
in software, protection mechanisms that were previously only feasible with
hardware based protection assistance.

[4] Engler: Exterminate All Operating System Abstractions (1995)

The motivation for this paper is to eliminate those parts of the OS that
abstract hardware and provide an interface that is at the hardware level.
The authors claim that hardware abstraction is the root of all OS problems.
They content that abstractions should be implemented outside the OS,
allowing applications more choice and control.  They define a structure
called an exokernel whose sole function is to allocate, deallocate and
multiplex physical resources in a secure way.

The concept is interesting, however, there was not enough information in to
make me feel comfortable about a couple of points.  (The do attempt to
answer these questions in their FAQ, but don't do so satisfactorily.)  One,
regarding the possibility of a chaotic system, they state that defining
standards and conventions should provide the simple remedy.  This is not
generally the case.  Witness X-Windows based UIs where you may have several
different models of widgets and toolkits, and application programmers may
choose one or more different toolkits for their applications, sometimes
resulting in different (chaotic) presentation models.  The same may likely
happen to an OS.  Two, their answer to the question of portability seems
contradictory, where they state that portability can be had by implementing
a low-level layer that hides machine dependence.  While this layer of
abstraction is not part of the kernel, it is an integral service provided by
the OS and may likely have the same effect as if the abstraction were
implemented in the kernel.

[5] Druschel: Extensible Kernels are Leading OS Research Astray (1997)

This paper takes the position that creating an extensible OS for production
use is not only unfeasible, but also poses a distraction from research on
the real challenges in OSs.  They cite safety (i.e., partitioning
applications to ensure errant or malicious behavior in one application does
not negatively effect other applications) as the major problem related to
extensible kernels, with compatibility , interoperability and evolution of
OS implementations also listed as problems.  They propose an approach where
extensible OSs are used for research and lessons learned can then be
implemented for a non-extensible kernel.

The problem with using one type of OS for research and development of
mechanisms that are then to be used in another OS is that the assumptions
made and work done for one OS may not easily translate to the other.  The
secondary questions raised by the authors relate to OS acceptance.  The
problem with their comments about OS acceptance is that, which OS is popular
in the marketplace is not so much based on technology rather it is based on
marketing.