DE4244266C2 - Verfahren und Schaltungseinrichtung zum dynamischen Konfigurieren von Gerätetreibern für Computersystem-Betriebsmittel - Google Patents

Description

Die Erfindung bezieht sich auf das Gebiet der Computersy­ steme und insbesondere auf Computersysteme, welche eine Schnittstelle für entfernbare System-Betriebsmittel und die Steuerung von zugehörigen Gerätetreibern unterstützen.

Es wird zunehmend wichtiger, Computersysteme zu konstruie­ ren und zu bauen, welche dynamisch konfiguriert werden können, ohne das Computersystem abzuschalten oder ein Rücksetzen bzw. ein Anfangsladen des Betriebssystems erforderlich zu machen. Die dynamische Konfiguration umfaßt die Möglichkeit, System-Be­ triebsmittel (Ressourcen) oder spezielle Merkmale hinzuzufügen oder zu entfernen, während sich das Computersystem im Betrieb befindet. Diese Systemressourcen und speziellen Merkmale umfas­ sen Erweiterungsspeicherplatinen, parallele oder serielle Ein­ gabe/Ausgabe-(I/O-)Ports, Festwertspeicher (ROM) oder Flash-Speichererweiterungsplatinen, Computer-Netzwerk-Schnittstellen­ karten, Modemkarten, intelligente Karten o. a. entfernbare Sy­ stemressourcen oder Mechanismen mit speziellen Merkmalen.

Derartige entfernbare Systemressourcen und spezielle Merk­ male werden im Stande der Technik häufig durch auswechselbare elektronische Erweiterungskarten realisiert, die den Standard der Personal Computer Memory Card International Association (PCMCIA), Sunnyvale, Kalif., Ausgabe 2.0, einhalten. Diese PCMCIA-Karten enthalten im allgemeinen mikroelektronische-Schal­ tungen innerhalb eines dünnen Gehäuses mit einer abnehmbaren Mehrleiter-Schnittstelle, mit der die Karte in den Steckplatz eines Computergehäuses lösbar einsetzbar ist. Nach dem Einset­ zen ist die Erweiterungskarte für den Prozessor im Computersy­ stem zugreifbar. Die Verwendung solcher Karten macht es einem Computerbenutzer möglich, spezielle Merkmale oder Betriebsmit­ tel aus verschiedenen von einem Computerverkäufer angebotenen Erweiterungskarten auszuwählen. Auf diese Weise erreicht der Computerbenutzer das gewünschte Funktionalitätsniveau, ohne un­ nötige Betriebsmittel oder Computersystem-Fähigkeiten kaufen zu müssen. Die Gesamtkosten des Computersystems werden daher für eine spezielle Anwendung optimiert. Die Verwendung von auswech­ selbaren Erweiterungskarten ist für tragbare Computer oder Lap­ top-Computer besonders wichtig, bei denen räumliche Beschrän­ kungen den Bedarf an System-Betriebsmittel-Optimierungen ver­ stärken. Konstruktion und Verwendung von Hardware-Geräten unter dem PCMCIA-Standard sind im Stande der Technik bekannt. Es ist für den Fachmann klar, daß andere Implementierungen auswechsel­ barer Systemressourcen möglich sind.

Praktisch alle Computersysteme arbeiten mit einer gewissen Art von Betriebssystem oder Software-Verarbeitungslogik. Die Verwendung eines Betriebssystems in einem Computersystem ist bekannt. Das Betriebssystem ist für die Verwaltung der Verar­ beitung und die Übertragung von Informationen zwischen ver­ schiedenen System-Betriebsmitteln verantwortlich. Eine bekannte Methode zur Verwaltung dieser Ressourcen ist die Verwendung von Gerätetreibern. Gerätetreiber sind Software-Module mit einer Verarbeitungslogik zum Steuern der auf einem unteren Niveau be­ findlichen bzw. gerätespezifischen Komponenten eines speziellen Computersystem-Betriebsmittels. Beispielsweise kann ein Geräte­ treiber zum Steuern eines mit einem Computersystem gekoppelten Magnetplattenlaufwerks verwendet werden. Bei diesem Beispiel steuert der Gerätetreiber die verschiedenen Hardware-spezifi­ schen Register, Latch-Schaltungen, Signale o. a. Komponenten des Magnetplattenlaufwerks. In ähnlicher Weise sind andere Com­ putersystemressourcen, wie serielle oder parallele Ein­ gabe/Ausgabe-(I/O-)Ports, Modems, Computernetzwerk-Schnittstel­ lengeräte oder Speichererweiterungsplatinen von Gerätetreibern gesteuert.

In konventionellen Computersystemen werden Gerätetreiber typischerweise während der Anfangslade-Initialisierung des Com­ putersystems in den Direktzugriffspeicher (RAM) geladen (siehe EP 0 439 988 A1 und DE 40 26 911 A1). Viele bekannte Computersysteme bedingen, daß die Gerätetreiber beim Starten geladen werden, damit der Direktzugriffsspeicher in ge­ eigneter Weise zugeordnet werden kann. Je nach Komplexität des vom Gerätetreiber gesteuerten Geräts kann der Gerätetreiber selbst relativ klein oder unter Inanspruchnahme vieler tausend Bytes an RAM-Kapazität sehr groß sein. Viele bekannte Systeme bedingen daher die Installation einer zum Zeitpunkt der An­ fangslade-Initialisierung installierten und verfügbaren vollen Systemkonfiguration. Nachträglich hinzugefügte oder entfernte Systemressourcen oder -Schnittstellen führen gewöhnlich dazu, daß auf ein neu installiertes Betriebsmittel nicht zugegriffen werden kann oder ein fehlerhafter Zugriff auf ein jetzt nicht mehr verfügbares System-Betriebsmittel stattfindet. Andere be­ kannte Computersysteme bedingen die Abschaltung des Computersy­ stems beim Hinzufügen oder Entfernen von Systemressourcen oder -charakteristiken. Wiederum andere Systeme müssen zumindest neu geladen werden, um auf eine neue Konfiguration von Systemres­ sourcen zugreifen zu können. Bekannte Computersysteme können daher im Ergebnis nicht auf eine neue Anordnung von Systemres­ sourcen umkonfiguriert werden.

Da bekannte Systeme typischerweise eine volle Systemkonfi­ guration von Betriebsmitteln zum Zeitpunkt des Starts bedingen, besteht die Tendenz, beim Einschalten des Computersystems eine oder alle System-Betriebsmittel, die wahlweise verwendet werden können, bereits sofort zu installieren. Diese Tendenz führt dazu, daß Betriebsmittel installiert werden, die während einer Computersitzung überhaupt nicht benutzt werden. Das Laden und Installieren von unbenutzten System-Betriebsmitteln verlängert die zum Anfangslade-Initialisieren des Systems benötigte Zeit und verringert den verfügbaren Arbeitsspeicherraum (RAM), da RAM-Raum auch für unbenutzte Gerätetreiber benötigt wird. Es ist daher wichtig, in einem Computersystem nur diejenigen Gerä­ tetreiber zu installieren, die während einer Computersitzung tatsächlich benötigt werden. In einigen Fällen kann es unmög­ lich sein, alle notwendigen Gerätetreiber zu laden, da der Ar­ beitsspeicher begrenzt ist.

Einige bekannte Computersysteme stellen Mittel als Schnitt­ stellen für auswechselbare elektronische Erweiterungskarten zur Verfügung. Um die oben beschriebenen Nachteile zu umgehen, speichern einige dieser Computersysteme zugehörige Gerätetrei­ ber auf den auswechselbaren elektronischen Erweiterungskarten selbst. Auf diese Weise braucht der Arbeitsspeicher innerhalb des Computersystems selbst für die Speicherung des Systemtrei­ bers nicht reserviert zu werden. Außerdem wird während der In­ itialisierung keine zusätzliche Zeit benötigt, um den Geräte­ treiber in den Arbeitsspeicher zu laden. Systeme, bei denen Ge­ rätetreiber auf auswechselbaren Erweiterungskarten konfiguriert werden, haben den Vorteil, daß sie die Speicherzuordnungserfor­ dernisse innerhalb des Computersystems optimieren.

Andererseits haben die Systeme, welche Gerätetreiber auf auswechselbaren Erweiterungskarten konfigurieren, einige schwerwiegende Nachteile. Wenn eine Erweiterungskarte aus dem Computersystem entfernt wird, wird der den Betrieb der Erweite­ rungskarte steuernde Gerätetreiber für das Computersystem un­ zugreifbar. In den meisten Fällen macht das Computersystem einen Zugriff auf einen Gerätetreiber erforderlich, um den Be­ trieb des Gerätes vor dem Entfernen der Erweiterungskarte in geeigneter Weise zu beenden. Typischerweise hat das Computersy­ stem nicht genügend Zeit, um vor dem Entfernen der Erweite­ rungskarte auf den Gerätetreiber zuzugreifen. Daher ergeben sich häufig Systemfehler aufgrund einer inkorrekt abgeschlosse­ nen Systemressource.

Andere Computersysteme, die mit Mitteln als Schnittstelle zu auswechselbaren elektronischen Erweiterungskarten versehen sind, können nur sehr begrenzt auf das Einsetzen oder Entfernen von Erweiterungskarten während des Computersystembetriebs nach dessen Initialisierungsoperation antworten. Einige Computersy­ steme erkennen keine System-Betriebsmittel, die nach der Been­ digung der Initialisierung angeschlossen worden sind. Andere Computersysteme unterbrechen den Betrieb des Computersystems oder frieren ihn ein, wenn eine Systemressource nach Abschluß der Initialisierung entfernt wird. Wiederum andere Computersy­ steme bedingen eine Systemabschaltung oder den Neustart, wenn eine neue Konfiguration von Systemressourcen gewünscht wird.

