http://nikitadanilov.blogspot.com/2005/03/rsx.html
2005/03/24
RSX
[expanded. 2004.03.25]
Lately, I looked through sources of RSX executive at bitsavers.org. RSX (which stands for
Realtime System eXecutive or Resource Sharing eXecitive) is a collective name for the series
of operating systems DEC developed for its PDP processors. [full text follows] Initial
version was RSX-15 developed for PDP-15 processor (a member of 18b family of DEC processors
---poorer and ultimately abandoned cousins of another branch that got us PDP-11) by Sam Reese,
Dan Brevik, Hank Krejci and Bernard LaCroute. See: a bit of history, original design, official
DEC reference manual. Later on, RSX was ported to PDP-11 (yes, version numbers can very well
go down), resulting in succession of RSX-11A, RSX-11B, RSX-11C, and RSX-11D, the latter being
full-blown operating system, multi-user and multi-tasking. You think it's quite an achievement
for a platform with 32K bytes of primary storage? Obviously David Cutler wasn't impressed, as
he re-wrote it from scratch to consume less resources giving birth to RSX-11M (and later to VAX
VMS, and Windows NT). Unfortunately, no RSX-11 kernel sources seem available (neither A-D, nor M
and beyond versions), except for little witty pieces here and there (bitsavers, however sports
materials from DEC's classes on RSX-11 internals). XVM/RSX-15 sources are available at bitsavers:
* Executive proper: P1 and P2, and
* MCR (Monitor Console Routine)
Why would one waste time looking through the obscure non-portable kernel that ran on a hardware
decommissioned quarter of century ago? A lot of reasons:
* It is radically different from UNIX, which is, basically, the only publicly available kernel
source base to-day.
* It was written at the times when computing was still young and engineers didn't take a lot
of things for granted, so one can see how and why they come to their designs.
* It's rather small by nowadays standards and easy to understand.
* It has surprisingly good comments.
* It was one of the first and probably (for quite a long time) largest open-source projects: hundreds
of megabytes of software for RSX were available in the source form (DECUS tapes)
* I agree with the sentiments R. Pike, esq. expressed in Systems Software Research is Irrelevant
article (also see Rik van Riel's note): modern operating system research revolves around (or,
rather, inside of) a cluster of well-known old ideas. By looking at the roots of operating
system development, one sees that these ideas are but choices.
* Nostalgia, of course. At the end of 80s I worked on some PDP clones: Ðлектроника-100/25, СМ-4.
At the center of RSX-15 is its executive, also known as monitor or kernel. This is small program written
in PDP-15 assembly language, that maintains following abstractions:
memory partitioning
rudimentary memory management scheme. Memory is partitioned during system generation into partitions
and common blocks.
task and scheduling.
Task is a machine code that can be executed under control of executive. Task is installed when
it is known to the executive (specifically, registered in STL---global System Task List). Tasks
are created by task builder---special task that builds task by linking relocatable code with
libraries and storing task on disk in the same format it will be stored in the primary storage
(i.e., task loading is just copying it from disk to the core, which is important for real-time
operating system). Some tasks are resident, which means they are always in core. Installed task
may be requested for execution (placed into ATL---Active Task List), and get its share of processor
cycles subject to priority and memory constraints. Simple fixed priority scheme is used. Memory is
managed on partition granularity: each task has a partition assigned to it during build, and will
be loaded into core when said partition is free. Partition can be used for one task only.
interrupt management
executive itself handles clock interrupt only. All other interrupts are handled by special IO
Handler Tasks (IOHTs), any installed task may become IOHT by connecting to interrupt line.
device management.
list of physical devices and mapping between physical and logical units (LUNs). Per-device
prioritized IO queues. Asynchronous IO as a default mechanism. LUNs are global.
interface to space management for disks
bitmap of free blocks. Implemented by IO handler task, not executive.
interface to simple flat file system.
Implemented by IO handler task.
[...To be continued...]
Here are some interesting features:
* usage of API (Automatic Priority Interrupts) to implement concurrency control.
In RSX-11M this was replaced with FORK processing: interrupts never directly access
kernel tables, hence, no synchronization is required on the uniprocessor. Similar to soft interrupts.
* separation of STL (system task list) and ATL (active task list)---a form of two level
scheduling: long level scheduling decisions are made by installing task into STL,
and assigning resources (devices and core partitions) to it. Short term scheduling
is done by scanning ATL which is sorted by task priority.
* interrupt is viewed (and used) more like asynchronous goto, rather than asynchronous
procedure call. For example, there is a procedure that scans ATL (active task list,
sorted by task priority). Interrupt may add task to the ATL, and so scan has to be
restarted if interrupt happens during it. To achieve this, interrupt handlers do a
jump to the address stored in L6TV ("Level Six Transfer Vector"). When normal task
runs, L6TV points to the routine that saves registers in the task's "core partition".
When ATL scan is started, L6TV is modified to point to the ATL scan procedure itself.
As a result, if interrupt happens, scan will be restarted automatically. Note, that
interrupt handlers do _not_ save registers in the stack (they do not create stack frame).
* "pseudo partitions" that overlay IO memory used to control devices from non-privileged tasks.
* RSX is a radical micro-kernel: the only thing executive handles is processor scheduling.
Everything else (including processing of interrupts other than clock) is handled by tasks.
One consequence of this is that executive interface is fundamentally asynchronous: most
calls take event variable as an argument, and calling task may wait for call completion by doing
WAITFOR eventvar
This is impossible to do in UNIX where system calls are served on the kernel stack
permanently attached to the process. In UNIX, kernel is a library executing in protected
mode, while RSX is a collection of autonomous tasks each running with its own stack
(this architecture, of course, requires very fast context switches).
* file system as special device driver layered on top of driver for underlying stable
storage device: file oriented device. Note, that this also unifies the notion of file
and device, but... other way around.
* SEEK call is used to open particular file on a devcie. After that LUN is effectively
narrowed (in EMACS sense) to mean opened file.
* all executables are known to the executive (listed in STL).
* system image can be stored on the permanent storage (by SAVE) and booted from (warm start),
like in Smalltalk or LISP system.
* instead of having separate run-queues and wait-queues, tasks are kept in single
ATL. As the only synchronization mechanism available is event variable, "scheduler"
simply checks whether waiting tasks can be run while scanning ATL.
* tasks are so light-weight that clock queue (callouts in UNIX terms) is a list of
tasks rather than functions.
* each task provides its own procedure to save its context on preempt
* no security of any sort. Give them enough rope.
Posted by: nikita / Thursday, March 24, 2005