Der Open-Systems-Gemeinde steht ein Technologieschub bevor. Der neueste Trend weist in Richtung verteilte DV-Umgebungen, massiv-parallele Rechner und Echtzeit-Anwendungen - Anforderungen, die herkömmliche Unix-Betriebssysteme nicht erfüllen können. Die Open-Systems-Propagandisten der Open Software Foundation (OSF) und der Unix System Laboratories (USL) setzen daher auf die Microkernel-Technik. Die konkurrierenden Produkte in diesem Gebiet heißen Mach und Chorus.

Die Organisation der Informationsverarbeitung im Unternehmen war in den letzten Jahren starken Veränderungen unterworfen. Durch die enormen Fortschritte in der Hardwaretechnologie und im Bereich Rechnerarchitekturen (RISC, Multiprozessoren) können heute dem einzelnen Mitarbeiter hohe Rechenleistungen vor Ort zur Verfügung gestellt werden.

Durch den Einsatz von Netzwerken ist dieser Ansatz des Personal Computing auch für personen- und abteilungsübergreifende Aufgaben geeignet. So dringen verteilte Systeme verstärkt in vormals typische Großrechner-Domänen vor. Diese Entwicklung geht einher mit der zunehmenden Abkehr des Anwenders von proprietären Betriebssystemen und dem Einsatz offener Systeme sowie standardisierter Plattformen. Diese ermöglichen eine weitgehende Herstellerunabhängigkeit im Hardware- und Softwarebereich und somit eine wirtschaftliche Nutzung der eingesetzten Ressourcen.

Neue DV-Trends überfordern UNIX

Die oben skizzierte Situation spiegelt sich auch in der Evolution der heute existierenden offenen Betriebssystem-Plattformen der Open Software Foundation und der Unix System Laboratöries wider. In bestehende Unix-Kerne wurden zusätzlich Funktionen integriert, um den veränderten Anforderungen gerecht zu werden. Konkret ging es dabei um die Unterstützung von Verteilung, um Sicherheitsaspekte, Multiprozessor-Unterstützung und Echtzeit-Fähigkeit.

Die nächste Stufe wird nun mit der Entwicklung von Betriebssystemen beschnitten, welche die oben beschriebenen Rechnerarchitekturen direkt durch neue Mechanismen unterstützen und so die für unterschiedliche Aufgabenfelder geforderte Funktionalität integriert anbieten. Zur Sicherung getätigter Investitionen ist dabei Kompatibilität zu existierenden Standards im Bereich offener Systeme gefordert.

Die Betriebssysteme Mach, eine Entwicklung der amerikanischen Carnegie Mellon University, und Chorus von der französischen Firma Chorus Systémes, sind zwei international relevante Produkte, die Unterstützung dieser neuen Architektur von IT-Systemen bieten. Sie werden heute allgemein als Basis zukünftiger offener Systeme angesehen.

Beide beruhen auf der Microkernel-Architektur, die sich als die kommende Technologie bei Betriebssystemen herauskristallisiert.

Im folgenden soll die Frage beantwortet werden, wie groß die Relevanz von Mach und Chorus für zukünftige offene Systeme ist. Dazu werden die oben angesprochenen technologischen Aspekte untersucht und das marktpolitische Umfeld der beiden Systeme analysiert.

Die Entwicklung von hochleistungsfähiger Hardware geht immer mehr in Richtung Multiprozessor-Architekturen.

Um auf der Anwenderseite die Leistungsvorteile möglichst vollständig nutzen zu können, müssen Betriebssysteme in ihrem Aufbau und ihren Mechanismen derartige Architekturen effizient unterstützen. Unix hat hier schwerwiegende Nachteile, da zum Beispiel aufgrund der langen Dauer für Prozeßwechsel eine große Anzahl an Prozessoren nicht optimal ausgenutzt werden kann.

Ein wesentlicher Aspekt zukünftiger offener Systeme ist die effiziente Unterstützung von Verteilung. Hierzu zählen eine ganze Reihe von Mechanismen, welche das betreffende System direkt anbieten muß.

Anforderungen an Systeme in verteilten Umgebungen