Benötigt wird daher eine verbesserte Einrichtung zum dyna­ mischen Konfigurieren von Systemressourcen in einem Computersy­ stem. Dies ist Aufgabe der Erfindung.

Diese Aufgabe wird durch die Merkmale der Patentansprüche 1 und 10 gelöst.

Das erfindungsgemäß ausgestattete Computersystem hat eine dynamische Gerätetreiberkonfiguration für auswechselbare Systemressourcen. Das Computersystem weist einen Prozessor, einen Systemspeicher und eine Schnittstelle zur Aufnahme auswechselbarer Systemres­ sourcen auf. Die Systemressourcen und speziellen Merkmale um­ fassen Erweiterungsspeicherplatinen, parallele oder serielle Eingabe/Ausgabe-(I/O-)Ports, Festwertspeicher (ROM) oder Flash-Speichererweiterungsplatinen, Computer-Netzwerk-Schnittstellen­ karten, Modemkarten, Smartkarten oder andere auswechselbare Sy­ stemressourcen oder Mechanismen für spezielle Charakteristiken (generell Erweiterungskarten oder Karten genannt).

Eine Erweiterungskarte enthält einen Kartenspeicherbereich. Der Kartenspeicherbereich enthält Software zum Steuern der restlichen kartenspezifischen Funktionen. Diese sowohl Daten als auch Verarbeitungslogik enthaltende Software innerhalb des Kartenspeicherbereichs weist einen Gerätetreiber zum Steuern der Erweiterungskarte auf.

Um die beim Stande der Technik anzutreffenden Probleme zu vermeiden, ist der erfindungsgemäß vorgesehene Erweiterungskar­ ten-Gerätetreiber in zwei Teile unterteilt: 1) ein Abschnitt mit einem vollständigen Gerätertreiber; und 2) ein Abschnitt mit einem Rumpf-Gerätetreiber. Der vollständige Gerätetreiber stellt alle Gerätetreiberfunktionen zur Verfügung, die zum Steuern jeder einzelnen Funktion der Erweiterungskarte erfor­ derlich sind. Der Rumpf-Gerätetreiber ist ein kleiner kompakter Abschnitt der dem vollen Gerätetreiber zugeordneten Verarbei­ tungslogik, der jedoch nur für die Verknüpfung des vollen Gerä­ tetreibers mit der Betriebssystemsoftware im Computersystem verantwortlich ist.

Der Kartenspeicherbereich enthält einen Gerätetreiber-In­ formationsblock(DDIB)-Kopfteil, ein Rumpf-Gerätetreiber-Code­ bild und einen vollständigen Gerätetreiber-Code. Der Geräte­ treiber-Informationsblock-Kopfteil enthält die zum Verknüpfen des Gerätetreibers mit anderen Gerätetreibern und der Computer­ system-Verarbeitungslogik verwendeten Informationen. Der Rumpf- Gerätetreiber-Codebild enthält einen kompakten Abschnitt mit Verarbeitungslogik und Daten, welche bei Einsetzen einer Erwei­ terungskarte in das Computersystem in den Computersystem-Spei­ cher kopiert wird. Der vollständige Gerätetreiber-Code bleibt auf der Karte.

Bei Einsetzen einer Karte in das Computersystem wird das Rumpf-Gerätetreiber-Codebild aus dem Karten-Speicherbereich ge­ lesen und in einen Bereich des Computersystem-Speichers über­ tragen. Der Rumpf-Gerätetreiber-Code wird danach vom Computer­ system-Prozessor aus dem Arbeitsspeicher des Computersystems heraus ausgeführt. Andererseits wird der volle Gerätetreiber-Code nicht in den Arbeitsspeicher des Computersystems übertra­ gen. Statt dessen wird der volle Gerätetreiber ausgeführt, wäh­ rend er noch auf der Karte resident ist. Bei Ausführen ermög­ licht der Rumpf-Gerätetreiber Zugriff auf den vollen kartenre­ sidenten Gerätetreiber und ein Speichermapping auf den vollen Gerätetreiber. Der volle Gerätetreiber kann dann vom Prozessor aktiviert werden.

Der DDIB-Kopfteil enthält einen Satz von Informationen zum Verknüpfen des Karten-Gerätetreibers in einer Verknüpfungsliste mit anderen Gerätetreibern und mit der Betriebssystemlogik, die im Computersystem arbeitet. Beim Durchlauf durch die Verknüp­ fungsliste kann ein spezieller Gerätetreiber lokalisiert wer­ den. Bei Einsetzen einer Karte wird die Verknüpfungsliste der Gerätetreiber durchlaufen, um festzustellen, ob sich der Rumpf-Gerätetreiber bereits im Computersystemspeicher befindet. Ist dies der Fall, wird die Operation des Kopierens des Rumpf-Gerä­ tetreiber in den Computersystemspeicher verhindert. Wenn eine Karte eingesetzt wird, wird ein Karten-Einsetz-Flag gesetzt, welches anzeigt, daß das auswechselbare System-Betriebsmittel mit dem Computersystem gekoppelt ist.

Wenn eine Karte aus dem Computersystem entnommen wird, wird die Verknüpfungsliste der Rumpf-Gerätetreiber durchlaufen, um alle mit der entfernten Karte in Verbindung stehenden Rumpf-Ge­ rätetreiber aufzufinden. Dieser zugehörige Rumpf-Gerätetreiber wird ausgeführt. Der Rumpf-Gerätetreiber sperrt den Zugriff auf die entfernte Karte durch Sperren des Speichermapping zur ent­ fernten Karte. Der Rumpf-Gerätetreiber wird von der Verknüp­ fungsliste der Rumpf-Gerätetreiber entkoppelt und da Karten-Einsetz-Flag wird rückgesetzt, um anzuzeigen, daß das entfernte System-Betriebsmittel vom Computersystem abgetrennt worden ist.

Mit Hilfe der Erfindung kann daher jedes System-Betriebs­ mittel bzw. -ressource beliebig vor oder nach dem Anfangslade-Ini­ tialisieren (Start) des Computersystems an- oder abgekoppelt werden. Systemressourcen können ohne Abschaltung des Computer­ systems rekonfiguriert werden. Systemressourcen können auch ohne Neustart des Initialisierungsprozesses rekonfiguriert wer­ den. Eine weitere vorteilhafte Funktion des erfindungsgemäßen Computersystems besteht darin, daß unbenutzte Systemressourcen-Ge­ rätetreiber nicht in den Arbeitsspeicher des Computersystems geladen zu werden brauchen. Ein anderer Vorteil des erfindungs­ gemäßen Computersystems besteht darin, daß zum Zeitpunkt der Anfangslade-Initialisierung die volle Systemkonfiguration gar nicht bekannt zu sein braucht. Das erfindungsgemäße Computersy­ stem kann mit einer Schnittstelle zur Aufnahme von lösbaren elektronischen Erweiterungskarten ausgerüstet sein, welche zu einem beliebigen Zeitpunkt während des Betriebs des Computersy­ stems eingesetzt oder entfernt werden können.

Im folgenden wird die Erfindung anhand von in der Zeichnung schematisch dargestellten Ausführungsbeispielen näher erläu­ tert. In der Zeichnung zeigen:

Fig. 1 ein Blockschaltbild der Architektur eines Computer­ systems, in welchem die Erfindung arbeitet;

Fig. 2 ein Beispiel eines Computergehäuses mit mehreren Erweiterungskarten-Steckplätzen;

Fig. 3 ein Blockdiagramm des Inhalts einer auswechselbaren elektronischen Erweiterungskarte;

Fig. 4 den Inhalt des Gerätetreiber-Informationsblock-Kopf­ teils;

Fig. 5 den Inhalt eines Computersystemspeichers, soweit er mit dem Inhalt des Erweiterungskartenspeichers in Beziehung steht;

Fig. 6a den Inhalt des Rumpf-Gerätetreiber-RAM-Bereichs;

Fig. 6b den Inhalt eines Rumpf-Blocks;

Fig. 6c den Inhalt eines Rumpf-Kopfteils;

Fig. 6d den Inhalt eines Rumpf-Datenbereichs; und

Fig. 7 bis 13 Ablaufdiagramme der Verarbeitungslogik bei dem bevorzugten Ausführungsbeispiel.

Beschrieben wird ein Verfahren und eine Einrichtung zum dy­ namischen Konfigurieren von Gerätetreibern auswechselbarer Sy­ stem-Betriebsmittel. In der folgenden Beschreibung werden zahl­ reiche Einzelheiten angegeben, um das Verständnis für die Er­ findung zu erleichtern. Es jedoch für den Fachmann klar, daß diese speziellen Einzelheiten bei der Realisierung der Erfin­ dung nicht notwendig sind. In anderen Fällen sind bekannte Strukturen, Schaltungen und Schnittstellen nicht im einzelnen gezeigt, um die vorliegende Erfindung nicht mit unnötigen Ein­ zelheiten zu belasten.

