DE4327119A1

DE4327119A1 - Dezentrale Software-Umgebung

Info

Publication number: DE4327119A1
Application number: DE4327119A
Authority: DE
Inventors: Ian Agranat; Karl E Zimmermann
Original assignee: Computervision Corp
Current assignee: Computervision Corp
Priority date: 1992-08-13
Filing date: 1993-08-12
Publication date: 1994-02-17
Also published as: US5519833A

Description

Die vorliegende Erfindung betrifft im allgemeinen eine dezentrale Software-Umgebung und genauer eine dezentrale Software-Umgebung zum Bereitstellen von Kommunikations diensten.

STREAMS ist eine Software-Umgebung, die von der American Telephone and Telegraph Company zur Verwendung mit dem "UNIX"-Betriebssystem ("UNIX" ist ein eingetragenes Waren zeichen der UNIX System Laboratories, Inc.) entwickelt worden ist. STREAMS ist in neueste Versionen von "UNIX" eingefügt und ist ein standardisierter Teil vom "UNIX"- System V, Version 4. STREAMS versorgt Entwickler mit Funktionen, Dienstprogrammen und Hilfsprogrammen, die beim Aufbau und bei der Entwicklung von Software unterstützen.

Der STREAMS-Mechanismus stellt eine standardisierte Einrich tung zur Verfügung, um Zugriff auf die "UNIX"-System- Kommunikationsdienste zu gewinnen.

Zentral für das Verständnis von STREAMS ist die Vorstellung eines "Stromes". Ein "Strom" ist ein Vollduplex-Datenüber tragungsweg zwischen einem Benutzerprozeß und einem Treiber in dem Kernraum des "UNIX"-Betriebssystems. Der Kernraum von "UNIX" ist der Teil des Betriebssystemes, der mit der Hardware wechselwirkt, um eine Anzahl von Diensten zur Verfügung zu stellen, die von Benutzerprogrammen verwendet werden können. Das "UNIX"-Betriebssystem umfaßt auch eine Schale zum Lesen und Interpretieren von Befehlen.

Fig. 1 zeigt eine Darstellung des Datenflusses in einem beispielhaften Strom 21. Der Strom 21 liefert einen Voll duplex-Datenübertragungsweg zwischen einem Benutzerprozeß 24, der innerhalb eines Benutzerraumes 20 vorliegt, und einem Treiber 30, der innerhalb eines Kernraumes 22 vor liegt. Der Kernraum 22 ist ein privilegierter Bereich, auf den Benutzerprogramme nicht zugreifen können, außer durch Systemaufrufe. Der Treiber 30 ist mit wenigstens einem Peripheriegerät über eine äußere Schnittstelle 32 verbunden. Der Strom 21 erleichtert somit einen Datenweg zwischen dem Benutzerprozeß 24 und wenigstens einem Peripheriegerät.

Jeder Strom 21 umfaßt einen Stromkopf 26, der an dem Ende des Stromes gelegen ist, das dem Benutzerprozeß 24 am nächsten liegt. Der Stromkopf 26 verarbeitet Systemaufrufe, die von dem Benutzerprozeß 24 gemacht wurden, um die Systemaufrufe in geeignet formatierte Meldungen umzuwandeln, die den Strom 21 hinabgesendet werden. Im allgemeinen kann ein Benutzer über STREAMS-spezifische Systemaufrufe Zugriff auf Hilfsprogramme gewinnen, die von der Software-Umgebung zur Verfügung gestellt werden. Diese Systemaufrufe umfassen den open(2)-Systemaufruf, der eine STREAMS-Datei erkennt und einen Strom zu einem spezifischen Treiber erzeugt. Weitere Systemaufrufe umfassen die read(2)- und write(2)-Systemauf rufe, die Daten auf einem Strom empfangen und senden. Der close(2)-Systemaufruf baut einen Strom ab und der ioctl(2)- Systemaufruf ermöglicht es einem Benutzer, Funktionen auszuführen, die für ein bestimmtes Gerät spezifisch sind. Schließlich ermöglichen es die putmsg(2)- und getmsg(2)- Systemaufrufe einem Benutzer, STREAMS-Meldungen zu senden bzw. zu empfangen.

Wie oben erwähnt umfaßt der Strom 21 auch den Treiber 30. Der Treiber 30 kann entweder ein Gerätetreiber zum Treiben wenigstens eines Eingabe/Ausgabe- (I/O) -Peripheriegeräts oder ein Softwaretreiber (bekannt als Pseudogerätetreiber) sein, der nicht ein Hardware-Gerät treibt, sondern stattdessen Meldungen interpretiert. Der Treiber 30 bearbeitet typi scherweise die Datenübertragung zwischen dem Kern und den Peripheriegeräten, die an ihn über die externe Schnittstelle 32 gekoppelt sind, führt jedoch nur geringe Datenverarbei tung anderer Art als der Umwandlung zwischen Datenstruk turen, die von dem STREAMS-Mechanismus verwendet werden, und Datenstrukturen, die von den angekoppelten Geräten verwendet werden, durch.

Ein Strom kann auch ein oder mehrere Module umfassen, so wie das Modul 28 in dem Strom 21. Module werden durch System aufrufe hinzugefügt und von dem Strom entfernt. Insbesondere fügt der ioctl I_PUSH-Systemaufruf ein Modul zu einem Strom unterhalb des Stromkopfes 26 hinzu, und der ioctl I_POP- Systemaufruf entfernt das Modul, das dem Stromkopf am nächsten ist, von dem Strom. Das Pop des Moduls ruft die "close (Schließen)"-Prozedur des Moduls auf.

Das Modul 28 verarbeitet den Datenstrom auf dem Strom 21 durch Ausführen unmittelbarer Transformationen auf Meldun gen, die zwischen dem Stromkopf 26 und dem Treiber 30 laufen. Das Modul 28 ist ein definierter Satz von Kern- Level-Routinen und Datenstrukturen, die zum Verarbeiten von Daten verwendet werden, Statusinformation und Steuerinforma tion. Jedes Modul in einem Strom ist unabhängig und funktio nal isoliert.