Transparenz ist in verteilten Umgebungen eine unabdingbare Forderung, sei es, daß die Kommunikation unabhängig vom Ort der Kommunikationspartner ist, sei es, daß Komponenten unbeeinflußt vom Fehlverhalten anderer Komponenten bleiben oder daß die Replikation von Komponenten verborgen bleibt. Alle diese Aspekte werden von heutigen Unix-Systemen nur ungenügend unterstützt.

Auch der Aspekt der Heterogenität der Umgebung spielt hier eine Rolle. Verteilte Systeme bestehen in der Regel aus Hardwarekomponenten unterschiedlicher Hersteller. Ein Betriebssystem sollte auf möglichst allen Plattformen effizient ablauffähig sein, vor allem der Portierungsaufwand auf eine Zielhardware muß begrenzt bleiben. Unix bietet in puncto Heterogenität dank der Herstellerunabhängigkeit bereits gute Ansätze.

Weitere Anforderungen, die immer wieder gegenüber Anbietern von offenen Systemen geäußert werden, sind:

- Sicherheits-Features mit Verschlüsselungs- und Authentifizierungsmechanismen,

- Unterstützung von Echtzeit-Anwendungen (Prioritäten, Aktivitätsverwaltung und Scheduling) und

- Einschwenken auf objektorientierte Techniken.

Gerade in diesen Bereichen sind die Mängel der gegenwärtigen Allzweck-Betriebssysteme besonders augenfällig.

Zur Geschichte von Mach und Chorus

Mach wird seit 1985 an der Carnegie Mellon Universität entwickelt. Entsprechende Konzepte wurden bereits in Vorläuferprojekten realisiert, wobei insbesondere Aspekte der Verteilung und Multiprozessor-Unterstützung eine große Rolle spielten.

Heute spielt eine wesentliche Rolle, daß Mach kompatibel zum Unix konzipiert wurde und darüber hinaus mit einem besonders kleinen Betriebssystem-Kern auskommt. Zu diesem Zweck wurden zuerst wesentliche Mechanismen wie Speicherverwaltung und Kommunikation in dem Kernel des Unix-Derivats BSD4.2 integriert, wobei die Binärkompatibilität zu diesem System erhalten blieb. Daraus entstand das seit 1989 verfügbare Mach 2.5, welches heute unter anderem die Basis des OSF/1-Betriebssystems der Open Software Foundation bildet.

Die Umsetzung der Microkernel-Architektur und die Integration zusätzlicher Mechanismen erfolgt seit 1989 im Rahmen der Mach Version 3.0. Diese ist wiederum Basis für die Arbeiten der Foundation bezüglich der neuen Betriebssystem-Plattform OSF/2.

Chorus entstand ungefähr zur gleichen Zeit am französischen Forschungsinstitut Inria. Auch hier lagen die Entwicklungsschwerpunkte auf effizienter Multiprozessor-Unterstützung und verteilten Architekturen. Im Gegensatz zu Mach stand der Gedanke der Unix-Kompatibilität weniger im Vordergrund, vielmehr wurde auf die Integration von Echtzeit-Funktionalität Wert gelegt.

Seit 1986 wird das System von der Firma Chorus Systémes weiterentwickelt und mit Unix System V, Version 3.2, und seit kurzem mit einem V.4-kompatiblen Subsystem kommerziell vermerktet. Während Chorus zunächst hauptsächlich im europäischen Raum - im Rahmen des Esprit-Programms oder bei der Raumfahrtbehörde ESA Verbreitung fand, existieren jetzt auch Kooperationen mit USL und dem Hardwarehersteller Unisys sowie enge Kontakte zu Intel im Bereich der Entwicklung von Parallelrechnern.

Die Prinzipien der Microkernel-Architektur

Die Microkernel-Architekturen Mach und Chorus gehen beide vom gleichen Designkonzept aus: Danach läuft auf der jeweiligen Hardware lediglich eine minimale Menge von Betriebssystem-Funktionen, nämlich Prozeßverwaltung, Interprozeßkommunikation, Gerätetreiber, virtuelle Speicherverwaltung und Kommunikation. Diese Grundfunktionalität stellt den Microkernel dar.