Im folgenden wird auf Fig. 1 Bezug genommen, in der ein Blockschaltbild desjenigen Computersystems dargestellt ist, in welchem die Erfindung arbeitet. Es ist natürlich für den Fach­ mann klar, daß alternative Computersystemarchitekturen verwen­ det werden können. Im allgemeinen enthalten Computersysteme entsprechend der Darstellung in Fig. 1 einen Bus 100 zur Infor­ mationsübertragung, einen mit dem Bus 100 gekoppelten Prozessor 101 zur Informationsverarbeitung und einen mit dem Bus 100 ge­ koppelten Direktzugriffsspeicher (Arbeitsspeicher) 102 zur Speicherung von Informationen und Befehlen für den Prozessor 101. Die erfindungsgemäße Verarbeitungslogik ist typischerweise in einem Bauelement, wie einem Arbeitsspeicher 102 gespeichert und wird vom Prozessor 101 ausgeführt. Zusätzlich kann ein ty­ pisches Computersystem andere Systemressourcen, einschließlich eines mit dem Bus 100 gekoppelten Nur-Lese-Speichers 103, einer mit dem Bus 100 gekoppelten Eingabevorrichtung 104, beispiels­ weise einer alphanumerischen Eingabevorrichtung oder eines Cur­ sor-Steuergeräts zur Mitteilung von Informationen und Befehls­ auswahlen an den Prozessor 101, eines mit dem Bus 100 gekoppel­ ten Displaygerätes 105, beispielsweise einem Video-Display-Ter­ minal oder einer Flüssigkristallanzeige zum Anzeigen von Infor­ mationen für den Computerbenutzer, eines mit dem Bus 100 gekop­ pelten Datenspeichergeräts 106, beispielweise eines Magnetplat­ tenlaufwerks, eines mit dem Bus 100 gekoppelten Ausgabegeräts, beispielsweise eines Druckers oder Facsimilegeräts zum Mittei­ len von Informationen an ein für das Computersystem externes Ziel und einer auswechselbaren elektronischen Erweiterungskar­ ten-Schnittstelle 108 zum elektrischen Koppeln einer elektroni­ schen Schaltungskarte mit dem Bus 100 aufweisen.

Austauschbare Erweiterungskarten, die auswechselbar in die Schnittstelle 108 eingesetzt sind, weisen mikroelektronische Schaltungen innerhalb eines dünnen Gehäuses mit einer abnehmba­ ren Mehrfachverbinder-Schnittstelle auf, mit der die Erweite­ rungskarte in einen Steckplatz eines Computersystemgehäuses lösbar einsetzbar ist. Bei dem beschriebenen Ausführungsbei­ spiel halten die Erweiterungskarten und die Erweiterungskarten-Schnitt­ stelle 108, die bei der Erfindung verwendet werden, den PCMCIA-Ausgabe 2.0-Standard, für elektronische Erweiterungskar­ ten ein. Erweiterungskarten dieser Art sind dem Fachmann be­ kannt.

Im folgenden wird auf Fig. 2 Bezug genommen, in der ein Computersystemgehäuse mit mehreren Erweiterungskarten-Schnitt­ stellen (203, 205, 207 und 209) dargestellt ist. Wie gezeigt, können Erweiterungskarten 211 und 213 eingesetzt werden, wo­ durch sie elektrisch mit einer Schnittstelle 108 innerhalb des Computersystems gekoppelt werden. Diese Erweiterungskarten­ struktur erleichtert das Einsetzen und/oder Entfernen von Er­ weiterungskarten während einer Computersitzung.

Im folgenden wird auf Fig. 3 Bezug genommen, in der die Struktur einer typischen Erweiterungskarte 301 dargestellt ist. Die Erweiterungskarte 301 weist eine Schnittstelle 302 auf, mit der die Erweiterungskarte 301 elektrisch mit einem Computersy­ stem lösbar gekoppelt werden kann. Die Erweiterungskarte 301 weist auch einen Kartenspeicherbereich 303 auf. Der Karten­ speicherbereich 303 enthält Software zum Steuern der restlichen kartenspezifischen Funktionen. Diese Daten und Verarbeitungslo­ gik enthaltende Software innerhalb des Kartenspeicherbereichs 303 weist einen Gerätetreiber zur Steuerung des Betriebs der Erweiterungskarte auf. Wie oben gesagt, ist es zweckmäßig, den Gerätetreiber für eine Erweiterungskarte auf der Erweiterungs­ karte selbst zu speichern. Unter Verwendung dieser Technik braucht der RAM-Raum innerhalb des Computersystems nicht für den Gerätetreiber vorgesehen zu werden und die Verarbeitungs­ zeit wird nicht für die Übertragung eines Gerätetreibers von der Karte zum Computersystem-RAM verbraucht. Das Halten des Karten-Gerätetreibers auf der Karte selbst hat außerdem den Vorteil, daß die Kompatibilität des Gerätetreibers mit den kar­ tenspezifischen Funktionen stets gewährleistet ist. Es gibt eine geringere Wahrscheinlichkeit einer Fehlanpassung zwischen dem in dem Computersystem gespeicherten Gerätetreiber und der auf der Karte vorgesehenen kartenspezifischen Funktionalität.

Um die mit dem Stande der Technik verbundenen Probleme zu vermeiden, ist der Erweiterungskarten-Gerätetreiber nach der Erfindung in zwei Teile unterteilt: 1) Einem Abschnitt für einen vollen Gerätetreiber und 2) einem Abschnitt für einen Rumpf-Gerätetreiber. Der volle Gerätetreiber stellt die gesamte Gerätetreiber-Funktionalität zur Verfügung, die zur Steuerung jeder der Funktionen der Erweiterungskarte erforderlich ist. Der Rumpf-Gerätetreiber ist ein kleiner kompakter Abschnitt der dem vollen Gerätetreiber zugeordneten Verarbeitungslogik, ist jedoch hauptsächlich zur Verbindung des kartenresidenten vollen Gerätetreibers mit der Betriebssystemsoftware im Computersystem verantwortlich. Der Rumpf-Gerätetreiber wird in den Computersy­ stem-Arbeitsspeicher kopiert und aus letzterem ausgeführt. An­ dererseits bleibt der volle Gerätetreiber auf der Erweiterungs­ karte resident und wird von hier aus ausgeführt. Da der Rumpf-Gerätetreiber für jede Erweiterungskarte ein kompakter Verar­ beitungslogikblock ist, können viele derartige Rumpf-Geräte­ treiber für unterschiedliche Erweiterungskarten im Computersy­ stem-Arbeitsspeicher gespeichert sein, ohne übermäßige Kapazi­ täten des Computersystem-RAM zu verbrauchen. Diese Konfigura­ tion macht es möglich, daß eine große Anzahl von Rumpf-Geräte­ treibern in dem Computersystem-Speicher resident gemacht wer­ den, ohne den Computersystem-RAM für den Vollgerätetreiber für jede Erweiterungskarte zuordnen zu müssen.

Im folgenden wird wieder auf Fig. 3 Bezug genommen. Karten­ speicherbereich 303 weist einen Gerätetreiber-Informations­ block(DDIB)-Kopfteil 305, ein Rumpf-Gerätetreiber-Codebild 307 und einen vollen Gerätetreiber-Code 309 auf. Der Gerätetreiber- Informationsblock-Kopfteil 305 enthält Informationen, die zum Verknüpfen des Gerätetreibers mit der Computersystem-Verarbei­ tungslogik verwendet werden. Der Inhalt und die Struktur des Gerätetreiber-Informationsblock-Kopfteils 305 ist in Fig. 4 dargestellt und wird weiter unten beschrieben. Der Karten­ speicherbereich 303 enthält auch das Rumpf-Gerätetreiber-Code­ bild 307, welches in den Computersystemspeicher kopiert wird, und den vollen Gerätetreiber-Code 309, der auf der Karte resi­ dent bleibt.

Bei Einsetzen der Karte 301 in das Computersystem wird das Rumpf-Gerätetreiber-Codebild 307 aus dem Kartenspeicherbereich 303 gelesen und in einen Bereich des Computersystem-Speichers 102 übertragen. Der Rumpf-Gerätetreiber-Code wird danach vom Prozessor des Computersystems aus dem Computersystem-Arbeits­ speicher heraus ausgeführt. Umgekehrt wird der volle Geräte­ treiber-Code 309 nicht in den Computersystem-Arbeitsspeicher 102 übertragen; vielmehr wird der volle Gerätetreiber ausge­ führt, während er noch auf der Karte 301 resident ist. Bei Aus­ führung aktiviert der Rumpf-Gerätetreiber den Zugriff zum vollen kartenresidenten Gerätetreiber 309 und ermöglicht ein Speichermapping auf den vollen Gerätetreiber 309. Der volle Ge­ rätetreiber 309 kann danach vom Prozessor 301 aktiviert werden.

Im folgenden wird auf Fig. 4 Bezug genommen, in der der In­ halt und die Struktur des Gerätetreiber-Informations­ block(DDIB)-Kopfteils dargestellt sind. Der DDIB-Kopfteil weist einen Informationssatz zum Verknüpfen des Karten-Gerätetreibers mit der Betriebssystemlogik auf, welche innerhalb des Computer­ systems arbeitet.

Der DDIB-Kopfteil enthält einen Gerätetreiber-Informations­ block-Identitätscode 403, welcher die restlichen Informationen als Teil eines DDIB-Kopfteils identifiziert. Ein Verknüpfungs­ datenfeld 405 dient zum Verknüpfen des DDIB (nicht gezeigt) im Kartenspeicherbereich 303. Die spezielle Identifizierung 407 für den Rumpf-Gerätetreiber ist ein besonderer Wert, welcher den Rumpf-Gerätetreiber identifiziert und ihn von allen ande­ ren Rumpf-Gerätetreibern unterscheidet.