Die Daten werden zwischen dem Treiber 30 und dem Stromkopf 26 in der Form von Meldungen geleitet. Diese Meldungen werden geleitet, indem Aufrufe an das putmsg oder getmsg- Systemaufrufe gemacht werden. Meldungen, die von dem Stromkopf 26 zu dem Treiber 30 geleitet werden, werden als "Stromabwärts"-Meldungen bezeichnet. Andererseits werden Meldungen, die von dem Treiber 30 zu dem Stromkopf 26 geleitet werden, als "Stromaufwärts"-Meldungen bezeichnet. In STREAMS ist eine Meldung ein Satz von Datenstrukturen, der verwendet wird, um Daten, Statusinformation und Steuer information weiterzuleiten. Jede STREAMS-Meldung umfaßt wenigstens einen Meldungsblock. Ein Meldungsblock ist ein 3- Tupel mit einer Kopfzeile, einem Datenblock und einem Datenpuffer.

Die Meldungen werden auf unterschiedlichen Stufen des Stroms 21 durch Warteschlangen gehalten. Diese Warteschlangen dienen als Schnittstellen zwischen Treibern oder Modulen und dem Rest des Stroms 21. Warteschlangen sind in Paaren angeordnet: einer stromaufwärtigen Warteschlange, die Meldungen empfängt, welche stromaufwärts gesendet werden und einer stromabwärtigen Warteschlange, die Meldungen empfängt, die stromabwärts gesendet werden. Beispielsweise, wie in Fig. 2 gezeigt, umfaßt das Modul 36 die stromaufwärtige Warteschlange 42u und die stromabwärtige Warteschlange 42d, und das Modul 38 umfaßt die stromaufwärtige Warteschlange 44u und die stromabwärtige Warteschlange 44d. Der Treiber 40 umfaßt auch eine stromaufwärtige Warteschlange 47u und eine stromabwärtige Warteschlange 47d.

Die Warteschlangen 42u, 42d, 44u, 44d, 47u und 47d halten zeitweilig Meldungen, während die Meldungen den Strom 21 hinauf- und hinabgeleitet werden. Oftmals kann eine Warte schlange mehr als eine Meldung zur Zeit halten. Unter solchen Umständen, wie in Fig. 3 gezeigt, umfaßt die erste Meldung in der Warteschlange (bezeichnet mit "Meldung 1") einen Zeiger 51 auf die nächste Meldung in der Warteschlange (d. h. "Meldung 2") und einen Zeiger 53 auf die Kopfzeile 49 der Warteschlange. Die Kopfzeile 49 der Warteschlange ist eine Kopfzeile, die am Anfang der verknüpften Liste der Warteschlange angeordnet ist. Die Meldungsblöcke 46, die die "Meldung 1" bilden, sind über Linker zu einer verknüpften Liste verbunden. Ähnlich sind die Meldungsblöcke 48, die die "Meldung 2" bilden, in einer verknüpften Liste verbunden.

Ein Strom wird als eine verknüpfte Liste von im Kern vorlie genden Datenstrukturen aufgebaut. Genauer gesagt wird die verknüpfte Liste als eine Menge verknüpfter Warteschlangen paare erzeugt. Die Kernroutinen kommunizieren mit dem Stromkopf, um Operationen auf dem Strom auszuführen. Jede Warteschlange umfaßt einen "Einstiegspunkt", der auf eine Prozedur zeigt, die Meldungen, die von der entsprechenden Warteschlange empfangen worden sind, verarbeitet.

Bei dem dargestellten Strom 21 der Fig. 1 ist der Strom eine lineare Verbindung zu Modulen, wobei in jedem Fall ein Modul mit höchstens einem stromaufwärtigen Modul und höchstens einem stromabwärtigen Modul verbunden ist. Obwohl diese Konfiguration für viele Zwecke geeignet ist, erfordern bestimmte Anwendungen die Fähigkeit, multiple Ströme in einer Vielzahl von Konfigurationen zu multiplexen. Daher liefert die STREAMS-Software-Umgebung eine multiplexe Struktur, die obere Ströme (Ströme, die stromaufwärts des Multiplexers liegen) mit unteren Strömen (Strömen, die stromabwärts des Multiplexers liegen) zu multiplexen.

Weitere Information im Hinblick auf die STREAMS-Umgebung, wird in dem "UNIX-System V, Version 4.0 STREAMS-Führer" 1990, American Telephone and Telegraph Company, gegeben.

Ein Problem mit der STREAMS-Umgebung ist, daß es nicht auf eine dezentralisierte Weise verwendet werden kann. Mit anderen Worten kann ein System nicht auf Treiber zugreifen, die zu einem anderen System gehören.

Es ist daher eine Aufgabe der vorliegenden Erfindung, eine dezentrale Software-Umgebung zum Entwickeln von System- Kommunikationsdienstleistungen zur Verfügung zu stellen.

Die vorangegangenen Aufgaben werden durch die vorliegende Erfindung erfüllt, wobei ein dezentrales Datenverarbeitungs system ein erstes Datenverarbeitungssystem umfaßt, welches ein Betriebssystem antreibt. Das erste Datenverarbeitungs system hat eine Anwendung, die auf dem Betriebssystem läuft. Das dezentrale System umfaßt auch ein zweites Datenverarbei tungssystem, das seinen Speicherweg mit dem ersten Datenver arbeitungssystem nicht teilt. Das zweite Datenverarbeitungs system betreibt auch ein Betriebssystem. Dieses Betriebs system kann dasselbe oder ein unterschiedliches von dem sein, das von dem ersten Datenverarbeitungssystem betrieben wird.

Das dezentrale System stellt eine räumliche Verbindung zwischen dem ersten und zweiten Datenverarbeitungssystem zur Verfügung, um die Kommunikation zwischen den Systemen zu ermöglichen. Das dezentrale Datenverarbeitungssystem umfaßt auch eine Software-Schnittstelle, um es der Anwendung auf dem ersten System zu ermöglichen, den ersten Treiber auf dem zweiten System über die räumliche Verbindung zu verwenden.

Das dezentrale Datenverarbeitungssystem umfaßt vorzugsweise weiterhin ein Modul auf dem zweiten Datenverarbeitungssystem zum Verarbeiten des Informationsaustausches zu und von dem ersten Treiber. Bevorzugt wird dieses Modul auf einen Vollduplex-Datenübertragungsweg gelegt, der zwischen der Anwendung und dem ersten Treiber vorgesehen ist. Der erste Treiber kann verwendet werden, um ein Peripheriegerät zu treiben, das Teil des zweiten Datenverarbeitungssystemes ist.