Höhere Betriebssystem-Funktionen auf der Basis dieser Kernel als Betriebssystem-Server implementiert. Dadurch erweisen sich die angebotenen Mechanismen als effizienter.

Außerdem vereinfacht die Trennung in Microkernel und Betriebssystem-Server die Portierung eines Gesamtsystems auf verschiedene Hardware. Auch lassen sich auf Basis des gleichen Microkernels verschiedene Betriebssysteme implementieren.

Von Bedeutung ist in diesem Zusammenhang die Unterscheidung von Single-Servern und Multiple-Servern. Im ersten Fall wird die gesamte Funktionalität als ein Server auf dem Microkernel implementiert, im zweiten werden mehrere kooperierende Server implementiert, welche jeweils eine spezifische Teilfunktionalität realisieren. Während die erste Lösung effizienter zu realisieren ist, verspricht die zweite Lösung größere Flexibilität.

Die Unterstützung von Multiprozessor-Systemen

Sollen Aktivitäten in einem Rechensystem parallel ablaufen, so müssen sie im allgemeinen auf das Prozeßkonzept des jeweiligen Systems abgebildet werden. Die Verwaltung von Prozessen stellt einen Aufwand dar, der bei einer Vielzahl nebenläufiger Aktivitäten, wie wir sie in Multiprozessor-Systemen vorfinden, nicht akzeptabel ist. Mach und Chorus gliedern deshalb den Prozeßbegriff wie wir ihn von Unix kennen in zwei Teile. Konkret existiert ein Objekt, welches die Ablaufumgebung mit Adreßraum, offenen Dateien und Kommunikationskanälen definiert. Einem weiteren wird der Aktivitätsfluß zugeordnet, zu dem Register und Befehlszähler gehören. Bei Mach wird hier von Tasks und Treads gesprochen, bei Chorus von Actor und Activity.

Parallelität ist nur auf der Ebene der Threads beziehungsweise Activities sichtbar. Um auch bei diesem Konzept den Aufwand beim Umschalten minimal zu halten, bietet Chorus die Möglichkeit vom Benutzer definierte und getestete Activities als Kernel-Activity ablaufen zu lassen.

Entscheidenden Einfluß auf die Multiprozessor-Unterstützung hat auch die virtuelle Speicherverwaltung des Kerns. Hier existieren unterschiedliche Speicherkonzepte wie gemeinsamer und gegliederter Speicherzugriff sowie Remote-Zugriff.

Mach bietet ein ausgeklügeltes System, welches transparent sogar gemeinsamen Speicher mit "non-uniform access" verwalten kann. Dort ist die virtuelle Speicherverwaltung in zwei Teile gegliedert, nämlich in einen maschinenunabhängigen und einen maschinenabhängigen Teil.

Der maschinenunabhängige Teil realisiert die Aufteilung des logischen Adreßraums einer Task in Segmente unterschiedlicher Größe, deren Vererbung, Parallelnutzung und das Nachladen des Adreßbereichs durch einen externen Seitenverwalter. Speicherbereiche werden bei Parallelnutzung erst bei schreibendem Zugriff kopiert. Dieses Schema erlaubt größtmögliche Flexibilität und Effizienz bei der Speicherausnutzung und der Verwaltung des Hintergrundspeichers.

Der maschinenabhängige Teil realisiert eine abstrakte Seitenverwaltungs-Schnittstelle für den physikalischen Speicher, die sich auf unterschiedliche Speicherarchitekturen abbilden läßt.

Die Implementierung der virtuellen Speicherverwaltung in Chorus ist ähnlich organisiert. Der einem Actor zugeordnete Adreßraum wird in Chorus Kontext genannt. Ein Kontext besteht aus nicht-überlappenden Regionen. Diese Regionen werden auf Hintergrundspeicher-Objekte, die Segmente, abgebildet.

Nur die Grunddienste befinden sich im Kernel