Die nächsten fünf DDIB-Kopffelder (d. h. Felder 411, 413, 415, 417 und 419) sind die gleichen Werte, die innerhalb eines Standard-Betriebssystem-Gerätetreiber-Kopfteils enthalten sind. Diese fünf Parameter sind insbesondere innerhalb des DOS-Gerä­ tetreiber-Kopfteils enthalten, der dem Fachmann bekannt ist. Gerätetreiber-Verknüpfungsinformationen 411, Gerätetreiber-At­ tribut-Informationen 413 und Gerätetreibereinheiten und -name 419 enthalten die Gerätetreiber-Identifikation und die Verknüp­ fungsinformationen, wie sie vom Betriebssystem zum Identifi­ zieren und Verknüpfen mit entsprechenden Gerätetreibern verwen­ det werden. Das Gerätetreiber-Strategie-Offset 415 und das Ge­ rätetreiber-Interrupt-Offset 417 enthalten das Offset vom Be­ ginn des Rumpf-Gerätetreiber-Codebereichs. Diese Felder werden durch die Erfindung modifiziert, wie weiter unten beschrieben werden wird. Das Rumpf-Gerätetreiber-Code-Offset 421 und die Rumpf-Gerätetreiber-Code-Länge 423 stellen ein Mittel zur Ver­ fügung, durch das die Verarbeitungslogik des Computersystems bestimmen kann, ob und wie groß das auf einer Erweiterungskarte residente Rumpf-Gerätetreiber-Code-Segment ist. In ähnlicher Weise liefern das Rumpf-Gerätetreiber-Daten-Offset 425 und die Rumpf-Gerätetreiber-Daten-Länge 427 ein Mittel zur Bestimmung des Vorhandenseins und der Größe des Rumpf-Gerätetreiber-Daten-Be­ reichs auf der Erweiterungskarte. Bei Kenntnis der Lage und Größe des Codes und der Datenbereiche des Rumpf-Gerätetreibers kann die Betriebssystemlogik innerhalb des Computersystems den Rumpf-Gerätetreiber-Code und Datenbereiche von der Erweite­ rungskarte in den Arbeitsspeicher des Computersystems übertra­ gen.

Im folgenden wird auf Fig. 5 Bezug genommen, in der ein Teil des Computersystemspeichers 501 dargestellt ist, der sich innerhalb des Arbeitsspeichers 102 befindet. Der Computersy­ stemspeicherabschnitt 501 weist einen Gerätetreiber-Lader 503, einen Rumpf-Gerätetreiber-RAM-Bereich 505 und PCMCIA-Steck­ platz-Dienste 507 auf. Der Gerätetreiber-Lader 503 weist eine Verarbeitungslogik zum Laden und zur Ausgabe des richtigen Ge­ rätetreibers bei Initialisierung des Computersystems und bei Einsetzen und Entfernen einer Karte (d. h. einem Karten-Einsetz- oder -Entfernungsereignis) aus dem Computersystem auf. Die Ein­ zelheiten der von dem Gerätetreiber-Lader 503 bei dem beschrie­ benen Ausführungsbeispiel durchgeführten Verarbeitung werden genauer in Verbindung mit den Ablaufdiagrammen gemäß den Fig. 7 und 8 beschrieben. Der Rumpf-Gerätetreiber-RAM-Bereich 505 weist einen Speicherbereich zur Speicherung der Rumpf-Geräte­ treiber auf, die entweder während der Initialisierungszeit des Computersystems oder beim Einsetzen einer Karte in das Com­ putersystem geladen werden. Der Inhalt des Rumpf-Gerätetreiber-RAM-Be­ reichs 505 wird genauer in Verbindung mit den Fig. 6a und 6b beschrieben. PCMCIA-Steckplatz-Dienste 507 enthalten eine Verarbeitungslogik zum Handhaben einer Steuerung auf niedrigem Niveau bei dem Karteneinsetzen und -entfernen. Die Verarbei­ tungslogik innerhalb der PCMCIA-Steckplatz-Dienste 507 erhält bei der Feststellung eines Karteneinsetz- oder -entfernungser­ eignisses Interrupts. Eine Verarbeitungslogik entsprechend der von den PCMCIA-Steckplatz-Diensten 507 ausgeführten Funktion ist dem Fachmann bekannt.

Ebenfalls in Fig. 5 ist ein Kartenspeicherbereich 303 dar­ gestellt, wie er oben in Verbindung mit Fig. 3 beschrieben wor­ den ist. Der Kartenspeicherbereich 303 weist einen Gerätetrei­ ber-Informationsblock-(DDIB)Kopfteil 305, ein Rumpf-Gerätetrei­ ber-Code-Bild 307 und einen vollen Gerätetreiber-Code 309 auf.

Bei einem Karten-Einsetzereignis erhalten die PCMCIA-Steck­ platz-Dienste (socket services) 507 ein Interrupt und antworten anfänglich auf das Kartenereignis. Die PCMCIA-Steckplatz-Dienste 507 aktivieren den Gerätetreiber-Lader 503, wie durch die Linie 603 in Fig. 5 dargestellt ist. Bei Aktivierung des Gerätetreiber-Laders 503 liefern die PCMCIA-Steckplatz-Dienste 507 für den Gerätetreiber-Lader 503 eine Identifizierung des Steckplatz-Adapters und des Steckplatzes, für den das Kartener­ eignis-Interrupt empfangen wurde. Der Gerätetreiber-Lader 503 greift dann auf den Gerätetreiber-Informationsblock(DDIB)-Kopf­ teil 305 auf der neu eingesetzten Karte entsprechend der Linie 605 zu. Durch Zugriff auf den DDIB-Kopfteil 305 gewinnt der Ge­ rätetreiber-Lader 503 Zugriff auf die oben in Verbindung mit Fig. 4 beschriebenen Karteninformationen. Der Gerätetreiber-La­ der 503 kann insbesondere die spezielle Identifizierung 407 des Rumpf-Gerätetreibers, das Rumpf-Gerätetreiber-Codeoffset 421, die Rumpf-Gerätetreiber-Codelänge 423, das Rumpf-Gerätetreiber-Da­ tenoffset 425 und die Rumpf-Gerätetreiber-Datenlänge 427 le­ sen. Unter Verwendung dieser Informationen bestimmt der Geräte­ treiber-Lader 503, wo sich das Rumpf-Gerätetreiber-Codebild 307 im Kartenspeicherbereich 303 befindet. Sobald die Lage und die Größe des Rumpf-Gerätetreiber-Codebildes 307 festgestellt ist (Linie 607), kopiert der Gerätetreiber-Lader 503 den Inhalt des Rumpf-Gerätetreiber-Codebildes 307 vom Kartenspeicherbereich 303 in einen Abschnitt des Rumpf-Gerätetreiber-RAM-Bereichs 505, was in Fig. 5 durch die Leitung 609 zum Ausdruck kommt. Das Rumpf-Gerätetreiber-Codebild 307 wird in den Rumpf-Geräte­ treiber-RAM-Bereich 505 geschrieben und in eine vom Gerätetrei­ ber-Lader 503 gehaltene Verknüpfungsliste von Rumpf-Gerätetrei­ bern eingebunden. Die Art, in der die Rumpf-Gerätetreiber vom Gerätetreiber-Lader 503 verbunden werden, wird in Verbindung mit den Fig. 6a und 6b geschrieben.

Im folgenden wird auf die Fig. 6a Bezug genommen, in der der Rumpf-Gerätetreiber-RAM-Bereich 505 dargestellt ist. Der Rumpf-Gerätetreiber-RAM-Bereich 505 enthält einen Speicherbe­ reich für eine Mehrzahl von Rumpf-Gerätetreiber-Blöcken. Bei­ spielsweise stellt die Fig. 6a einen Rumpf-1-Block 510, einen Rumpf-2-Block 512, einen Rumpf-3-Block 514 und einen Rumpf-n-Block 516 dar. Für den Fachmann ist klar, daß eine beliebige Anzahl von Rumpf-Gerätetreiber-Blöcken zwischen 0 und n inner­ halb des Rumpf-Gerätetreiber-RAM-Bereichs 505 vorgesehen sein können. Es ist für den Fachmann ebenfalls klar, daß die Anzahl von Rumpf-Blöcken innerhalb des Rumpf-Gerätetreiber-RAM-Be­ reichs 505 sich während der Benutzung des Computersystems dyna­ misch ändert. Daher brauchen die Rumpf-Gerätetreiber zum Zeit­ punkt der Urladung im Speicher nicht festgelegt zu sein. Es ist ebenfalls zu beachten, daß die relative Größe oder Anzahl von Speicherplätzen für jeden Rumpf-Gerätetreiber-Block relativ klein im Vergleich zum vollen Gerätetreiber-Code ist, der die Erweiterungskartenfunktionen steuert. Die relativ geringe Größe jedes Rumpf-Gerätetreiber-Blocks gibt die Möglichkeit, eine große Anzahl unterschiedlicher Rumpf-Gerätetreiber innerhalb des Rumpf-Gerätetreiber-RAM-Bereichs 505 zu speichern.

Die Rumpf-Gerätetreiber-Blöcke innerhalb des Rumpf-Geräte­ treiber-RAM-Bereichs 505 bestehen jeweils aus drei Komponenten. Hierzu wird auf Fig. 6b Bezug genommen, in der die drei Kompo­ nenten jedes Rumpf-Blocks des Rumpf-Gerätetreiber-RAM-Bereichs 505 dargestellt sind. Jeder Rumpf-Block enthält einen Rumpf-Kopfteil 540, Rumpf-Daten 542 und einen Rumpf-Code 544. Der Rumpf-Kopfteil (auch Stub-Header genannt) 540 wird hauptsäch­ lich von der Betriebssystemlogik benutzt, welche den Betrieb des Computersystems steuert.