Die Software-Schnittstelle kann einen Vollduplex-Datenüber tragungsweg in dem ersten Datenverarbeitungssystem zwischen der Anwendung und einem zweiten Treiber, der zu einem Kern des Betriebssystemes gehört, vorsehen. Dieser zweite Treiber kommuniziert mit der räumlichen Verbindung. Ähnlich kann das zweite Datenverarbeitungssystem einen Vollduplex-Datenüber tragungsweg zwischen dem ersten Treiber und einem dritten Treiber vorsehen, der mit der räumlichen Verbindung kommuni ziert. Diese räumliche Verbindung kann auf viele Weisen bewerkstelligt werden, einschließlich eines lokalen Netzes. Wenn einmal die Software-Schnittstelle eingerichtet ist, können Meldungen von der Anwendung in dem ersten Datenverar beitungssystem zu dem Treiber und anderen Elementen in dem zweiten Datenverarbeitungssystem übertragen werden. Das Weiterleiten dieser Meldungen ermöglicht das Öffnen und Schließen des ersten Treibers ebenso wie das Ausschalten und Anschalten von Modulen auf dem ersten Übertragungsweg, der zu dem ersten Modul führt.

Die vorliegende Erfindung wird genauer hiernach mit Bezug auf die Zeichnungen beschrieben, in denen:

Fig. 1 einen herkömmlichen Strom zeigt, der von dem STREAMS-Mechanismus geliefert wird;

Fig. 2 eine Darstellung des Stromes der Fig. 1 ist, die die Warteschlangen, die in dem Strom verwendet werden, erläutert;

Fig. 3 eine Darstellung von Meldungen ist, die in einer Warteschlange gehalten werden;

Fig. 4a-4g Schritte beim Öffnen eines fernen Treibers darstellen;

Fig. 5 ein Flußdiagramm der Schritte ist, die beim Öffnen eines fernen Treibers beteiligt sind;

Fig. 6 ein Flußdiagramm der Schritte ist, die beim Öffnen eines Dateiknotens für einen fernen Treiber auf einem System beteiligt sind;

Fig. 7a-7f Schritte zeigen, die beim Einschalten eines Moduls auf dem Strom, der zu einem fernen Treiber führt, beteiligt sind;

Fig. 8 ein Flußdiagramm der Schritte ist, die beim Einschalten eines Moduls auf einen Strom, der zu einem fernen Treiber führt, beteiligt sind;

Fig. 9a-9f die Schritte darstellen, die beim Aus schalten eines Modul es aus einem Strom, der zu einem fernen Treiber führt beteiligt sind;

Fig. 10 ein Flußdiagramm der Schritte ist, die beim Ausschalten des Moduls aus einem Strom, der zu einem fernen Treiber führt, beteiligt sind;

Fig. 11a-11d die Schritte darstellt, die beim Schließen eines fernen Treibers beteiligt sind; und

Fig. 12 ein Flußdiagramm der Schritte ist, die beim Schließen eines fernen Treibers beteiligt sind.

Die vorliegende Erfindung stellt eine Software-Umgebung zur Verfügung, die es einem Betriebssystem erlaubt, Ströme auszubilden, die Treiber und Module verwenden, welche zu anderen Teilnehmersystemen gehören, die mit einer separaten Kopie eines Betriebssystemes laufen. Die beiden Systeme sind in der Lage, über eine herkömmliche Netzwerkverbindung zu kommunizieren. Diese Software-Umgebung ermöglicht es einem System, Treiber oder treibende Module in dem anderen System zu öffnen. Tatsächlich können mehr als zwei Systeme durch die Software-Umgebung mit einander verschaltet werden.

Die Software-Umgebung wird als ein dezentrales Software- Paket implementiert, das auf einem Betriebssystem wie "UNIX"-System V, Version 4, installierbar ist. Die Module und Treiber, die Teil der Software-Umgebung sind, sind mit den Anforderungen des Systems V, Version 4, kompatibel. Die bevorzugte Ausführungsform wird als eine Verbesserung der STREAMS-Software-Umgebung implementiert.

Die bevorzugte Ausführungsform der vorliegenden Erfindung bietet eine Möglichkeit, Meldungen von einem ersten System zu einem zweiten System zu leiten. Auf diese Weise ist das erste System in der Lage, mit Treibern und Modulen des zweiten Systems zu kommunizieren. Die bevorzugte Ausfüh rungsform der vorliegenden Erfindung sorgt auch für das Management von Ereignissen in einer dezentralen Einstellung. Diese Ereignisse umfassen das Öffnen und Schließen eines Stromes, ebenso wie das Einschalten und Ausschalten eines Moduls. In einem nicht-dezentralen System werden diese Ereignisse durch Unterprogrammaufrufe behandelt. In der dezentralen Umgebung jedoch werden die Meldungen zwischen Systemen übertragen, um diese Ereignisse zu behandeln. Die folgende Diskussion wird funktional beschreiben, wie diese leitenden Ereignisse behandelt werden.

Die Software der vorliegenden Erfindung stellt spezielle Module zur Verfügung, die in der herkömmlichen STREAMS- Umgebung nicht verfügbar sind. Diese speziellen Module ermöglichen eine dezentrale Implementierung von STREAMS. Jedes dieser speziellen Module wird weiter unten genauer beschrieben.

Die bevorzugte Ausführungsform ermöglicht es einem ersten System, einen Treiber in einem zweiten System zu öffnen. Um zu verstehen, wie das erste System einen Treiber in dem zweiten System öffnen kann, ist es hilfreich, ein Beispiel zu betrachten. Fig. 4a zeigt ein Beispiel, bei dem zwei Datenverarbeitungssysteme (System A und System B) beide das "UNIX"-Betriebssystem betreiben, und Ströme existieren schon in diesen Systemen. Diese Ströme wurden auf herkömmli che Weise erzeugt.

Bevor eine Anwendung Zugriff auf einen fernen Treiber gewinnen kann, muß eine Verbindung zu dem fernen System hergestellt werden, in dem der ferne Treiber liegt. Diese Verbindung wird durch ein Zugriffsverfahrensprogramm bewerkstelligt. Das Zugriffsverfahrensprogramm führt drei Aufgaben aus. Erstens richtet das Zugriffsverfahrensprogramm eine Transportverbindung zu einem damit zusammenarbeitenden fernen System ein. Zweitens schaltet das Zugriffsver fahrensprogramm irgendwelche erforderlichen Konvergenzfunk tionsmodule auf geeignete Ströme. Drittens leitet das Zugriffsverfahrensprogramm die Verbindung auf den STREAMS- Mechanismus.

