RMoX: A Raw Metal occam Experiment Fred Barnes ( frmb2@ukc.ac.uk ) - - PDF document

▶
rmox a raw metal occam experiment
SMART_READER_LITE
LIVE PREVIEW

RMoX: A Raw Metal occam Experiment Fred Barnes ( frmb2@ukc.ac.uk ) - - PDF document

Jul 01, 2023 314 likes •636 views

RMoX A Raw Metal occam Experiment 1/30 RMoX: A Raw Metal occam Experiment Fred Barnes ( frmb2@ukc.ac.uk ) Christian Jacobsen ( clj3@ukc.ac.uk ) Brian Vinter ( vinter@imada.sdu.dk ) Computing Laboratory, University of Kent

slide-1
SLIDE 1

RMoX – A Raw Metal occam Experiment 1/30

RMoX: A Raw Metal

  • ccam Experiment

Fred Barnes† (frmb2@ukc.ac.uk) Christian Jacobsen† (clj3@ukc.ac.uk) Brian Vinter‡ (vinter@imada.sdu.dk)

† Computing Laboratory, University of Kent ‡ Department of Maths and Computer Science,

University of Southern Denmark

slide-2
SLIDE 2

RMoX – A Raw Metal occam Experiment 2/30

Contents

  • Introduction
  • Dynamic occam
  • Design:

– the ‘kernel’ – device drivers – filesystems – networking – top-level and console

  • Implementation:

– accessing hardware – real and user-mode RMoX

  • Conclusions
slide-3
SLIDE 3

RMoX – A Raw Metal occam Experiment 3/30

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!

slide-4
SLIDE 4

RMoX – A Raw Metal occam Experiment 4/30

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
slide-5
SLIDE 5

RMoX – A Raw Metal occam Experiment 5/30

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
slide-6
SLIDE 6

RMoX – A Raw Metal occam Experiment 6/30

Mobile Data

  • Provides a movement semantics for assign-

ment and communication

  • Implementation supports both static and

dynamic mobiles

  • Unit-time assignment and communication
  • Unit-time ‘garbage-collection’ (strict alias-

ing)

Q P x c ! x c ? y c c P Q y

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

enforced

slide-7
SLIDE 7

RMoX – A Raw Metal occam Experiment 7/30

Mobile Channel-Ends

Ends of channel-types — structured bundles

  • f channels:

? !

buf! req? ret? buf? req! ret! BUF.MGR

CHAN TYPE BUF.MGR MOBILE 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)

slide-8
SLIDE 8

RMoX – A Raw Metal occam Experiment 8/30

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?)

slide-9
SLIDE 9

RMoX – A Raw Metal occam Experiment 9/30

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

slide-10
SLIDE 10

RMoX – A Raw Metal occam Experiment 10/30

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

slide-11
SLIDE 11

RMoX – A Raw Metal occam Experiment 11/30

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

slide-12
SLIDE 12

RMoX – A Raw Metal occam Experiment 12/30

Securely Shared Channel-Ends

  • 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...

slide-13
SLIDE 13

RMoX – A Raw Metal occam Experiment 13/30

Securely Shared Channel-Ends

clients servers

slide-14
SLIDE 14

RMoX – A Raw Metal occam Experiment 14/30

Dynamic Process Creation

(using the FORK)

  • Allows a process to dynamically create

another process that runs concurrently

  • Implementation supports the FORK of an

arbitrary PROC, with parameter restrictions WHILE test SEQ ... FORK P (n, in?, out!) ...

  • Parameters to FORKed processes follow a

communication semantics, instead of re- naming semantics

  • An alternative syntax would be easy:

P ! (n, in?, out!)

slide-15
SLIDE 15

RMoX – A Raw Metal occam Experiment 15/30

Design of RMoX

kernel driver. core network. core console filesystem drivers device drivers network drivers and 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]
slide-16
SLIDE 16

RMoX – A Raw Metal occam Experiment 16/30

The Kernel

kernel client processes processes system driver

  • Acts as an ‘arbitrator’ for system services
  • POSIX based interface

– but others are certainly possible – DOS, VMS, ...

  • Has special privileges for ‘process control’
slide-17
SLIDE 17

RMoX – A Raw Metal occam Experiment 17/30

Device Drivers

driver. core ramdisk serial keyboard VGA keyboard client process hardware access hardware access hardware access requests responses

  • ‘driver.core’ manages individual drivers