Im folgenden wird auf Fig. 6c Bezug genommen, in der der Inhalt des Rumpf-Kopfteils 540 für jeden Rumpf-Block darge­ stellt ist. Der Rumpf-Kopfteil 540 weist Gerätetreiber-Verknüp­ fungsinformationen 630, Gerätetreiber-Attribut-Informationen 632, ein Gerätetreiber-Strategie-Offset 634, ein Gerätetreiber-Inter­ ruptoffset 636 und Gerätetreiber-Einheiten und -Namen 638 auf. Die Computersystemspeicher-102-residenten Gerätetreiber-In­ formationen 630, 632, 634, 636 und 638 des Rumpf-Kopfteils 540 entsprechen den Gerätetreiber-Informationen 411, 413, 415, 417 und 419 des kartenresidenten DDIB-Kopfteils. Die DDIB-Gerä­ tetreiber-Informationen werden zum Rumpf-Kopfteil 540 übertra­ gen, wenn ein Rumpf-Gerätetreiber geladen wird.

Gerätetreiber-Verknüpfungsinformationen 630, Gerätetreiber-Attri­ butinformationen 632 und Gerätetreiber-Einheiten und -Na­ men 638 enthalten Treiberidentifikationen und Einbindungsinfor­ mation für das Betriebssystem zum Identifizieren und Einbinden des korrespondierenden Gerätetreibers. Die Gerätetreiber-Ver­ knüpfungsinformationen 630 dienen dem Betriebssystem zur Erzeu­ gung einer Vorwärts-Verknüpfungsliste der Gerätetreiber ent­ sprechend den Linien bzw. Pfeilen 519 in Fig. 6a. Unter Verwen­ dung der Gerätetreiber-Verbindungsinformation 630 kann das Be­ triebssystem 518 auf jeden Gerätetreiber in der Verknüpfungsli­ ste dadurch zugreifen, daß die Liste unter Verwendung der Gerä­ tetreiber-Verknüpfungsinformationen für jeden Rumpf-Gerätetrei­ ber-Block solange nach unten durchlaufen wird, bis der letzte Rumpf-Gerätetreiber-Block auf das Betriebssystem 518 zurückver­ weist. Der Rumpf-Kopfteil 540 enthält auch ein Gerätetreiber- Strategie-Offset 634 und ein Gerätetreiber-Interrupt-Offset 636, die zur Identifizierung des Eintrittspunktes zum Rumpf-Code 544 entsprechend der Darstellung durch Linie 546 in Fig. 6b verwen­ det werden.

Im folgenden wird auf Fig. 6d Bezug genommen, in der der Inhalt der Rumpf-Daten 542 dargestellt ist. Die Rumpf-Daten 542 enthalten Zeiger 660 und 662, die vom Gerätetreiber-Lader 503 zur Erzeugung einer Vorwärts- und Rückwärts-Verknüpfungsliste der Rumpf-Gerätetreiber-Blöcke innerhalb des Rumpf-Gerätetrei­ ber-RAM-Bereichs 505 verwendet werden. Zeiger 660 ist ein Zei­ ger auf den vorangegangenen Rumpf-Gerätetreiber-Block in der Verknüpfungsliste. Zeiger 662 ist ein Zeiger auf den nächsten Rumpf-Gerätetreiber-Block in der Verbindungsliste. Diese dop­ pelt verknüpfte Listenstruktur ist in Fig. 6a durch die Linien bzw. Pfeile 517 veranschaulicht.

Im folgenden wird auf Fig. 6a Bezug genommen. Der Geräte­ treiber-Lader 503 enthält einen Zeiger auf den ersten Rumpf-Ge­ rätetreiber-Block 510 in der Verknüpfungsliste. Der Zeiger 662 des Rumpf-1-Blocks 510 zeigt auf den Rumpf-2-Block 512. In ähn­ licher Weise zeigt Zeiger 660 des Rumpf-1-Blocks 510 zurück auf den Gerätetreiber-Lader 503. In ebenfalls ähnlicher Weise wer­ den die Zeiger 660 und 662 jedes Rumpf-Gerätetreiber-Blocks zum Zeigen auf den vorhergehenden Rumpf-Gerätetreiber in der Ver­ knüpfungsliste verwendet. Daher sind alle Rumpf-Gerätetreiber in einer Verknüpfungsliste vorwärts- und rückwärtsverknüpft.

Der letzte Rumpf-Gerätetreiber-Block in der Verknüpfungsliste (d. h. Rumpf-n-Block 516) zeigt zurück auf den Gerätetreiber-La­ der 503, um die doppelt verknüpfte Liste zu vervollständigen.

Im folgenden wird erneut auf Fig. 6d Bezug genommen. Rumpf-Daten 542 enthalten auch eine Adapter-Identifikation 664 und eine Steckplatz-Identifikation 666. Die Adapter-Identifikation 664 und die Steckplatz-Identifikation 666 erzeugen eine spe­ zielle Identifizierung der Computersystem-Hardwareschnitt­ stelle, der der Rumpf-Gerätetreiber zugeordnet ist. Die spe­ zielle Rumpf-Gerätetreiber-Identifikation 668, welche die glei­ che Identifizierung wie die spezielle Identifizierung 407 des Erweiterungskarten-residenten Rumpf-Gerätetreiber gemäß Fig. 4 ist, identifiziert speziell den der Erweiterungskarte zugeord­ neten Rumpf-Gerätetreiber. Ein Karten-Einsetz-Flag 672 dient zum Aufrechterhalten der Anzeige, ob die dem Rumpf-Gerätetrei­ ber zugeordnete Karte eingesetzt oder entfernt ist. Ein trei­ berspezifischer Datenbereich 674 ist ein Speicherbereich, der dem Rumpf-Gerätetreiber zur Speicherung seiner eigenen Daten dient.

Im folgenden wird auf die Fig. 7 bis 13 Bezug genommen, in denen Ablaufdiagramme zur Darstellung der bei dem beschriebenen Ausführungsbeispiel verwendeten Verarbeitungslogik gezeigt sind. Es ist für den Fachmann klar, daß die hier beschriebene Verarbeitungslogik vom Prozessor 101 des Computersystems ausge­ führt werden kann.

Zunächst wird auf Fig. 7 Bezug genommen, in der die dem Ge­ rätetreiber-Lader 701 zugeordnete Verarbeitungslogik darge­ stellt ist. Die Gerätetreiber-Lader-Logik 701 entspricht dem in den Fig. 5 und 6a dargestellten Gerätetreiber-Lader 503. Die Verarbeitungslogik kann beim Start am Oval 701 vom Betriebssy­ stem während der Urladung des Computersystems aktiviert werden. Bei Aktivieren des Gerätetreiber-Laders wird eine Kartenereig­ nis-Serviceroutine mit dem Betriebssystem im Verarbeitungsblock 702 eingetragen. Mittel zum Eintragen einer Serviceroutine mit dem Betriebssystem sind im Stande der Technik bekannt. Diese Kartenereignis-Serviceroutine wird bei einem Karten-Einsetz- oder -Entfern-Ereignis aktiviert. Der Rumpf-Gerätetreiber-RAM-Be­ reich 505 wird im Verarbeitungsblock 703 reserviert. Eine vorgegebene Kapazität des Arbeitsspeichers 102 wird für die Speicherung von Rumpf-Gerätetreiber im Rumpf-Gerätetreiber-RAM-Be­ reich 505 reserviert. Eine Gruppe von üblicherweise verwende­ ten Gerätetreibern kann wahlweise während der anfänglichen La­ dezeit im Verarbeitungsblock 705 in den Rumpf-Gerätetreiber-RAM-Be­ reich 505 vorgeladen werden. Diese anfänglich geladenen Gerätetreiber können in einem Massenspeichergerät gespeichert und von dort in den Rumpf-Gerätetreiber-RAM-Bereich 505 über­ tragen werden. Als nächstes werden die Hardware-Schnittstellen abgefragt, um die Identitäten und Adressen von Karten-Steck­ platzadaptern festzustellen, welche angeschlossen sind und zur Verwendung innerhalb des Computersystems zur Verfügung stehen. Bei einem alternativen Ausführungsbeispiel kann eine vorgege­ bene Liste von Karten-Steckplatzadaptern vorgesehen und vom Ge­ rätetreiber-Lader im Verarbeitungsblock 707 gewonnen werden. In ähnlicher Weise wird die Adresse oder Identität jedes der Kar­ tensteckplätze innerhalb jedes Karten-Steckplatzadapters im Verarbeitungsblock 709 festgestellt. Wenn Erweiterungskarten in einem der verfügbaren Steckplätze des Computersystems instal­ liert sind, wird die Identität oder Adresse der installierten Karten im Verarbeitungsblock 711 gewonnen. Der Gerätetreiber-La­ der hat jetzt eine Liste von Karten-Steckplatzadaptern, eine Liste von Karten-Steckplätzen und eine Liste von derzeit in­ stallierten Erweiterungskarten. Im Verarbeitungsblock 713 wird ein Indexparameter initialisiert, der auf die erste der derzeit installierten Karten in der Liste von installierten Karten hin­ weist. Eine Subfunktion, genannt "Karten-Einsetz-Verarbeitung" wird danach im Verarbeitungsblock 715 aktiviert, um den Rumpf-Gerätetreiber für die gerade indexierte Karte zu installieren.

Die Gerätetreiber-Lader-Verarbeitung wird am mit A in Fig. 8 bezeichneten Kreis fortgesetzt.

Die Verarbeitung für den Gerätetreiber-Lader wird gemäß Fig. 8 an dem mit A bezeichneten Kreis fortgesetzt. Während die Liste der derzeit installierten Karten verarbeitet wird, wird der Entscheidungsblock 1017 ausgeführt, um festzustellen, ob alle Karten verarbeitet worden sind. Soweit alle Karten in der Liste der installierten Karten verarbeitet worden sind, wird der Verarbeitungspfad 1021 zur Rückkehr 1027 genommen, wo der Prozeß für den Gerätetreiber-Lader endet. Wenn noch nicht jede der gemäß Liste installierten Karten verarbeitet worden ist, wird der Verarbeitungspfad 1019 zum Verarbeitungsblock 1023 be­ schritten, wo der Index in der Liste von installierten Karten weitergerückt wird, um auf die nächste installierte Karte zu zeigen, und die Verarbeitung wird an dem mit G bezeichneten Kreis in Fig. 7 fortgesetzt. An dem mit G bezeichneten Kreis wird die Karten-Einsetzverarbeitungs-Subfunktion für die neu indexierte installierte Karte aktiviert.

