[PDF] - The Flux OSKit: A Substrate fo r Kernel and Language Resea PDF Document

SLIDE 1 The Flux OSKit: A Substrate fo r Kernel and Language Resea rch Bry an F

rd

Go dma r Back Greg Benson Ja y Lep reau Alb ert Lin Olin Shivers Computer Systems Lab

rato

ry Universit y

f

Califo rnia, Davis MIT AI Lab flux@cs.utah.edu http://www.cs.utah.edu/projects/flu x/ Octob er 6, 1997 1

SLIDE 2 Motivation OS resea rch and development has a high cost

f

entry due to mundane infrastructure:

Bo
tstrapping
Basic

k ernel runtime environment

Device

drivers fo r diverse ha rdw a re

Compatibili

t y with existing systems 2

SLIDE 3 Reusable Comp

nents

fo r OS Development

Drivers FreeBSD Glue Linux Glue Kernel Support Minimal C Library Malloc Debugging List-based Memory Manager SMP Address Map Manager Executable Bootp

Language Run-Time System

File System Reader Disk Partitioning FreeBSD Math Library Hardware Linux Glue

Client Operating System or

Encapsulated Legacy Code Native OSKit Code Networking Loading FreeBSD NetBSD File System Glue Generic Device Driver Support Generic Device Driver Support Drivers FreeBSD

3

SLIDE 4 Key Concepts Our app roach to comp

nent-based

OS's:

Don't

create a new OS; instead create com- p

nents

that can b e used in

ther

OS's.

Don't

rewrite from scratch when p

ssible;

reuse existing OS co de in a maintainable w a y b y encapsulating it within glue co de.

Emphasis
n

usabilit y and p racticalit y , not religion

r

buzzw

rd-compliance.

4

SLIDE 5 Reusable Comp

nents

fo r Arbitra ry Environments Comp

nent

must have some exp ectations

f

its environment. F

r

reusabilit y , exp ectations should b e:

Simple
W

ell-dened

Unconstraining

5

SLIDE 6 Imp

rtant

Prop erties

f

OSKit Comp

nents

Inter-comp

nent

interfaces based

n

Microsoft's Comp

nent

Object Mo del (COM). Minimal interdep endencies, no mandato ry global infrastructure. Common unip ro cesso r/blo cking concurrency mo del. 6

SLIDE 7 COM interfaces

Simil

a r to Java interfaces

Standa

rdized and w ell-kno wn in industry

Sepa

rates interface from implementation

Supp
rts

indep endent interface extension and evolution

No

required runtime supp

rt

co de 7

SLIDE 8 Diagram

f

a COM Interface

Release method pointer Function table pointer Query method pointer AddRef method pointer Method pointer 4 Method pointer 5 Method pointer 6 Method pointer 7 . . .

(opaque to client)

Private object state Interface function table Interface pointer Functions implementing interface methods

8

SLIDE 9 No Implicit Dep endencies Comp

nents

dep end

n
nly

a handful

f

w ell- dened, easily reimplementable functions:

Memo

ry allo cation

Synchronization

p rimiti ves

Erro

r p rinting/logging

Ha

rdw a re access (fo r device drivers) Other facilities used b y pa rticula r comp

nents

a re pa rameterized through COM interfaces. 9

SLIDE 10 No Implicit Dep endencies e.g., contrasts with:

BSD's

VFS and net w

rking

a rchitecture: requires common vnode/mbuf co de.

Win32-based

COM environment: requires va rious pa rts

f

the Win32 API 10

SLIDE 11 OSKit Concurrency Mo del Denes:

Ho

w and when comp

nent

can b e invok ed

Ho

w and when the comp

nent

can mak e callbacks to its surrounding environment. OSKit uses the w ell-kno wn blo cking mo del, ca refully dened and do cumented in a comp

nent-

centric w a y . 11

SLIDE 12 OSKit Concurrency Mo del

Component OSKit Environment

blocking callback

12

SLIDE 13 Encapsulation

f

Legacy Co de

Environment Environment

File Systems Device Drivers Linux OSKit Glue Code Networking Code FreeBSD OSKit Glue Code OSKit Glue Code NetBSD OS Environment OSKit Glue Code Encapsulated Code from Existing OS

OS Environment

OSKit Interfaces OSKit Interfaces OSKit Interfaces

13

SLIDE 14 Challenges fo r Encapsulation Imp

rted

co de mak es many assumptions:

proc/task

structures

The

\current p ro cess" va riable

Memo

ry allo cation and mapping faciliti es

Sleep/w

ak eup faciliti es

Interrupt

p rio rit y levels

mbuf,

skbuff, vnode infrastructure, etc. 14

SLIDE 15 Solution: Lots

f

Ugly Magic T

avoid

changing the imp

rted

co de, all

f

these assumptions must b e emulated:

Glue

routines translate memo ry allo cation, synchronization, and

ther

p rimitives.

