Overview of TOS

A D i s t r i b u t e d E d u c a t i o n a l Operating System in Java

Tyrone Nicholas, Jerzy A. Barchanski

Brock University
St.Catharines
Ont. Canada

Abstract

This paper describes TOS - a distributed educational operating system

implemented in Java. First, the current trends in commercial operating
systems are shortly presented and compared with several available
educational operating systems. Next, we give our rationals for Java as
the TOS implementationlanguage.. Then the architectureof the system
and its components - launchers and servers are described. Finally we
explain the advantagesof this architecture and provide some information
on its implementationand portability.

I. Introduction

Among the central components of any undergraduate computer science curriculum is that of
the operating system. No professional programmer, administrator, or analyst can do their jobs
effectively without a fundamental understanding of how operating systems are designed and
implemented.
There is no real substitute, in learning how software works, to actually dealing with the source
code. Commercial operating systems are manifestly unsuitable for this purpose. The source
code of most is a closely guarded trade secret; even when it is not, the source code base is far too
large for students to be able to grasp quickly. There are usually optimizations liberally scattered
in a commercial system, optimizations that do improve performance considerably but detract
from readability.
For this reason, there are now in use many purely educational operating systems, with a much
simpler set of features and smaller code base, generally designed and implemented entirely by
academics. Some of these boot directly from the hardware, but the majority either run over a
native operating system or over a software simulation of the hardware.
The majority of educational systems today rely heavily on the stand alone uniprocesor approach
to operating system construction, which has dominated both the industry and academia for
nearly a quarter of the century. It must be realized however that this traditional framework does
not reflect the current trend in operating system design.
One of the most important developments in computing today is the distributed system. In
commercial settings, applications are already routinely constructed that run over many different
computers of different architectures. Catching up to this is the distributed operating system, one
that runs on many computers simultaneously, and provides applications with a single system
image regardless of what location the application happens to be situated in.
Distributed educational systems in use today, such as Amoeba [7] suffer some of the same
limitations as commercial systems; they are sufficiently large and complex that their source code
does not lend itself to thorough examination in a one-semester undergraduate course. In addition,
it is important that the impact of the distributed paradigm not totally overshadow the
fundamentals of the operating system concepts. The future likely holds for a mixture of single-
computer and multi-computer operating systems, not the elimination of the former entirely.
For these reasons, there is a definite need for an educational operating system sufficiently simple
to cover the core topics of operating system design, and yet includes many of the key features of
distributed systems.

Most unicomputer operating systems have a monolithic kernel, to provide the performance
required by commercial applications. In a distributed environment, such an architecture loses a
good deal of its usefulness. Since the kernel must be accessible on every machine in the system.
it would be necessary to place its copy on every machine. This leads to a potentially enormous
amount of redundancy and sacrifices most of the advantages of using a distributed operating
system in the first place, since the end result is essentially a networked set of machines each
running their own kernel.
The alternative would be to place the kernel on one machine to which every other machine
must make calls in order to utilize system services. Such an approach is inherently unscalable.
Were the distributed system to grow very large, the strain on the machine running the kernel
would inevitably become unsustainable.
Instead of the monolithic kernel then, a design scheme that has gained increasing popularity in
recent years is the microkemel approach. In this paradigm, every machine hosts only a small
part of the traditional kernel. The rest of it is delegated out to machines designated as servers.
Each server offers only a specialized subset of system services. One machine acts as a file server,
another as a device server, and so on. There can be more than one server machine for each type
of functionality.
This is a more scalable approach, since system expansion can be matched by increasing the
number of servers to match. It is also more modular and modifiable, since any one server
component can be replaced without having to rewrite other components, as long as the defined
interfaces between components remain the same.
Unfortunately, few educational operating systems, as yet, make use of this technique in a way
that is simple and small enough for students to easily observe. This is unfortunate, as it can leave
students with a mistaken impression that the traditional monolithic approach is the only effective
way to build operating systems.

