This is a totally unedited compilation of various posts comparing Mach and Chorus that have appeared on comp.os.mach. I included those posts that seemed to contain actual facts, rather than pure flames. Article: 1445 of comp.os.mach Path: crabapple.srv.cs.cmu.edu!fs7.ece.cmu.edu!sei.cmu.edu!cert!netnews.upenn.edu!jvnc.net!darwin.sura.net!wupost!spool.mu.edu!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!heruka.cs.adelaide.edu.au!francis From: francis@heruka.cs.adelaide.edu.au (Francis Vaughan) Newsgroups: comp.os.mach Subject: Chorus and Mach ( was: USL Announces Pact with Chorus.) Message-ID: <5480@sirius.ucs.adelaide.edu.au> Date: 4 Dec 91 10:00:36 GMT References: Sender: news@ucs.adelaide.edu.au Reply-To: francis@cs.adelaide.edu.au Organization: Adelaide Univerity, Computer Science Lines: 128 Nntp-Posting-Host: heruka.cs.adelaide.edu.au It is interesting to contrast the differences between Mach and Chorus. I suspect that we here are one of the best placed to make some comparisons being quite familiar with both systems. Here we have used both systems extensivly but in rather different ways. There are good natured religious discussions about meta issues between our groups. Probably the most glaring difference between the two has been the approach to development. To make a rather sweeping statement, it seems that the two operating systems development has proceeded in a manner very much consistent with national personalities. One could charaterise the initial devepopment of Mach (at least the 2.0 and 2.5 releases that I have used) as a "get a functioning and useful system out the door as soon as possible" effort. With large slabs of Berkely code still in the kernel these releases could hardly be considered micro kernels at all. In fact they were really no smaller that conventional Unixes and suffered from all the failures that the micro kernel technology was trying to avoid. As an imeadiately useful testbed for important ideas they were brilliant. I for one am very grateful for the approach. We have used Mach for close to three years. We used it for all the interesting user level funtionality and would have been complelety unable to pursue some very successful work without it. Now that 3.0 is well under way with associated support packages we can see the first mature product from the research, which we are eager to use when it becomes a useful, stable release. But we will regard it as a perfomance and functionality enhancment only. We are not heartbroken about not being able to use it usefully yet. Chorus on the other hand seem to have adopted a more European and perhaps purist approach. From the very early days they had a micro kernel implemented. Which was fine. Development proceeded from the basics out in a very structured manner. But there was a huge gulf to be filled in order to produce a system in which a user not within the Chorus organization could be productive. If you wanted an embeded systems kernel for real time control they could provide what you wanted but you still needed a cross development environment. They did provide a single full Unix environment, it ran on one variety of a Compaq 386 box. Unfortunately it was little use beyond a demostration since the system was too buggy for everyday use. The code was very heavily based on SCO Unix. I am doubtfull that we could build the same system on Chorus today that we built under Mach 2.5 which is now quite old. The similarities between Mach and Chorus are quite striking in many places and one does see the occasional bit of (good natured) rivalry. The Chorus memory management primitives are almost a dead ringer for the Mach external pager abstractions. It would probably not be a difficult task to port a lot of code between the two. (Unsubstantiated statement here, I have not tried it.) One area that Chorus stands out in is in the area of documentation. From a position where the documentation and support was very minimal they now provide really excelent documentation for the entire system. It suffers a bit from verbage and one needs to be versed in the jargon a bit but on the whole it leaves the Mach documentation for dead. This is not surprising. Chorus is a large company now and probably employs a number of full time technical writers. Something that is just not an option within a university research project. Chorus always had a great deal of support from within the EEC, and it took me rather by surprise to see them branching out the way they have. I visited them two years ago, and at that time they seemed to be living off what I then termed the "Euro Gravy Train." The major part of their income came in the form of goverment assistance, both direct and via income from EEC agencies. This was EEC level to a large extent not French, some of it defence related. Customers wanted embeded controlers, real time software and the like, some interest in multi processors and the lure of a portable platform independant system was great. The differences between the Mach and Chorus groups is at all levels. Chorus luxuriate in a new building in downtown Versailes, ultra modern offices with colour co-ordinated slimline blinds (they match the corporate colours) and some of the snaziest halogen lighting I have seen. CMU on the other hand seems more like a cattle yard. I have the nasty feeling that almost all of Mach was written in a room about 8 feet by 12 feet, containing just about every kind of workstation available (half on the floor) and three or four slaves chained to their desks. I guess the lure of a job at OSF and a PhD from CMU must make up for a lot. :-) In article , Rick.Rashid@cs.cmu.edu writes: |> If by commercial performance you mean performance in the |> marketplace, then Mach has clearly outperformed Chorus. There |> are more Mach based systems on people's desktops, in research |> labs and in companies than Chorus systems by several orders |> of magnatude. For that matter, when last I heard (which was |> admittedly a number of months ago) Chorus Systems itself didn't use |> Chorus for development. They used Sun workstations, |> PCs, etc. running SunOS and System V. By that measure they |> are running about 6 years behind Mach. This is I think mostly a result of the development plan. That they STILL don't use it is a real worry. |> The fact of the matter is that USL is now getting |> desperate for a microkernel strategy. Their major |> competitors (e.g. Microsoft and OSF) are already announcing |> commercial microkernel-based products based on systems like |> NT and Mach. USL is badly behind, knows it, and has decided |> to take a time-honored (but seldom successful) approach to |> solving the problem. I feel that Chorus does have some reasonably mature micro kernel experience. What worries me is that I don't think they have the needed experience in building a real operating system around it. They have done this before in a limited way but if they still don't use their own product for internal development there must be a distinct lack of maturity. Disclaimer. I guess I will have said things to upset someone, perhaps everyone. I speak only for myself, and obviously only from my own limited perspective. I know a number of people at Chorus read this list, maybe they might like to put me straight if I have erred, CMU too. Francis Vaughan ------------------------------------------------------------- Article: 1454 of comp.os.mach Path: crabapple.srv.cs.cmu.edu!cantaloupe.srv.cs.cmu.edu!rochester!cornell!batcomputer!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!berlioz.cs.adelaide.edu.au From: gordoni@berlioz.cs.adelaide.edu.au (Gordon Irlam) Newsgroups: comp.os.mach Subject: Re: Chorus and Mach ( was: USL Announces Pact with Chorus.) Message-ID: <5520@sirius.ucs.adelaide.edu.au> Date: 5 Dec 91 13:07:45 GMT References: <5480@sirius.ucs.adelaide.edu.au> Sender: news@ucs.adelaide.edu.au Reply-To: gordoni@cs.adelaide.edu.au Lines: 258 Nntp-Posting-Host: berlioz.cs.adelaide.edu.au Forgive this long rambling article; it was fairly late when I wrote most of it. ------------------------------------------------------------------- francis@heruka.cs.adelaide.edu.au (Francis Vaughan) writes: > I suspect that we here are one of the best placed to make some > comparisons being quite familiar with both systems. Here we have > used both systems extensively but in rather different ways. Francis spends most of his time working on top - that is writing applications, and probably leans towards Mach. Whereas I spend most of my time working underneath - that is hacking kernels, and lean towards Chorus. Unix is now some 20 odd years old. It has evolved in ways that couldn't possibly have been anticipated when it was first developed. The source code to the v6 kernel was of the order of 10k lines, the source code to a modern unix kernel is of the order of 400k lines. Unix's problems today are a consequence of it's tremendous success. Now, more than ever, increasingly powerful forces are pulling it in conflicting directions according to various needs: networking, multiprocessors, distributed processing, supercomputing, real time .. Despite the tremendous flexibility of the original design the effects of these forces are now clearly visible. Their are portions of unix that are overstressed, being made to perform more than they were originally designed for. While other parts have become ghettos that are rarely visited - but nobody dares demolish them in case somebody still frequents them. Paradoxically the fact that unix is still alive today is due in part to the fact that AT&T were in the early days largely uninterested in it, and also due to the fact that not every improvement managed to find its way back into the standard reference sources. The biggest problems facing unix today are those familiar to every student of software engineering: dealing with large systems, dealing with changing requirements, and a gradual breakdown of the design and implementation of the system over time. Eventually there comes a time when you have to say enough is enough, throw the source code away, and start all over again. In doing so you can draw on both the mistakes, and successes of the past, as well as the current, and perceived future requirements - to design a new system that is better able to meet the current requirements, and evolve into the future. The emergence of Posix provides a particularly opportune time for such work to be undertaken. Sure, things would be done differently if an operating system was being designed from scratch, but it is still possible to clear much of the deadwood. Getting down to business, Chorus took the step of starting again from the ground up. Whereas Mach was of the opinion that it would be possible to modernize unix by performing a miracle hack that would separate the system into a set of clearly delineated components. The Chorus kernel is now fairly mature, however the unix sub-system which runs on top and is derived from System V is less mature, and less effort has been put into it. Trying to keep up with the latest version of unix has clearly been expensive. For a long time the micro-kernelization of Mach required you to squint fairly hard before you could actually see it. I think this has changed now, but I don't have very much knowledge of the current system. I think the biggest difference would between the two systems would have to be in the documentation provided. Sure documents do exist on Mach, but by and large they have been created either to be submitted to a conference, or as part of somebodies thesis. I haven't seen the documentation that Mt. Xinu produces so perhaps the situation is not as bad as this. On the other hand the documentation that comes with Chorus has been created explicitly for the end user. Thorough documentation exists that both explains the facilities provided by Chorus, and explains the internal structure of Chorus, and how to go about porting Chorus to another machine. (When we were porting Chorus many of the "internals" documents didn't exist, causing us to make a number of mistakes). Systems that aren't documented, probably weren't designed, and systems that weren't designed ..., well. Having proper documentation on a system sure beats scratching your head looking at the sources and trying work out how the hell the signal trampoline code is meant to work, and what you have to do to port it. Not that you won't have this problem with Chorus, since the upper levels are no better documented than what comes from AT&T, but the bits that Chorus have developed themselves are well documented. ------------------------------------------------------------------- Please, please, please, don't take this seriously, it is just for fun. Here is how I would rate the quality of the various vendors/systems: I'm a hard marker. Chorus 6 out of 10 A quite worker. Able to work independently, and has learnt from past mistakes. The body of her work is good, but she should probably spend more of her time applying finishing touches. Being a foreign born child she speaks slightly differently from the other children, but most of the other children don't have too much difficulty understanding her. Her background allows her to see alternative solutions to many of the exercises the children are set. AT&T 5 out of 10 Traditionally a slow, but careful worker. Recently has shown a disturbing trend towards attempting to replace quality by quantity. Grades likely to deteriorate if this trend is not reversed. Now days only allows the other children to borrow colouring pencils from his rainbow jumbo pack if they give him something in return. Suspected of haven written several very good short stories that I found crumbled up in the bin. Used to be fairly friendly, but has become something of a bully lately. Doesn't have any real friends any more. Recently has been nice to Chorus, but only so he could copy her exercise. BSD 4.5 out of 10 Originally a rebellious child, who used to scribble all over her exercise books using bright green crayons. Appears to have repented for spraying graffiti over the school gymnasium when she arrived at school, but unfortunately it could not be removed, and it is only slowly disappearing as a result of the weather. Is showing considerable maturity of late, and may get six out of ten for her next assignment. Enjoys talking on the play phone, however until recently she used to insist that she was able to use it without putting any money in. Cooperates well with others children particularly on the class POSIX project. Has won the friendship of the other children, who frequently copy her work, and let her copy a small amount of theirs in return. Sun 4.5 out of 10 Spends too much time filling in his exercise book with coloured in pictures and not enough time writing. Requires 96, rather than 48 page exercise books like the other children. Work is very nice to look at, but reading it suggests he has difficulty with some of the more important concepts. Might have difficulty in future years when more emphasis is given to what the children write than the pictures they draw. Sometimes shares his work with other children, but often expresses the fear that AT&T might thump him if does it to much. Consequentially requires other children to fill out complicated legal disclaimers when they want to borrow one of his books. Other children fill them out, but only to keep him happy. Frequently makes mistakes, but promptly corrects them when the other children point them out. Mach 4 out of 10 Tries hard, but fails to understand the importance of neat handwriting. Might actually be a gifted child, but has difficult communicating this information to other children. Unfortunately chose to work on his on work rather than participate with the rest of the class on the POSIX exercise, and is likely to get less out of future class exercises as a result of this. A friendly child that enjoys being the center of attention. Grades might improve if he obtains remedial treatment with Dr. GNU or Dr. Xinu. I've never seen OSF sources, perhaps someone who has can issue a report card. ------------------------------------------------------------------- Francis also writes, > .. but if they still don't use their own product for internal > development there must be a distinct lack of maturity. Not really. Chorus is quite stable. You under estimate the expense of what might be termed release engineering. That is pulling all the bits and pieces together and producing a complete integrated system. You would want your development machines to support things like NFS, X11, AT&T C++, GCC, all the standard unix utilities, and making sure everything is set up how it should be. That this involves considerable effort is suggested by the fact that CMU don't do this for Mach - sure they are not expected to - but the existence of Mt. Xinu that does this work indicates that it is both time consuming, and important. That this can be done for Chorus is beyond question - we did it for all the standard utilities and GCC, but not X11 or NFS. And the problems we encountered were typically problems in the application sources, or our port of Chorus to the SPARC, not problems in the generic kernel. If building such an environment was a one of effort it would make sense for Chorus to do this, but it requires a constant work. Every time a new release of X11 comes out, or an updated version of System V is released considerable work is required. Tracking the changes to these bits and pieces, applying bug fixes, and dealing with bug reports from whoever you ship the system to further down the line - as is necessary if you are to maintain a high quality product - is expensive. Since Chorus does not supply end users, and since the organizations it does supply are likely to want to do much of this work themselves (so that they have control over exactly what they ship) it makes sense that Chorus have not so far put very much effort into this area. ------------------------------------------------------------------- For those that are interested a document that compares Mach and Chorus is available for anonymous ftp as ftp.cs.adelaide.edu.au:/pub/mach_v_chorus.Z It is almost two years old, and is the result of my first contact with the two systems. It contains a number of technical inaccuracies (including a few which I promised someone at Chorus Systemes I would fix up, but never got around to, sorry). Sometimes these technical inaccuracies were a result of my not having as much time as would be necessary to do a completely through comparison of the two systems, in other cases erroneous, or non-existent documentation may have been the cause, and finally I obviously make mistakes like everybody else. In the case of lack of documentation, I unrepentantly assert that if something is not clearly documented you have essentially wasted your time doing it. Code can constitute documentation, although often lacks the necessary clarity. Much change to both Chorus and Mach has occurred over the last two years, however I feel that the overall flavour of the two systems is very much the same. ------------------------------------------------------------------- Finally I should declare my own biases, which are in favour of free software. I note that virtually every successful piece of software that I use (unix, BSD, NFS, X11, gcc, ..) has many technical flaws, and frequently better systems either existed, or could have been developed. However in nearly every case it will be seen that an openess on the part of the producer, in either making the software available in source form free of charge, or at very little cost, along with a willingness to allow the software to run on third party architectures, has resulted in the promulgation of the system to the role of a defacto standard. While competing systems have dropped away, and are never heard of again. In my opinion Chorus is technically superior to Mach, but that doesn't mean Chorus is the best system to use in the long term. The openess associated with Mach means that a synergistic effect is achieved whereby the development of Mach is advanced by the large number of users each working on their own problems. Of course this very vitality eventually results in the system breaking down as the original structure is further eroded. I tend to think of Mach as the life raft that will keep us alive until we know how, and have the resources to build a better vessel from scratch. Gordon Irlam (gordoni@cs.adelaide.edu.au) Go Mach! Go Chorus! ------------------------------------------------------------------ Article: 1458 of comp.os.mach Organization: Carnegie Mellon, Pittsburgh, PA Path: crabapple.srv.cs.cmu.edu!andrew.cmu.edu!+ Newsgroups: comp.os.mach Message-Id: Date: Thu, 5 Dec 91 16:44:23 -0500 From: Rick.Rashid@cs.cmu.edu Subject: Re: Chorus and Mach ( was: USL Announces Pact with Chorus.) It is my belief (based on statements I have heard from people at Chorus and various companies and labs) that the number of people who have actually used Chorus "in anger" (meaning as an everyday tool to get normal work done) is very close to nil. Of course, I could be wrong and my information out of date. I know for a fact that Chorus Systems itself traditionally has not used Chorus for its own development. (This could have changed in the last few months, but it has certainly been true over the last few years.) I guess I just have a lot of trouble believing in something which its own authors don't use (or haven't used). Every operating system I have written has been used by its authors (at least) and by others as soon as it was feasible -- typically very early in the project. RIG was used from 1976 on. Accent was used by late 1981/ early 1982. Mach from 1986 on. Chorus has claimed a Unix compatible system for years now (I was in meetings at Unix international in 1989 in which they were "selling" their system on its merits as a Unix box). Yet when it came to Unix cycles they opted for Suns and SysV PCs. Mach (in its various forms) is used by 10s of thousands of people every day. Mach has been available for scrutiny by all consistently for the last 5 years. Current versions of Mach 3.0 sources are available on anonymous ftp archives around the world (right next to the PC video games!) and Mach papers and technical reports are subject to direct verification by a huge community. There is a large body of existing Mach documentation in the form of technical reports, manuals, tutorials, video tapes, etc. Most of these are available through the OSF, the USENIX society or via anonymous ftp. Clearly CMU is not a company, but there are companies which are going to be (and are already) selling Mach based products. ----------------------------------------------------------------------- Article: 1463 of comp.os.mach Path: crabapple.srv.cs.cmu.edu!fs7.ece.cmu.edu!sei.cmu.edu!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!qt.cs.utexas.edu!cs.utexas.edu!uunet!mcsun!corton!chorus!mg From: mg@chorus.fr (Michel Gien) Newsgroups: comp.os.mach Subject: Re: Chorus and Mach ( was: USL Announces Pact with Chorus.) Message-ID: <12408@chorus.fr> Date: 7 Dec 91 12:58:50 GMT References: <5480@sirius.ucs.adelaide.edu.au> Sender: mg@chorus.fr Reply-To: mg@chorus.fr Organization: Chorus systemes, 6 av. Gustave Eiffel, 78182 Saint-Quentin-en-Yvelines, France Lines: 63 Considering the proliferation of inaccurate information concerning CHORUS, I felt that I should set the record straight. During the past few of days, several negative and inaccurate statements about CHORUS, based on little to no information, have been promulgated. The fact of these inaccuracies is hidden behind the blanket excuse that the "information" may be out of date. Furthermore, these remarks are made in such a way as to make it nearly impossible to respond with technical arguments. The playing field has been chosen and the referees have been paid. It seems to be a foregone conclusion, in this news group, that Mach is sufficient; indeed it is by certain metrics. In another arena, however, Mach falls short. It is the goal of this posting to clear up some misconceptions about CHORUS and to propose alternative metrics by which systems can be compared. We do not intend to enter into a flame war here. We would be eager, however, to carry on a technical discussion about CHORUS, Mach, NT, OSF/1, Amoeba, Sprite, Plan 9, or any other advanced technology operating system. To address the specific points: 1) We DO use CHORUS on a daily basis. CHORUS has been running on thousands of X-Terminals, such as the one that I am using to prepare this message, for over 2 years, without a single bug report regarding its operating system. 2) We DO use CHORUS to develop CHORUS. Our multi-server, distributed SVR3.2 system (CHORUS/MiX V.3.2) has been in constant use for its own development and day-to-day operation for the past 2 years. Our new SVR4 compatible system (CHORUS/MiX V.4.0) has been used as its own development environment for the past year. Our distributed, object-oriented platform (COOL) has been developed on CHORUS machines from its inception. It is true, however, that we do not yet have a BSD or SunOS compatible environment. The reason is purely economic: our choices for product development need to be driven by market forces. We do not devote our valuable resources to port device drivers and utilities. Instead, we have chosen to provide full binary compatibility with industry standards to take advantage of existing device drivers and utilities. Additionally, we would not exist today as a company had we spread ourselves too thin in the attempt to provide binary compatibility with BSD and SunOS in the first place. 3) Chorus is not in competition with Mach; Mach is a federally funded university research project. Chorus is a privately owned, privately funded company. Our focus is significantly different from that of the Mach project. Our current major objective is to provide distributed operating systems for the embedded real-time and parallel computer (scientific and business) markets. We do not sell binary distributions; we provide the technology to equipment manufacturers who package their systems with their own particular added value. Now that we've had a chance to clear up some misconceptions, I hope that we can move on to a more productive discussion of technical issues. Regards, Michel -- _ _ _ _ Michel Gien ' ) ) ) / // Chorus systemes / / / o _. /_ _ // 6 avenue Gustave Eiffel / ' (_<_(__/ /_+ Newsgroups: comp.os.mach Message-Id: Date: Sat, 7 Dec 91 17:34:21 -0500 From: Rick.Rashid@cs.cmu.edu Subject: Re: Chorus and Mach ( was: USL Announces Pact with Chorus.) I think I sent this to the wrong address, it will either come out multiple times or just this once: ********** I'm glad to hear from Michel that Chorus has begun to use its own system for development. As I said in my earlier messages, I felt that it was quite possible my information was out of date and that Chorus had finally begun to use its system in that way. I also know from conversations with Chorus personel that this was not the case either originally or for that matter even in relatively recent times. I still suspect (Michel can set me straight on this one) that Chorus still relies heavily on non-Chorus systems for its daily work. I should have qualified my comments about use to mean "use as a System V" platform. This was implicit in my remarks (since I referred to their System V presentation to UI in 1989), but should have been more explicit. I would be quite pleased if Michel could provide us with a current accounting of Chorus usage by end users as a System V.4 platform. I am actually quite curious about it, but have never seen any published figures or heard Michel or others at Chorus state a figure in a public forum. Finally, wrt Michel's comments about the fact that a large portion of the Mach project's funding has been governmental, he neglected to point out that, over the years, a huge portion of Chorus funding has come from the EEC in the form of ESPRIT projects. Purely in terms of dollars (or ecus) Chorus has been for years the much larger consumer. It should also be pointed out that, as a result of government monies, CMU developed Mach code has been made freely available to everyone (even companies like Chorus) and that their are dozens of anonymous ftp sites all over the world which will allow you to download CMU sources. Chorus, although the recipient of substantial governmental money through various Esprit projects, retains its proprietary interest in its software. Now, I don't begrudge Michel his chance to make money. Many people sell Mach too. I just feel he is in a poor position to question Mach's research funding. ---------------------------------------------------------------------- Article: 1487 of comp.os.mach Path: crabapple.srv.cs.cmu.edu!cantaloupe.srv.cs.cmu.edu!rochester!rutgers!apple!voder!pyramid!ctnews!risky!starlite!barry From: barry@starlite.convergent.com (Barry Gleeson) Newsgroups: comp.os.mach Subject: Re: Mach versus Chorus Message-ID: <8510@risky.Convergent.COM> Date: 12 Dec 91 01:22:51 GMT References: <1991Dec10.012058.11624@cs.cornell.edu> <8509@risky.Convergent.COM> Sender: root@risky.Convergent.COM Reply-To: barry@convergent.com Organization: UNISYS Unix Systems Group, San Jose, Ca. Lines: 46 In early 1989, we at Unisys looked carefully at both Chorus and Mach. We elected to build a system based on Chorus, because it appeared to us at that time to be a more mature base for commercial operating system development, and because it was possible for us to enter into a business relationship with them. (That relationship was announced in the press a year ago.) We have not tracked the development of Mach since then; we have been intimately involved in the development of a Motorola 88K-based SVR4 binary compatible system using Chorus. Work on that system began in late 1989. We now have a system that is: 1) Fully binary compatible with standard SVR4. (88open BCS, OCS, ABI, Networking; SVVS, XPG/3, POSIX, ad nauseam...) 2) Runs NFS client & server, X11R3 (a consequence of 1) 3) Is price/performance competitive with native SVR4 systems. (I have numbers; I am constrained from publishing them at this time.) Initial debug of two of the major SVR4 servers - the file system server and the STREAMS server - was done in user space on Chorus SVR3 systems. This greatly accelerated the initial development. We switched to our own hardware and OS as our internal development platform almost a year ago. The system is now sold through a Unisys subsidiary. (Forgive me for advertising - I am just trying to show that the system is real.) We took considerable care to preserve SVR4 internal interfaces where appropriate. In particular, DDI-compliant device drivers are NOT aware that they are running in a non-SVR4 environment. We found that the fact that the system was split into multiple servers to be a substantial plus during our development: it facilitated parallel development of different parts of the OS. The microkernel has proved a highly stable platform on which to develop an operating system. The only 'features' of SVR4 that were not implemented were RFS and the Xenix system calls. This ommision was not for technical reasons: we did not see a major market requirement, and we were able to shorten our schedule. We have been very pleased the both the quality of the Chorus microkernel, and with the professional level of support provided by the company. Barry Gleeson. Unisys. ---------------------------------------------------------------------- Article: 1549 of comp.os.mach Path: crabapple.srv.cs.cmu.edu!cantaloupe.srv.cs.cmu.edu!rochester!news.bbn.com!usc!cs.utexas.edu!uunet!mcsun!corton!chorus!lipkis From: lipkis@chorus.fr (Jim Lipkis) Newsgroups: comp.os.mach Subject: Re: Mach versus Chorus Message-ID: <12630@chorus.fr> Date: 12 Jan 92 17:20:25 GMT References: <1991Dec10.012058.11624@cs.cornell.edu> Sender: news@chorus.fr Lines: 72 Over a month ago Ken Birman posed a couple of technical questions regarding Chorus and Mach that no one seems to have answered yet, so I'll take a stab. In article <1991Dec10.012058.11624@cs.cornell.edu>, ken@CS.Cornell.EDU (Ken Birman) writes: > ... > I, for one, would be curious to know how virtual memory management > in Mach differs from the scheme in Chorus. The two are similar in overall architecture, though mechanisms and protocols differ. The following paper from SOSP89 is a good reference on the Chorus design, with some material comparing and contrasting with the Mach v.m. design (including some performance comparisons). %A V. Abrossimov %A M. Rozier %A M. Shapiro %T Generic Virtual Memory Management for Operating System Kernels %R 12th ACM Symposium on Operating Systems Principles, Litchfield Park, Arizona %D 89/12 %P 27 Of course many aspects have evolved in the last two years (probably in Mach as well). Beyond the v.m. management specifics, I would say that the role of virtual memory differs somewhat between Mach and Chorus. Virtual memory is optional in Chorus (I think it is not in Mach). Furthermore, for reasons of performance as well as flexibility, Chorus makes far less use of page remapping devices to optimize functions like IPC message body transmission and file I/O, even on machines with full paged v.m. hardware. (Copy-on-write and/or copy-on-reference are used in Chorus region-level operations, however, in particular for UNIX fork()). > ... Another issue that interests > me concerns the mechanisms for turning user-space actors into kernel > actors in Chorus (actor==task, for Mach users). Is this worth the > system complexity it must have added? There's nothing complicated here. User actors and supervisor actors use the same microkernel facilities through exactly the same interface. Any program designed to run as a user actor can be run as a supervisor actor with no change (probably has to be relinked but does not in general have to be recompiled). User and supervisor actors are loaded into execution in similar ways, whether - loaded by a subsystem (e.g. an actor loaded by a UNIX subsystem Process Manager becomes a UNIX process) - loaded as a pure actor (non-UNIX program using microkernel facilities directly) by an "actor loader" - loaded statically, at boot time. There is a procedure for loading (e.g.) the multi-server UNIX system, which consists of a number of different executable binaries, in a single "boot archive" file. Boot-loaded actors can be either user or supervisor, either pure actors or UNIX processes. One ramification of all this is that UNIX subsystems can (and do) support UNIX "system processes", i.e., programs that run in supervisor mode, contain interrupt handlers, etc., and make use of the normal UNIX interface and environment. Supervisor actors allow interactions among themselves and with the microkernel to be highly optimized, transparently, using among other things an ultra-lightweight RPC. Basically, they provide a way to keep the advantages of modularity while allowing a degree of protection to be traded off for performance in the local (non-distributed) case. Supervisor actors also have access to various privileged microkernel facilities, such as dynamic connection of interrupt, trap, and exception handlers. Servers containing device drivers, as one example, make use of these facilities. (The microkernel never contains device drivers in Chorus.) Drivers usually run in supervisor actors for performance, but can also run in user mode with a stub in supervisor space. Jim Lipkis (lipkis@chorus.fr) Chorus syste`mes ------------------------------------------------------------------------ Article: 1550 of comp.os.mach Path: crabapple.srv.cs.cmu.edu!cantaloupe.srv.cs.cmu.edu!rochester!rutgers!cs.utexas.edu!wupost!m.cs.uiuc.edu!rchen From: rchen@m.cs.uiuc.edu (Rong Chen) Newsgroups: comp.os.mach Subject: Re: Mach versus Chorus Message-ID: <1992Jan12.222559.30344@m.cs.uiuc.edu> Date: 12 Jan 92 22:25:59 GMT References: <1991Dec10.012058.11624@cs.cornell.edu> <12630@chorus.fr> Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL Lines: 36 lipkis@chorus.fr (Jim Lipkis) writes: >Over a month ago Ken Birman posed a couple of technical questions regarding >Chorus and Mach that no one seems to have answered yet, so I'll take a stab. >> ... Another issue that interests >> me concerns the mechanisms for turning user-space actors into kernel >> actors in Chorus (actor==task, for Mach users). Is this worth the >> system complexity it must have added? >There's nothing complicated here. User actors and supervisor actors use the >same microkernel facilities through exactly the same interface. Any program >designed to run as a user actor can be run as a supervisor actor with no >change (probably has to be relinked but does not in general have to be >recompiled). .... >Supervisor actors allow interactions among themselves and with the microkernel >to be highly optimized, transparently, using among other things an >ultra-lightweight RPC. Basically, they provide a way to keep the advantages >of modularity while allowing a degree of protection to be traded off for >performance in the local (non-distributed) case. >Supervisor actors also have access to various privileged microkernel >facilities, such as dynamic connection of interrupt, trap, and exception >handlers. Servers containing device drivers, as one example, make use of >these facilities. (The microkernel never contains device drivers in Chorus.) >Drivers usually run in supervisor actors for performance, but can also run >in user mode with a stub in supervisor space. Well, if my guess is right, Chrorus has a backdoor trap for some user actors. When the trap returns, it leaves the hardware super-user bit on, so a user actor would be called a supervisor actor now. -Rong Chen (rchen@cs.uiuc.edu) Department of Computer Science University of Illinois at Urbana-Champaign ------------------------------------------------------------------------ Article: 1551 of comp.os.mach Path: crabapple.srv.cs.cmu.edu!cantaloupe.srv.cs.cmu.edu!rochester!rutgers!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!spool.mu.edu!uunet!gossip.pyramid.com!pyramid!ctnews!risky!starlite!scott From: scott@starlite.convergent.com (Scott Lurndal) Newsgroups: comp.os.mach Subject: Re: Mach versus Chorus Message-ID: <8656@risky.Convergent.COM> Date: 13 Jan 92 18:47:46 GMT References: <1991Dec10.012058.11624@cs.cornell.edu> <12630@chorus.fr> <1992Jan12.222559.30344@m.cs.uiuc.edu> Sender: root@risky.Convergent.COM Reply-To: scottl@convergent.com Organization: UNISYS Unix Systems Group, San Jose, Ca. Lines: 24 In article <1992Jan12.222559.30344@m.cs.uiuc.edu>, rchen@m.cs.uiuc.edu (Rong Chen) writes: |> Well, if my guess is right, Chrorus has a backdoor trap for some user actors. |> When the trap returns, it leaves the hardware super-user bit on, so a user |> actor would be called a supervisor actor now. |> |> -Rong Chen (rchen@cs.uiuc.edu) |> Department of Computer Science |> University of Illinois at Urbana-Champaign No. A supervisor actor becomes such when it is created [in the case of a separate address space architecture like the Motorola 88100, the supervisor actor needs to be loaded into the supervisor address space, where a user actor would be loaded into its own address space.]. Additionally, the supervisor bit would be set for a thread-of-execution not for a piece of code. There are no back-door traps provided by the Chorus microkernel. There is nothing preventing a supervisor actor from providing such a back-door to an application program, provided the architecture allows it [88100 doesn't unless the appl code is in both a user address space and the supervisor address space]. Note that a supervisor actor is allowed to create another supervisor actor.... scott lurndal unix systems group unisys san jose ------------------------------------------------------------------------- Article: 1564 of comp.os.mach Path: crabapple.srv.cs.cmu.edu!cantaloupe.srv.cs.cmu.edu!rochester!news.bbn.com!usc!cs.utexas.edu!uunet!mcsun!corton!chorus!lipkis From: lipkis@chorus.fr (Jim Lipkis) Newsgroups: comp.os.mach Subject: Re: Mach versus Chorus Message-ID: <12695@chorus.fr> Date: 18 Jan 92 19:49:09 GMT References: <1991Dec10.012058.11624@cs.cornell.edu> <12630@chorus.fr> <1992Jan12.222559.30344@m.cs.uiuc.edu> Sender: news@chorus.fr Lines: 34 In article <1992Jan12.222559.30344@m.cs.uiuc.edu>, rchen@m.cs.uiuc.edu (Rong Chen) writes: > Well, if my guess is right, Chrorus has a backdoor trap for some user actors. > When the trap returns, it leaves the hardware super-user bit on, so a user > actor would be called a supervisor actor now. No, there's no such thing in Chorus, and I'm not sure I see what the purpose of such a feature would be (apart from demolishing any pretense of software security). User actors cannot change into supervisor actors on the fly. Threads of user actors can execute in supervisor mode only by issuing a trap instruction and thus executing a trap handler in supervisor space that a supervisor actor has connected. When control returns to the user program, the CPU is never in supervisor state. In any case, the distinction between supervisor and user actors affects more than the CPU privilege bit. Perhaps I should have explained more thoroughly in my previous posting: user actors run in individual protected address spaces (much like UNIX processes), whereas supervisor actors share a single supervisor address space with each other and with the microkernel. The goal is to give the system builder or configurer the capability of choosing between greater protection among system modules (run servers as user actors) on one hand, and better performance (run servers as supervisor actors sharing a memory context) on the other, or a combination of the two. (The performance advantages of having separate programs share an address space are also desirable at the user level in some environments, and it's likely that address space sharing will be extended to user actors at some point in the future. There are also reasons to want multiple supervisor spaces, instead of just one. But the current arrangement has proven remarkably flexible, given the current state of the art in hardware protection mechanisms.) Jim Lipkis Chorus syste`mes