Create

dummy proc structures

n

entry , destro y them

n

return.

Prep

ro cesso r magic to ensure namespace cleanliness (e.g., tsleep !

skit

freebsd tsleep). It's ugly , but the ugliness is conned! 15

SLIDE 16 Current OSKit Comp

nents

Drivers FreeBSD Glue Linux Glue Kernel Support Minimal C Library Malloc Debugging List-based Memory Manager SMP Address Map Manager Executable Bootp

Language Run-Time System

File System Reader Disk Partitioning FreeBSD Math Library Hardware Linux Glue

Client Operating System or

Encapsulated Legacy Code Native OSKit Code Networking Loading FreeBSD NetBSD File System Glue Generic Device Driver Support Generic Device Driver Support Drivers FreeBSD

16

SLIDE 17 Eciency TCP throughput (Mbit/sec): Receiver: Linux F reeBSD OSKit Sender: Linux 72.4 71.2 71.3 F reeBSD 60.0 78.6 78.7 OSKit 56.4 68.3 68.2 TCP latency (sec): Server: Linux F reeBSD OSKit Client: Linux 152 168 180 F reeBSD 168 197 210 OSKit 180 210 222 17

SLIDE 18 Exp eriences

Fluk

e OS

ML-based

OS

SR-based

OS

Java-based

net w

rk

PC

:

: :

ther

users 18

SLIDE 19 Fluk e First and most closely b

und

OSKit customer Over half

f

Fluk e comes from the OSKit:

C

lib ra ry

Debugging
File

systems (as user-mo de servers)

Net

w

rking

(as user-mo de servers)

Device

drivers (in sup erviso r and user mo de) 19

SLIDE 20 ML-based OS ML is a high-level functional language: Lisp with strong t yping and a syntax. ML/OS created at MIT AI Lab as rst external client

f

the OSKit; to

k

a few months. Only uses OSKit's b

tstrap

supp

rt

and C lib ra ry; everything else written in ML. Unique language runtime features that b enet from direct ha rdw a re access:

Stackless

implementation

Continuation-based

multithreading 20

SLIDE 21 SR-based OS P a rallel/distri buted p rogramming language. SR/OS develop ed b y Greg Benson from U.C. Davis, w

rking

at Utah. Initial implementati

n

to

k
ne

w eek; net w

rk

supp

rt

to

k

another w eek. Uses Arizona's x

k

ernel fo r net w

rking,

but with the OSKit's Linux net w

rk

drivers. 21

SLIDE 22 Java Develop ed b y Go dma r Back at Utah. Uses Kae, a free JVM. T

k

14 hours to get \Hello W

rld"

running; JIT compiler to

k

another da y; multithreaded Jigsa w w eb server running in three w eeks. F unctionally simila r to JavaOS, but uses stable native comp

nents

instead

f

rewriting everything in Java. 22

SLIDE 23 Status F ully functional and fairly w ell do cumented. Prelimina ry release w as made ea rlier this y ea r. Latest version available at http://www.cs.utah.eduh/projects/f lux. 23

SLIDE 24 F uture W

rk
Interop

erabilit y with t yp esafe languages such as Java and ML.

Direct

supp

rt

fo r multithreaded co de and multithreaded environments

IDL

compiler supp

rt

fo r COM interfaces 24

SLIDE 25 Conclusion Key ideas:

New

reusable OS comp

nents

instead

f

new OS's

Encapsulation

allo ws unmo died legacy co de to p resent clean interfaces

Emphasis
n

p racticalit y and usabilit y

Catalyzes

OS resea rch and sp ecialized OS development. 25

SLIDE 26 Example COM Interface typedef struct blkio { struct blkio_ops *ops; } blkio_t; struct blkio_op s { error_t (*query)( bl kio _t *io, const struct guid *iid, void **out_iha ndl e) ; unsigned (*addref) (b lki

_

t *io); unsigned (*release )( blk io _t *io); unsigned (*getbloc ks ize )( blk io _t *io); error_t (*read)(b lk io_ t *io, void *buf,

ff_t
ffset,

size_t amount, size_t *out_act ual ); error_t (*write)( bl kio _t *io, const void *buf,

ff_t
ffset,

size_t amount, size_t *out_actua l) ; error_t (*getsize )( blk io _t *io,

ff_t

*out_siz e) ; error_t (*setsize )( blk io _t *io,

ff_t

new_size ); }; #define BLKIO_IID GUID(0x4a a7d f8 1, 0x7c74, 0x11cf, \ 0xb5, 0x00, 0x08, 0x00, 0x09, 0x53, 0xad, 0xc2) 26

SLIDE 27 Related W

rk
Extensible

systems (SPIN, VINO, exo)

Emb

edded systems (QNX, VxW

rks)
Object-o

riented OS's (Choices, T aligent) T ypical p roblems:

New,

incompatible OS environments.

Little

reuse

f

existing OS co de. 27