Im folgenden wird auf Fig. 9 Bezug genommen, in der die Verarbeitung für eine Kartenereignis-Bedienungsroutine 1101 dargestellt ist. Die Kartenereignis-Bedienungsroutine 1101 ist eine Softwareroutine, die mit dem Betriebssystem bei der Urla­ dung des Computersystems eingetragen wird. Die Kartenereignis-Be­ dienungsroutine 1101 wird aktiviert, wenn ein Hardwareereig­ nis bei Einstecken oder Entfernung einer Erweiterungskarte in irgendeinen vom Computersystem vorgesehenen Steckplatz festge­ stellt wird. Bei Aktivierung der Kartenereignis-Bedienungsrou­ tine 1101 wird die Identität des Karten-Steckplatzes entspre­ chend dem Hardwareereignis im Verarbeitungsblock 1103 gewonnen. Wenn ein Karten-Einsteckereignis festgestellt wird, wird der Verarbeitungspfad 1107 zum Verarbeitungsblock 1108 eingeschla­ gen, wo die Karten-Einsteck-Verarbeitungssubfunktion für die neu installierte Karte aktiviert wird. Die darauf folgende Ver­ arbeitung endet bei der Rückkehr 1131.

Im folgenden wird wiederum auf den Entscheidungsblock 1105 Bezug genommen. Wenn keine Karte in einen Steckplatz einge­ steckt wurde, wird der Verarbeitungspfad 1109 zum Entschei­ dungsblock 1111 genommen. Wenn ein Karten-Entfernungsereignis festgestellt wird, wird der Verarbeitungspfad 1115 zum Verar­ beitungsblock 1119 genommen, wo die Verknüpfungsliste der Rumpf-Gerätetreiber innerhalb des Rumpf-Gerätetreiber-RAM-Be­ reichs 505 bei der Suche nach einem dem Steckplatz für die ent­ fernte Karte entsprechenden Rumpf-Gerätetreiber durchlaufen wird. Wenn ein der entfernten Karte entsprechender Rumpf-Gerä­ tetreiber gefunden wird, wird der Verarbeitungspfad 1125 zum Verarbeitungsblock 1127 genommen, wo ein Karten-Einsetz-Flag in den Rumpf-Daten zurückgesetzt wird, um anzuzeigen, daß die ent­ sprechende Karte entfernt worden ist. Sobald das Karten-Ein­ setz-Flag für die entfernte Karte rückgesetzt worden ist, wird der Rumpf-Gerätetreiber entsprechend der entfernten Karte im Verarbeitungsblock 1129 aktiviert. Die Aktivierung des der ent­ fernten Karte entsprechenden Rumpf-Gerätetreibers läßt den Rumpf-Gerätetreiber eine während der Installation der Karte ab­ laufende Aktion kontrolliert beenden und sperrt einen weiteren Zugriff auf die entfernte Karte. Der Rumpf-Gerätetreiber wird dann von der Verknüpfungsliste der Rumpf-Gerätetreiber entkop­ pelt. Bei Beendigung des Verarbeitungsblocks 1129 wird die Steuerung auf den Verarbeitungsblock 1119 zurückübertragen, wo die Rumpf-Verbindungsliste wiederum nach einem anderen Rumpf-Gerätetreiber entsprechend demjenigen Steckplatz durchlaufen wird, für den ein Karten-Entfernungsereignis festgestellt wurde. Die Schleife zwischen den Verarbeitungsblocks 1119 und 1129 wird für jeden Rumpf-Gerätetreiber in der Verbindungsliste so lange fortgesetzt, bis jeder Rumpf-Gerätetreiber der ent­ fernten Karte verarbeitet ist. Ist dies geschehen, so wird der Verarbeitungspfad 1123 zur Blase 1131 genommen, wo die Verar­ beitung für die Kartenereignis-Bedienung endet.

Im folgenden wird wieder auf Block 1111 Bezug genommen. Wenn das die Aktivierung der Kartenereignis-Dienstroutine 1101 bewirkende Hardware-Ereignis entweder ein Karte-Einsetz- oder ein Karte-Entfern-Ereignis ist, wird der Verarbeitungspfad 1113 genommen, um Block 1117 zu verarbeiten, wo das nicht identifi­ zierte Ereignis aufgezeichnet ist. Die Verarbeitung endet dann in der Blase 1131.

Im folgenden wird auf Fig. 10 Bezug genommen, in der die Karten-Einsteck-Verarbeitungssubfunktion 800 dargestellt ist. Die Karten-Einsteck-Verarbeitung 800 wird entweder vom Verar­ beitungsblock 715 (Fig. 7) oder vom Verarbeitungsblock 1108 (Fig. 9) aktiviert. Die Karten-Einsteckverarbeitung 800 ist für die Steuerung der Zuweisung und das Laden eines einer neu ein­ gesetzten Erweiterungskarte entsprechenden Rumpf-Gerätetreibers verantwortlich. Beginnend am Verarbeitungsblock 801 wird auf den Kartenspeicherbereich der neu eingesetzten Karte zugegrif­ fen. Wenn ein Gerätetreiber-Informationsblock (DDIB) im Karten-Speicherbereich der neu installierten Karte vorhanden ist, wird der Verarbeitungspfad 805 zum Verarbeitungsblock 807 genommen. Wenn kein DDIB im Karten-Speichergebiet vorhanden ist, wird der Verarbeitungspfad 803 zu dem in Fig. 12 mit C bezeichneten Kreis genommen, wo die Karten-Einsteckverarbeitung an der Blase 1017 endet. Da nicht alle Erweiterungskarten einen Gerätetrei­ ber benötigen, ist der Verarbeitungspfad 803 für diejenigen Karten vorgesehen, die keinen Gerätetreiber brauchen.

Am Verarbeitungsblock 807 wird der Kopfteil des DDIB der neu installierten Karte gelesen. Der Entscheidungsblock 809 prüft, ob der Rumpf-Gerätetreiber für die neu installierte Karte auf der Basis der speziellen Identifizierung des Rumpf-Ge­ rätetreibers zuvor geladen worden ist. Wenn dieser Rumpf-Ge­ rätetreiber zuvor geladen worden ist, braucht der ausführbare Code des Rumpf-Gerätetreibers nicht erneut geladen zu werden. Wenn der Rumpf also zuvor bereits geladen worden ist, wird der Verarbeitungspfad 811 zum Entscheidungsblock 821 genommen, wo verfügbarer Raum innerhalb des Rumpf-Gerätetreiber-RAM-Bereichs 505 geprüft wird. Wenn verfügbarer RAM-Raum für die Rumpf-Gerä­ tetreiber-Daten und den Rumpf-Kopfteil zur Verfügung steht, wird der Verarbeitungspfad 825 zu dem in Fig. 11 mit B bezeich­ neten Kreis genommen. Wenn es im Entscheidungsblock 821 nicht genug RAM-Raum gibt, wird der Verarbeitungspfad 823 zum Verar­ beitungsblock 824 genommen, wo ein Fehler in der Treiber-Lade-Ver­ arbeitung berichtet wird. Die Karten-Einsteck-Verarbeitung endet dann an dem in Fig. 12 mit C bezeichneten Kreis.

Im folgenden wird erneut auf den Entscheidungsblock 809 Be­ zug genommen. Wenn ein Rumpf-Gerätetreiber für die neu instal­ lierte Erweiterungskarte nicht zuvor geladen worden ist, wird der Verarbeitungspfad 813 zum Entscheidungsblock 815 genommen, wo ein Test durchgeführt wird, um festzustellen, ob in dem Rumpf-Gerätetreiber-RAM-Bereich 505 für die Speicherung des ausführbaren Codes des Rumpf-Gerätetreibers, die Rumpf-Geräte­ treiber-Daten und des Rumpf-Kopfteils genügend Raum zur Verfü­ gung steht. Wenn genügend RAM-Raum zur Verfügung steht, wird der Verarbeitungspfad 819 zu der in Fig. 11 mit B bezeichneten Blase genommen. Wenn jedoch nach dem Ergebnis des im Entschei­ dungsblock 815 durchgeführten Tests nicht genügend RAM-Raum zur Verfügung steht, wird der Verarbeitungspfad 817 zum Verarbei­ tungsblock 824 genommen, wo ein Fehler in der Gerätetreiber- Lade-Verarbeitung berichtet wird und die Verarbeitung über den in Fig. 12 mit C bezeichneten Kreis endet.

