Evaluation #4 Zhanhai QIN

zqin@cs.ucsd.edu
Tue, 18 Apr 2000 08:00:20 -0700 (PDT)

Thanks. Hope is not too late. It was raining hard.

Yours sincerely

Zhanhai QIN

**************************************************
http://www-cse.ucsd.edu/users/zqin

Mailing addr:
9152-F Regents Rd.
La Jolla CA-92037

Office addr:
VLSI CAD Lab (4550)
Applied Physics & Mathematics bldg.
UCSD

Phone:
858-534-8174

Pilot: An operating system for a personal computer
--------------------------------------------------

1. Overview of the paper
As an OS for a personal computer, it emphasizes
close user/system cooperations, but tends to
deemphasize the largely ajudicatory role of a
monolithic time-sharing system.

Pilot omits certain functions such as user-command
interpretation; such facilities are provide by
higher level software, if needed. On the other
hand, Pilo provides a more comlete set of
services than is normally associated with the
"kernel" or "nucleus" of an operating system.

Protection mechanism: defensive but not absolute.
Because in a single-user system, errors are
a more serious problem than maliciousness. All
protection in Pilot ultimately depends on the
type-checking provided by Mesa, which is
extremely reliable but by no means impenetrable.

Resource allocation mechanism: Pilot doesn't
deal with how to fairly distribute the
scarce resources among contending parties.
Shortage of some resource must generally be
dealt with either through more effective
utilization of by adding more of the resource.

2. Pilot features:
a)Hierarchical virtual memory ;
b)a large "flat" file system ;
c)streams ;
d)network communication facilities(Package);
e)concurrent programming support .

3. Pilot Interface(Definition Modules):
"Public" interfaces defining the services
provided by Pilot to its clients;

"Private" interfaces, which form the
connective tissue binding the implementation
together.

Interface.Item
Item includes: types, procedures, constants,
and error signals.

(3.1) Files.
Two interfaces: File and Volume.

(3.1.1) Files have no recognized realtionships
among them.

(3.1.2) UIDs for distinct files created anywhere at
any time by any incarnation of Pilot are distinct.

(3.1.3) Only 4 attributes attached to each file:
size: 0 ~ 2^23 x 512 bytes ;
type: 16-bit tag for recovery of file system;
permanence: for files holding valuable information;
immutability: never editable.

(3.1.4) The abstraction presented at the Volume
interfaces is acturally a logical volume.

Physical Volume 0 \
Physical Volume 1 - Logical Volume i
Physical Volume 2 /

/ Logical Volume 0
Physical Volume i - Logical Volume 1
\ Logical Volume 2

(3.2) Virtual memory.
Interface: Space.

Allocation Entity:Space could be nested.
Mapping Entitity: Space should be mapped before
the pages in it is refered.
Swapping Entity: Subdividing the mapped spaces.
Further optimization:
Space.Activate
Space.Deactivate
Space.Kill
Space.ForceOut

(3.3) Streams & I/O devices
Interfaces: Transducer and Filter.

Implicitly, file <-> virtual memory;
Directly, driver interface;
Indirectly, stream facility.

Flexibility but not protection is required.

Transducer: a module which imports a device driver
interface and exports an instance of the Pilot
Stream interface.
Filter: a module which imports one instance of the
Pilot standard stream interface and exports another.

Client -> filter 1 -> ... -> filter n -> Transducer -> Device.

(3.4) Communications
Interfaces: Socket and NetworkStream.

Tightly coupled processes: Shared memory;
Loosely coupled processes: communication protocols.

Socket interface: It's like a virtual device;
NetworkStream: It's implemented as a transducer, which
converts the device-like socket interface into a Pilot
stream.

NetworkStream works as:

Server Listens... <-> ...Clients requests

(3.5) Mesa Language Support
Pilot provides recursive procedure calls, coroutines,
concurrent processes, signals, and "world-swap" facility
for debugging.


4. Pilot Implementation(Program Modules):
Manager/kernel pattern: a given facility is implemented
in two stages: a low-level kernel provides a basic core
of function, which is extended by the higher level manager.
Layers interposed between the kernel and the manager can
make use of the kernel and can in turn be used by the
manager. It's quite like policy/mechanism pattern.