Segmente werden außerhalb des Kernel durch externe Server, die Segment Mapper, verwaltet. Sie definieren die Implementierung, den Schutz und die Benennung von Segmenten. Somit können über einem Segment auch verschiedene Regionen mit unterschiedlichen Schutzanforderungen definiert werden. Auf der Hardwareseite bietet Chorus lediglich Unterstützung für Speicherarchitekturen mit gemeinsamem Zugriff.

Beide Microkernel bieten einen minimalen Satz an Grunddiensten. Höhere Dienste stehen in Form von auf dem Kern aufsetzenden Betriebssystem-Servern zur Verfügung. Somit sind die meisten Teile des aufsetzenden Betriebssystems bereits vollkommen Hardware-unabhängig.

Im Kern selbst findet eine strikte Trennung zwischen Hardware-abhängigen und -unabhängigen Teilen statt. Diese beiden Eigenschaften erleichtern wesentlich die Portierung auf diverse Plattformen. Doch nicht nur Heterogenität auf der Hardwareseite findet in den beiden Architekturen ihren Niederschlag. Die Kommunikation zwischen Knoten in einem LAN wird im Kern auf der Basis unterschiedlicher Protokolle unterstützt, zu denen bei Mach TCP/IP, UDP und VMTP gehören sowie TCP/IP und OSI bei Chorus. Die objektorientierte Strukturierung der Systeme nach dem Client-Server-Prinzip erleichtert die Einbindung heterogener Komponenten. Daß sich diese Konzepte auch in der Praxis bewähren, zeigt die lange Liste von Portierungen beider Systeme.

Verteilung wird sowohl in Mach als auch in Chorus durch ortstransparente Kommunikation unterstützt. Sie erfolgt über sogenannte Ports. Jedem Port ist eindeutig eine empfangende Task zugeordnet. Alle Threads in einer Task können simultan Nachrichten über einen Port der Task empfangen. Das Versenden von Nachrichten über das Netz des verteilten Systems ist transparent.

Beide Systeme unterstützen sowohl asynchrone Kommunikation als auch einen Mechanismus für Remote Procedure Calls (RPC). Im Chorus-System finden bei der Kommunikation zwischen Actors auf Benutzerebene weniger Kontext-Wechsel als im Mach-Kernel statt, was die Laufzeit der betreffenden Aufrufe verkürzt.

Beide Systeme bieten Sicherheitsmechanismen bereits auf sehr systemnaher Ebene an, wobei Chorus etwas weiter geht. In Mach können sowohl Speicherregionen als auch Ports durch Zugriffsrechte geschätzt werden. Für Ports existieren ein Sende-, Empfangs- und Besitzrecht. Daneben besteht die Möglichkeit, Nachrichten verschlüsselt zu versenden. Auf diesen Basismechanismen können höhere Dienste implementiert werden.

Chorus arbeitet mit Capabilities. Ihr Besitz impliziert spezifische Zugriffsrechte auf ein Objekt im System. In ihnen steht der Identifikator des Objekts und der jeweilige Zugriffsschlüssel. Capabilities werden vom betreffenden Objekt selbst oder von zentralen Instanzen vergeben. Dieses Konzept erlaubt in Verbindung mit Authentifizierungsdiensten sehr flexible und effiziente Sicherheitsmechanismen.

Einige Anwendungsgebiete stellen besondere Anforderungen an Betriebssysteme. So werden heute bei der Telekommunikation Echtzeit-Fähigkeiten verlangt. Hier bietet Chorus mit den unterbrechbaren Kernel-Operationen, dem Scheduling und der Prioritäten-Regelung die wesentlichen Mechanismen an, auf denen höhere Dienste für Echtzeit-Systeme realisiert werden können. Hinzu kommt, daß die Verteilung des Betriebssystems möglich ist. Echtzeit-Unterstützung bildete bei der Mach-Entwicklung keinen Schwerpunkt. Diesen Mangel versuchen die Entwickler durch die Implementierung eines Mach. Echtzeit-Kernels zu beheben.

