Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!decwrl!nsc!voder!pyramid!csg From: csg@pyramid.pyramid.com (Carl S. Gutekunst) Newsgroups: comp.sys.pyramid Subject: Re: SysV + BSD + Pyramid. Message-ID: <124029@pyramid.pyramid.com> Date: 20 Aug 90 22:20:21 GMT References: <308@dynasys.UUCP> Reply-To: csg@pyramid.pyramid.com (Carl S. Gutekunst) Organization: Pyramid Technology Corp., Mountain View, CA Lines: 40 In article <308@dynasys.UUCP> jessea@dynasys.UUCP (Jesse W. Asher) writes: >I'm going to be working with Pyramids sometime in the near future and I >was curious about something. Someone mentioned that you are able to >run both SysV and BSD software, but it would switch modes or some such. Pyramid's OSx Operating System implements what is commonly called a "dual port." The system includes two complete environments (Pyramid calls them "universes"), one 4.[23] BSD, and the other SVR3.2. This means the kernel implements two complete sets of system calls, and the filesystem has to hold two complete sets of utilities and header files. For each process, a runtime flag indicates the "universe" in which it is running, and in the filesystem a "conditional symbolic link" is used to select which directories and files are to be used. Similar implementations are used by Apollo, Harris, and Gould (now Encore). Sequent's Dynix is in between: internally, it is organized more like a merged port (see below), but externally it looks like dual port. The alternative is a "merged port," in which the vendor provides the desired features of both Berkeley and System V within the same unified environment. The most common varient of this is "System V with Berkeley extensions," done by everyone from Microsoft to Unisoft. Sun has been doing a more sophisticated merge with SunOS for some time, and more recently AT&T with SVR4. I don't think there is any disagreement today that a dual port is a kludge (Dennis Ritchie's exact word was "appalling"), and that a merged port is far more desirable. (Pyramid is providing two reference ports for SVR4.) But the dual port has been very popular for many reasons. The biggest is that it's a lot easier than a merge; it requires very little design and much less coding effort. In addition, crafting a merge involves many compromises and deviations from the "base" Berkeley and System V semantics. Any vendor's merge is likely to not be source-compatible with any other vendor's merge. (Indeed, Gould tried this early on, and it was a complete flop.) Also, given the large number of pure Berkeley and System V ports, the dual port made sense for developers who needed to maintain source "purity." An old adage was that OSx was not particularly easy to port *to*, but it is very easy to port *from.* The nuisance is that if you really want a particular System V feature in your Berkeley code, it's either very difficult or impossible.