Being educational does not spare an operating system from some of the same pitfalls that bedevil
commercial systems. Perhaps the single biggest problem is portability. Different academic
settings use a widely variegated set of hardware and native operating systems. An educational
OS written for one platform usually does not port easily to another without a good deal of effort.
Instructors often cannot use the product they would prefer in their courses because they do not
have access to the platform needed to run it.
This paper describes TOS - an educational operating systems developed as an honours
computing project [5]. The main goal of this project was to design and implement an operating
system with a microkernel-based structure. It was to be run in a distributed environment
without obscuring the core functions of an operating system. It had to be implemented in Java to
facilitate portability, and to support user applications also written in Java. Assumptions about
the host operating system had to be kept to a minimum. Native code, if it were to be used,
would almost certainly end up using platform-specific functions that would only confuse
students. This did impose some constraints on the system where the use of native code would
have simplified matters. In the commercial world applications written in Java often are forced to
rely on short sections of native code. Even the Java class libraries themselves contain substantial
amounts of native code.
The system was to be extendible, so it could be used not only for some senior-level computing
projects, but to the point where it would be viable for use in commercial distributed Java
applications. For this to be possible, its design had to be scalable to a large number of running
hosts and users, and had to be written with a later goal of commercial usage firmly in mind.
The rest of the paper is organized as follows. Section 2 reviews several educational operating
systems and operating systems implemented in Java. Section 3 gives our reasons to select Java as
the TOS implementation language. Section 4 outlines the overall architecture of TOS, while
section 5 provides some information on TOS implementation and portability.

2. Related work

There are two groups of work related to ours - educational operating systems and
operating systems implemented in Java.

2.1. Educational Operating Systems

The best known (at least to us - we have used all of them in our courses on operating systems)
are probably Nachos, Xinu and MINIX.

Nachos [ 1] developed at Duke University in 1994, is tied very firmly to the MIPS hardware it
was originally built upon. Nachos is built upon a simulator of the MIPS processor, complete
with interrupts, a clock, and paging system. The kernel, running on this machine, provides thread
switching, a simulated virtual disk and file system, and synchronization and process handling
services.
Nachos suffers a number of disadvantages. Its use of a MIPS simulator obscures its teaching
effectiveness for students unfamiliar with MIPS hardware. The kernel also has no bootstrap
mechanism of its own; the only way a user can start the system was by cross-compiling an
application to run over Nachos, which would then be linked statically with the Nachos kernel.
This places limitations on how effectively students could see the inner workings of the system.
There were few utilities to actually view and observe system contents or data tables.
Nachos does have some innovative features. One, imitated by TOS, was in simulating a virtual
disk drive rather than merely building a file system on top of a host file system. In this way,
students get to see the ins and outs of low-level I/O to disk that cannot be as easily made clear by
an approach like that of Xinu (see below).
Xinu ('Xinu Is Not Unix') developed by D. Comer et al [2] at Purdue University to run over a
number of hardware platforms and under a number of native operating systems, is more amenable
to porting than Nachos. Xinu provides a nearly complete range of system services, but in other
respects relies heavily on its native system for support. Its file system, for instance, is merely a
wrapper to the underlying native file system. As with Nachos, users use a cross-compiler to
create programs; further, they even have to link it directly with the Xinu kernel in order to run
their applications! Thus the only effective way for the user to run more than one process is for
one process to explicitly create another.
The Xinu code base contain liberal quantities of platform-dependent code. Students are forced
to wade through dozens of references to native OS functions that are not documented in the Xinu
text. They have only the function's name from which to infer its operation, and this only
detriments their understanding of Xinu operations.
Despite its name, Xinu does offer many similarities to UNIX. It also offers a well-organized,
comprehensive, and neat system architecture.

Minix [6] (Mini Unix) was developed by A. Tanenbaum and his students in mid-1980s to
substitute UNIX, when it became unavailable for study. It is quite large system (around 27 000
lines of code), much larger than Nachos and XINU. Like UNIX, MINIX was written in the C
programming language and was intended to be easy to port to various computers.
MINIX was originally designed for compatibility with Version 7 UNIX, but was later modified
to comply with the POSIX standard. It is a stand alone, single processor OS running on bare
hardware. It strongly depends on the hardware components and their configuration.
It is interesting to note, that resistance by A. Tanenbaum to further enhance MINIX by its users
led to development of Linux.