Als Schlüsselfaktor für Kumtige Systeme gilt heute ihre Fähigkeit, Standards zu entsprechen. Für den Anwender ist es wichtig, getätigte Software-Investitionen zu sichern. Konkret verlangt er manchmal sogar Binärkompatibilität neuer Betriebssysteme zu den bisherigen Produkten. Während Chorus lediglich Quellcode-kompatible Implementierungen zu Unix System V bietet, wurde in Mach ein ausgeteiltes Konzept entwickelt, die Betriebssystem-Schnittstellen mit Hilfe der transparenten Libraries binärkompatibel auf den Kernel aufzusetzen.

Ruft zum Beispiel eine Unix-Anwendung (Binärcode) einen Betriebssystem-Dienst auf, so erkennt Mach an der Nummer des erzeugten Software-Interrupts, daß es sich um den Aufruf eines ergänzendes Subsystems handelt, und leitet ihn an die entsprechende Stelle in der transparenten Library weiter. Diese ist für jede angebotene Betriebssystem-Schnittstelle spezifisch, und übergibt den Aufruf entweder an einen als Server implementierten Dienst, oder benutzt einen Mechanismus des Mach-Kernels.

Der Applikation bleibt dieser Ablauf verborgen, sie sieht lediglich die angeforderte Unix-Funktionalität. Daß dieses Schema mit Einbußen bei der Performance verbunden ist, liegt auf der Hand. Legt der Anwender jedoch auf Binärkompatibilität Wert, so muß er diesen Nachteil in Kauf nehmen.

Offene Systeme auf dem Microkernel

Die Implementierung von offenen Systemen wurde sowohl für Mach als auch für Chorus durchgeführt. Im wesentlichen umfaßt dies die Portierung existierender Systeme als Server auf die Kernel-Schnittstellen der beiden Produkte. Dies bedeutet, daß für viele Dienste auf die effizienteren Mechanismen des Microkernels zurückgegriffen werden kann. Es entsteht ein verteiltes offenes System.

Die OSF entwickelt bereits seit längerem eine ganze Reihe von Servern auf Basis von Mach 3.0. Zunächst muß das betreffende System in zwei Teile zerlegt werden. Bei einer Single-Server-Version läuft der größere als gewöhnliche Applikation auf dem Microkernel, der kleinere stellt die Basismechanismen zur Verfügung.

Für eine Multiple-Server-Version erfährt das betreffende System eine stärkere Modularisierung. Jeder Teil läuft als Applikation auf dem Microkernel und kommuniziert bei seinen Aufgaben mit anderen Teilen. Die Basismechanismen werden vom Kern realisiert. Bei beiden Lösungen ist darauf zu achten, daß soviel Code wie möglich weiterbenutzt werden kann und daß die gewählte Architektur keinen negativen Einfluß auf die Performance des Gesamtsystems hat. Bei der OSF finden derzeit Server-Entwicklungen für BSD4-3, OSF/1, SVR4 und OS/2 statt.

Obwohl Chorus von der Architektur her die gleichen Möglichkeiten eröffnet, wurde hier bei der Entwicklung standardisierter Betriebssystem-Schnittstellen auf dem Microkernel eine andere Strategie gewählt. Derzeit steht nur ein System zur Verfügung, das SVR4-kompatible Chorus Mix. Bei seiner Entwicklung lag das Augenmerk auf der Performance. So wurde die strikte Trennung zwischen Microkernel-Schnittstelle und Betriebssystem-Server an vielen Stellen unterlassen und eine engere Integration von Microkernel und aufsetzendem System realisiert. Die Flexibilität des Gesamtsystems, die eine spezielle Eigenschaft derartiger Server darstellt, ging damit verloren, allerdings wurden an einigen Stellen Perfomance-Zuwächse erzielt.

Der Microkernel aus Marketing-Sicht

Bei der Betrachtung der Zukunftsperspektiven von Mach und Chorus muß neben den technischen Aspekten insbesondere das markt- und entwicklungspolitische Umfeld analysiert werden. Durch die starke Förderung des Department of Defense (DoD) in den USA gelang es Mach bereits relativ früh, als Betriebssystem-Basis zahlreicher universitärer und kommerzieller Entwicklungen Fuß zu fassen. So ist derzeit eine relativ breite Palette fortschrittlicher Softwarewerkzeuge und Systemerweiterungen auf Mach-Basis verfügbar.

