RMoX: A Raw Metal occam Experiment - University of KentRMoX { A Raw Metal occam Experiment 1/30...

RMoX – A Raw Metal occam Experiment 1/30

RMoX: A Raw Metal

occam Experiment

Fred Barnes† ([email protected])

Christian Jacobsen† ([email protected])

Brian Vinter‡ ([email protected])

† Computing Laboratory, University of Kent

‡ Department of Maths and Computer Science,

University of Southern Denmark


Contents

• Introduction

• Dynamic occam

• Design:

– the ‘kernel’

– device drivers

– filesystems

– networking

– top-level and console

• Implementation:

– accessing hardware

– real and user-mode RMoX

• Conclusions


Motivation

• Do we really need another OS ?

• Most existing operating systems suffer:

– from software error

– from high overheads

– a lack of scalability

• We want an operating system that:

– has a rigorous design

– is free from software error

– is fast!


Introduction

• Raw Metal occam:

– runs on the “raw” hardware

– with some help from

the UTAH Flux OSKit

– and a modified KRoC

run-time system

• CSP design

• Dynamic occam implementation


Dynamic occam

RMoX extensively uses two of the new dynamic

features of KRoC/occam:

• mobile channel-bundle ends

• dynamic process creation (fork)

These support:

• dynamic network expansion and

re-configuration

• scalable server farms


Mobile Data

• Provides a movement semantics for assign-ment and communication

• Implementation supports both static anddynamic mobiles

• Unit-time assignment and communication

• Unit-time ‘garbage-collection’ (strict alias-ing)

QP x

c ! x c ? y

c

c

P Q y

• ‘P’ can no longer access ‘x’ — compilerenforced


Mobile Channel-Ends

Ends of channel-types — structured bundlesof channels:

?! buf!req?

ret?buf?req!

ret!BUF.MGR

CHAN TYPE BUF.MGRMOBILE RECORD

CHAN INT req?:CHAN MOBILE []BYTE buf!:CHAN MOBILE []BYTE ret?:

:

• Channel bundles have two ends:“?” (or server) and “!” (or client)

• Direction of communication is specified(from the ‘?’ view)


Mobile Channel-Ends

server

BUF.MGR?generator

client

BUF.MGR!! ?BUF.MGR

Code to setup the network is trivial:

CHAN BUF.MGR! cli.chan:

CHAN BUF.MGR? svr.chan:

PAR

generator (cli.chan!, svr.chan!)

client (cli.chan?)

server (svr.chan?)


Mobile Channel-Ends

The ‘generator’ process creates the channel

bundle then communicates the ends:

PROC generator (CHAN BUF.MGR! cli.chan!,

CHAN BUF.MGR? svr.chan!)

SEQ

... create channel bundle

cli.chan ! buf.cli

...

:

After the client end is communicated:

server

BUF.MGR?BUF.MGR!

BUF.MGR

!

?

generator

client


Mobile Channel-Ends

PROC generator (CHAN BUF.MGR! cli.chan!,

CHAN BUF.MGR? svr.chan!)

SEQ

... create channel bundle

cli.chan ! buf.cli

svr.chan ! buf.svr

:

After the server end is communicated:

BUF.MGR?BUF.MGR! generator

BUF.MGR! ?client server

The ‘client’ and ‘server’ processes now

communicate directly using the channel bundle


Securely Shared Channel-Ends

Channel-ends may also be declared shared,

enabling the creation of multi-client multi-server

process networks

server

clients

SHARED BUF.MGR! buf.cli:

BUF.MGR? buf.svr:

SEQ

buf.cli, buf.svr := MOBILE BUF.MGR

PAR

server (buf.svr)

.. client processes using buf.cli



• Processes using shared ends must claim

that end before using the channels within

• A channel-end may not be moved whilst

claimed

The process body of a simple client could be:

MOBILE []BYTE buffer:

CLAIM to.svr

SEQ

to.svr[req] ! ...

to.svr[buf] ? buffer

... use ‘buffer’

to.svr[ret] ! buffer

But this prevents other clients/servers from

interacting...



clients servers


Dynamic Process Creation

(using the FORK)

• Allows a process to dynamically createanother process that runs concurrently

• Implementation supports the FORK of anarbitrary PROC, with parameter restrictions

WHILE testSEQ

...FORK P (n, in?, out!)

...

• Parameters to FORKed processes follow acommunication semantics, instead of re-naming semantics

• An alternative syntax would be easy:

P ! (n, in?, out!)


Design of RMoX

kernel

driver.core

network.core

consolefilesystem drivers

device drivers

network driversand protocols

fs.core

• Logical structure — client-server

• Built using channel-types and FORK

• Built with ‘plug-in’ components

• Scalable (as many components as needed)

• Dynamically extensible/degradable

• Fast (< 100ns comms/cxt.sw.) [P3-800]


The Kernel

kernel

clientprocesses

processessystem driver

• Acts as an ‘arbitrator’ for system services

• POSIX based interface

– but others are certainly possible

– DOS, VMS, ...

• Has special privileges for ‘process control’


Device Drivers

driver.core

ramdisk serial

keyboard VGA

keyboardclient process

hardwareaccess

hardwareaccess

hardwareaccess

requests

responses

• ‘driver.core’ manages individual drivers– started by FORKing them

• Requests for a specific device arepassed to the right driver

• Driver returns a channel-type-end forinteracting with the device

• Recursive channel-type is used to snapback the channel in on itself when done


Device Drivers II

serial

serial.1

serial.0

hardwareaccess

hardwareaccess

(driver.core)

• A top-level driver may actually be a

network of sub-processes

• Device naming scheme routes requests

appropriately

• Useful for hierarchical device structures:

– USB, IEEE-1284 (parallel), ...


Device Drivers III

serial

serial.1

serial.0

biosmem

hardwareaccess

hardwareaccess

bios data RAM

(driver.core)

• Drivers may request connections to other

device drivers

• Carefully controlled to avoid deadlock


Filesystems

driver.core

ramdisk serial

dev.fsramdisk.fs

fs.corerequests

responses

requests

responses

• Most filesystems will need a deviceto operate on

• Currently implementing a fairly traditionalUNIX-style file-system

• The ramdisk is mounted on / when thesystem starts up


File handling

ramdisk

user/systemprocess

ramdisk.fs

file.handler

• When a file or directory is opened,‘ramdisk.fs’ FORKs a handler process

• Handler processes (file or directory)return a client channel-end

• Handler services all requests on the fileor directory by using that channel end.

• Channel-end snapped-back to finish


Networking

serial.0

slip.interface interface

loopback.

multiplexIP checking

assemblerand fragment

proto.match proto.match proto.match

route

multiplex

servericmp

serverudp

servertcp

channel links to network controllerand application processes

checksicmp

checksudp

checkstcp

• Network infrastructure is from “occamnet”– a 3rd year project at UKC

• Clear and logical design


Networking II

servericmp

inboundpackets

outboundpackets

network.core

application

ping.worker

• Internal server-process structure similar toother RMoX server components

• Currently supported protocols are limitedto ICMP and UDP

– a simple DNS application exists

– NFS is a larger, but feasible, project


fs.core

driver.core

network.core

console

kernel idle.task

uptime.tick

log channel

PROC main ()CT.DRIVER? ct.driver.svr:SHARED CT.DRIVER! ct.driver.cli:... other declarationsSEQ

ct.driver.cli, ct.driver.svr := MOBILE CT.DRIVER... other initialisationsSHARED CHAN BYTE debug.chan:PAR

driver.core (ct.driver.svr, log.cli, debug.chan!)kernel (ct.kernel.svr, ct.driver.cli, ct.fs.cli,

ct.network.cli, log.cli)... other processesSEQ

SETPRI (31)CLAIM debug.chan?

idle.task (debug.chan?):


The console

vt220

vt220

matrix

vt220

vtkeyswitch

vgaplex

vt.handler vt.handler vt.handler

console log in

to kernel

vgadriver

link to

keyboardlink to

driver

to driver.core

consolesystem.

• Starts everything else off

• Handles the kernel log

• ‘system.console’ process providesprompt and basic commands


Implementation

• Hardware is accessed in one of three ways:

– IO port reads/writes

– memory-mapped devices

– interrupts

• Some devices may require polling:

– not generally recommended

– possible, with minor efficiency loss,

through the use of timeouts

• RMoX requires a lower-level interface for

managing these


Structure

occam applications

RMoX

RMoXdevicedrivers

CCSP/libs

OSKit

hardware

applicationsC

• OSKit manages memory, IO ports andinterrupts

• Once ‘allocated’, memory and IO ports canbe used directly from occam

• CCSP schedules occam processes– and controls execution of C processes

• Interrupts are handled using a combinationof the OSKit and CCSP


User-Mode RMoX

driver.core

ramdisk

ramdisk.fs

fs.core

keyboard

VGA

host.fs

requests

responses

requests

responses

occamfile library

libraryxtextwindow

• RMoX is simply a dynamic set ofcommunicating occam processes

– ... and can be run as a normalKRoC/occam application

• User-mode RMoX (UM-RMoX) provides anabstraction for hardware, using the existingRMoX interfaces


User-Mode RMoX II

• Allows the core components of RMoX to

be developed in a ‘regular’ environment:

– good test for language extensions

– significantly reduces test-debug time

• Cannot provide real hardware

– emulation is only an approximation

– IO port accesses are possible using iopl()

• Gives wider access for development and

experimentation

– student projects, ...


On-going Research

• Still under development, but progressingwell (delayed by thesis)

• Reasonable number of basic devices nowsupported:

– serial driver works well enough to launcha ‘system.console’ process on it

– using FIFOs and interrupt-driven com-munication

• Basic file-system driver support:

– ‘ram.fs’ and ‘dev.fs’ are implemented andwork correctly

– device filesystem mirrors the nested struc-ture of devices

• Very fast! :-)

RMoX: A Raw Metal occam Experiment - University of KentRMoX { A Raw Metal occam Experiment 1/30...

Documents

Transcript of RMoX: A Raw Metal occam Experiment - University of KentRMoX { A Raw Metal occam Experiment 1/30...