Arvind Santhanam (arvind@cwc.ucsd.edu)
Tue, 25 Apr 2000 06:51:58 -0700 (PDT)

Hi Dr. Voelker,

The evals for the paper are down below!


On the Duality of Operating System Structures

The primary goal of this paper is to establish the duality
(similarity) in seemingly dissimilar structures (ideologies) in OS design
i.e Message-based system versus Procedure-based System. It provides a
one-to-one correspondence between the aforementioned systems. The
hypothesis goes as far as saying that the ideal models for these two
seemingly different system are closely related and everything from
performance and interactions between subsystems have a very close
correlation. The hypothesis that the perfomance of a message-based system
and procedure-based system appears to be the same using these rather ideal
models, but the differences in real systems could be glaring, something
the paper acknowledges.

The assumption in this paper that the operating system must solely
be developed with the given hardware (system resources) and with little
consideration to the applications that run on them is a reasonable one, as
applications can always be written easily if the operating system manages
the system resources efficiently. This could be considered a drawback if
the OS is to support (predominantly) a specific kind of functionality.

This paper does provide a good deal of insight on the similarity
between the two aforementioned techniques with the use of canonical
models, but it does not advocate the use of one over the other. Whether a
designer chooses a message-based system or a procedure-based system would
entirely be determined by the the goals of the system and the underlying
hardware (resources).

The utility of such a result is unclear, although it seems
plausible that one need not totally constrict oneself to using either of
these techniques singularly but could use a hybrid of them if that helps.

The Structuring of Systems Using Upcalls

This paper explores the idea of using upcalls in OS design, and
throws light on issues that might have to be dealt with in this reagrd.
Use of upcalls seems a very natural route for implementing networking
protocols (which must be integrated with the OS). One of the key
attributes of using upcalls is that the flow of control upward through the
layers is done using subroutine calls which are synchronous rather than an
asynchronous interprocess signal.

The implementation of upcalls can dramatically help simplify the
code while enhancing the performance of the OS. It also facilitates the
possibility of a layer asking advice from another and using this
information to determine its action. The use of `Piggybacking' helps
improve the performance of the OS significantly and is a direct offshoot
of the upcall scheme. The knowledge of how tasks are used (and the
communication amongst them) among other design decisions must be local
rather than global. The decision about how tasks are used can be made late
in the design if necessary giving the designer much needed flexibility in
developing the system.

The major drawback is that this strategy could give rise to a
large number of hideous complications like circular dependencies, making
the OS less reliable. Use of flow-control in networking protocols results
in a large number of recursive downward calls, whose effects are nothing
but catastrophic in nature. There are a large number of techniques
described in the paper to combat the occurance of deadlocks.

Use of upcalls does increase the efficiency of the OS, as one
avoids the overheads involved in interprocess communication. Use of
deadlines as priorities for task scheduling gives the system a more
ordered execution of jobs.