Newsgroups: comp.os.chorus,news.answers,comp.answers Subject: comp.os.chorus Frequently Asked Questions (FAQ) Summary: This posting contains a list of Frequently Asked Questions (and their answers) about the CHORUS microkernel technology. Date: 25 Jan 95 14:11:14 GMT Posting-Frequency: monthly Maintainer: "Philippe Robin" Table of Contents ================= 1. General Information 1.1. Organization and Availability of this FAQ 1.2. What's New? 1.3. What is CHORUS? 1.4. How to Contact Chorus Systems? 2. Documentation 2.1. Documentation Available through Anonymous FTP 2.2. Papers on CHORUS 2.3. Other references 3. Chorus Product Offering 3.1. Overview 3.2. Offering for Universities 4. CHORUS Microkernel 4.1. General 4.2. Supported Microprocessors 4.3. Porting on various platforms 4.4. Scheduling and real-time 4.5. CHORUS on Transputers 4.6. Comparison with other OS 4.7. Perfomances 4.8. Object Oriented issues 5. OS Personalities 5.1. OS personalities available on top of CHORUS 5.2. CHORUS/MiX V.3.2 -------------- 1. General Information =================== 1.1. Organization and Availability of this FAQ ----------------------------------------- This FAQ contains informations related to the CHORUS operating system, description of the products and contacts. It will be progressively updated according to the discussions held in this newsgroup and the evolution of the products. It is initially posted once a month in the following newsgroups: << comp.os.chorus, news.answers, comp.answers >>. It is also available via e-mail by sending a request to "chorus-adm@comp.lancs.ac.uk" and should be soon accessible via ftp. You can make any comments, suggestions or contributions to this FAQ by sending an e-mail to "chorus-adm@comp.lancs.ac.uk" or "pr@comp.lancs.ac.uk" or by discussions in the newsgroup. 1.2. What's New? ----------- Few updates (supported processors, etc.) and question related to the performance measurement utilities (see paragraph 4.7) on the micro-kernel. 1.3. What is CHORUS? -------------- CHORUS is a family of open microkernel-based operating system components to meet advanced distributed computing needs in areas such as telecommunications, internetworking, embedded systems, realtime, "mainframe UNIX", supercomputing and high availability. The CHORUS/MiX multiserver implementations of UNIX allow to dynamically integrate part or all of standard UNIX functionalities and services in the above application areas. CHORUS is designed, developed and marketed by Chorus Systems. 1.4. How to Contact Chorus Systems ----------------------------- North America: Chorus Systems Inc. 1999 South Bascom Avenue, Suite 400 Campbell, CA 95008 United States Phone: +1 (408) 879-4100 Fax: +1 (408) 879-4102 Voice Mail: +1 (408) 291 8832 Email: info@chorus.com Europe: Chorus systemes SA 6 avenue Gustave Eiffel F-78182 St Quentin-en-Yvelines Cedex France Phone: +33 (1) 30 64 82 00 Fax: +33 (1) 30 57 00 66 Email: info@chorus.fr Asia Pacific: Chorus Systems KK Mitsutake Building Ikejiri, 8F 3-22-4 Ikejiri, Setagaya Ku Tokyo 154 Japan Phone: +81 (3) 5430-1131 Fax: +81 (3) 5430-1133 Email: info-ap@chorus.com 2. Documentation ============= 2.1. Documentation Available through Anonymous FTP --------------------------------------------- There are several technical reports on CHORUS available via anonymous FTP from Chorus systemes, France: ftp.chorus.fr [192.33.15.3], directory pub/chorus-reports (see the file "index" for an overview). A set of slides on CHORUS is also available in the directory "pub/chorus-slides", documents CS-TR-92-64 (PostScript, versions 1-up and 2-up). The latest version is the document CS-TR-92-64.4, Apr 94. Product Data Sheets are available (in ascii or PostScript format) in the directory "pub/chorus-datasheets". Those reports are also available through the World Wide Web at Chorus systemes: ftp://ftp.chorus.fr/pub. 2.3. Papers on CHORUS ---------------- [Bricker, 1991] A. Bricker, M. Gien, M. Guillemont, J. Lipkis, D. Orr and M. Rozier, "A new look at micro-kernel-based UNIX operating systems: Lessons in performance and compatibility". Proc. of the EurOpen Spring'91 Conference, Tromsoe, Norway, 20-24 May 1991. Chorus Systems Technical Report CS-TR-91-7 [Coulson, 1994] Coulson G., and G.S. Blair. "Microkernel Support for Continuous Media in Distributed Systems". Computer Networks and ISDN Systems, Special Issue on Multimedia, 1994; also available as internal report MPG-93-04, Computing Dept., Lancaster University. [Gaultier, 1994] O. Gautier and Y. Metais. "Mise en Place d'une Plateforme CHORUS, Conception et Implementation d'un Ordonnanceur a Echeance au Sein du Noyau Chorus". Memoire CNAM, Paris, March 1994. CS/TR-94-82.1 "CHORUS Kernel v3 r5 for T425/T805 Connection Manager and Aserver Library" (Internal Report) CS/TR-94-81.1 "CHORUS Kernel v3 r5 for T425/T805 Host Server User's Manual, Aserver Guide" (Internal Report) 2.4. Other references ---------------- [Bradley, 1993] J Bradley Chen and Brian N Bershad "The Impact of Operating System Structure on Memory System Performance", ACM SIGOPS Dec. '93 [Coulouris, 1994] G. Coulouris, J. Dollimore and T. Kindberg. "Distributed Systems, Concepts and Design", Addison-Wesley, second edition, 1994. [Douglis et al., 1992] Douglis, F., Kaashoek, M.F., and Tanenbaum, A.S.: "A Comparison of Two Distributed Systems: Amoeba and Sprite," Computing Systems, vol. 4, Fall 1991 (sic). [Tanenbaum, 1992] Andrew S. Tanenbaum: "Modern Operating Systems", Prentice-Hall, 1992. [Tanenbaum, 1994] Andrew S. Tanenbaum, "Distributed Operating Systems", Prentice-Hall, ISBN 0-13-219908-4 3. Chorus Product Offering ======================= 3.1. Overview -------- All CHORUS products, except CHORUS/Fusion, are source products. The CHORUS Nucleus is a realtime distributed microkernel; current release is v3 r5.2 (Apr 94). CHORUS/Simulator is a port of the CHORUS microkernel on top of UNIX; current release is v3 r5.2 (May 94). It runs as a UNIX process, e.g. under SunOS 4.1 on a Sun SPARCstation, and allows one to develop and test applications using the microkernel's API. CHORUS/MiX V.4 is a distributed multi-server implementation of UNIX SVR4.0 on top of the CHORUS microkernel; current release is r3.0 (Jan 94). E.g. on a 386/486 PC/AT, it offers binary compatibility with native SVR4.0v4. MiX V.4 requires a Novell/USG SVR4.0 sources license. CHORUS/Fusion for SCO Open Systems Software is a multi-server implementation of SCO UNIX and extends it with realtime functionality (POSIX 1003.1b and .1c, i.e. the former .4 and .4a interfaces) and clustering functionality. CHORUS/Fusion is developed and marketed jointly by SCO and Chorus as a binary product on Intel-based PC's. The current release is r1.0 (Jun 94). CHORUS/COOL is a distributed programming environment for object-oriented applications. CHORUS/COOL supports the dynamic creation of C++ objects, these objects can be invoked, using C++ mechanism in a system wide transparent way. Objects can migrate, and remain persistent unless explicitly deleted. The programming model used is based on the Object Management Group's architecture (OMG). Current release: v2 r1. CHORUS/ClassiX is host-target cross-development environment for C-written applications, named C_actors. C_actors can be loaded, unloaded and debugged dynamically from the host (e.g. SPARCstation/SunOS) on the target (e.g. ix86 PC/AT), interconnected via Ethernet. C_actor applications can interoperate with UNIX on the host through TCP/IP sockets and NFS. On the target, there is only the CHORUS/Nucleus microkernel and the CHORUS/C_actor subsystem but no CHORUS/MiX UNIX System V subsystem. The current release of this product is r1.0 (Jun 94). 3.2. Offering for Universities ------------------------- Chorus Systems has special programs for universities. More information on offerings, conditions, etc is available via ftp on "ftp.chorus.fr" in the following ASCII files - pub/README - pub/academic/README - pub/academic/offerings If you have questions, you may contact Didier.Irlande@chorus.fr. 4. CHORUS Microkernel ================== 4.1. General ------- * What is a microkernel? A "microkernel" is an operating system with only the essential services, such as interprocess communication, short-term scheduling, and memory management. It basically provides the process abstraction and a means for processes to communicate. It is designed to be portable between computer architectures, using high-level languages such as C or C++ and reducing the machine-dependant component to a minimal bottom layer. The microkernel appears as a layer between the hardware layer and a layer consisting of system components called 'subsystems'. Their size can vary from about 10Kb to several hundred kilobytes of executable code and static data. * Synchronisation primitives offered to CHORUS threads? The CHORUS microkernel (v3 r5.x) offers the following synchronisation primitives: - mutexes - (counting) sempahores - spin locks (supervisor applications only) - mini messages (supervisor applications only) Other synchronisation primitives such as condition variables and reader/writer locks can be built on top of those basic primitives. * Do CHORUS threads support specific data? Yes. The microkernel supports so-called "software registers". Each thread has two software registers which are systematically saved/restored by the microkernel upon a thread context switch. The software registers can be read/written through threadStoreR(K) and threadLoad(K) system calls. A software register typically contains a pointer to a per-thread private data area. Via software registers, one can implement e.g. a per-thread value of "errno". * Distributed synchronization service on top of the CHORUS microkernel? This work is part of a PhD thesis undertaken by Stephane Eranian implementing distributed synchronization service on top of the CHORUS microkernel. It implements pure mutex (no mr/sw). The synchronization is achieved using a token-based algorithm through a server. Its main role is to manage token creation, deletion and sharing among sets of clients. For more information contact S. Eranian. 4.2. Supported Microprocessors ------------------------- Various versions of the CHORUS microkernel have been ported to a variety of microprocessors, either by Chorus Systems or by its clients: - i386/i486/Pentium (various PC/ATs) - mc68030/mc68360/mc68040 (MVME147S, QUADS, MVME167S) - mc88k - SPARC (SPARCstation SLC, SPARCstation Classic, SPARC CPU-3CE) - transputer T425/T805 - R3000/R4000 (Sony 3410) - PA-RISC (HP 9000/834 and 9000/720) - YMP (Cray YMP) 4.3. Porting on various platforms ---------------------------- * Chorus on Macintosh? The INT (Institut National des Telecommunications, Evry, France) has ported the v3 r3 version of the CHORUS microkernel to a Macintosh II CX (mc68030-based). CHORUS and MacOS coexist and cooperate on the same hardware. The paper "Cohabitation and Cooperation of Chorus and MacOS", by Christian Bac and Edmond Garnier, was presented at the Usenix Symposium on Microkernels and Other Kernel Architectures in Sep 93 in San Diego. You can find the paper in the proceedings. It is available from ftp.int-evry.fr:/pub/systeme. In the same directory you will also find another paper on the same subject: "ChorusToolbox : MacOS running on top of Chorus", by Christian Bac and Hong Quang Nguyen from INT. This paper was presented at SUUG'94 in April 94 in Moscow. * CHORUS on transputers? Archipel, Chorus and SGS/Thomson Inmos have ported the CHORUS microkernel and the CHORUS/MiX V.3.2 subsystem (SVR3.2 compatible) to T425 and T805 transputers. This was done in the context of the Esprit project "Harmony" (EC-funded R&D). Initially, a T9000 port was planned to be available by now. Due to a delay in the availability of the T9000, the CHORUS port (which is underway now), has shifted as well. Inmos and Chorus have been working together in order to assure that CHORUS/MiX (i.e. UNIX) will run in an optimal manner on the T9000. * CHORUS on 64-bit architecture? CHORUS has been ported to DEC's Alpha, Cray Research's YMP and MIPS' R4000. * Port of CHORUS on HP-PA? On December 1st Jon Inouye wrote: Prof. Jonathan Walpole supervised a port of the CHORUS v3.3 nucleus to the Hewlett-Packard 9000/834 workstation from late 1990 to mid-1991. This was part of a funded research project to evaluate the CHORUS operating system with respect to the Hewlett-Packard PA-RISC architecture. The nucleus did not support any disk/network drivers and performed all console/ keyboard I/O though IODC (PROM) routines. A CHORUS/MiX V.3.2 Process Manager (PM) port was partially completed to the point where UNIX shells and certain system calls were supported ... but not a UNIX file system. Since then, I have been porting Chorus/MiX V.3.2 (with the v3.4 nucleus) to the HP 9000/720. Since I am performing this port in my spare time it is not progressing very fast. The v3.4 nucleus runs along with a serial driver. It lacks other device drivers, FP emulation support (though basic FP operations are supported) and still uses the old HP-UX PDIR structure rather than the more recent HPT. The Ethernet driver is still being debugged as is an ancient version of the MiX V.3.2 PM. The port is being used for virtual memory experiments. Both ports use a considerable amount (over 40,000 lines combined) of HP-UX source code for the assembly language utilities, boot up, I/O initialization, and device drivers. The 834 port uses a Tut (HP-UX 2.0 modified to run Mach 2.0) base and the 720 port uses a HP-UX 8.0 base. For this reason, we have not been able to release anything because of all the legal implications ... HP, Chorus, USL copyrights. The evaluation is available as a series of OGI technical reports which can be obtained via anonymous ftp from cse.ogi.edu (129.95.20.2) in the directory /pub/tech-reports or via the URL: "http://www.cse.ogi.edu/DISC/projects/pa-chorus/pa-chorus.html". 4.4. Scheduling and real-time ------------------------ * Scheduling mechanisms and scheduling policies The CHORUS microkernel makes a distinction between scheduling mechanism and scheduling policies. The core scheduler within the microkernel does pure preemptive scheduling (SCHED_FIFO in POSIX RT terms). On top of that, different scheduling policies can be implemented in the form of scheduling classes; each class communicates with the core scheduler and can make its own scheduling decisions within that class based upon attributes (priorities, deadlines, etc) and behaviour (time-slicing, SCHED_RR, ...). Today, 4 scheduling classes are provided: a default class and the 3 UNIX SVR4 classes (SVR4_TS, SVR4_RT and SVR4_SYS). Work is in progress for additional classes (deadline, fair-share, etc) cf the work done by Olivier Gaultier and Y. Metais at CNAM Paris on the implementation of an EDF (Earliest Deadline First) policy in the CHORUS kernel. * Relative cost of context switch between user and supervisor threads? User threads/actors have their own address spaces, and are protected from other user address actors. Supervisor threads/actors all share the supervisor address space, each supervisor actor has its own "slot" in the supervisor address space. For comparison, let's take: [U] a context switch between 2 user threads in different user actors, [S] a context switch between 2 supervisor threads in different supervisor actors Unlike [U], [S] does not require the saving/restoring of the memory context, so [S] is less costly. For the CHORUS/Nucleus v3 r5.2 on a i486/50MHz, the ratio [U]/[S] is 1.57. 4.5. CHORUS on Transputers --------------------- * On transputers, how to communicate from CHORUS to UNIX (SunOS)? There is no standard way to do this with CHORUS. This is the kind of things CHORUS/MiX is there for. Specific to transputer, you can use emulated links: On your workstation run a daemon, the "Aserver", which comunicate with your b300 box. Together they emulate transputer virtual links over TCP/IP. These links can then be used by transputer and Unix applications to communicate. For details on how to do that, see the sections on the Aserver in the CHORUS documentation (CS/TR-94-82.1 and CS/TR-94-81.1). * Use of the INMOS RTL for the C-toolchain to work with sockets? [Answer on Dec. 6 from B. Wipfel ]: I'm guessing that you want to make socket calls from one of your actors, and have the B300 handle them in the normal way. Trouble is, as you've noticed, the transputer implementation of CHORUS uses AServer, not IServer. Since AServer communication is encapsulated in IServer MEGA_PACKETS, the B300 never gets to see any of the socket packets and passes everything to the host. I doubt whether this is possible, but it's worth suggesting in case things have changed since I was last involved with this. The AServer gateway is a hidden HPP added by the configuration system. But, you need something like this: Root Link to B300, runs IServer protocol | +----+----+ | IServer | | MUX | +-+-----+-+ | | | +--- Channel pair to your actor, actor | is linked with the socket library and | believes this is its root link. | | Fake IServer root link to the AServer gateway | Normal Chorus AServer network The IServer MUX is a standard process (written in OCCAM) available in one the support libraries. All processes external to Chorus should be HPP. The problem with this is that the configuration tool probably won't let you put the MUX where it is shown above, since it will always `insert' the AServer gateway on the root link. A real option is to write a new AServer server to provide your socket service. In this case, all communication will go to the host, and it will make the socket calls on behalf of your actor in the target system. The B300 wouldn't be involved, other than maintaining normal AServer communication with the host. This is kind of a shame, since the B300 has the necessary functionality. A long time ago, someone at INMOS worked on an AServer implementation for a BSD socket service, using the AServer RPC generator tool "asgen". The socket calls were specified in a language similar to SUN's RPC generation language. It might be possible to obtain this work, it's certainly worth asking. Also, since one of the goals of AServer was to support third party implementation of hosted services, maybe this work has already been done. An implementation of the AServer library at the Chorus side is available, you need this to access hosted third party AServer services. Yet another option would be to get INMOS to add native AServer support to the B300! The trouble with all of this stuff is that the native transputer libraries tend to do channel communication. The socket library does. But because actors were implemented as low priority transputer processes, they must not deschedule and so can't execute any channel communication instructions. Thus, not many of the regular libraries can be used by actors. A last option might be to use a second root link. Wire up two links from the B300 to your transputer network. Boot the network via one of the links. Configure the second link as a network "EDGE". Have your actor connect to the edge link with one of the AServer routines; something like cmLinkOpen("/dev/raw/00") ? Once the link is open, and you have the channel pointers, it might be possible to attach the socket library channels to these channels. You'll need to do communication via CHORUS' channel I/O routines however. * If we have made ourselves a sockgateway process, configured in the .cfs file as: .... interface(input fromhost, output tohost, input formChorus, output toChorus); Where do we connect the input and outputs ? [Answer on Nov. 25 from N. Stephen ]: I don't know what release you might have, but look up the #device primitive in the build tool users manual. This primitive allows you to attach native transputer processes' channels (which normally control devices) to the CHORUS world, and does all the necessary wiring so that these channels are accessible from the connection manager. There may also be an example of this being done in one of the tutorials, if you have them with your release - the CHORUS Nucleus Tutorial (2), mixing CHORUS and Native transputer code. In order to get the gateway channels necessary to communicate back to the host, in the CHORUS world a channel pair can be demanded of the connection manager. In the native transputer world, a channel pair could either be obtained by their addresses being passed across from the CHORUS world (yuk) or by configuring in the connections by hand. I don't suggest the route of running an hpp process from inside the CHORUS world either, it's much neater to configure in such a process. IMHO the use of supHppRun should only be for very small pieces of code which are integrally linked in with the CHORUS world. 4.6. Comparison with other OS ------------------------ * differences between Mach and CHORUS? There are a lot of similarities between the concepts of the CHORUS v3 r5 microkernel and the Mach 3.0 microkernel: IPC, threads, memory management. Some of the differences are: ------------------------------------------ Feature Mach CHORUS ------------------------------------------ Supervisor actors/tasks no yes Device drivers out of uK no yes Global object (port) names no yes Typed messages yes no Realtime no? yes Sender port no yes Send-once yes no RPC no? yes Reliable IPC yes no Port group (destination) no yes Scheduling classes ? yes (Counting) semaphores no yes Condition variables yes no Support for non-VM machines no? yes ------------------------------------------ 4.7. Performances ------------ * Is there any system for performance analysis? As far as the CHORUS microkernel applications ("actors") are concerned, the CHORUS/Profiler and the CHORUS benchmarks can be used. The CHORUS/Profiler allows one to obtain and display symbolic call-graph profile data for actors (similar to UNIX' gprof(1)): callers, calllees, absolute and relative time spent in different procedures within one actor. Actors are to be compiled with the -p option. The profiler consists of a supervisor actor (PROF) plus 2 CHORUS/MiX utilities. Profiling be can enabled/disabled dynamically using the CHORUS/MiX utility profctl(1). profctl(1) stores the raw profiling data in a UNIX file, which can then be exploited by the report generator profrpg(1) in order to produce a human-readable profile report. See ftp.chorus.fr:/pub/chorus- datasheets/Profiler_v3_r4.{ascii,ps.Z}. CHORUS benchmarks allow you to get performance figures for individual microkernel system calls. For some system calls, like ipcSend(K), you get performance figures for different cases/parameters (small/medium/big message sizes). These basic figures can also help you to analyse and tune the performance of your microkernel applications. In the context of the ESPRIT project Ouverture, Alcatel, Siemens and Chorus have designed and implemented so-called hooks for monitoring and debugging in the CHORUS microkernel. These hooks are a clean set of new microkernel system calls which allow monitoring and debugging tools (e.g., PATOC, PARTAMOS) to be informed about the occurrence of events they're interested in (context switch, message arrival, thread creation, etc). They will be available in a future CHORUS product release. PATOC is a graphical tool (Motif-based) that allows to monitor applications running on CHORUS. It is event based and is able to display its information is various forms (diagrams, bar-charts etc). PATOC is not a product but rather a working prototype. 4.8. Object Oriented Issues ---------------------- * How is CHORUS Object-Oriented? The major part (>90%) of the CHORUS microkernel is written in C++. OO techniques are used in the implementation of the microkernel, but the API exported by the microkernel is a traditional procedure call based interface (like UNIX). 5. OS Personalities ================ 5.1. OS personalities available on top of CHORUS? ------------------------------------------- Chorus Systems has developed the following personalties: - SVR4.0 - SVR3.2 - SCO ODT 3.0 - BSD4.3 - object-oriented (CHORUS/COOL) - POSIX real-time (POSIX 1003.1b/.1c, former .4/.4a) Others have developed, or are developing, personalities for SVR4.2 MP, UNICOS, MacOS, CHILL, ESTEREL, TINA DPE, and a number of (proprietary) real-time OSs. 5.2. CHORUS/MiX V.3.2 ---------------- * What is the link between a u_thread and a kernel thread? A u_thread is an abstraction, created by the CHORUS/MiX V.3.2 subsystem, on top of the microkernel threads (like a UNIX process is created on top of a CHORUS actor). Each u_thread is mapped 1-1 to a microkernel thread. A u_thread has some UNIX-specific attributes, like signal context, which is managed at the CHORUS/MiX subsystem level, as an added value w.r.t. a microkernel thread. * Which synchronisation primitives are offered to u_threads? Sempahores and mutexes. * Do u_threads support Thread Specific Data? Yes, through the threadsafe C library (c_threadPrivate(3CT), c_getPrivate(3CT)). These functions are in fact built on top of the software registers described for the kernel threads (cf 4.1). * How are u_threads scheduled? By the microkernel, just like any other thread. If one want to implement N user level threads on top of 1 kernel thread, he need a user level scheduler in some kind of run-time library (just like an Ada run-time schedules multiple Ada tasks within one Ada program).