Making Paths Explicit in the Scout Operating System

Mosberger, Petersen (1996)

Unifying theory: there are a bunch of instances of paths, each of which tackles a specific problem. (It's basically a framework for thinking about how to violate layering and abstraction boundaries.)
It's mostly a paper about abstraction and then how that abstraction is manifested in an implementation.
This paper is particularly interesting, because there is no eval per se. There are some numbers to demonstrate principles, but it's really all about the abstraction.

Once upon a time people began separating code functionality out into well-defined layers with strong interfaces between them. These interfaces encouraged modularity, improved clarity and enabled the development of larger and more complicated systems. At the same time, this layering frequently introduced a performance hit as data moves between the layers, sometimes being copied at each layer. The authors develop and propose a framework that views the flow of data from a source to a sink as a path. They realize this abstraction in Scout, which is a pretty stripped down system, but provides a path abstraction and implements a video player (MPEG). Their clean architecture and improved throughput convince everyone to adopt paths so that they can live happily ever after.

Data path from source to destination.
Once data is enqueued, its destination is known.
Paths are assembled in two phases
1. Using local information, a feasible path is found
2. Use transformation rules to produce a shorter/more compact path
Data can be transformed as it traverse a path (including creating more packets or combining packets).
Routers: the units in a path that perform specific tasks.
Routers may have dependencies on other routers.
Conceptually, routers may be anything from basic blocks to procedures.
Routers have input/output queues.
Paths can be bidirectional, so you basically have two pairs of I/O queues.

Single address space operating system
Goal: Interact with existing network protocols
Non-goal: POSIX compliance
Router is the unit of modularity
It seems that there are many things that don't necessarily fit into this (i.e., "the rest of the kernel") - I wish they had at least mentioned this and told us how much of the kernel is "conventional." My gut instinct is "a lot"
In some ways, it seems that there is similarity in target domain between Scout and Nemesis.

Think of a router as a chunk of functionality -- IP
A router implements one or more services (methods)
Services have a name and type
Names are unique, but arbitrary
Types define interfaces: one interface says what the type provides and the other says what isDt requires. (Types provide inheritance.)
Router declarations indicate how routers can be connected
Path consists of a series of stages (each router in a path is a stage) (stages connect services).

Paths get executed by threads.
Threads are non-preemptive. (May allow for uncooperative threads in the future.)

In lieu of an evaluation we have a sample application
A few measurements are designed to highlight its performance, but the point is really to show how the implementation is realized in the context of an application.
What do people think about this?
If you actually read this comment, send me an email; my theory is that no one actually reads my notes.