Difference between file manager and vm manager:
File manager is on filter kernel, while vm manager
was on swap kernel. File manager deals with file creation
and deletion, while vm manager deals with more complexed
virtual memory operations, such as traversing subtrees
of the hierarchy of nested spaces and maintaining the
hierarchy.

The swapper:
The swapper, or virtual memory kernel, manages primary
memory and supervises the swapping of data between mapped
memory and files.

Hierarchy: Constituting the funcamental representation
behind space interface.
Swap unit: The smallest set of pages transferred between
primary memory and file backing storage.
Projection: Containing all the description of swap units,
and is used to update the swap unit cache.

The robustness provided by the scavenger can only guarantee
the integrity of files as defined by Pilot(!).

5. Personal comments on the paper:
I think the trend the paper follows is correct. That is,
OS on personal computers should be more concerned with better
user/system interface and flexibility but not protection
mechanism. And the stream machanism is a very good way to
provide flexibility and friendly user interface as well.

-------------------------------------------------------------

Sharing and Protection in a Single Address Space Operating System
-----------------------------------------------------------------

1. Overview

The paper discussed Pro's and Con's of a singel address space
operating system, Opal, versus the conventional model of private
virtual address spaces for each executing program. The paper
concentrated on Opal's support for sharing and the use of protection
structures.

Every program can see all data in the system, but it
will generally not have the right to access all of that data;
the protection domain in which that program executes defines its access
rights(capability), limiting its access to a sepecific set of pages
at a specific instant.

2. Overview on private virtual address space OS
Pro's:
a) Larger address space available to all programs;
b) Hard memory protection boundaries;
c) Being easy to cleanup when a program exits.

Con's:
a) The mechanism for memory protection presents obstacles to efficient
cooperation between protected application components. (e.g. pointer-based
information sharing pattern must be known statically)
b) The primary cooperation mechanisms rely on copying data between
private virtual memories. It's expensive and inconvinient for large or
sparsely used data structures.
c) Poor tradeoffs among protection, performance, and integration. (i.e.
multi processes sacrificing performance vs. single process sacrificing
protection.)

3. Overview on Opal
It preserves Pro's of traditional OS and has the following Pro's as well:
a) Separating program execution, resource ownership, and resource naming
from protection domains makes memory protection cheaper, easier to use,
and easier to change.
b) The independence of protection and addressing substantially increases
flexibility.

4. Sharing and Trust
Protection structures do not impose modularity, they only enforce
selected module boundaries. In any case, shared data should be accessed
through procedural interfaces, and protection structures should be flexible
enough to permit application-specific choice of how modularity is enforced.

5. Mechanisms for management of single address space

The Opal units of storage allocation and protection are segments. The
Opal units of execution are threads. A protection domain is an execution
context of threads, restricting their access to a specific set of segments
at a particular instant in time. Those protection domains are called
capabilities. A process can request a partricular access rights to the
segment, but cannot specify more rights than are permitted by the capability.

In Opal, shared memory is the primary form of sharing and communication
between trusting threads in different protection domains.

The child of the parent fully trusts the parent, but not vice versa.

The essentials of linking and execution are the same in both classes
of systems; sharing and dynamic use of code modules is easy in the shared
address space; and support of private data in shared modules is trickier
in some respects.

The basic storage management mechanism is explicit reference counting,
which applications and support facilities use to allocate and release
untyped storage in coarse units. "Resource Groups" and "Reference Objects"
are used trickily in managing reference counts.

6. Issues for single address space approach
The tradeoffs are related to the inability to use context-dependent
addressing in single address space systems. That is, private address systen
often benefit from the assignment of different meanings to the same address.

The loss of contiguity in memory allocation; conserving address space
if address space is limited; Unix could not be built above a native Opal
kernel; The absense of remapped copying.

7. Personal comments on the paper:
I believe Opal is promising and significant because it exploits modern
64-bit processors to meet the goals of previous systems in a way that is
simple, general, and efficient.