Die Fakten, die dem Zugriffsverfahrensprogramm zugeleitet werden, umfassen den Namen des Treibers, der einen Trans portdienst leisten wird, den Namen geeigneter Konver genzfunktionsmodule, eine Systemadresse für das System, das die Verbindung einrichtet oder eine Systemadresse, bei der das antwortende System die Verbindungsanforderung akzep tieren wird.

Das Zugriffsverfahrensprogramm wird während der Initialisie rung des dezentralen STREAMS-Servers laufen gelassen, das unten beschrieben werden wird. Speziell unterhält jedes System eine Text-"System"-Datei. Jede Zeile Text in dieser Datei umfaßt zwei Felder. Das erste Feld gibt den Namen eines fernen Systemes an, mit dem eine Verbindung gesucht wird. Das zweite Feld ist ein Schalenbefehl für das Be triebssystem, um das Zugriffsverfahrensprogramm aufzu führen. Wenn einmal das Zugriffsverfahrensprogramm betrieben wird, richtet es die geeignete Verbindung ein, wobei Transportdienstlieferer und Konvergenzfunktionsmodule verwendet werden, wie es weiter unten beschrieben wird.

Es sei angenommen, daß das System A wünscht, einen Strom zu öffnen, der zu dem Treiber 78 führt, welcher im System B vorliegt. Die Grenze 55 ist in Fig. 4a vorgesehen, um den Benutzerraum von dem Kernraum zu trennen und die Grenze 57 ist vorgesehen, um das System A vom System B zu trennen. Der Benutzerraum des Systemes A umfaßt eine Einrichtung 54 und einen dezentralen STREAMS-Server (dss)-Dämon 56. Der dss 56 ist ein Dämon, der als ein Stellvertreter für ferne Anwen dungen handelt, um Treiber zu öffnen. Ein Dämon ist ein Prozeß, der in dem "UNIX"-Betriebssystem vorgesehen ist, das nützliche Arbeit im Hintergrund versieht. Jedes System muß einen dss umfassen, um das dezentrale STREAMS zu unterstüt zen. Wenn der dss 56 gestartet wird, öffnet er einen Steuerstrom 39 zu einem dezentralen STREAMS-Multiplexer- (ds_mux)-Modul 58. Der Steuerstrom wird verwendet, um Steuerinformation weiterzuleiten.

Das ds_mux 58 dient als ein Viele-an-Viele-Multiplextreiber, der Zugriff zu fernen Treibern schafft, indem geeignete Steuermeldungen an die fernen Systeme gesendet werden und indem "obere" Ströme auf untere Transportverbindungen (so wie 62 und 76) gemultiplext werden. Jedes System muß einen ds_mux umfassen, um dezentrales STREAMS zu unterstützen.

Zwei untere Ströme 43 und 45 (d. h. Ströme unterhalb vom ds_mux) werden mit dem ds_mux 58 verbunden. Der untere Strom 43 umfaßt ein Konvergenzfunktionsmodul (cf1) 64, das mit einem Transportdienstlieferer-Modul (bezeichnet als if1) 66 verbunden ist. Das Konvergenzfunktionsmodul 64 dient dazu, STREAMS-Meldungen in ein geeignetes Format zu bringen, so daß die Meldungen über die Transportverbindung, die zu dem System B führt, übertragen werden können. Die Transportver bindung wird von einem Treiber geschaffen, der als Trans portdienstlieferer 62 bekannt ist, der als Netzwerk-Software oder eine andere geeignete Schnittstellen-Software reali siert werden kann, die zuverlässige Kommunikation über das Netzwerk zur Verfügung stellt oder Information, die sich zwischen dem System A und dem System B erstreckt. Der andere untere Strom 45 des ds_mux 58 umfaßt ein ähnliches Konver genzfunktionsmodul (cf2) 60 und einen Transportdienstliefe rer (if2) 62, die eine Verbindung zu einem weiteren System (nicht gezeigt) schaffen. Wie oben diskutiert werden die Verbindungen zwischen den Systemen während der Initiali sierung des dss realisiert.

Der Transportdienstlieferer 62 des unteren Stromes 45 des ds_mux 58 kommuniziert mit einem kompatiblen Transport dienstlieferer (if2) 76, der innerhalb des Systemes B vorgesehen ist. Der Transportdienstlieferer 76 ist ähnlich dem entsprechenden Treiber 62 in dem System A. Der Trans portdienstlieferer 76 ist über eine Vollduplex-Verbindung mit einem Strom verbunden, der das Funktionsmodul (cf2) 74 darauf hat. Das Konvergenzfunktionsmodul 74 dient dazu, Meldungen über die Transportverbindung zu empfangen und zu übertragen, die von dem Treiber 76 geschaffen wird. Das Konvergenzfunktionsmodul 74 ist wiederum mit dem ds_mux 72 in dem System B verbunden. Das ds_mux 72 ist mit dem dss 68 verbunden, der in dem Benutzerraum des Systems B vorgesehen ist.

Das System B umfaßt zusätzlich den Treiber 78, in dem Kernraum, den das System A zu öffnen wünscht. Zusätzlich umfaßt der Kernraum des Systems B ein dezentrales STREAMS- Verschlußband- (dstt)-Modul 70. Das dstt-Modul 70 wirkt als ein "Umleiter"-Modul, um Meldungen an den Treiber 76 zu leiten, wie es genauer unten beschrieben werden wird.

Fig. 5 zeigt ein Flußdiagramm der Schritte, die daran beteiligt sind, wenn eine Anwendung 54 einen Strom öffnet, der zu dem Treiber 78 (Fig. 4a) des Systems B führt. Der erste Schritt beim Öffnen eines Stroms zum Treiber 78 ist es, einen Dateiknoten auf dem System A für den Treiber 78 des Systems B zu öffnen (Schritt 102 in Fig. 5).