2.2. Operating Systems in Java

The best known Java-implemented operating system is of course JavaOS [4], the Sun's platform
for Java, intended for use on legacy computer systems, network computers (NCs) and a wide
variety of embedded devices and appliances. JavaOS provides all the functionality of an
operating system on which Java programs can be run.
It might be thought that TOS could be built using JavaOS as a reference model. Such an
assumption would be mistaken. JavaOS bears little resemblance to TOS, either in its targets or
its basic design philosophy. For starters, it is not a distributed operating system, but a
unicomputer operating system intended merely to be portable even to small handheld devices or
household appliances.
Secondly, despite its name, JavaOS is not entirely written in Java. All operating systems must,
at some point or another, deal directly with the hardware, and that means a layer of native code
is essential. The core of JavaOS is thus written in C. Use of C code would violate one of the
key requirements of TOS, that it be implemented entirely in Java.

JavaSpaces, not JavaOS, is the nearest thing Sun has to a distributed operating system.
Like TOS, JavaSpaces is based on the principle of providing a unified, consistent set of services
for distributed applications already running on top of a native operating system with its own
copy of the Java virtual machine. However, emulating its design would not be advisable for an
educational system.
Fundamentally, JavaSpaces offers just three operations - write, lookup, and take, with which
applications can pass information into and retrieve it from an object called a space, which acts as
an object-independent repository for data. Distributed application developers may find this
highly useful, but students learning how operating systems work will not. JavaSpaces is, after
all, not an operating system but a framework in which distributed applications can be deployed.
It is true that frameworks dominate the marketplace today and exclude true distributed operating
systems, but that may change.

3. Rationals for Java as the TOS implementation language

The widespread acclaim that Java is receiving in both academia and industry is well
justified. The language cannot truly be said to incorporate the very latest advances in
programming language theory, but nonetheless it manages the rare feat of providing a base for
robust, stable programs while giving programmers many casual similarities to C++.
As a programming language, Java eliminates many of the criticisms that can be made of the
previous industry language standards, C and C++. Java boasts language-level support for threads
and runtime exceptions. It compiles to a platform-independent bytecode that makes porting to
other hardwares very nearly trivial. It is fully object-oriented, not a hybrid like C++. Its use of
automatic garbage collection for out-of-scope objects and its deliberate lack of a pointer
mechanism make impossible some of the most frequent and expensive bugs in C++ programs.
The use of Java as both the system language and application language naturally has a considerable
impact on the layering of the system. Certain facilities that traditionally are part of an operating
system have been omitted from TOS completely without compromising the system's quality.
These are:
a) Scheduling.
Threads are a part of the Java language and their scheduling and context switching is the
responsibility of the Java Virtual Machine. Providing a separate threading mechanism fo TOS
would have been reinventing the wheel. Instead, TOS has extended the Java threading mechanism
to allow communication between and coordination of threads located in different virtual machines
on different computers.
b) Memory management.
Java programs do not have to worry about memory. The Java Virtual Machine (JVM) provides
applications with all the memory they need. The JVM handles the nuances of obtaining more
memory from the underlying host operating system. Java programmers do not even need to
concern themselves with returning memory they no longer need to the system, because of the
JVM's automatic garbage collection mechanism which automatically deallocate objects with no
references to them. Any concept of a global, TOS-wide stack or heap would be both redundant
and unnecessary, and has therefore been safely omitted.
Version 1.1 of the Java Development Kit (JDK) introduced the Remote Method Invocation
system (RMI). This is the component that makes TOS possible. RMI makes possible the
seamless invocation of a method of a remote object as if it were local. Every one of the server
processes in TOS is such an exported remote object whose functions are thus easily accessible to
any client process.
The JDK comes with a simple tool, rmiregistry, which can be run from the command line or
invoked via the static library function Registry.createRegistry O. This tool sets up a network
port on which to listen for remote calls. Any client can look up objects exported to that port
using the Naming.lookupO function, which takes a URL as an argument.
When clients make use of a lookup function, the RMI libraries return a remote stub object, which
to the client is a remote object. The client is then free to make remote calls freely, without having
to concern itself at all with the distinction between local and remote.
Remote stubs are serializable objects. This means they can be passed as parameters to other
functions or even to other processes. TOS makes considerable use of this; it is, in fact, the main
method different servers use to keep track of system objects. Any pipe server can thus deal with
any pipe; any synchronization server can deal with any synchronization object.