Außerdem steht in Mach das für Wide Area Networks (WAN) geeignete verteilte Filesystem AFS zur Verfügung. Neben diesen Entwicklungs-Tools ist im marktpolitischen Bereich das starke Engagement der OSF von entscheidendem Vorteil. Zum einen verliert Mach durch die ständige Pflege und Weiterentwicklung des Microkernels viel von seinem universitären Anstrich, der oft bemängelt wird. Das Vertrauen der Anwender wird so gestärkt. Zum anderen sorgen die Mitglieder der OSF für eine ständige Verbreitung und Weiterentwicklung der in Mach realisierten technologischen Innovationen.

Das Engagement der OSF begann bereits bei der Version 2.5 des Mach-Systems. Hier handelte es sich noch nicht um einen Microkernel, sondern um einen verbesserten BSD-4.2-Kern. Dieser bildete die Basis für das OSF/1-System. Derzeit arbeitet die OSF an der zweiten Version ihres Betriebssystems, das nun den Microkernel verwendet.

Chorus hatte diesem starken Engagement einer großen Benutzervereinigung im Bereich offener Systeme bis vor kurzem nur wenig entgegenzusetzen. Neben einer geplanten Rechnerreihe von Unisys auf Chorus-Basis und dem Telecom-Konzern Alcatel gab es kaum kommerziell interessante Partner. Im Rahmen von Esprit und anderen Forschungskooperationen entstanden jedoch auch hier zahlreiche Werkzeuge und Basisentwicklungen im Umfeld des Systems.

Seit Herbst 1991 existiert zudem eine strategische Liaison mit der USL. Ziel ist es, Chorus Mix und SVR4 schrittweise zu einer gemeinsamen Systemlinie zu integrieren. USL sieht die Vorzüge der Chorus-Implementierung hauptsächlich im Bereich von massiv parallelen Rechnern bei Systemen mit Echtzeitanforderungen. Hier stellt Chorus Mix den Migrationspfad zur Microkernel-Technologie für das USL-Unix dar. Chorus Mix ist bereits heute eine Implementierung, die zu allen Schnittstellen dieses Unix kompatibel ist. Dazu gehört, daß es die Application Binary Interfaces (ABIs) von System V ebenso unterstütz wie die Posix- und X/Open-Standards.

Die Zukunft der Microkernel-Technik

Sowohl Mach als auch Chorus erfüllen mit Verteilung, Multiprozessor-Fähigkeit oder Kompatibilität zu existierenden Standards die wesentlichen Anforderungen an Betriebssysteme. Allerdings setzen sie unterschiedliche Schwerpunkte. Die Microkernel-Architektur, das grundlegende Designkonzept beider Kandidaten, stellt einen wesentlichen Schritt in Richtung zukünftiger Betriebssysteme dar. Davon zeugt auch die Entwicklung von Microsofts "New Technology", bei der Rick Rashid, Vater des Mach-Systems, federführend ist. Dies allein genügt jedoch nicht, um existierende Unix-Technologien auf dem Gebiet offener Systeme abzulösen.

Durch das Engagement der OSF und des DoD erschließt sich Mach die Akzeptanz von namhaften Herstellern. Die Kooperation mit der USL wirkt sich in gleichem Maß vorteilhaft für Chorus aus, obwohl sie langfristiger angelegt und derzeit noch weniger konkret ist. Der technologische Vorsprung auf dem Microkernel-Sektor, den die OSF durch die Aktivitäten der letzten Jahre erworben hat, wird schwer aufzuholen sein, obwohl Chorus technisch eine mindestens gleichwertige Lösung zu Mach darstellt. Was Leistung und Echzeit-Unterstützung betrifft, kann es sogar einen Vorsprung verbuchen.

Zusammenfassend gilt also: Technisch haben beide Systeme das Potential, Basis für offene Systeme zu werden. Der tatsächliche Erfolg jedoch hängt von Randbedingungen ab, die aus heutiger Sicht nur schwer zu beurteilen sind.