Im folgenden wird auf Fig. 11 Bezug genommen. Die Karten- Einsteck-Verarbeitung wird an dem mit B bezeichneten Kreis fortgesetzt. An diesem Punkt wurde festgestellt, daß genügend Raum für die Speicherung des Rumpf-Gerätetreiber der neu einge­ setzten Erweiterungskarte im Gerätetreiber-RAM-Bereich 505 zur Verfügung steht. Im Verarbeitungsblock 827 wird ein Teil des DDIB-Kopfteils von der neu installierten Karte in den zuvor re­ servierten Rumpf-Gerätetreiber-RAM-Bereich kopiert. Insbeson­ dere werden Felder 411, 413, 415, 417 und 419 des DDIB-Kopf­ teils in Felder 630, 632, 634, 636 und 638 des Rumpf-Kopfteils kopiert. Ein zusätzlicher Teil des RAM im Rumpf-Gerätetreiber-RAM-Be­ reich wird für Rumpf-Gerätetreiber-Daten im Verarbei­ tungsblock 829 reserviert. Die Größe dieses Rumpf-Daten-Be­ reichs wird von einem Parameter 427 im DDIB-Kopfteil spezifi­ ziert. Wenn der Rumpf-Gerätetreiber nicht zuvor geladen worden ist, und zwar aus einer Erweiterungskarte oder einer Liste von während der Urladung des Computersystems geladenen Rumpf-Gerä­ tetreibern, wird der Verarbeitungspfad 911 zum Verarbeitungs­ block 913 genommen. Im Verarbeitungsblock 913 wird der ausführ­ bare Code des Rumpf-Gerätetreibers aus der neu installierten Erweiterungskarte zu dem zuvor reservierten Rumpf-Gerätetrei­ ber-RAM-Bereich innerhalb des Rumpf-Gerätetreiber-RAM-Bereichs 505 kopiert. Die Strategie- und Interrupt-Offsets werden im Verarbeitungsblock 915 geladen, um in geeigneter Weise auf den neu geladenen Code Bezug zu nehmen. Im folgenden wird erneut auf den Entscheidungsblock 907 Bezug genommen. Wenn der Rumpf-Ge­ rätetreiber zuvor aus einer früheren Erweiterungskarte oder einer optionellen Ladeliste während der Urladung geladen worden ist, wird der Verarbeitungspfad 909 zum Verarbeitungsblock ge­ nommen, wo die Strategie- und Offset-Verbindung auf den zuvor geladenen ausführbaren Code gesetzt wird. Auf diese Weise kann das Laden eines zuvor bereits geladenen Rumpf-Gerätetreiber verhindert werden. Die Verarbeitung wird dann am Verarbeitungs­ block 917 fortgesetzt.

Am Verarbeitungsblock 917 wird der Rumpf-Kopfteil-Bereich und der Rumpf-Datenbereich innerhalb des Rumpf-Gerätetreiber-RAM-Be­ reichs 505 initialisiert bzw. geladen. Das Initialisieren dieser Bereiche umfaßt das Laden von Verbindungszeigern, Adap­ ter- und Steckplatz-Identifikationsinformationen und der Rumpf- Gerätetreiber-Identifikation. Diese Bereiche können dann durch Übertragung der entsprechenden Informationen von den kartenre­ sidenten DDIB-Kopfteil geladen werden. Ein Karten-Einsetz-Flag in den Rumpf-Daten wird im Verarbeitungsblock 919 gesetzt, um anzuzeigen, daß die Karte in einen Steckplatz eingesetzt und vom Computersystem zugreifbar ist. Die Verarbeitung wird dann an den mit E in Fig. 12 bezeichneten Kreis fortgesetzt.

Der neu installierte Rumpf-Gerätetreiber wird der vom Be­ triebssystem gehaltenen Verbindungsliste der Gerätetreiber hin­ zugefügt, und zwar im Verarbeitungsblock 1001. Bei Hinzufügen des neu installierten Rumpf-Gerätetreibers zu dieser Verbin­ dungsliste wird ein Zeiger in dem Rumpf-Kopfteil derart ge­ setzt, daß es auf den nächsten Gerätetreiber-Block in der Ver­ bindungsliste hinweist. In ähnlicher Weise wird der Rumpf-Kopf­ teil-Zeiger des vorhergehenden Gerätetreiber-Blocks derart ein­ gestellt, daß er auf den neu installierten Rumpf-Gerätetreiber zeigt. Der der neu eingesetzten Karte entsprechende Rumpf-Gerä­ tetreiber wird im Verarbeitungsblock 1009 aktiviert. Als Folge der Aktivierung des Rumpf-Gerätetreibers gibt der Rumpf-Geräte­ treiber die Aktivierung des vollen Gerätetreiber-Codes 309 frei, der auf der neu installierten Karte resident ist. Eine Aktivierung des vollen kartenresidenten Gerätetreiber-Codes 309 wird freigegeben und ein Speichermapping zur neu installierten Karte zugelassen. Daher bildet der Rumpf-Gerätetreiber eine Verknüpfung zwischen der Computersystem-Software und dem kar­ tenresidenten Gerätetreiber und den kartenresidenten Funktio­ nen.

Wenn ein anderer Gerätetreiber-Informationsblock im Karten-Spei­ cherbereich für die neu installierte Karte vorhanden ist, wird der Verarbeitungspfad 1013 zu dem in Fig. 10 mit F be­ zeichneten Kreis genommen, wo der Kopfteil für den nachfolgen­ den Gerätetreiber-Informationsblock im Verarbeitungsblock 807 gelesen wird. Da Erweiterungskarten mehr als einen Funktions­ satz enthalten können, kann mehr als ein Gerätetreiber pro Karte vorhanden sein. Wenn jedoch kein weiterer Gerätetreiber-In­ formationsblock für die neu installierte Karte vorhanden ist, wird der Verarbeitungspfad 1015 zur Beendigungsblase 1017 ge­ nommen, wo die die Karten-Einsteck-Verarbeitung endet.

Im folgenden wird auf Fig. 13 Bezug genommen, in der die Verarbeitungslogik für jeden Rumpf-Gerätetreiber beginnend an der Blase 1201 dargestellt ist. Die Rumpf-Gerätetreiber-Verar­ beitungslogik wird in Abhängigkeit vom Ereignis des Einsetzens oder Entfernens einer Karte aktiviert. Beispielsweise wird die Rumpf-Gerätetreiber-Verarbeitungslogik in Abhängigkeit von der Aktivierung der Rumpf-Gerätetreiber-Logik im Verarbeitungsblock 1129 (Fig. 9) und im Verarbeitungsblock 1009 (Fig. 12) ausge­ führt.

Wenn der Rumpf-Gerätetreiber aktiviert wird, um den Betrieb des Rumpf-Gerätetreibers nach dem Laden zu initialisieren, wird der Verarbeitungspfad 1207 zum Entscheidungsblock 1204 genom­ men. Wenn die Aktivierung des Rumpf-Gerätetreibers das Ergebnis des Ereignisses des Einsetzens einer Karte ist, wird der Verar­ beitungspfad 1206 zum Verarbeitungspfad 1210 genommen, wo auf den Karten-Speicherbereich der eingesetzten Karte zugegriffen wird. Ggf. erforderliche Konfigurations- oder Karten-Parti­ tionsinformationen werden im Verarbeitungsblock 1214 vom Rumpf-Ge­ rätetreiber gewonnen. Das Abbilden bzw. Mapping zum auf der Erweiterungskarte residenten vollen Gerätetreiber wird im Ver­ arbeitungsblock 1213 freigegeben. Der Zugriff auf den kartenre­ sidenten vollen Gerätetreiber wird im Verarbeitungsblock 1216 freigegeben. Als Ergebnis des Freigabezugriffs auf den karten­ residenten vollen Gerätetreiber kann eine Verarbeitungssteue­ rung nachfolgend auf den kartenresidenten vollen Gerätetreiber übertragen werden, wo die Erweiterungskarten-Funktionsvielfalt voll ausgenutzt werden kann. Durch Ausführen des kartenresiden­ ten vollen Gerätetreibers braucht der ausführbare Code des vollen Gerätetreibers nicht in den Computersystem-Arbeitsspei­ cher zur dortigen Ausführung übertragen zu werden.

Im folgenden wird wieder auf den Entscheidungsblock 1204 Bezug genommen. Wenn der Rumpf-Gerätetreiber aufgrund des Kar­ ten-Einsteckereignisses nicht aktiviert worden ist, wird das Ereignis des Kartenentfernens unterstellt. In diesem Falle wird der Verarbeitungspfad 1205 zum Verarbeitungsblock 1218 genom­ men, wo ein Zugriff auf den kartenresidenten vollen Gerätetrei­ ber in Abhängigkeit vom Entfernen der Karte entaktiviert wird. Auf diese Weise wird verhindert, daß die Computersystem-Soft­ ware zufällig auf eine bereits entfernte Karte Zugriff nimmt.

Im folgenden wird wiederum auf den Entscheidungsblock 1203 Bezug genommen. Wenn ein Rumpf-Gerätetreiber zum Zweck des In­ itialisierens des Rumpf-Gerätetreibers nicht freigegeben ist, wird der Verarbeitungspfad 1205 zum Verarbeitungsblock 1209 ge­ nommen. Der Verarbeitungspfad 1205 wird während des normalen Betriebs des Rumpf-Gerätetreibers nach dem Initialisieren ge­ nommen. In diesem Falle wird das Vorhandensein der zum Rumpf-Ge­ rätetreiber gehörigen Karte im Verarbeitungsblock 1209 über­ prüft. Wenn die Karte entfernt worden ist, wird der Verarbei­ tungspfad 1211 zum Verarbeitungsblock 1217 genommen, wo ein Ge­ rätetreiber-definierter Fehler zurückgegeben wird und die Ver­ arbeitung an der Blase 1219 endet. Wenn die dem Rumpf-Geräte­ treiber entsprechende Karte jedoch noch vorhanden und aktiv ist, wird der Verarbeitungspfad 1213 zum Verarbeitungsblock 1215 genommen, wo eine normale Gerätetreiber-Anforderung vom kartenresidenten vollen Gerätetreiber präsentiert wird. Bei Beendigung der normalen Anforderung in einem Verarbeitungsblock 1215 endet die Verarbeitung an der Blase 1219.

Vorstehend wurde ein Computersystem mit einem Verfahren und Mitteln zum dynamischen Konfigurieren von Gerätetreibern für Systemressourcen beschrieben.

