While the engineering of operating systems is well understood, their formal structure and properties are not. The latter needs a clear definition of the purpose of an OS and an identification of the core. In this paper I offer definitions of the OS, processes and files, and present a few useful principles. The principles allow us to identify work like closure and continuation algorithms, in programming languages that is useful for the OS problem. The definitions and principles should yield a symbolic, albeit semiquantitative, framework that encompasses practice. Towards that end I specialise the definitions to describe conventional OSes and identify the core operations for a single computer OS that can be used to express their algorithms. The assumptions underlying the algorithms offer the design space framework. The paging and segmentation algorithms for conventional OSes are extracted from the framework as a check. Among the insights the emerge is that an OS is a constructive proof of equivalence between models of computation. Clear and useful definitions and principles are the first step towards a fully quantitative structure of an OS.
The growing complexity of the OS problem has greatly increased the turnaround time for building experimental systems and efforts to build such systems have reduced. The decade long K42 effort by Wisniewski al @cite_10 is a notable exception. They explore the facets of building a full OS, share the experience and insights, and point out to the need to fill the gap between good values of research (producing meaningful results beyond microbenchmarks) and actual research practice (high cost of complete OS research against time-cost constraints). They point out that some important practical questions, e.g. the useful lifetime of the GNU Linux or Windows structures, are unanswered, and offer plausible reasons for the lack of whole-OS research efforts. Whole-OS efforts, e.g. to describe the structure of an OS, are needed in addition to incremental work.
@cite_10
2035144019
We started the K42 project more than ten years ago with the ambitious goal of developing an operating system for next-generation hardware that would be widely valued and thus widely used. Based on the premise that current operating systems were not designed to be scalable, customizable, or maintainable, we set forth to rectify that by applying proven techniques from other disciplines to operating systems and by developing additional innovative mechanisms. Now, ten year later, K42 is used by ten or so universities and national labs for research purposes, not ten million information technology departments desiring better everyday computing platforms. As a presentation to the primary operating systems community we provide an examination from two different perspectives as to what went right and what went wrong. First, we concentrate on what technology worked well and why, and what technology failed or caused undue difficulties, and why. Second, based on that experience, we provide our thoughts on the state and direction of the OS community at large. To be clear, this paper is neither a results paper nor an overview paper; we refer to other papers for background material. Rather, it is an exploration by researchers with experience with at least six different previous operating systems of the merit of technologies investigated in K42, and an extrapolation of the implications of that experience to the wider operating system community.