4. O v e r v i e w of TOS

4.1. TOS Architecture and Components

TOS may run on any number of machines, as long as they are connected on a single
physical network, intranet, or the Internet. TOS consists of two kinds o f components -
launchers and servers. Launchers contain the basic TOS functionality, while most od the OS
services are provided by servers.
To start TOS on a machine a user must first run a launcher program on this machine. The first
launcher to run will start up a filename server, pipe server, and sync server. Other launchers
must connect to an already-running launcher.

Ad.r~
/

LW~Q~
"Lrnm~.~)" c~m.E
!

I
I lariat
a:z [-~tls[ 1
. . . . . . . . . ------. . . . .

i
. . . . . .

~eL'W]"~t'l~e~gells
peec ¢mmecwlL [---t i Fk~

P ................... t~e

Fig. 1. TOS architecture and components.

Launchers have three basic responsibilities:

a) Starting and stopping servers

 Most computers do not permit a program running on another machine to remotely start a
process. To get around this, a launcher must be started directly by a user on every host that will
be running TOS server components. Once the launcher is in place, it can make use of the Java
Runtime.exec0 function to launch other servers. Similarly, launchers can be employed to force
the shutdown of any running server.

b) Providing access points

End users never see the servers, only the launchers. The launcher signifies the presence of TOS
on a host and is the single point to which user-written applications connect to deal with the
operating system. Remote references to other servers are not obtained directly but are provided
by the launchers.

c) Maintaining system tables

Launchers maintain lists of every server running on the system, for the purpose of being able to
provide this information to the user (via the Administrator) and to be able to add and remove
servers easily. Arguably, this is redundant, since the servers themselves o f necessity also
maintain lists of other servers of their class, but it is also more robust. The risk of inconsistency
is there, to be true, but TOS carries out updates to the tables in the launchers simultaneously
with those in the servers, so it is not a worrisome factor.

Most o f the functionality o f TOS is provided in servers. There are 4 types o f servers
implemented at present - filename servers, disks servers, pipe servers and sync servers.

Filename servers are responsible for holding the tables mounting disks to directory names.
Every time a user program wishes to open a file, it must ask a filename server for a reference
to the correct disk server.

Unlike other servers of the TOS system, a single machine may have more than one disk server.
Each disk server maintains its data in a single physical file on the host system. The launcher on
that host keeps track of the disks.

Pipe servers are responsible for the running of the TOS interprocess communication system.
They provide a full-duplex method for two threads in different TOS processes to exchange data
asynchronously. User programs can create a pipe by name; other programs connect to the same
pipe by its name, without having to know any of the details of the pipe's creator and its location.
Both ends of the pipe can even be passed as parameters to other threads or processes without
affecting the other end, or even data already within the pipe. The actual sending and receiving of
data is carried out by the pipe servers.

Sync servers manage the objects that TOS user programs use to coordinate access to shared
resources or act in parallel -mutexes, semaphores, and signals. Their functioning is very
similar to that o f pipe servers - user programs can create an object and pass it freely to other
processes.
When the first launcher of the TOS system is started, it creates one filename server, one pipe
server, and one sync server. Each new launcher that starts connects to the three existing servers.
Thus, each launcher has one connection to one server of each type, which is referred to here as its
default server.
Launchers change their default server if the Administrator has them start a server on their own
host listening on their port. Whenever a user process needs a reference to a server, it asks its
launcher to provide one. The launcher will provide it the reference of its default server. Each
server is connected to every other server, so a reference to one, is, in effect, a reference to them
all.
For example, to use any pipe in the system it does not matter which pipe server a user
application is connected to. If a pipe server does not contain the pipe requested by the user, it
will refer the user over to the correct pipe server transparently. At no time does the
application programmer even need to know where the pipe is. The same is true ofsync objects
and sync servers.
User processes also have a default server, which will simply be the same of the launcher they
connect to on startup, which will in turn be the same as the console that started them, if they
were started from a console.