Das "UNIX"-Betriebssystem ordnet jedem Peripheriegerät in einem System einen Dateiknoten zu. Diese Dateiknoten werden in einem speziellen Inhaltsverzeichnis, das als "/dev" bekannt ist, gespeichert. Jede Datei umfaßt einen Dateityp, der angibt, ob der Datei ein Gerät zugeordnet ist, oder ob sie eine Textdatei ist. Jede Gerätedatei hat eine Gerätenum mer, die mit ihr verbunden ist, die dazu benutzt wird, ein Codestück in dem Kern zu identifizieren, das zum Verwalten des Gerätes verwendet wird. Eine größte Gerätenummer und eine kleinste Gerätenummer ist jeder Gerätedatei zugeordnet. Die größte Gerätenummer zeigt auf einen speziellen Treiber zum Handhaben des Gerätes. Die kleinste Gerätenummer identifiziert ein spezielles Gerät, das von dem Treiber getrieben werden wird, welche von der größten Gerätenummer identifiziert wird. Beispielsweise kann die größte Geräte nummer auf einen Treiber zeigen, und die kleinste Gerätenum mer kann ein spezielles Gerät identifizieren, so wie einen Disk-Treiber in einer Anordnung von Disk-Treibern, die von dem Treiber getrieben wird. Die größten Gerätenummern werden nacheinander bei der Initialisierung durch Initialisierungs routinen zugeordnet. Die kleinsten Gerätenummern werden durch den Entwickler des Treibers bezeichnet, der durch eine größte Gerätenummer identifiziert wird.

Wenn der dss 56 und der dss 68 geöffnet werden, lesen sie die Auflistung des Inhaltsverzeichnisses für jeden Dateikno ten in der "/des/ds". Diese dss 56 und 68 ziehen den System namen, den Knotennamen und die größte Gerätenummer aus der Auflistung für jeden Dateiknoten. Die dss 56 und 68 senden dann diese Informationen an die entsprechenden ds_mux 58 bzw. 72. Die ds_mux 58 und 72 sind dann in der Lage, den Namen des fernen Systems und den Knotennamen aus der größten Gerätenummer, die in einem "offenen" Aufruf durchge leitet worden ist, zu finden (wie es unten beschrieben werden wird).

Fig. 6 zeigt ein Flußdiagramm der Schritte, die erforder lich sind, um den Dateiknoten auf einem System A für den Treiber des Systems B zu öffnen (Schritt 102 in Fig. 5). Die in Fig. 6 gezeigten Schritte werden unten mit Bezug auf Fig. 4b beschrieben. Wenn der Dateiknoten auf dem System A geöffnet wird, werden die größte und kleinste Gerätenummer auf dem Dateiknoten eingestellt, um die "Öffnen-Anforderung" auf das ds_mux 58 zu leiten. Dieses Senden der Öffnen-An forderung an das ds_mux 58 wird durch die Verbindung 80 in Fig. 4b dargestellt. Eine "Öffnen" -Routine, ausgeführt von dem ds_mux 58, bildet die größte und kleinste Gerätenummer des Dateiknotens auf den richtigen unteren Strom 45 und den richtigen Dateiknotennamen auf dem System B ab (Schritt 118 in Fig. 6). Das ds_mux 58 (Fig. 4b) erzeugt dann eine Meldung, die eine dezentrale STREAMS- "Öffnen-Anforderung" (Schritt 120 in Fig. 6) enthält und sendet diese Nachricht stromabwärts über den unteren Strom 45 (Fig. 4b) zum System B (Schritt 122 in Fig. 6) . Die "Öffnen" -Routine, die von dem ds_mux 58 (Fig. 4b) ausgeführt wird, ruht dann (Schritt 124 in Fig. 6).

Das Konvergenzfunktionsmodul 60 nutzt den Transportdienst lieferer 62, um eine Meldung zu übertragen, die die "Öffnen- Anforderung" an das ds_mux 72 in dem System B enthält (Schritt 126 in Fig. 6), wie folgt. Das Konvergenzfunk tionsmodul 60 konvertiert die Meldung in ein Format, das von dem Transportdienstlieferer 62 gefordert ist und fördert die überarbeitete Meldung über einen Datenstrom, der von dem Transportdienstlieferer 62 zur Verfügung gestellt wird (Fig. 4b). Die Umwandlung der Meldung in eine Form, die für den Transportdienstlieferer geeignet ist, kann das Kopieren von Kopfzeileninformation aus Datenstrukturen an Datenpuffer umfassen und das Übersetzen von Konstanten. Das Konver genzfunktionsmodul 60 bewahrt den Anfangspunkt und den Endpunkt der ursprünglichen Meldung und bewahrt den Typ jeden Blockes innerhalb der ursprünglichen Meldung. Zusätz lich bewahrt das Konvergenzfunktionsmodul 60 die Länge und den Inhalt von Daten in jedem der Blöcke der Meldungen und bewahrt die Abweichung von Daten vom Beginn des ersten Blockes in einer fortlaufenden Liste von Blöcken in der Meldung.

Die überarbeitete Meldung wird dann weitergeleitet an den Transportdienstlieferer 62 im System A, der die überar beitete Meldung an den Transportdienstlieferer 76 in dem System B weiterleitet. Der Transportdienstlieferer 76 leitet die überarbeitete Meldung an das Konvergenzfunktions modul 74, welches die überarbeitete Meldung zurück in ein STREAMS-Meldungsformat konvertiert. Die STREAMS-Meldung wird an das ds_mux 72 gegeben. Die Meldungen werden an dem ds_mux 72 im herkömmlichen STREAMS-Format empfangen.

Das ds_mux 72 in dem System B erkennt die "Öffnen-Anfor derung" in der überarbeiteten Meldung und sendet die Identität der Quelle der Meldung (d. h. System A) zusammen mit der Anforderung an den dss 68 (Schritt 128 in Fig. 6). Schließlich verifiziert der dss 68, daß es dem System A erlaubt ist, den bezeichneten Treiber 78 zu verwenden (Schritt 130 in Fig. 6). Jedes System hält eine Textdatei anderer Systeme, die zu Knoten in dem System zugreifen dürfen. Die Verifizierung wird durch Zugreifen auf die Textdatei realisiert um zu sehen, ob das System A Zugriffs rechte auf den Treiber 78 hat. Das System B weiß dann, daß das System A einen Dateiknoten für den Treiber 78 geöffnet hat (Fig. 4b).