Claims (17)

1. Verfahren zum dynamischen Konfigurieren von Gerätetreibern als Betriebsprogramm für entfernbare Computersystem-Betriebsmittel (108) unter Verwendung eines Computersystems mit einem Prozessor (101), einem Systemspeicher (102, 501) und einer Schnittstelle (108, 203-209) zur Aufnahme eines entfernbaren System-Betriebsmittels (211, 213, 301),
dadurch gekennzeichnet, daß
ein Betriebsmittelspeicher (303) in einem entfernbaren System-Betriebsmittel (301) verwendet wird;
ein Gerätetreiber (309) in den Betriebsmittelspeicher geladen wird, wobei der Gerätetreiber zum Steuern des entfernbaren System-Betriebsmittels dient;
ein Rumpf-Gerätetreiber (307) in den Betriebsmittelspeicher geladen wird, wobei der Rumpf-Gerätetreiber zum Aktivieren des Gerätetreibers dient;
nach dem Initialisieren des Prozessors (101) eine Anzeige dafür aufgenommen wird, daß das entfernbare System-Be­ triebsmittel (301) mit der Schnittstelle gekoppelt ist;
der Rumpf-Gerätetreiber in den Systemspeicher kopiert wird;
durch Ausführen der Rumpf-Gerätetreiber-Kopie im Systemspeicher ein Zugriff auf den Gerätetreiber aktiviert wird, wobei dieser Aktivierungsschritt den Schritt enthält, eine Speicherabbildung des im Betriebsmittelspeicher (303) befindlichen Gerätetreibers (309) zu ermöglichen; und daß
der im Betriebsmittelspeicher geladene Gerätetreiber ausgeführt wird.

2. Verfahren nach Anspruch 1, gekennzeichnet durch
eine Anzeige, falls ein entfernbares System-Be­ triebsmittel von der Schnittstelle- entkoppelt worden ist; und
Deaktivieren des Zugriffs auf den Gerätetreiber, wobei die Deaktivierung von der Rumpf-Gerätetreiber-Kopie (305) im Systemspeicher ermöglicht wird.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß im Betriebsmittelspeicher (303) ein. Gerätetreiber-Informationsblock-DDIB-Kopfteil (305, 401) gespeichert und in den Systemspeicher (501) kopiert wird.

4. Verfahren nach Anspruch 3, wobei der DDIB-Kopfteil (305, 401) mit Verknüpfungsdaten (405) und einer speziellen Rumpf-Gerätetreiber-Identifikation (407) versehen ist, und wobei ferner die Rumpf-Gerätetreiber-Kopie (505) mit einer im Systemspeicher (501) gespeicherten anderen Rumpf-Gerätetreiber-Kopie (510-516) verbunden wird.

5. Verfahren nach Anspruch 4, wobei das Verbinden der Rumpf-Gerätetreiber-Kopie weiterhin den Schritt enthält, die Rumpf-Gerätetreiber-Kopie in Vorwärtsrichtung mit einer folgenden Rumpf-Gerätetreiber-Kopie zu verbinden und in Rückwärtsrichtung mit einer vorhergehenden Rumpf-Gerätetreiber-Kopie zu verbinden, wobei die folgende und die vorhergehende Rumpf-Gerätetreiber-Kopie im Systemspeicher vorhanden sind.

6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß festgestellt wird, ob die Rumpf-Ge­ rätetreiber-Kopie bereits im Systemspeicher (501) enthalten ist, und daß der Kopierschritt verhindert wird, wenn sich die Rumpf-Gerätetreiber-Kopie bereits im Systemspeicher befindet.

7. Verfahren nach einem der Ansprüche 3 bis 6, dadurch gekennzeichnet, daß der DDIB-Kopfteil (305, 401) Verknüpfungsdaten (405) und eine spezielle Rumpf-Gerätetreiber-Iden­ tifikation (407) enthält, und daß die Rumpf-Gerätetreiber- Kopie von einer anderen, im Systemspeicher gespeicherten Rumpf Gerätetreiber-Kopie entkoppelt wird.

8. Verfahren nach einem der Ansprüche 1 bis 7, weiterhin die Schritte enthaltend:
Bilden eines Karten-Einsetz-Flags (672) im Systemspeicher;
Setzen des Karten-Einsetz-Flags, wenn das entfernbare System-Betriebsmittel an die Schnittstelle angekoppelt ist;
Aufnehmen einer Anzeige, daß das Karten-Einsetz-Flag gesetzt ist, wobei das entfernbare System-Betriebsmittel an die Schnittstelle gekoppelt wurde, nachdem der Prozessor initialisiert worden ist.

9. Verfahren nach Anspruch 8, weiterhin die Schritte enthaltend:
Zurücksetzen des Karten-Einsetz-Flags (672), wenn das entfernbare System-Betriebsmittel von der Schnittstelle entkoppelt wurde; und
Deaktivieren des Zugriffs auf den Gerätetreiber in Abhängigkeit des Rücksetzens.

10. Schaltungseinrichtung zum dynamischen Konfigurieren von Geräte­ treibern als Betriebsprogramm für entfernbare Computersystem-Betriebsmittel in einem Computersystem mit einem Prozessor (101), einem Systemspeicher (102; 501) und einer Schnittstelle (108) zur Aufnahme eines entfernbaren System-Betriebsmittels (211, 213; 301);
gekennzeichnet durch
einen Betriebsmittelspeicher (303) im entfernbaren System-Be­ triebsmittel (301), wobei der Betriebsmittelspeicher einen Gerätetreiber (309) zum Steuern des entfernbaren System-Be­ triebsmittels und weiterhin einen Rumpf-Gerätetreiber (307) zum Aktivieren des Gerätetreibers enthält;
Mittel zum Aufnehmen einer Anzeige, daß das entfernbare System-Betriebsmittel mit der Schnittstelle (108) gekoppelt ist, nachdem der Prozessor initialisiert worden ist;
Mittel zum Kopieren des Rumpf-Gerätetreibers (307) in den Systemspeichern (501);
Mittel zum Aktivieren eines Zugriffs auf den Gerätetreiber durch Ausführen der Rumpf-Gerätetreiber-Kopie im Systemspeicher, wobei die Mittel zum Aktivieren eines Zugriffs auf den Gerätetreiber Mittel enthalten, die eine Speicherabbildung zu dem im Betriebsmittelspeicher befindlichen Gerätetreiber ermöglichen;
Mittel zum Ausführen des Gerätetreibers aus dem Betriebsmittelspeicher heraus.

11. Schaltungseinrichtung nach Anspruch 10, dadurch gekennzeichnet, daß der Betriebsmittelspeicher (303) außerdem einen Gerätetreiber-Informationsblock DDIB-Kopfteil (305) aufweist, und daß außerdem Mittel zum Kopieren des DDIB-Kopfteils (305) in den Systemspeicher (501) vorgesehen sind.

12. Schaltungseinrichtung nach Anspruch 11, dadurch gekennzeichnet, daß der DDIB-Kopfteil (305) Verbindungsdaten (405) und eine besondere Identifikation (407) für den Rumpf-Gerätetreiber aufweist, und daß ferner Mittel zum Verbinden der Rumpf Gerätetreiber-Kopie mit einer anderen, im Systemspeicher (501) gespeicherten Rumpf-Gerätetreiber-Kopie vorgesehen sind.

13. Schaltungseinrichtung nach Anspruch 12, wobei die Mittel zum Verbinden der Rumpf-Gerätetreiber-Kopie weiterhin Mittel zum Verbinden der Rumpf-Gerätetreiber-Kopie in Vorwärtsrichtung mit einer folgenden Rumpf-Gerätetreiber-Kopie und Mittel zum Rückwärtsverbinden der Rumpf-Gerätetreiber-Kopie mit einer vorhergehenden Rumpf-Gerätetreiber-Kopie enthalten, wobei die folgenden und vorhergehenden Rumpf-Gerätetreiber-Kopien sich im Systemspeicher befinden.

14. Schaltungseinrichtung nach einem der Ansprüche 10 bis 13, dadurch gekennzeichnet, daß Mittel zum Feststellen des Vorhandenseins der Rumpf-Gerätetreiber-Kopie im Systemspeicher und Mittel zum Verhindern des Kopierschritts bei Vorhandensein der Rumpf-Gerätetreiber-Kopie im Systemspeicher vorgesehen sind.

15. Schaltungseinrichtung nach einem der Ansprüche 10 bis 14, weiterhin enthaltend:
ein Karten-Einsetz-Flag (672) im Systemspeicher;
Mittel zum Setzen des Karten-Einsetz-Flags, wenn das entfernbare System-Betriebsmittel an die Schnittstelle (108) gekoppelt ist.

16. Schaltungseinrichtung nach Anspruch 15, weiterhin enthaltend:
Mittel zum Zurücksetzen des Karten-Einsetz-Flags (672), wenn das entfernbare System-Betriebsmittel von der Schnittstelle entkoppelt ist; und
Mittel zum Deaktivieren des Zugriffs auf den Gerätetreiber in Abhängigkeit von dem zurückgesetzten Karten-Einsetz-Flag.

17. Schaltungseinrichtung nach einem der Ansprüche 11 bis 16, dadurch gekennzeichnet, daß der DDIB-Kopfteil (305, 401) Verknüpfungsdaten (405) und eine spezielle Rumpf-Gerätetreiber-Iden­ tifikation (407) enthält, wobei die Einrichtung weiterhin Mittel zum Lösen der Verbindung der Rumpf-Gerätetreiber-Kopie von einer anderen, im Systemspeicher gespeicherten Rumpf-Gerätetreiber-Kopie enthält.