To administer the system, the user must run the GUI Administrator program. This can be run
from anywhere on the network, not necessarily a machine running a launcher. Once it connects
to one of the launchers, it can display information about the hosts in the TOS system, the
running processes, servers, and disks, and individual pipe and synchronization objects. N e w
servers and disks can be created or removed from the system; deadlocks can be broken by killing
processes or directly manipulating pipes or synchronization objects.

TOS also has a Console program, providing a command-line shell through which users can
navigate the file system and create and destroy files. They may also edit, compile, and run Java
programs directly.

User applications that make use of TOS are derived from an abstract class created for this
purpose, called TOSProcess, that provides access to system services without permitting subclass
developers to see the details of the implementation.

4.2. Advantages of the TOS architecture

a) Incremental Extendibility

A new launcher, server, or disk can be added at any time and removed at any time without
affecting the functioning of the rest of the system. User programs need not have to worry about
the physical location of disks, servers, and launchers. The single launcher they connected to will
provide them access to the entire system.

b) Universal Access Points

An application program, upon starting up, has only to connect with one launcher. That launcher
will provide the application, either directly or indirectly, with all the references to servers and
disks that it needs, regardless of their locations. The nuances of dealings with servers and disks
are in hidden sections of the user application, leaving the programmer with largely hassle-free
use of TOS system services.
The same principle is applied within the TOS architecture itself. Launchers do not have to search
for and make direct contact with individual servers; each one maintains a reference to a single
server of each type and uses that reference to access the entire subsystem. The only exception to
this principle are disks, which have to be persistent and therefore deal directly with their
launcher.

5. Conclusions

The system described in this paper was designed, implemented and tested on three
platform - Macintosh under MacOS, PC under Windows NT and SGI under IRIX.
TOS does have explicit installation files for Windows, UNIX, and the Macintosh, but porting to
other platforms will be almost trivial. The only platform-dependent code is a small if-elseif
structure to choose the look and feel for GUI components, a single line of code in the console in
which user applications are run, and the native packaging used to start TOS executables.
In comparison with some other educational operating systems, TOS is relatively small - 11 000
lines of code, yet it represents not only the current trends in commercial operating systems but
goes much further ahead. We can conclude therefore that the goals set at the beginning of the
project have been reached. We are working now on some extensions to the present version of
TOS and on its inclusion in our operating systems course.
The source code and full documentation of TOS is available for downloading on our web side [5]
subject to copyright and to the conditions of the GNU Public Licence.

References

1. Anderson, T., Nachos, http://www.cs.berkeley.edu/~tea/nachos

2. Comer, D. and Munson, S., Operating System Design Vol. 1: The Xinu Approach, Englewood
Cliffs, Prentice Hall, 1989.

3. Downing, T.B., Java RMI: Remote Method Invocation, New York: IDG Books, 1998.
Microsoft Corporation, Microsoft Developer Network Library, July 1998 Edition,
Redmond: Microsoft, 1998.

4. JavaOS, http://www.sun.com/javaos/, Sun Microsystems Inc.

5. Nicholas, T., A Microkernel-Based Educational Operating System in Java, Dec. 1998,

COSC4F90 Project proposed and supervised by J.A. Barchanski,
http://www.cosc.brocku.ca/Offerings/4F90/info/nicholas/
6. Tanenbaum, A. S., Woodhull, A.S., Operating Systems: Design and Implementation,
Second Edition, Prentice Hall, 1997.

7. Tanenbaum, A. S., Distributed Operating Systems, Prentice Hall, 1995.

10