Der dezentrale STREAMS-Server 68 (Fig. 4c) in dem System B öffnet dann einen neuen Strom 82 an den ds_mux 72 (Schritt 104 in Fig. 5). Somit verbinden der Steuerstrom 37 und der neue Strom 82 den dezentralen STREAMS-Server 68 mit dem ds_mux 72. Der Strom 82 (Fig. 4c) wird nachfolgend der Targetstrom für Meldungen, die von Anwendung 54 des Systems A an den Treiber 78 gesendet werden. Der dss 68 (Fig. 4d) in dem System B schiebt als nächstes ein Ersuchen 88 eines dezentralen STREAMS-Verschlußband-(dstt)-Moduls über den neuen Strom 82, der zu dem ds_mux 72 führt (Schritt 106 in Fig. 5), wobei I_PUSH ioctl verwendet wird. Das dstt-Modul wirkt als ein Umgehungsmodul, das Mitteilungen, die strom aufwärts gesendet wurden, einen unterschiedlichen Strom hinableitet (wie es genauer unten beschrieben wird). Der dss 68 (Fig. 4d) bittet die Anforderung 88 des dstt-Moduls, sich selbst zu identifizieren (Schritt 108 in Fig. 5) . Der dss 68 (Fig. 4d) erhält somit die Identifizierung der neuen Aufforderung 88 des dstt und sichert den Identifizierer (Schritt 110 in Fig. 5).

Nachdem den Identifizierer der neuen Aufforderung 88 des dstt gesichert worden ist (Fig. 4e), öffnet der dss 68 den Strom 90, der zu dem Target-Treiber 78 führt (Schritt 112 in Fig. 5). Wenn einmal der Strom 90 zu dem Treiber 78 (Fig. 4f) geöffnet ist, schiebt der dezentrale STREAMS-Server 68 (indem er I_PUSH ioctl verwendet) eine neue Anforderung 94 von dstt auf den Strom 90 (Schritt 114 in Fig. 5).

Der dss 68 (Fig. 4g) instruiert die beiden Aufforderungen 84 und 94 des dstt, in Umleitemeldungen zu arbeiten, die einen Strom hinauf um die stromabwärtige Seite eines anderen Stromes gesendet wurden (Schritt 116 in Fig. 5). Insbe sondere werden Meldungen, die von dem ds_mux 72 stromabwärts zu 82 gesendet worden sind, zum Strom 90 und hinab zu dem Treiber 78 umgeleitet. Diese "Umleiter"-Fähigkeit ist in der Fig. 4g durch die Verbindung 98 dargestellt. Somit werden Meldungen, die von dem System A an das ds_mux 72 gesendet werden, an den Treiber 78 zurückgeleitet (und umgekehrt).

Der dss 68 (Fig. 4g) in dem System B sendet dann eine "Öffnen bestätigt" -Meldung an das ds_mux-Modul 72 (Schritt 117) in Fig. 5. Das ds_mux-Modul 72 (Fig. 4g) ordnet den neu erzeugten oberen Strom dem unteren Strom zu, der zum System A führt (Schritt 119 in Fig. 5) . Zusätzlich sendet das ds_mux-Modul 72 (Fig. 4g) eine "Öffnen bestätigt"- Meldung an das ds_mux 58 in dem System A (Schritt 121 in Fig. 5). Das ds_mux 58 (Fig. 4g) im System A gibt dann einen Weckruf an die "Öffnen"-Routine, so daß sie es der Routine-Anwendung 54 erlaubt weiterzuarbeiten (Schritt 123 in Fig. 5).

Nachdem ein Treiber in dem System B geöffnet worden ist, könnte die Anwendung, die auf dem System A läuft, nun wünschen, ein Modul auf dem Strom 90 (Fig. 7a) einzuschal ten, das zu dem Treiber 78 führt. Die Fig. 7a zeigt ein Beispiel, bei dem die Anwendung 54 in dem System A wünscht, das Modul 134 auf dem Strom 90 einzuschalten, das zu dem Treiber 78 führt. Um ein solches Modul 134 über den Treiber 78 im System B einzuschalten, muß ein Schatten-Modul "mod.r" 132 voll in dem System A installiert sein, und zusätzlich muß das Modul 134 voll auf dem System B instal liert sein.

Fig. 8 zeigt ein Flußdiagramm der Schritte, die beim Anschalten des Moduls 134 (Fig. 7a) auf dem Strom 90 in dem System B beteiligt sind. Die Schritte in diesem Flußdiagramm werden mit Bezug auf die Fig. 7b-7f beschrieben. Anfangs schaltet die Anwendung 54 (Fig. 7b) das dezentralisierte STREAMS-Schattenmodul 132 auf den Strom 100, der zu dem ds_mux 58 führt (Schritt 142 in Fig. 8), wobei ein I_PUSH ioctl-Systemaufruf verwendet wird. Das Schattenmodul 132 (Fig. 7b) umfaßt eine "Öffnen"-Prozedur, die verifiziert, daß das Modul nicht über einen lokalen Treiber oder Modul eingeschaltet ist (Schritt 144 in Fig. 8). Das Schatten modul 132 (Fig. 7b) bereitet dann eine "Einschalteanfor derung"-Meldung vor, die den Modulnamen enthält und sendet die "Einschalteanforderung"-Meldung stromabwärts (Schritt 146 in Fig. 8). Die "Öffnen"-Prozedur des Schattenmoduls 132 (Fig. 7b) ruht dann (Schritt 148 in Fig. 8). Diese "Einschalteanforderung"-Meldung wird zu dem ds_mux-Treiber 72 in dem System B transportiert (Fig. 7b).

