Group A5 4th Paper Presentation INFERNO Operating system

1. Group A5 4th Paper Presentation INFERNO Operating system Group Members: Daniel Saenz Gilbert Rahme Sandeep George Mohan

2. Inferno Operating Systems • Developed in Lucent technologies by Dennis Ritchie. • Replaces a plethora of protocols in a network by a simple unifying file service protocol (styx). • Applications compute their own name spaces and consider all resources as file systems. • Used in Embedded applns and small networked devices. Eg :CATv, PDA etc.

3. Interesting features of Inferno • Styx open communication protocol. • Concurrent Modular language LIMBO. • Virtual machine and byte code interp-reter with JIT compilers. • Portability and virtualization techniques. • Automatic garbage collection.

4. Inferno-Strengths • Portability across processors Runs on Intel,SPARC, AMD, MIPS etc • Portability across environments Can run as a standalone as well as a user appln in Windows NT/95, Unix, Linux, HP/UX, AIX* etc. • Distributed Design Identical environment at client and server.

5. Inferno- Strengths(cont) • Minimal hardware requirements Can run useful applns as a stand alone with as little as 1 MB of memory. • Portable Applns Inferno applns are written in type-safe LIMBO whose binary representation is identical for all platforms. • Dynamic adaptability Depending on the H/W or resource availability,applns may use diff modules to perform a specific function.

6. Inferno Interfaces The role of Inferno system is to create se- veral standard interfaces for its applns. • Applns use various resources which include a virtual machine that runs applns programs together with library modules like string manip etc. • Applns exist in an external env containing resources such as data files and objects. Devices present themselves to the appln as files.

7. External env of Inferno applns • The purpose of most Inferno applns is to present informn/media to user. • To the applns the user’s devices shows up as resources for it. • The way the resources are designed to show up to the applns are 1.Resources - Named & accessed like files. 2.Disjoint resource hierarchies provided by different services show up in a single hierarchical name space. 3.Regardless of whether resources are local/global, a communication protocol called styx is used.

8. External env of Inferno applns • The glue that connects diff parts of the resource name space together is the styx protocol. • Inferno kernel implements a mount driver which transforms file operations to RPC’s for transport over the network. • On the other side of the conxn, a server unwraps the styx messages and implements them using resources local to it.

9. Internal env of Inferno applns • Inferno applns written in LIMBO which supports most of the standard data types and also addnl ones like tuples, lists, strings etc. • A communication mechanism called channel is present which is used to connect diff LIMBO tasks. • Multi tasking supported by the LIMBO language.

10. Internal env of Inferno applns • LIMBO programs are built of modules, which are self contained units having a well defined interface containing functions,abstract data types and constants. • Modules are accessed dynamically by executing a load statement naming the desired module. Then a handle for the module is returned and the module is accessed.

11. Internal env of Inferno applns • Limbo is fully type checked at compile and run time. • No memory protection H/W is there. • All LIMBO data and program objects are subject to a garbage collector built deeply into LIMBO run time system. • All System data objects are kept track of and freed as soon as they become idle.

12. Internal env of Inferno applns • Limbo programs are complied into byte codes representing instructions for a virtual machine called DIS. • The resulting code executes at a speed approaching that of complied C. • Underlying DIS is the inferno kernel which contains the interpretor and an on the fly complier.

13. Environment of the Inferno system • Inferno creates a standard environment for applns. Identical applns programs can run under any instance of this environment-even in distributed fashion and see the same resources. • Several versions of Inferno kernel, DIS/LIMBO interpreter and device driver set can be used depending on the environment within which inferno is implemented.

14. Environment of the Inferno system • When running as the native operating system kernel includes all the low level glue like interrupt handlers, device drivers etc. • But when running in a hosted system like Windows NT, Inferno runs as an ordinary process. • Here instead of mapping its device control functionality to real hardware, it adapts to the resources provided by the operating system under which it runs.

15. Inferno Operating System Styx Architecture

16. INTRODUCTION • The styx protocol was proposed to meet two operating systems models, plan 9 and inferno • Its objective is to present their resources as files in a hierarchical name space • Objects may represent stored data, but may also be devices, dynamic information sources, interfaces to services, and control points

17. INTRODUCTION (cont’d) • By representing a computing resource as a form of file system, difficulties of making resource available disappear • Styx exports the resources transparently • Resources published by Styx do not need to exist as standard files on disk • The /dev/mouse file is accessed by standard file I/O mechanisms but has no permanent existence

18. INTRODUCTION (cont’d) • Besides interactive graphics, services such as debugging, maintenance, file backup, and even access to the underlying network hardware can be made available using Styx

19. Styx PROTOCOL • Styx is analogous to Sun NFS or Microsoft CIFS but simpler to implement. • NFS and CIFS are designed for sharing regular disk files • Unlike Styx, they are clumsy at exporting dynamic device-like files such as /dev/mouse

20. Styx PROTOCOL • Provides a view of hierarchical, tree-shaped file system name space together with access information about the files • Its users don’t see the protocol itself • Styx client is an entity on one machine; establishes communication with server on the same or another machine

21. Styx PROTOCOL • Client mechanisms may be built into the operating system or into application libraries • Server may be part of the operating system, or application code on a separate server machine • Client and server communicate by exchanging messages

22. Styx PROTOCOL • Starting communication • Navigating the file system • Reading and writing a file • Performing file status inquiries and changes • Application writers request to open, read, or write files. Styx translates the requests into the necessary byte sequences

23. Styx PROTOCOL • Styx fits at the OSI Session Layer of the ISO standard classification. • Its specification is independent of most details of machine architecture • It runs over either TCP/IP or Internet link (IL). • Styx runs fine over a Unix pipe or even using shared memory.

24. EXAMPLE • Consider the operation: open (“/usr/rob/.profile”, O_READ); • It is translated by the underlying system into a sequence of Styx messages • Attach message authenticates the user and returns an object called a FID • A clone message duplicates the root FID • The new FID is then moved to the file /usr/rob/.profile

25. EXAMPLE • Finally, open message checks that the user has permission to read the file • Once I/O is completed, the close message will release the FID

26. REFERENCES • http://www.vitannuova.com/inferno/papers/styx.html • Lucent Technologies Inc./ Bell Labs Technical Journal • http://techupdate.cnet.com/enterprise/0-6133429-723-3897916.html

27. QUESTIONS ??