– started by FORKing them

  • Requests for a specific device are

passed to the right driver

  • Driver returns a channel-type-end for

interacting with the device

  • Recursive channel-type is used to snap

back the channel in on itself when done

slide-18
SLIDE 18

RMoX – A Raw Metal occam Experiment 18/30

Device Drivers II

serial serial.1 serial.0 hardware access hardware access (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), ...

slide-19
SLIDE 19

RMoX – A Raw Metal occam Experiment 19/30

Device Drivers III

serial serial.1 serial.0 biosmem hardware access hardware access bios data RAM (driver.core)

  • Drivers may request connections to other

device drivers

  • Carefully controlled to avoid deadlock
slide-20
SLIDE 20

RMoX – A Raw Metal occam Experiment 20/30

Filesystems

driver. core ramdisk serial dev.fs ramdisk.fs fs.core requests responses requests responses

  • Most filesystems will need a device

to operate on

  • Currently implementing a fairly traditional

UNIX-style file-system

  • The ramdisk is mounted on / when the

system starts up

slide-21
SLIDE 21

RMoX – A Raw Metal occam Experiment 21/30

File handling

ramdisk user/system process 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 file
  • r directory by using that channel end.
  • Channel-end snapped-back to finish
slide-22
SLIDE 22

RMoX – A Raw Metal occam Experiment 22/30

Networking

serial.0 slip. interface interface loopback. multiplex IP checking assembler and fragment proto.match proto.match proto.match route multiplex server icmp server udp server tcp channel links to network controller and application processes checks icmp checks udp checks tcp

  • Network infrastructure is from “occamnet”

– a 3rd year project at UKC

  • Clear and logical design
slide-23
SLIDE 23

RMoX – A Raw Metal occam Experiment 23/30

Networking II

server icmp inbound packets

  • utbound

packets network. core application ping.worker

  • Internal server-process structure similar to
  • ther RMoX server components
  • Currently supported protocols are limited

to ICMP and UDP – a simple DNS application exists – NFS is a larger, but feasible, project

slide-24
SLIDE 24

RMoX – A Raw Metal occam Experiment 24/30

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 declarations SEQ ct.driver.cli, ct.driver.svr := MOBILE CT.DRIVER ... other initialisations SHARED 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 processes SEQ SETPRI (31) CLAIM debug.chan? idle.task (debug.chan?) :

slide-25
SLIDE 25

RMoX – A Raw Metal occam Experiment 25/30

The console

vt220 vt220 matrix vt220 vtkeyswitch vgaplex

vt.handler vt.handler vt.handler

console log in to kernel vga driver link to keyboard link to driver to driver.core console system.

  • Starts everything else off
  • Handles the kernel log
  • ‘system.console’ process provides

prompt and basic commands

slide-26
SLIDE 26

RMoX – A Raw Metal occam Experiment 26/30

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

slide-27
SLIDE 27

RMoX – A Raw Metal occam Experiment 27/30

Structure

  • ccam applications

RMoX RMoX device drivers CCSP/libs OSKit hardware applications C

  • OSKit manages memory,

IO ports and interrupts

  • Once ‘allocated’, memory and IO ports can

be used directly from occam

  • CCSP schedules occam processes

– and controls execution of C processes

  • Interrupts are handled using a combination
  • f the OSKit and CCSP
slide-28
SLIDE 28

RMoX – A Raw Metal occam Experiment 28/30

User-Mode RMoX

driver. core ramdisk ramdisk.fs fs.core keyboard VGA host.fs requests responses requests responses

  • ccam

file library library xtextwindow

  • RMoX

is simply a dynamic set

  • f

communicating occam processes – ... and can be run as a normal KRoC/occam application

  • User-mode RMoX (UM-RMoX) provides an

abstraction for hardware, using the existing RMoX interfaces

slide-29
SLIDE 29

RMoX – A Raw Metal occam Experiment 29/30

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, ...

slide-30
SLIDE 30

RMoX – A Raw Metal occam Experiment 30/30

On-going Research

  • Still under development, but progressing

well (delayed by thesis)

  • Reasonable number of basic devices now

supported: – serial driver works well enough to launch a ‘system.console’ process on it – using FIFOs and interrupt-driven com- munication

  • Basic file-system driver support:

– ‘ram.fs’ and ‘dev.fs’ are implemented and work correctly – device filesystem mirrors the nested struc- ture of devices

  • Very fast! :-)