Der ds_mux-Treiber 72 identifiziert den oberen Strom, auf welchen die "Einschalteanforderung" wirken muß (Schritt 150 in Fig. 8 . Im gegebenen Moment sucht die "Einschalteanfor derung", auf den Strom 90 zu wirken (Fig. 7b). Das ds_mux- Modul 72 sendet die "Einschalteanforderung" und die Identi tät des oberen Stromes den Steuerstrom 37 hinauf zu dem dss 68 (Schritt 152 in Fig. 8). Unter Verwendung der Identität, die von dem ds_mux 72 zur Verfügung gestellt wird (Fig. 7c), findet der dss 68 den Strom, der zu dem Treiber 78 führt und schließt das Ersuchen des dstt 94 (Fig. 7b) vom Strom ab (Schritt 154 in Fig. 8). Der dss 68 schaltet dann das Targetmodul 134 über den Treiber 78 ein, wie in Fig. 7d gezeigt (Schritt 156 in Fig. 8). Nachdem das Modul 134 (Fig. 7d) über den Treiber 78 eingeschaltet worden ist, schaltet der dss 68 in dem System B eine neue Anforderung 136 des dstt über das Targetmodul, wie in Fig. 7e gezeigt (Schritt 158 in Fig. 8).

Angenommen, daß die Anforderungen 134 und 136 (7f) des dstt- Moduls nun an Ort und Stelle sind, instruiert der dss 68 im System B die zwei Anforderungen 84 und 136 des dstt-Moduls, in umlaufenden Meldungen miteinander zusammenzuwirken, die einen Strom hinauf und einen anderen hinunter gesendet werden (siehe Verbindung 140) (Schritt 160 in Fig. 8). Der dss 68 (Fig. 7f) sendet eine "Einschalten Bestätigen"- Meldung den Steuerstrom 37 hinunter zu dem ds_mux 72, welcher wiederum die Meldung an das ds_mux 58 in dem System A transportiert (Schritt 162 in Fig. 8). Das ds_mux 58 (Fig. 7f) in dem System A gibt dann einen Weckruf an seine "Öffnen"-Prozedur (Schritt 164 in Fig. 8), um den Abschluß der "Öffnen" -Routine zu ermöglichen. Beim Abschluß übergibt die "Öffnen" -Routine die Kontrolle zurück an die Anwendung 54 (Fig. 7f).

System A kann dann das Modul benutzen, das in dem System B vorliegt. Wenn einmal die Anwendung in dem System A seine Verwendung des Moduls abgeschlossen hat, kann es wünschen, das Modul auszuschalten. Fig. 10 zeigt ein Flußdiagramm der Schritte, die beim Ausschalten des Moduls beteiligt sind. Diese Schritte werden hiernach mit Bezug auf die Fig. 9a-9f beschrieben. Anfangs gibt die Anwendung 54 in dem System A einen I_POP ioctl-Systemaufruf aus (Schritt 170 in Fig. 10). Dieser Systemaufruf bezieht sich auf die "Schließen"- Prozedur (Schritt 172 in Fig. 10) des Schattenmoduls 132 (Fig. 9a). Das Schattenmodul 132 erzeugt eine dezentrale STREAMS-"Ausschalteanforderung" -Meldung und sendet diese Meldung stromabwärts (Schritt 174 in Fig. 10). Die Schat tenmodul-"Schließen"-Routine ruht dann (Schritt 176 in Fig. 10). Die "Ausschalteanforderung"-Meldung wird zu dem ds_mux 72 (Fig. 9a) in dem System B übertragen. Das ds_mux 72 erkennt die Meldung (Schritt 178 in Fig. 10) und schickt die Meldung den Steuerstrom 37 hinauf (Fig. 9a) zu dem dss 68 (Schritt 180 in Fig. 10).

In Reaktion auf die Abschalteaufforderung schaltet der dss 68 (Fig. 9b) die Anforderung 136 (Fig. 9a) des dstt-Moduls (Fig. 9a) ab, das zuvor auf dem Strom 90 (Schritt 182 in Fig. 10) war. Der dss 68 (Fig. 9c) macht einen zweiten I_POP ioctl-Systemaufruf, was das Abschalten des fernen Moduls 134 (Fig. 9b) vom Strom 90 bewirkt (Schritt 184 in Fig. 10). Der dss 68 (Fig. 9d) schaltet als nächstes eine neue Aufforderung 152 auf das dstt-Modul über den Treiber 78 (Schritt 186 in Fig. 10).

Der dss 68 (Fig. 9e) instruiert die beiden Anforderungen 84 und 152 des dstt-Moduls, Strom-Meldungen zu umgehen, die einen Strom hinauf- und den anderen Strom hinabgesendet wurden (Schritt 188 in Fig. 10). Der dss-Modul 68 sendet dann eine "Ausschalten bestätigen"-Meldung den Steuerstrom 37 hinunter zu dem ds_mux 72 (Schritt 190) in Fig. 10. Der dezentrale STREAMS-Multiplexer 72 (Fig. 9e) in System B schickt die "Ausschalten bestätigen" -Meldung an das ds_mux 58 in System A (Schritt 192 in Fig. 10). In Reaktion auf das Empfangen der "Ausschalten bestätigen"-Meldung weckt das ds_mux 58 (Fig. 9e) die "Schließen"-Prozedur (Schritt 194 in Fig. 10). Die "Schließen"-Prozedur beendet somit die Ausführung (Schritt 196). Das Betriebssystem entfernt dann automatisch das Schattenmodul 132 aus dem Strom, wie in Fig. 9f gezeigt (Schritt 198 in Fig. 10). Die Anwendung 54 (Fig. 9f) kann dann fortfahren, den fernen Treiber 78 ohne das ferne Modul 124 zu benutzen.

Wenn einmal die Anwendung 54 (Fig. 11a) des Systemes A seine Verwendung des fernen Treibers 78 abgeschlossen hat, führt die Anwendung die Schritte durch, die in Fig. 12 gezeigt sind, um den Strom 90 zu schließen (Fig. 11a), der zu dem Treiber führt. Diese Schritte werden hiernach mit Bezug auf die Fig. 11a-11d beschrieben. Der erste Schritt, der von der Anwendung 54 (Fig. 11a) in dem System A durchgeführt wird, ist es, den Strom 158 zu schließen, der zu dem ds_mux 58 im System A führt (Schritt 200 in Fig. 12). Die Aufforderung, den Strom zu schließen, bewirkt den Aufruf der ds_mux 58-"Schließen"-Prozedur (Schritt 202). Die "Schließen"-Prozedur erzeugt eine dezentrale STREAMS- "Schließanforderung"-Meldung und sendet die Meldung den geeigneten unteren Strom hinab, von dem sie zu dem ds_mux 72 (Fig. 11a) in System B transportiert wird (Schritt 204 in Fig. 12). Die ds_mux 58 (Fig. 11a) -"Schließen" -Routine ruht dann (Schritt 206 in Fig. 12). Das ds_mux 72 in System B erkennt die "Schließanforderung"-Meldung und sendet die Meldung den Steuerstrom 37 hinauf zu dem dss 68 (Fig. 11a) in System B (Schritt 208 in Fig. 12).

Beim Empfang der Schließanforderung schließt der dss 68 (Fig. 11b) den Strom, der zu dem Treiber 78 führt, und das Betriebssystem schaltet die Anforderung 152 des dstt-Moduls (Fig. 11a) ab, das auf dem Strom 90 ist (Schritt 210 in Fig. 12). Der dss 68 (Fig. 11c) schließt dann den Sekun därstrom, der zu dem ds_mux 72 führt (Schritt 212 in Fig. 12). Der dss 68 sendet dann eine "Schließen bestätigen"- Meldung den Steuerstrom 37 hinunter zu dem ds_mux 72, der die Meldung durch das ds_mux 72 auf das System A transpor tiert (Schritt 214 in Fig. 12).

Das ds_mux-Modul 72 (Fig. 11c) erzeugt dann einen Weckruf, so daß es der ds_mux-"Schließen"-Prozedur ermöglicht wird, ihre Ausführung wieder aufzunehmen (Schritt 216 in Fig. 12). Das ds_mux-Modul 72 (Fig. 11d) beendet somit die Ausführung seiner "Schließen"-Prozedur (Schritt 218 in Fig. 12). Schließlich entfernt das Betriebssystem von System A den Strom von der Anwendung (Schritt 220 in Fig. 12), und die Anwendung kann dann die Verarbeitung wieder aufnehmen.

Obwohl die vorliegende Erfindung mit Bezug auf eine bevor zugte Ausführungsform gezeigt ist, weiß der Fachmann um viele Änderungen in Form und Funktion, die durchgeführt werden können, ohne daß man sich vom Geist und Umfang der Erfindung wie in den beigefügten Ansprüchen definiert entfernt.

Die in der vorstehenden Beschreibung, in der Zeichnung sowie in den Ansprüchen offenbarten Merkmale der Erfindung können sowohl einzeln als auch in beliebiger Kombination für die Verwirklichung der Erfindung wesentlich sein.

Claims

1. Dezentrales Datenverarbeitungssystem mit

a) einem ersten Datenverarbeitungssystem, das mit einem ersten Betriebssystem arbeitet und mit einer Anwendung, die auf dem Betriebssystem läuft;
b) einem zweiten Datenverarbeitungssystem, dem ein gemeinsam mit dem ersten Datenverarbeitungssystem benutzter Speicherweg fehlt, das mit einem zweiten Betriebssystem arbeitet und das einen ersten Treiber hat;
c) einer räumlichen Verbindung zwischen dem ersten und zweiten Datenverarbeitungssystem, um die Kommu nikation zwischen dem ersten und zweiten Datenverar beitungssystem zu ermöglichen; und
d) einer Software-Schnittstelle, um es der Anwendung auf dem ersten Datenverarbeitungssystem zu ermöglichen, den ersten Treiber in dem zweiten Datenverarbeitungssystem über die räumliche Verbin dung zu benutzen.

