The Flux OSKit: A Substrate fo r Kernel and Language Resea rch Bry an F o rd Go dma r Back Greg Benson Ja y Lep reau Alb ert Lin Olin Shivers Computer Systems Lab o rato ry Universit y of Califo rnia, Davis MIT AI Lab flux@cs.utah.edu http://www.cs.utah.edu/projects/flu x/ Octob er 6, 1997 1
Motivation OS resea rch and development has a high cost of entry due to mundane infrastructure: � Bo otstrapping � Basic k ernel runtime environment � Device drivers fo r diverse ha rdw a re � Compatibili t y with existing systems 2
Reusable Comp onents fo r OS Development Native OSKit Code Client Operating System or Encapsulated Legacy Code Language Run-Time System Executable Loading File System FreeBSD NetBSD Reader Address Map FreeBSD Networking File System Manager Math Library Disk Glue Glue Partitioning 3 Generic Device Driver Support Minimal C Library Malloc Linux FreeBSD Debugging Drivers Drivers List-based Bootp Linux Glue FreeBSD Glue Memory Manager Generic Device Driver Support Kernel Support SMP Hardware
Key Concepts Our app roach to comp onent-based OS's: � Don't create a new OS; instead create com- p onents that can b e used in other OS's. � Don't rewrite from scratch when p ossible; reuse existing OS co de in a maintainable w a y b y encapsulating it within glue co de. � Emphasis on usabilit y and p racticalit y , not religion o r buzzw o rd-compliance. 4
Reusable Comp onents fo r Arbitra ry Environments Comp onent must have some exp ectations of its environment. F o r reusabilit y , exp ectations should b e: � Simple � W ell-de�ned � Unconstraining 5
Imp o rtant Prop erties of OSKit Comp onents Inter-comp onent interfaces based on Microsoft's Comp onent Object Mo del (COM). Minimal interdep endencies, no mandato ry global infrastructure. Common unip ro cesso r/blo cking concurrency mo del. 6
COM interfaces � Simil a r to Java interfaces � Standa rdized and w ell-kno wn in industry � Sepa rates interface from implementation � Supp o rts indep endent interface extension and evolution � No required runtime supp o rt co de 7
Diagram of a COM Interface Private object state Interface function table (opaque to client) Interface pointer Function table pointer Query method pointer AddRef method pointer Release method pointer Functions Method pointer 4 implementing 8 Method pointer 5 interface methods Method pointer 6 Method pointer 7 . . .
No Implicit Dep endencies Comp onents dep end on only a handful of w ell- de�ned, 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 onents a re pa rameterized through COM interfaces. 9
No Implicit Dep endencies e.g., contrasts with: � BSD's VFS and net w o rking a rchitecture: requires common vnode / mbuf co de. � Win32-based COM environment: requires va rious pa rts of the Win32 API 10
OSKit Concurrency Mo del De�nes: � Ho w and when comp onent can b e invok ed � Ho w and when the comp onent can mak e callbacks to its surrounding environment. OSKit uses the w ell-kno wn blo cking mo del, ca refully de�ned and do cumented in a comp onent- centric w a y . 11
OSKit Concurrency Mo del Environment blocking callback OSKit Component 12
Encapsulation of Legacy Co de OS Environment OSKit Interfaces OSKit Glue Code OSKit Glue Code FreeBSD NetBSD Networking Code File Systems OSKit Interfaces 13 OSKit Glue Code Environment Environment Linux Device Drivers OSKit Interfaces OS Environment OSKit Glue Code Encapsulated Code from Existing OS
Challenges fo r Encapsulation Imp o 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
Solution: Lots of Ugly Magic T o avoid changing the imp o rted co de, all of these assumptions must b e emulated: � Glue routines translate memo ry allo cation, synchronization, and other p rimitives. � Create dummy proc structures on entry , destro y them on return. � Prep ro cesso r magic to ensure namespace cleanliness (e.g., tsleep ! oskit freebsd tsleep ). It's ugly , but the ugliness is con�ned! 15
Current OSKit Comp onents Native OSKit Code Client Operating System or Encapsulated Legacy Code Language Run-Time System Executable Loading File System FreeBSD NetBSD Reader Address Map FreeBSD Networking File System Manager Math Library Disk Glue Glue Partitioning Generic Device Driver Support Minimal C Library 16 Malloc Linux FreeBSD Debugging Drivers Drivers List-based Bootp Linux Glue FreeBSD Glue Memory Manager Generic Device Driver Support Kernel Support SMP Hardware
E�ciency 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
Exp eriences � Fluk e OS � ML-based OS � SR-based OS � Java-based net w o rk PC � : : : other users 18
Fluk e First and most closely b ound OSKit customer Over half of Fluk e comes from the OSKit: � C lib ra ry � Debugging � File systems (as user-mo de servers) � Net w o rking (as user-mo de servers) � Device drivers (in sup erviso r and user mo de) 19
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 of the OSKit; to ok a few months. Only uses OSKit's b o otstrap supp o rt and C lib ra ry; everything else written in ML. Unique language runtime features that b ene�t from direct ha rdw a re access: � Stackless implementation � Continuation-based multithreading 20
SR-based OS P a rallel/distri buted p rogramming language. SR/OS develop ed b y Greg Benson from U.C. Davis, w o rking at Utah. Initial implementati on to ok one w eek; net w o rk supp o rt to ok another w eek. Uses Arizona's x -k ernel fo r net w o rking, but with the OSKit's Linux net w o rk drivers. 21
Java Develop ed b y Go dma r Back at Utah. Uses Ka�e, a free JVM. T o ok 14 hours to get \Hello W o rld" running; JIT compiler to ok 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 onents instead of rewriting every- thing in Java. 22
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
F uture W o rk � Interop erabilit y with t yp esafe languages such as Java and ML. � Direct supp o rt fo r multithreaded co de and multithreaded environments � IDL compiler supp o rt fo r COM interfaces 24
Conclusion Key ideas: � New reusable OS comp onents instead of new OS's � Encapsulation allo ws unmo di�ed legacy co de to p resent clean interfaces � Emphasis on p racticalit y and usabilit y � Catalyzes OS resea rch and sp ecialized OS development. 25
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 o_ 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, off_t offset, size_t amount, size_t *out_act ual ); error_t (*write)( bl kio _t *io, const void *buf, off_t offset, size_t amount, size_t *out_actua l) ; error_t (*getsize )( blk io _t *io, off_t *out_siz e) ; error_t (*setsize )( blk io _t *io, off_t new_size ); }; #define BLKIO_IID GUID(0x4a a7d f8 1, 0x7c74, 0x11cf, \ 0xb5, 0x00, 0x08, 0x00, 0x09, 0x53, 0xad, 0xc2) 26
Related W o rk � Extensible systems (SPIN, VINO, exo) � Emb edded systems (QNX, VxW o rks) � Object-o riented OS's (Choices, T aligent) T ypical p roblems: � New, incompatible OS environments. � Little reuse of existing OS co de. 27
Recommend
More recommend
