Unterthema: iX-TRACT
Unterthema: Schall und Rauch
Unterthema: UNTERSTÜTZTE PC-HARDWARE
Die Motivation für ein neues Betriebssystem reifte an den Bell Laboratories gegen Ende der 80er Jahre. Ausschlaggebend war die Entwicklung, die typische Unix-Systeme bis zu diesem Zeitpunkt durchlaufen hatten: Das alphanumerische Terminal am bürokratisch verwalteten Mainframe bekam Konkurrenz durch eine Workstation mit Zugriff auf die Dienste mehrerer Serversysteme, beide unter Unix. Der durch die multifunktionale Workstation gewonnenen Freiheit des einzelnen Anwenders stand der große administrative Aufwand gegenüber, dem der normale Anwender nicht gewachsen war.
Mit Plan 9 startete die Entwicklergruppe unter Dennis Ritchie den Versuch, ein zentral administriertes, kosteneffektives System auf Basis preiswerter Hardware zu schaffen. Dies erinnert an den Tenor der seit etwa zwei Jahren geführten Diskussion um die `Total Cost Of Ownership' moderner EDV-Systeme. Man hat inzwischen auch anderenorts erkannt, daß die Verwaltung von Arbeitsplatzcomputern einen hohen Aufwand erfordert, den Anwender selbst in der Regel nicht erbringen können. Hierzu bedarf es meist mehrerer Spezialisten, die solche, oftmals heterogene Systeme administrieren, die zudem meist noch an unterschiedlichen, weit verteilten Standorten installiert sind.
Die Lösung à la Plan 9 für dieses Problem heißt: jeder tut nur das, was er am besten beherrscht. Ein großes Plan-9-System besteht aus einer Reihe vernetzter Rechner. Den eingesetzten Maschinen fallen dedizierte Aufgaben zu. Es werden dabei vier Konfigurationen unterschieden: Terminals, CPU-, Autorisierungs- und Fileserver, von denen jede in praktisch beliebiger Häufung vorkommen darf.
Einfache, billige Maschinen dienen dem Anwender als grafisches Terminal für die Inanspruchnahme zentraler Dienste. Sie stellen den Investitionsschutz sicher, da sie aufgrund der geringen Anforderungen auch bei Weiterentwicklung des Systems über einen sehr langen Zeitraum verwendbar bleiben und durch preiswerte Discount-PC-Hardware realisierbar werden können. Diese Terminals sind über Netzwerke niederer Bandbreite wie Ethernet und ISDN mit leistungsstarken Servern verbunden. Beim Einschalten bootet ein Terminal den Plan-9-Kernel entweder übers Netz oder von der optionalen Festplatte.
Sämtliche Server stehen über Netzwerke mit extrem hoher Bandbreite in Verbindung und stellen zentrale Dienste wie Rechenzeit und Massenspeicher bereit. CPU-Server unterscheiden sich, was ihre Softwarekonfiguration anbelangt, nur unwesentlich von einem Terminal: sie arbeiten mit nahezu dem gleichen Kernel. Der wesentliche Unterschied besteht in der leistungsfähigen Hardware, die ein CPU-Server vielen Benutzern in Form von Rechenzeit zur Verfügung stellt. Der Autorisierungsserver, der die Benutzerzulassung der Terminals regelt, ist immer auch CPU-Server, schon allein, weil seine wenig ressourcenbelastenden Aufgaben keine eigene Maschine rechtfertigt. Einzig der Fileserver nimmt eine Sonderposition ein. Auf ihm läuft ein dedizierter Plan-9-Kernel, der ausschließlich Dateidienste bereitstellt. Dafür bieten sie aber die notwendige Kapazität.
Plan 9 im Vollausbau: CPU- und Fileserver bilden in einem LAN sehr großer Bandbreite eine Einheit, deren Dienste Terminals nutzen, die auch mit langsamen Verbindungen zurechtkommen (Abb. 1).
Anders als bei dem älteren Bruder Unix können technisch Interessierte Plan 9 im Source verstehen. Für zirka 170 DM erhält man zwei rund 500 Seiten starke Handbücher, eine CD sowie vier Disketten für eine PC-Installation. Die Images der Disks sind übrigens als Evaluierungsversion, natürlich ohne Quellen und Dokumentation, im Internet verfügbar (http://plan9.bell-labs.com/plan9/index.html).
Schon die fehlende Skalierbarkeit beim Einrichten zeigt, daß es sich bei dem Setup um ein Mittel zum Zweck handelt. Keine ausgeklügelte Hardwareerkennung, keine intuitive Partitionierungssoftware, also nichts für den OS-Jäger und -Sammler, der neben NT und Linux eine weitere Trophäe für sein OS/2-Bootmenü sucht. An Plan 9 Interessierte wissen und nehmen hin, daß dessen Setup die Partitionstabelle ignoriert und den gesamten Platz nach der ersten Partition in ein eigenes Filesystem (9fs) wandelt ...
Belohnt wird man aber in jedem Fall mit einem kompakten, aber auch sehr gewöhnungsbedürftigen Window-System, einem mindestens ebenso gewöhnungsbedürftigen Editor sowie einer kompletten Entwicklungsumgebung, in der ein Cross-Plattform-Debugger nicht fehlen darf.
Damit der U9FS-Server in die Lage versetzt werden konnte, ein Plan-9-Root-Filesystem zu exportieren, bedurfte es noch einiger Modifikationen, danach waren die Terminals endlich bootfähig. Für die Anmeldung bedarf es noch eines Autorisierungsservers, eine Aufgabe, die nur ein Plan-9-CPU-Server übernehmen kann. Bemerkenswert in diesem Zusammenhang, daß man sich nicht an einem laufenden Plan-9-System anmeldet, sondern die Anmeldung Bestandteil des Bootvorgangs ist, also das Terminal komplett in einem Benutzerkontext läuft.
Zusätzlich zu den beiden C-Umgebungen bietet Plan 9 auch noch Alef, eine Sprache, die primär zur Realisierung von parallelen Prozeßsystemen gedacht ist. Von der Syntax her ist sie fast identisch mit C, bietet aber Erweiterungen zur Prozeßsynchronisation. Alef-Programme sehen zwar auf den ersten Blick wie C-Programme aus, sind aber anders strukturiert und funktionieren auch ein wenig anders. Zu Alef gehört Acid, ein Cross-Plattform-Sourcelevel-Debugger, der die speziellen parallelen Multiprozeßeigenschaften Alefs berücksichtigt. Er geht dabei weit über die Möglichkeiten anderer Debugger hinaus und bietet keinen festen Befehlssatz an, mit dem die wichtigsten Methoden der Fehlersuche umgesetzt werden können, sondern stellt eine Sprache zur Verfügung, mit der gerade für eine spezielle Problemstellung gewünschte Anforderungen an einen Debugger implementierbar sind. Das klingt sehr gut, heißt aber auch, daß man eine nicht wenig komplexe Sprache, die aus sehr viel Syntax besteht, eigens zur Fehlersuche erlernen muß.
Das Betriebssystem Plan 9 bietet nun eine ganze Reihe neuer Konzepte, die einer Markteinführung, zumindest einer erfolgreichen, entgegensprechen. Dabei bleiben die Details und die darin verborgenen Potentiale exklusiver Vorbehalt des aufmerksamen Betrachters. Dem Anwender, also dem der dafür bezahlen soll, stellt sich ein Plan-9-System nicht anders als eine der ihm bekannten heterogenen Rechnerumgebungen dar, in dem eine große Anzahl intelligenter Client-Systeme mit einer kleineren Anzahl von Serversystemen kommuniziert, gravierend jedoch der Unterschied zum Bekannten: Auf einem Plan-9-Client läuft weder FrameMaker noch MS-Office.
Ganz ist die Technologie jedoch nicht verloren. In Lucents Inferno [1] scheinen viele Konzepte aus Plan 9 wiedergeboren, und es dürfte nicht unwahrscheinlich sein, daß in Zukunft alle bei der Benutzung von Telefonen oder Set-Top-Boxen zu Plan-9-Anwendern avancieren. (rh)
arbeitet als Kundenbetreuer im Bereich PC-Management bei Dr. Materna, Dortmund.
ist Produktmanager im Bereich PC-Management bei Dr. Materna, Dortmund.
[2] Achim Born; Betriebssysteme; Mach's noch mal, Bell Labs; AT&Ts Plan 9 soll auf den Markt; iX 4/94, S. 13
Schlüssel zum System: Der Namensraum von Plan 9 - ähnlich dem Unix-Dateisystem - bildet den Zugang zum Ganzen. Dienste exportieren aufeinander aufbauende Dateien in den Namensraum, den spezielle Kommandos benutzerspezifisch zusammenstellen (Abb. 2).
Unix-Anwender und Plan-9-Novizen sucht zuweilen ein Gefühl der Unsicherheit heim, während sie ihre ersten Schritte im Namensraum von Plan 9 unternehmen. Dateien und Verzeichnisse im Unix-System sind hinsichtlich ihrer Existenz als Daten auf einer Festplatte real. Das gilt auch für die Datei- und Dateisystemabstraktionen unter Unix. Gerätetreiber werden über existierende Dateien referenziert, /proc und Filedescriptor-Dateisysteme sind in wirklichen Verzeichnissen montiert, ebenso wie die Netzwerkdateisysteme - was das gute Gefühl realer Existenz vermittelt; weiß man doch, daß es sich um den Zugriff aus der Ferne auf Festplattendateien handelt.
Drei Prinzipien stellen die Basis von Plan 9 dar:
1. Ressourcen werden auf Namen in einem hierarchischen Dateisystem abgebildet.
2. Der Zugriff auf Ressourcen erfolgt mittels eines dafür vorgesehenen Protokolls.
3. Dateihierarchien unterschiedlicher Dienste (die von diesen Diensten bereitgestellten Ressourcen) sind zu einem einzigen, privaten und hierarchischen Dateisystem, dem Namensraum zusammengefaßt.
Während der Unix-Kernel bootet, erklärt er ein ausgezeichnetes Dateisystem zur Wurzel, an die alle weiteren Festplatten-, Netzwerk- und sonstigen Dateisysteme angehängt werden. Die Wurzel des Namensraums von Plan 9 entsteht ebenfalls während des Bootvorgangs, aber mit Plan-9-Methoden. Dateisysteme sind optionales Beiwerk. Den Ursprung des Namensraums bildet ein virtuelles Gebilde, dessen Lebenszeit auf die des Plan-9-Kernel begrenzt ist. Das Modell des Namensraums entspricht dem eines hierarchischen Dateisystems. Ressourcen werden auf Dateien im Namensraum abgebildet. Dabei stellt der Kern Hardwareressourcen wie Maus, Tastatur, Bildschirm oder Systemuhr direkt bereit. Der Zugriff erfolgt über die korrespondierenden Dateinamen
/dev/mouse /dev/keyboard /dev/cons /dev/time /dev/dateDarüber hinaus erstellt der Kern Einträge im Namensraum für wichtige Datenstrukturen von potentiell allgemeinem Interesse. Hierzu zählt unter anderem die Prozeßumgebung (Environment) im Verzeichnis /env mit Dateieinträgen, deren Namen denen der Umgebungsvariablen entsprechen und Dateiinhalten, in denen die Werte dieser Variablen enthalten sind. Ein weiterer Kandidat ist das Verzeichnis /proc. Es enthält, Abbildungen der dem System bekannten Prozesse in Form von Dateihierarchien. Ein Feature, das den meisten Linux-Benutzern unter den Lesern bestens vertraut sein dürfte, da es auch Linus Thorvalds derart begeisterte, daß er diese Idee vom dateiorientierten Zugriff auf laufende Prozesse in sein Betriebssystem übernahm.
Neben den Hardwareressourcen des Plan-9-Kernels gibt es die Dienste. Sie werden durch Serverprozesse implementiert, die ihre Objekte, die Gegenstände ihrer Dienstleistung, als Dateihierarchien exportieren. Beispiele sind das Festplattendateisystem kfs, der FTP-Service und das Window-System 8 1/2.
Der kfs-Service ist die Implementierung des Plan-9-Festplatten-Dateisystems. Nach dem Start des Dienstes exportiert dieser die Dateien auf den lokalen Festplatten als Dateihierarchie. Die Plan-9-Variante des bekannten FTP-Service ermöglicht ebenfalls einen dateisystemorientierten Zugriff auf den Datenbestand eines externen FTP-Servers. Für eine Anwendung ist daher nicht ersichtlich, ob sie auf lokalen Dateien arbeitet oder solchen, die via FTP bereitgestellt werden. Das Plan 9 Window System 8 1/2 fungiert als Multiplexer für die Dateien /dev/bitblt, /dev/keyboard und /dev/mouse. 8 1/2 exportiert diese Dateien in sämtliche geöffneten Fenster. Dabei übertreffen Konzeption und Bedienung dieses Fenstersystems den Namen in puncto Gewöhnungsbedürftigkeit um Längen.
Raumgreifend: Durch die Überlagerung von Dateiverzeichnissen zu Unions wird der Namensraum von Plan 9 zu einem dreidimensionalen Gebilde (Abb. 3).
Werkzeuge zur Manipulation des Namensraums ermöglichen es nun, die von den Diensten exportierten Dateihierarchien prozeßspezifisch zu organisieren, somit einen Namensraum zu erstellen. Dabei ist es möglich, auch auf die Dienste entfernter Plan-9-System zuzugreifen. So kann der kfs-Service von einer entfernten Maschine in den lokalen Namensraum einer Workstation importiert werden, wodurch die Workstation Zugriff auf die Festplatten des entfernten Systems erhält. Der Import von /proc einer fernen Maschine erlaubt das Untersuchen mit einem lokalen Debugger der auf dem exportierenden System laufenden Prozesse.
Ermöglicht wird dieser Mechanismus durch das 9P-Protokoll, das zentraler Bestandteil des Plan-9-Systems und in dessen Kernel integriert ist. Es handelt sich um ein transaktionsorientiertes, byteweise arbeitendes Protokoll der Anwendungsebene, konzipiert zur Kontrolle von Dateisystemen.
Eine Besonderheit im Namensraum von Plan 9 bilden die sogenannten Unions: Diese sind eine Zusammenfassung mehrerer Dateiverzeichnisse zu einem einzelnen Knoten. Wird /proc einer fernen Maschine importiert, so enthält das Verzeichnis im Namensraum der Workstation die Abbildungen der lokalen und der auf dem entfernten System laufenden Prozesse. Dabei sind die mit gleicher PID (Dateinamen) mehrfach enthalten.
Das Auslesen von Unions erfolgt verzeichnisweise in der Reihenfolge der Zusammenstellung. Dank dieses Mechanismus vermag etwa die Plan-9-Shell rc ohne eine PATH-Variable auszukommen: Ausführbare Programme sucht sie stets in /bin des Namensraums. Dabei ist dies ein Union, das sämtliche Verzeichnisse mit den darin enthaltenen ausführbaren Programmen enthält.
Die Abbildung von Ressourcen auf Dateien hat auch im Betriebssystem Plan 9 Grenzen. Es startet wie Unix ein Programm durch eine fork()/exec()-Sequenz und nicht, wie man vermuten könnte, durch das Kopieren des Executables nach /proc. Und es ist nicht möglich, den Hauptspeicher einer Maschine etwa auf ein Terminal zu importieren und ihn den lokalen Prozessen bereitzustellen.
| CPU | 386, 486 oder Pentium |
| Bussysteme | ISA/EISA-Bus, keine direkte PCI-Unterstützung |
| Festplatte | IDE- (mit LBA-Support) und SCSI-Platten; SCSI: Adaptec 1542(BC) und kompatible oder Ultrastor (13)4f |
| Netzwerkkarten | WD8003, WD8013, SMC Elite und 3C509/579 |
| Grafik | S3 801/805/928/864, ET4000, ATI Mach 32/64 und CLGD-542x/543x |
| Audio | Soundblaster 16 |
| CD-ROM | SCSI-CD-ROM oder Mitsumi, Panasonic oder Matsushita an Soundblaster |
| Maus | 3-Tasten-, seriell oder PS/2 |