2. Dezentrales Datenverarbeitungssystem nach Anspruch 1, dadurch gekennzeichnet, daß das zweite Datenverarbei tungssystem weiterhin ein Modul zum Verarbeiten des Informa tionsaustausches zu und von dem ersten Treiber umfaßt.

3. Dezentrales Datenverarbeitungssystem nach Anspruch 1, dadurch gekennzeichnet, daß die räumliche Verbindung ein Netzwerk ist.

4. Dezentrales Datenverarbeitungssystem nach Anspruch 1, dadurch gekennzeichnet, daß das zweite Datenverarbei tungssystem weiterhin ein Peripheriegerät aufweist und der erste Treiber das Peripheriegerät treibt.

5. Dezentrales Datenverarbeitungssystem nach Anspruch 1, dadurch gekennzeichnet, daß das erste Datenverarbeitungs system weiterhin einen Vollduplex-Datenweg zwischen der Anwendung und einem zweiten Treiber in einem Kern des Be triebssystemes aufweist, der mit der räumlichen Verbindung kommuniziert.

6. Dezentrales Datenverarbeitungssystem nach Anspruch 1, dadurch gekennzeichnet, daß das zweite Datenverarbei tungssystem weiterhin einen Vollduplex-Datenweg zwischen dem ersten Treiber und einem dritten Treiber aufweist, der mit der räumlichen Verbindung kommuniziert.

7. Dezentrales Datenverarbeitungssystem nach Anspruch 1, dadurch gekennzeichnet, daß das erste Betriebssystem dasselbe Betriebssystem wie das zweite Betriebssystem ist.

8. Dezentrales Datenverarbeitungssystem nach Anspruch 1, dadurch gekennzeichnet, daß das erste Betriebssystem ein anderes Betriebssystem als das zweite Betriebssystem ist.

9. Verfahren zum Öffnen eines Treibers in einem zweiten Datenverarbeitungssystem durch eine Anwendung auf dem ersten Datenverarbeitungssystem, wobei das erste Datenverarbei tungssystem und das zweite Datenverarbeitungssystem zu einem dezentralen Datenverarbeitungssystem gehören und dem zweiten Datenverarbeitungssystem ein mit dem ersten Datenverarbei tungssystem gemeinsam benutzter Speicherweg fehlt, mit den Schritten:

a) Schaffen eines Vollduplex-Datenübertragungs weges zwischen der Anwendung und dem Treiber;
b) Senden einer Öffnen-Aufforderung von der Anwendung an den Treiber über den Vollduplex- Datenübertragungsweg; und
c) Öffnen des Treibers in Reaktion auf die Auffor derung.

10. Verfahren zum Einschalten eines Moduls auf einen Vollduplex-Datenübertragungsweg, der zu einem Treiber in einem zweiten Datenverarbeitungssystem führt, wobei ein erstes Datenverarbeitungssystem und das zweite Datenverar beitungssystem zu einem dezentralen Datenverarbeitungssystem gehören und dem zweiten Datenverarbeitungssystem mit dem ersten Datenverarbeitungssystem gemeinsam benutzter Spei cherweg fehlt mit den Schritten:

a) Schaffen eines Vollduplex-Datenübertragungs weges zwischen einer Anwendung in dem ersten Datenverarbeitungssystem und einem Treiber in dem zweiten Datenverarbeitungssystem;
b) Senden einer Aufforderung von der Anwendung an den Treiber, wobei das Einschalten eines Moduls gefordert wird; und
c) Einschalten des Moduls auf den Vollduplex- Datenübertragungsweg.