DE69423853T2

DE69423853T2 - Ein-/Ausgabeobjekte in einem Betriebssystemkern

Info

Publication number: DE69423853T2
Application number: DE69423853T
Authority: DE
Inventors: David Barnett Golub; Iii Freeman Leigh Rawson; Sotomayor, Jr
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1993-12-13
Filing date: 1994-11-11
Publication date: 2000-10-19
Anticipated expiration: 2014-11-12
Also published as: EP0657809A1; US5794035A; JP3248659B2; EP0657809B1; JPH07200450A; DE69423853D1

Description

Die vorliegende Erfindung bezieht sich im allgemeinen auf das Verwalten von Eingabe/Ausgabe(I/O)-Betriebsmitteln in einem Rechnersystem.
Ein Gerätetreiber ist ein Softwarevorgang, der ein Hardwaregerät steuert, das mit einen I/O-Kanal eines Rechnersystems verbunden ist. Beispielsweise benutzt das UNIX- Betriebssystem (OS) ein Dateisystem in Form einer Datenstruktur, die sich auf der Festplatte befindet, die für jedes Hardwaregerät eine Datei enthält. Innerhalb des OS- Betriebssystems werden Verweise auf eine bestimmte Hardware- Gerätedatei in Hardwarebefehle zum Zugriff auf ein Band oder Ähnliches umgewandelt.
Modelle von Gerätetreibern nach dem Stand der Technik haben üblicherweise keinen klaren Mechanismus zum Kennzeichnen der Hardware-Betriebsmittel, die vom Gerätetreiber benötigt werden. Jeder einzelne Gerätetreiber enthält üblicherweise seine eigenen Mechanismen. Da es keinen Standardmechanismus zum Kennzeichnen der benötigten Betriebsmittel gibt, sind Gerätetreiber gezwungen, über die vorhandenen Hardware- Betriebsmittel intelligente Vermutungen anzustellen. Diese Schemata zur AD-hoc-Betriebsmittelkennzeichnung führen üblicherweise zu Gerätetreibern, die beliebige gekennzeichnete Betriebsmittel benutzen. Kollisionen zwischen Gerätetreibern, welche die gleichen Hardware-Betriebsmittel benutzen, werden nur durch verschiedene Hardwareausführungen verhindert.
Ein wesentliches Problem bei den Ad-hoc-Schemata, wie sie in früheren Gerätetreibermodellen benutzt worden sind, besteht darin, dass die Ermittlung der vorhandenen Hardware- Betriebsmittel sehr empfindlich auf eine bestimmte Systemausführung ist. Dies führt zu Gerätetreibern, die nicht nur für ein bestimmtes Hardwaregerät, sondern auch für das Betriebsmittel-Kennzeichnungsverfahren zugeschnitten sind, das vom Gerätetreiber benutzt wird. Die Ad-hoc-Betriebsmittel- Kennzeichnungsmechanismen führen auch zu einem ziemlich statischen Gerätetreibermodell, da die Gerätetreiber gewöhnlich die Kennzeichnung nur während der Initialisierung durchführen. Die Kennzeichnung kann nicht durchgeführt werden, wenn sich das Gerät im tatsächlichen Betrieb befindet, da es möglicherweise nicht zuverlässig funktioniert oder es zu Störungen am Gerät oder, noch schlimmer, am System selbst führen kann. Der Bedarf nach einem eher dynamischen Gerätetreibermodell wird bei einigen der neuen Techniken außerordentlich wichtig, beispielsweise bei PCMCIA- Standardkarten (Personal Computer Memory Card Interface Association).
Zusätzlich erhebt sich beim Benutzen von virtuellen Bildschirmen in vielen Systemen das Problem der Betriebsmittelzuordnung. Die Benutzung von virtuellen Bildschirmen gestattet es, dass mehrere Anwendungen auf dem System laufen und jede Anwendung glaubt, dass ausschließlich sie Zugriff auf die Anzeigehardware hat. Derzeit gibt es keine Standardverfahrensweise für Gerätetreiber, identische Hardware gemeinsam zu nutzen.
US-Patentschrift 5 115 499 richtet sich auf ein Zuordnungssystem gemeinsam genutzter Rechnerbetriebsmittel, in dem die gemeinsam genutzten Betriebsmittel von verschiedenen zentralen Prozessoreinheiten gemeinsam genutzt werden. Der Zugriff auf ein bestimmtes Betriebsmittel wird durch einen Speicherstandort gesteuert, der Informationen enthält, die den aktuellen Zustand des Betriebsmittels und die Identität eines beliebigen Verarbeitungselementes darstellt, welches das Betriebsmittel derzeit benutzt. Der Speicherstandort kann durch ein beliebiges der Verarbeitungselemente über Befehls- und Adressinformationen abgefragt werden. Wenn der Inhalt des Speicherstandortes anzeigt, dass sich das dazugehörige Betriebsmittel nicht in Gebrauch befindet, erhält das anfragende Verarbeitungselement sofort die Steuerung des Betriebsmittels. Wenn sich das Betriebsmittel in Gebrauch befindet, werden die Identität des Verarbeitungselementes, das derzeit das Betriebsmittel benutzt, und alle gespeicherten Betriebsmittel-Zustandsinformationen an das anfragende Verarbeitungselement zurückgeschickt.
Die vorliegende Erfindung ist auf das Bereitstellen eines dynamischen Gerätetreibermodells gerichtet, das zuverlässig funktioniert, wenn sich das Gerät in Betrieb befindet.
Dementsprechend stellt die Erfindung eine Vorrichtung zum Verwalten von Eingabe/Ausgabe(I/O)-Betriebsmittelinformationen in einem Rechner bereit, die Folgendes umfasst: Mittel, um in einer Datenbank Informationen über Eingabe/Ausgabe- Betriebsmittel zu definieren; Mittel zum dynamischen Aktualisieren der Eingabe/Ausgabe-Betriebsmittelinformationen; und Mittel zum Bereitstellen der Eingabe/Ausgabe- Betriebsmittelinformationen an einen oder mehrere Gerätetreiber.
Dies stellt eine Datenbank von Betriebsmitteln, die durch Gerätetreiber abgefragt werden kann, und ein Verfahren zum Verfolgen und Zuordnen von I/O-Betriebsmitteln für Gerätetreiber bereit.
Auf diese Weise kann eine Vielzahl von Gerätetreibern eine Gruppe von Hardware-Betriebsmitteln gemeinsam nutzen.
In einer Ausführungsform stellt ein Hardware- Betriebsmittelverwalter (HRM) eine Datenbank von I/O- Betriebsmitteln an Gerätetreiber bereit, wobei die Datenbank von den Treibern jederzeit abgefragt werden kann, um festzustellen, welche Betriebsmittel vorhanden sind. Zusätzlich stellt der HRM ein Verfahren zum Verfolgen und Zuordnen von Betriebsmitteln zwischen den Gerätetreibern bereit. Der HRM versorgt Gerätetreiber mit einer Standardausführung eines Betriebsmittel-Kennzeichnungssystems. Die Gerätetreiber müssen nur die Datenbank abfragen und mit ihr in Wechselwirkung treten. Die Gerätetreiber hängen nur von einer bestimmten Ausführung des HRM ab und müssen daher für unterschiedliche Betriebssysteme nicht mehr getrennt eingerichtet werden. Die von dem HRM bereitgestellte Datenbank kann auch dynamisch aktualisiert werden, was es den Gerätetreibern ermöglicht, hinsichtlich wichtiger Veränderungen in der Hardwarekonfiguration aktuelle Information zu empfangen.
Das Verfahren zum Verfolgen und Zuordnen von Betriebsmitteln, das vom HRM bereitgestellt wird, ermöglicht es mehreren Gerätetreibern, die gleiche physische Menge von Hardware- Betriebsmitteln gemeinsam zu benutzen. Der Gerätetreiber kann nicht nur den HRM nach einem bestimmten Hardware- Betriebsmittel abfragen, sondern der Treiber kann auch das Betriebsmittel anfordern. Wenn ein Betriebsmittel angefordert wird, stellt der HRM fest, ob derzeit ein anderes Gerät das Betriebsmittel benutzt. Wenn dies nicht der Fall ist, wird das Betriebsmittel dem anfordernden Gerätetreiber zugeordnet. Wenn sich das Betriebsmittel gerade in Gebrauch befindet, kann der HRM anfordern, das der Gerätetreiber auf das Betriebsmittel verzichtet. Die Antwort des anfänglichen Gerätes legt jede weitere Aktion fest, die vom HRM unternommen wird.
Die dynamische Natur des HRM-Systems gestattet, dass neue Geräte einfach hinzugefügt werden können. Dieses Problem entsteht sehr oft, wenn das Gerät und seine Steuerungshardware über einen langen Zeitraum benutzt worden sind und der Gerätetreiber speziell für das Gerät und die verwendete Steuerung geschrieben worden ist. An einem gewissen Punkt wird ein neues und völlig unterschiedliches Gerät entwickelt, es benutzt jedoch noch die gleiche Steuerung, gewöhnlich mit dem ursprünglichen Gerät, das noch dazugehört; z. B. ein zweites Plattenlaufwerk, das an die Steuerung angeschlossen ist, mit der das ursprüngliche Plattenlaufwerk verbunden war. Dies erfordert es üblicherweise, dass die ursprüngliche Gerätetreiber-Software neu geschrieben wird, um beide Gerätetypen zu unterstützen. Die Verwendung des HRM nach der Erfindung gestattet es jedoch, dass Software für zwei unterschiedliche Gerätetreiber für die beiden unterschiedlichen Geräte/Steuerungspaare geschrieben wird. Jeder Gerätetreiber würde sich in Unkenntnis des Vorhandenseins des anderen befinden.
Die Fähigkeit des HRM, neue Informationen dynamisch aufzunehmen, gestattet es dem System auch, sogar angesichts von Teilausfällen und während der Ausfalldiagnose funktionsfähig zu bleiben. Der HRM gestattet es einem Diagnoseprogramm, die Hardware-Betriebsmittel zu bekommen, die zum Durchführen der Diagnose erforderlich sind. Jeglicher Gerätetreiber, der vorher die Hardware benutzt hatte, würde im Wesentlichen von der Tatsache unberührt bleiben, dass derzeit eine Diagnose durchgeführt wird. Darüber hinaus würde das Einbauen der Diagnosefunktionen in den HRM es zulassen, dass der Programmierer des Gerätetreibers sich darauf konzentriert, Gerätetreiber-Software mit hoher Qualität und großem Leistungsvermögen bereitzustellen. Gleichermaßen kann sich der Programmierer der Diagnosesoftware darauf konzentrieren, Diagnosesoftware bereitzustellen, die zahlreiche Probleme und mögliche Probleme bei einem Hardwareteil erkennen kann.
Eine bevorzugte Ausführungsform der Erfindung wird nun unter Bezugnahme auf die Zeichnungen beschrieben, in denen:
Fig. 1 ein Objektdiagramm ist, das Beziehungen von Einheiten in einer HRM-Musterdatenbank zeigt;
Fig. 2 ein Objektdiagramm ist, das nur die topologischen Knoten in einer HRM-Musterdatenbank zeigt;
Fig. 3 ein Objektdiagramm ist, das die HRM-Datenbank mit Aktivitätsknoten veranschaulicht, wobei die Datenbank eine Untermenge der in Fig. 2 gezeigten Datenbank ist;
Fig. 4a bis 4d Objektdiagramme sind, die ein Gewährungs/Abtretungs-Protokollbeispiel unter Verwendung der Musterdatenbank zeigt, wie in Fig. 2 und 3 gezeigt ist, und insbesondere
Fig. 4a eine Veranschaulichung des Anfangsstatus der Datenbank ist,
Fig. 4b eine Veranschaulichung des Gerätetreibers ist, der Zugriff zu einem I/O-Betriebsmittel anfordert,
Fig. 4c den Zustand der Datenbank zeigt, wenn ein Gerätetreiber Zugriff erhält, und
Fig. 4d eine Veranschaulichung des ursprünglichen Gerätetreibers ist, der Zugriff zum Betriebsmittel freigibt; und
Fig. 5 ein Schaubild ist, das ein Beispiel des Busläufers veranschaulicht, der Gerätedienste bereitstellt.
Der Hardware-Betriebsmittelverwalter(HRM) besteht aus einer Menge von Rechnerprogrammen, welche die Vielfalt von Hardware- Betriebsmitteln verwalten, die zu einem Rechnersystem gehören. Der HRM gestattet es Gerätetreibern und anderen Software- Untersystemen, auf die physischen Hardware-Betriebsmittel zuzugreifen. Der HRM wird vorzugsweise in einer objektorientierten Programmiersprache ausgeführt. Es wird jedoch auch ins Auge gefasst, dass hierarchische und andere Programmiertechniken benutzt werden könnten, um die Erfindung wie beschrieben erfolgreich zu realisieren.
Die Konzepte und die Terminologie, wie sie zum Beschreiben der HRM-Datenbank benutzt werden, sind solche, wie sie auf dem Gebiet der Rechnerwissenschaft als objektorientiertes Programmieren (OOP) bekannt sind. OOP ist die bevorzugte Umgebung für den Aufbau benutzerfreundlicher, intelligenter Rechnersoftware. Schlüsselelemente von OOP sind Datenverkapselung, Vererbbarkeit und Polymorphismus. Diese Elemente können verwendet werden, um eine grafische Benutzerschnittstelle (GUI) zu erzeugen, die üblicherweise durch eine Fensterumgebung gekennzeichnet ist, die Symbole, Mauspositionsanzeiger und Menüs hat. Obwohl diese drei Schlüsselelemente den OOP-Sprachen gemeinsam sind, benutzen die meisten OOP-Sprachen die drei Schlüsselelemente unterschiedlich.
Beispiele von OOP-Sprachen sind Smalltalk, Object Pascal und C++. Smalltalk ist in der Tat mehr als eine Sprache; es könnte eher genauer als Programmierumgebung bezeichnet werden. Smalltalk wurde in den frühen Siebzigern in der Learning Research Group beim Palo Alto Research Center (PARC) von Xerox entwickelt. In Smalltalk wird an ein Objekt eine Nachricht geschickt, das Objekt selbst auszuwerten. Nachrichten führen eine Task aus, die der von Funktionsaufrufen in konventionellen Programmiersprachen gleicht. Der Programmierer muss sich mit der Art der Daten nicht befassen; statt dessen muss sich der Programmierer nur mit dem Erzeugen der richtigen Reihenfolge einer Nachricht und dem Benutzen der richtigen Nachricht befassen. Object Pascal ist die Sprache, wie sie für Macintosh-Rechner von Apple benutzt wird. Apple entwickelte Object Pascal in Zusammenarbeit mit Niklaus Wirth, dem Entwickler von Pascal. C++ wurde 1983 von Bjarne Stroustrup in den AT&T Laboratories als Erweiterung von C entwickelt, das die Sprache ist, in der das UNIX-Betriebssystem geschrieben wurde. Das Schlüsselkonzept von C++ ist eine Klasse, die eine benutzerdefinierte Art ist. Klassen stellen objektorientierte Programmiermerkmale bereit und haben üblicherweise zwei Arten von Mandanten, die als Instanzen und Unterklassen bezeichnet werden. C++-Module sind mit C-Modulen kompatibel und können frei verknüpft werden, so dass vorhandene C-Bibliotheken mit C++-Programmen benutzt werden können. Die bevorzugte Ausführungsform der Erfindung ist in C++ geschrieben.
Die am meisten benutzten objektbasierten und objektorientierten Programmiersprachen verfolgen ihr Erbe zurück bis auf Simula, die in den Sechzigern von O-J. Dahl, B. Myhrhaug und K. Nygard aus Norwegen entwickelt wurde. Weitere Informationen über das Thema des objektorientierten Programmierens kann durch Bezugnahme auf Object Oriented Design with Applications von Grady Booch, The Benjamin/Cummings Publishing Co., Inc., Redwood City, Calif. (1991), und An Introduction to Object-Oriented Programming von Timothy Budd, Addison-Wesley Publishing Co. (1991) erhalten werden.
Wie vorstehend angemerkt wurde, besteht der HRM aus einer Menge von Programmen. Diese Programme gehören im allgemeinen zu einer von vier Kategorien. Die erste Art von Programm ist der Namensdienst. Es gibt nur ein Programm dieser Art in jedem HRM, und es ist ein Nachweis von Informationen und ist für das Aufrechterhalten des Platzes für den lokalen Namen des Systems verantwortlich. Der Namensdienst ist ein Standardteil des I/O- Systems, und seine Hauptfunktion besteht darin, es unterschiedlichen Programmen zu gestatten, Informationen über die jeweils anderen Programme zu erhalten. Alle Dienste, die Programmtasken verfügbar sind, werden in dem Namensdienst gepflegt, so dass alle Tasken auf die gewünschten Dienste zugreifen können. Die zweite Kategorie von Programmen sind Betriebsmittel-Verwalterobjekte. Diese Programme bieten einen Bezugspunkt für die verschiedenen Busverwalter, die den Großteil des HRM ausmachen. Die dritte Art von Programmen sind die Busverwalter, welche die Schlüsselfunktion des HRM ausmachen. Jeder Bus hat einen bestimmten Busverwalter, der eine Datenbank aller Hardware-Betriebsmittel enthält, die in einem System vorhanden sind. Beispielhaft für gewöhnliche Busse sind der MicroChannel-Bus und der Bus der Kleinrechner- Systemschnittstelle (SCSI). Zusätzlich richten die Busverwalter das "Gewährungs/Abtretungs-Protokoll ein, das es anderen Baugruppen im System erlaubt, zu den verschiedenen Hardware-Betriebsmitteln Zugriff zu erlangen. Die vierte Kategorie von Programmen, die Busläufer, sind mit einen bestimmten Busverwalter verbunden und sind für das Laden der Datenbank mit Informationen verantwortlich, die mit dem Typ des Busses übereinstimmt, der verwaltet werden soll. In einigen Fällen ist der Busläufer ein einfaches Programm, das eine Scriptdatei lesen kann und diese Informationen dafür benutzt, die Datenbank seines Busverwalters zu laden. In anderen Fällen muss der Busläufer jedoch eine Anzahl von Dateien lesen und die Informationen benutzen, um eine von der Hardware vorbereitete Datenbank zu übersetzen (d. h. in nichtflüchtigem Speicher mit wahlfreiem Zugriff), um die Datenbank seines Busverwalters zu laden.
Die Datenbank, welche die gesamten Hardware-Betriebsmittel im System darstellt, wird in den verschiedenen Busverwaltern verteilt. Die Datenbank wird durch die Busverwalter gepflegt und ist nicht dauerhaft. Jeder Busverwalter behält seine Datenbank als Menge von Datenstrukturen, die abgefragt und bearbeitet werden kann, in seinem Speicherabbild. Die Wechselwirkung zwischen den verschiedenen Datenbanken ist minimal und ist auf das beschränkt, was über die HRM- Schnittstellen bereitgestellt wird.
Unter Bezugnahme auf die Zeichnungen und insbesondere auf Fig. 1 wird dort ein Objektdiagramm der Datenbank des Hardware-Betriebsmittelverwalters (HRM) gezeigt. Die Datenbank ist als Baum organisiert, wobei die Knoten des Baumes die verschiedenen Hardware-Betriebsmittel darstellen, die im System vorhanden sind. Die Größe und Form des Baumes wird durch die Typen von vorhandenen Betriebsmitteln und die Beziehungen zwischen Betriebsmitteln bestimmt. Jeder Zweig des Baumes stellt einen bestimmten Objekttyp dar, und es gibt Beschränkungen, an welchen Knoten sich Eltern oder Kinder von anderen Knoten sein können. Zusätzlich zur Darstellung der Beziehungen zwischen den verschiedenen Knoten zeigt Fig. 1 die Programme, die jeden der Knoten und den Typ der Knoten (d. h. topologischer Knoten und Aktivitätsknoten) enthalten.
Wieder unter Bezugnahme auf Fig. 1 können die Knoten in dem Baum in zwei Hauptkategorien unterteilt werden. Der erste Typ sind Knoten, welche die Topologie des Systems beschreiben oder, mit anderen Worten, kennzeichnen, welche Betriebsmittel in dem System vorhanden sind. Die zweite Kategorie sind solche Knoten, welche die Aktivität des Systems, oder welche Betriebsmittel derzeit im System in Gebrauch sind, beschreiben. Die Aktivitätsknoten des Systems sind als Unterbäume dargestellt, die den Teil der topologischen Knoten beschatten, für welche die Aktivität gerade dargestellt wird. Es ist von Bedeutung, hier anzumerken, dass es für einen bestimmten topologischen Knoten mehr als einen Aktivitäten- Unterbaum geben kann. Diese Struktur ist für das Gewährungs/Abtretungs-Protokoll wichtig und gestattet es mehreren Mandanten, Zugriff auf das gleiche physische Betriebsmittel zu erlangen.
Es gibt eine Anzahl von Typen von topologischen Knoten, und jeder Knoten ist von bestimmtem Typ. Wie in Fig. 1 gezeigt, ist der erste Typ von Knoten ein Betriebsmittel- Verwalterobjekt 10. Dieses Objekt wird durch das Betriebsmittel-Objektverwalterprogramm dafür benutzt, die verschiedenen Bustypen und Busobjekte mit dem Baum zu verbinden. Ein zweiter Typ von Knoten ist ein Bustyp 20, welcher den Typ von Bus kennzeichnet, den der Busverwalter unterstützt und der diese Informationen exportieren kann. Beispiele von Bustypen könnten MicroChannel-Architektur (MCA), AT-Bus- oder Industry-Standard-Architektur (ISA) und ihre Untergruppe Erweiterter ISA (EISA) und Kleinrechner- Systemschnittstelle (SCSI) sein. Der Busobjektknoten 30 wird durch einen Busverwalter erzeugt und kennzeichnet das Vorhandensein eines physischen Busses von dem Typ, den der Busverwalter unterstützt. Der nächste Typ von Knoten, ein Assoziationsknoten 40, wird dafür benutzt, ein oder mehrere Betriebsmittelobjekte zu einer einzigen Einheit zu gruppieren. Dies gestattet es, dass mehrere physische Einheiten zu einer logischen Einheit zusammengruppiert werden. Ein Betriebsmittelobjektknoten 50 wird dafür benutzt, ein oder mehrere Betriebsmittel in eine einzige Einheit zusammenzugruppieren, die es gestattet, dass mehrere physische Betriebsmittel in einer Form zusammengruppiert werden, die analog zu einer Steuerung ist. Der Betriebsmittel-Typknoten 60 wird dafür benutzt, den Typ und die Attribute eines Betriebsmittels anzuzeigen. Einige Beispiele von Betriebsmitteltypen sind I/O-Anschlüsse, I/O-Speicher und Unterbrechungsebenen. Ein letzter Typ von Knoten ist der Betriebsmittelknoten 70, der dafür benutzt wird, ein einzelnes physisches Betriebsmittel darzustellen. Beispiele dafür sind eine Unterbrechungsebene, ein benachbarter Bereich von I/O- Anschlüssen oder ein benachbarter Bereich von I/O-Speichern.
Es gibt auch bestimmte Typen von Aktivitätsknoten, die erzeugt werden, wenn ein Mandant die Betriebsmittel benutzen möchte, die durch einen topologischen Unterbaum dargestellt werden. Jeder Aktivitätsknoten stellt eine aktive Instanz eines entsprechenden topologischen Knotens dar. Wie in Fig. 1 gezeigt, sind drei Beispiele von Typen von Aktivitätsknoten Assoziationsinstanz 80, Betriebsmittel-Objektinstanz 90 und Betriebsmittelinstanz 100. Eine aktive Instanz eines topologischen Unterbaumes wird an der Spitze des Unterbaumes erzeugt. Ein vollständig aktiver Unterbaum wird erzeugt, wenn der Knoten an der Spitze des Unterbaumes aktiviert wird. Ein Beispiel wird für einen topologischen Unterbaum dargestellt, der aus einem Betriebsmittelobjekt und drei Betriebsmitteln besteht. Zuerst wird die Betriebsmittel-Objektinstanz erzeugt, und zur gleichen Zeit wird eine Betriebsmittelinstanz für jedes der drei Betriebsmittel erzeugt. Jede der Betriebsmittelinstanzen wird nicht nur mit dem Betriebsmittel verbunden, die sie darstellt, sondern auch mit der Betriebsmittel-Objektinstanz, die ihre Erzeugung ausgelöst hat. Darüber hinaus werden, wenn eine Assoziationsinstanz erzeugt worden ist, Betriebsmittel-Objektinstanzen für alle der Betriebsmittelobjekte unter dieser Assoziation erzeugt, und es werden jeweils Betriebsmittelinstanzen für jedes Betriebsmittelobjekt erzeugt. Wie diese Beispiele veranschaulichen, müssen jeder entsprechende Aktivitätsunterbaum und topologischer Unterbaum identisch sein.
Es gibt mehrere Dinge, die aus Fig. 1 nicht unmittelbar hervorgehen. Zuerst wird durch einen einzelnen Busverwalter ein einzelner Bustyp verwaltet. Es ist für ein einzelnes ausführbares Programm möglich, mehr als einen Bustyp zu unterstützen, dies wird jedoch wie mehrere Busverwalter gehandhabt. Andererseits ist es wahrscheinlich, das ein einzelner Busverwalter mehrere Busobjekte (die physische Busse darstellen) unterstützen kann. Zweitens werden die Bustyp- und die Betriebsmittel-Typknoten durch den Busverwalter definiert und hängen nicht vom Inhalt des Restes der Datenbank ab. Daher sind sie immer in der Datenbank vorhanden. Im Gegensatz dazu werden alle restlichen Knoten mit Ausnahme des Betriebsmittel- Verwalterobjektes durch Busläufer in der Datenbank untergebracht.
Fig. 2 veranschaulicht ein vereinfachtes Muster einer HRM- Datenbank, bei der nur die topologischen Knoten vorhanden sind, die es gestatten, dass die topologische Struktur einfach beobachtet werden kann. Es ist wichtig anzumerken, dass jeder topologische Knoten Informationen hat, die mit ihm verbunden ist, einschließlich eines Namens. Der Name wird in der Datenstruktur benutzt, den Knoten darzustellen, und wird durch den HRM auch im Namendienstprogramm benutzt. Es sollte angemerkt werden, dass zum Zwecke der Vereinfachung des Diagramms die Verknüpfungen zwischen dem Busobjektknoten und den Betriebsmittelknoten nicht gezeigt worden sind.
Wie in der HRM-Datenbank in Fig. 2 gezeigt, ist Muster 110 ein Bustyp. Dieser Bustyp hat drei Typen von Betriebsmitteln, Typ A 112, Typ B 114 und Typ C 116, die mit dem Bus benutzt werden können. Muster 0 118 stellt einen physischen Bus dar, der durch den Busverwalter verwaltet werden soll. Muster 0 hat sechs angeschlossene Betriebsmittel, die Verbindungen zwischen ihnen sind jedoch, wie vorstehend vermerkt, in der Figur nicht gezeigt. Betriebsmittel R-a 120, R-d 122 und R-f 124 haben einen Betriebsmitteltyp vom Typ A. Betriebsmittel R-b 126 und R-e 128 haben einen Betriebsmitteltyp vom Typ C. Schließlich hat Betriebsmittel R-c 130 einen Betriebsmitteltyp vom Typ B. Die Betriebsmittel sind in Betriebsmittelobjekten organisiert, und in diesem Beispiel werden die sechs Betriebsmittel in drei Betriebsmittelobjekten gruppiert. Das erste Betriebsmittelobjekt Ctlr-A 132 enthält ein einziges Betriebsmittel R-e. Das zweite Betriebsmittelobjekt, Ctlr-B 134 enthält zwei Betriebsmittel R-a und R-c. Das letzte Betriebsmittelobjekt Ctlr-C 136 enthält vier Betriebsmittel R- b, R-c, R-d und R-f. Eine Assoziation, Gruppe 138, enthält zwei der Betriebsmittelobjekte Ctlr-A und Ctlr-B. Es ist wichtig anzumerken, dass Betriebsmittel R-c in zwei Betriebsmittelobjekten enthalten ist, Ctlr-B und Ctlr-C. Dies gestattet es mehreren Benutzern, auf das gleiche Betriebsmittel zuzugreifen. Das Verhalten des Betriebsmittels wird durch den Betriebsmitteltyp festgelegt. Das Betriebsmittel kann gemeinsam nutzbar sein, was mehreren Benutzern den gleichzeitigen Zugriff auf das Betriebsmittel gestattet. In anderen Fällen kann das Betriebsmittel nicht gemeinsam nutzbar sein, wodurch der Zugriff auf das Betriebsmittel zu einem Zeitpunkt auf einen einzigen Benutzer begrenzt wird.
Fig. 3 stellt eine Veranschaulichung der Beziehungen zwischen Aktivitätsknoten und topologischen Knoten in der HRM-Datenbank bereit. Um das Schaltbild zu vereinfachen, werden nur die topologischen Knoten gezeigt, die durch Aktivitätsknoten beschattet werden. Fig. 3 ist eine Untermenge der Knoten, die in Fig. 2 gezeigt werden, und Fig. 3 wird unter Bezugnahme auf die vorstehend bereitgestellte Information beschrieben.
Unter Bezugnahme auf Fig. 3 stellen die dunkleren Knoten topologische Knoten dar, und die dunkleren Linien zeigen ihre Beziehungen untereinander. Die helleren Knoten stellen Aktivitätsknoten dar, und die helleren Linien zeigen ihre Beziehungen untereinander. Die Aktivitätsknoten sind im "Schatten" der topologischen Knoten angeordnet, mit denen sie verbunden sind. Der in Fig. 3 gezeigte Baum und die Beziehungen stellen für die Aktivitätsknoten zeitlich eine Augenblickssituation dar. Es sollte angemerkt werden, dass topologische Knoten dynamisch hinzugefügt oder entfernt werden können. Die Veränderungen sind jedoch gewöhnlich von Veränderungen an der physischen Konfiguration des Systems abhängig. Andererseits werden sie, da Aktivitätsknoten den Gebrauch der verschiedenen Teile des Systems widerspiegeln, der Datenbank des HRM gewöhnlich mit größerer Häufigkeit als topologische Knoten hinzugefügt oder aus ihr entfernt.
Die Konfiguration der in Fig. 3 gezeigten Datenbank veranschaulicht ein Endergebnis von Knoten, nachdem der HRM einige der Betriebsmittel im System verfolgt und zugeordnet hat. Es sollte sich jedoch verstehen, dass die folgende Beschreibung nur einen der möglichen Handlungsabläufe beschreibt, die aufgetreten sind und zu den gezeigten Ergebnissen geführt haben. Das Erzeugen eines aktiven Instanzknotens für eine Assoziation oder ein Betriebsmittelobjekt signalisiert dem HRM, für alle Knoten in dem Unterbaum aktive Instanzen zu erzeugen. In diesem Falle besteht der erste Schritt im Erzeugen einer aktiven Instanz der Gruppe 200, einer Assoziation. Dies erzeugt automatisch aktive Instanzen von Betriebsmittelobjekten Ctlr-A 202 und Ctlr-B 204. Zusätzlich werden für die in den Betriebsmittelobjekten enthaltenen Betriebsmittel aktive Instanzen erzeugt. Daher sind für die Betriebsmittel R-a 206, R-c 208 und R-e 210 aktive Instanzen erzeugt worden. Nachdem die aktive Instanz der Gruppe erzeugt worden ist, wird für das Betriebsmittelobjekt Ctlr-B eine getrennte aktive Instanz erzeugt. Das Erzeugen der aktiven Instanz von Ctlr-B veranlasst, dass aktive Instanzen für die Betriebsmittel R-a und R-c erzeugt werden. Abschließend wird für das Betriebsmittelobjekt Ctlr-C 212 eine aktive Instanz erzeugt, die veranlasst, dass für die Betriebsmittel R-b 214, R-c 208, R-d 216 und R-f 218 aktiven Instanzen erzeugt werden.
Obgleich der Aktivitätenunterbaum nun in der HRM-Datenbank erzeugt worden ist, hat der Mandant des HRM noch keinen Zugriff auf die durch den Unterbaum dargestellten tatsächlichen Betriebsmittel. Ein Mandant kann Zugriff auf die Betriebsmittel erlangen, indem er sie anfordert. Die Anforderung geht gewöhnlich an einen vollständigen Unterbaum (d. h. eine Assoziation oder ein Betriebsmittelobjekt) statt an einzelne Betriebsmittel.
Die Anforderung eines Betriebsmittels kann durch mehrere Mandanten des HRM gleichzeitig erfolgen. Dieser Konflikt erfordert es, dass der HRM die Betriebsmittel zwischen den Mandanten zuordnet. Vom HRM wird ein "Gewährungs/Abtretungs"- Protokoll benutzt, um festzulegen, welcher Mandant auf das Betriebsmittel zugreifen kann. Dieses Protokoll wird aufgerufen, wenn ein Mandant eine Gruppe von Betriebsmitteln anfordert. Der erste Schritt besteht für den HRM darin festzustellen, ob ein anderer Mandant derzeit auf diese Betriebsmittel zugreift. Wenn dies nicht der Fall ist, gewährt der HRM die Betriebsmitttel dem anfordernden Kunden direkt. Andererseits muss, wenn ein anderer Mandant auf die Betriebsmittel zugreift, der HRM anfragen, ob und wann der andere Mandant die Betriebsmittel erlangen kann. Das Ergebnis legt fest, ob der anfordernde Mandant auf die Betriebsmittel zugreifen kann oder ob der anfordernde Mandant warten muss, bis der ursprüngliche Mandant willens ist, die Betriebsmittel freizugeben.
Eine Veranschaulichung des "Gewährungs/Abtretungs"-Protokolls wird in Fig. 4a bis 4d bereitgestellt. Diese Figuren beruhen auf dem Beispiel der HRM-Datenbank, wie es in Fig. 2 und 3 veranschaulicht ist und vorstehend erörtert wurde. Diese Figuren veranschaulichen die Aktivität von drei HRM- Mandanten, a, b und g. Mandant a stellt einen Mandanten dar, der einen Aktivitätenunterbaum erzeugt hat, der mit der Assoziationsgruppe begonnen hat. Mandant b stellt einen Mandanten dar, der einen Aktivitätenbaum erzeugt hat, der bei dem Betriebsmittelobjekt Ctlr-B begonnen hat. Schließlich stellt Mandant g einen Mandanten dar, der einen Aktivitätenunterbaum erzeugt hat, der an Betriebsmittelobjekt Ctlr-C begonnen hat.
Fig. 4a veranschaulicht einen Anfangszustand einer HRM- Datenbank, in der Mandant b angefordert hat, dass seine Instanz von Ctlr-C 212 vollständig aktiviert wird, so dass Mandant b auf die Hardware-Betriebsmittel in dem Unterbaum Ctlr-C vollständigen Zugriff haben wird. Die Aktivitätenknoten, die aktiv sind, werden durch Schattierung angezeigt. An diesem Punkt wird, um das vom HRM benutzte Protokoll zu veranschaulichen, Mandant a Zugriff zu den Betriebsmitteln anfordern, die durch den Gruppenunterbaum dargestellt werden.
Fig. 4b zeigt den Zustand der HRM-Datenbank, nachdem Mandant a Zugriff auf die Betriebsmittel in Gruppenunterbaum angefordert hat. Durch den HRM sind eine Anzahl von Schritten ausgeführt worden, um den Zustand der Datenbank von dem einen in Fig. 4a gezeigten zu dem in Fig. 4b gezeigten zu verändern. Der erste Schritt in dem Umwandlungsvorgang besteht darin, dass der Zustand der dem Mandanten a eigenen Instanz 300 der Gruppe verändert wird, um sie aktiv zu machen. Dann beginnt der HRM damit, alle Unterbäume der Betriebsmittel- Objektinstanzen zu aktivieren, die Teil der Gruppeninstanz von Mandant a sind. In diesem Beispiel sind Ctlr-A und Ctlr-B die betroffenen Betriebsmittel-Objektinstanzen. Daher wird der Zustand der Instanz von Ctlr-A 320 des Mandanten a als aktiviert gekennzeichnet, und der HRM beginnt damit, die Betriebsmittel zu aktivieren, die in der Instanz Ctrl-A des Mandanten a enthalten sind. Das einzige Betriebsmittel, das in diesem Beispiel aktiviert werden muss, ist R-e. Der HRM fragt den Betriebsmittelknoten für R-e ab, um festzustellen, ob das Betriebsmittel schon aktiv ist. Da es nicht aktiv ist, kann der HRM die Instanz von R-e 330 des Mandanten a als vollständig aktiv verändern. Die Verfahrensweise, die Instanz vollständig aktiv zu machen, ist in dem Betriebsmitteltyp für das bestimmte Betriebsmittel definiert. An diesem Punkt läuft der HRM weiter durch die restlichen Betriebsmittelinstanzen für Mandanten a, die sich in dem Unterbaum Ctlr-A befinden. Da in diesem Beispiel keine anderen Betriebsmittelinstanzen vorhanden sind und der HRM R-e vollständig aktiviert hat, kann der HRM nun die Instanz von Ctlr-A 320 von Mandant a auf vollständig aktiv verändern. Nun kann der HRM eine Gewährungsnachricht an Mandanten a senden, die anzeigt, dass der Mandant vollständigen Zugriff auf alle die Betriebsmittel hat, die in dem Betriebsmittelobjekt enthalten sind. Zu diesem Zeitpunkt wird der HRM zu den restlichen Betriebsmittelobjekten, falls solche vorhanden sind, in der Assoziation weiterlaufen. In diesem Beispiel ist Ctlr-B das einzige verbleibende Betriebsmittelobjekt. Daher wird der Zustand der Instanz von Ctlr-B 330 des Mandanten a verändert, um anzuzeigen, dass sie aktiv wird. Die vom HRM unternommenen Aktivitäten hinsichtlich des ersten mit Ctlr-B 330, R-a verbundenen Betriebsmittels sind die gleichen wie diejenigen, die vorstehend für R-e erörtert worden sind. In diesem Falle hat Ctlr-B jedoch ein zweites mit ihm verbundenes Betriebsmittel R-c. Der HRM markiert den Zustand der Instanz von R-c 340 des Mandanten a als aktiviert und fragt an, ob es eine weitere Instanz von Betriebsmittel R-c gibt, die aktiv ist. Bei diesem Betriebsmittel ist die Instanz 350 für Mandanten b schon aktiv. Daher markiert der HRM die Instanz für Mandant b als inaktiv und muss dann anfragen, ob Mandant b willens ist, das/die Betriebsmittel freizugeben. Mandant b kann entweder mit "wird freigegeben", "später", "wird entschieden" oder "nein" antworten. Wenn der Mandant willens ist, das/die Betriebsmittel freizugeben, muss er den derzeitigen Zustand des/der Betriebsmittel sichern. Wenn der derzeitige Mandant keine unmittelbare Freigabe erteilen kann, aber in der nahen Zukunft zur Freigabe in der Lage sein wird, antwortet er mit "später". Im Falle eines Mandanten, der nicht genug Informationen hat, um festzulegen, ob er eine Freigabe erteilen kann, antwortet der Mandant mit "wird entschieden", und ein anderer Teil des Systems nimmt die Entscheidung vor. Schließlich wird der Mandant, wenn das Betriebsmittel kritisch ist und nicht aufgegeben werden kann, mit "nein" antworten. In diesem Beispiel wird angenommen, dass Mandant b willens ist, Zugriff zu dem Betriebsmittel zu gewähren. Daher muss Mandant b immer den Zustand sichern, der für das Betriebsmittel von Bedeutung ist, und er muss annehmen, dass er nun keinerlei Zugriff zu dem Betriebsmittel mehr hat.
Fig. 4c veranschaulicht die Datenbank, nachdem Mandant b für Betriebsmittel R-c Zugriff gewährt hat, und sie wird dafür benutzt, die Schritte des HRM aufzuzeigen, nachdem dieser Vorgang abgelaufen ist. Nachdem der HRM benachrichtigt worden ist, dass Mandant b Zugriff zu dem Betriebsmittel gewährt hat, wird der Zustand der Instanz von Mandant a für R-c auf vollständig aktiv geändert. Der HRM würde nun für Mandant a zu anderen Betriebsmittelinstanzen von Ctlr-B fortschreiten. Da es keine Übrigbleibenden gibt, wird der HRM den Zustand der Instanz von Ctlr-B von Mandant a dahingehend modifizieren, dass sie vollständig aktiv ist. An diesem Punkt ist das Betriebsmittelobjekt Ctlr-B vollständig aktiv, und der HRM wird Mandanten a davon benachrichtigen, dass er vollständigen Zugriff auf alle Betriebsmittel in diesem Betriebsmittelobjekt hat. Zusätzlich kann, da es keine weiteren Betriebsmittelobjekte gibt, die mit der Gruppe verbunden sind, der Zustand der Instanz a der Gruppe auf aktiv verändert werden, und Mandant a wird davon benachrichtigt.
Der ursprüngliche Mandant, der ein Betriebsmittel benutzt, wird gewöhnlich freiwillig die restlichen Betriebsmittel freigeben, die mit dem Betriebsmittelobjekt verbunden sind, da er im allgemeinen an einer Anzahl von Betriebsmitteln interessiert ist und nicht an einem einzelnen bestimmten Betriebsmittel. Daher wird, wie in Fig. 4c gezeigt, die Instanz b von Ctlr-C 360 so eingestellt, dass sie inaktiv wird, und der HRM wird voranschreiten, die restlichen Instanzen zu deaktivieren, in denen Mandant b noch aktiv ist. Dann prüft der HRM entsprechend der Betriebsmittel- Objektinstanz für Ctlr-C von Mandant b jede der Betriebsmittelinstanzen, um festzustellen, ob irgendwelche aktiv sind. Jedes Mal, wenn der HRM auf eine aktive Instanz trifft, verändert der HRM den Zustand der Instanz so, dass sie inaktiv wird, und sendet dann an den Mandanten eine Freigabenachricht. Wie vorstehend erörtert, antwortet der Mandant, ob er willens ist, die Freigabe zu erteilen oder nicht. Angenommen, der Mandant erteilt die Freigabe, sichert der Mandant den verbleiben restlichen Zustand der Hardware, die durch das Betriebsmittel dargestellt wird, und antwortet dann dem HRM. Beim Empfang der Antwort verändert der HRM den Zustand der Instanz auf inaktiv. Der HRM läuft durch alle Betriebsmittel weiter, bis alle freigegeben sind, und dann verändert der HRM den Zustand der Betriebsmittel-Objektinstanz auf inaktiv. Abschließend benachrichtigt der HRM den Mandanten b, dass die Betriebsmittel-Objektinstanz freigegeben worden ist. Fig. 4d veranschaulicht die Datenbank, nachdem Mandant b den Zugriff auf alle Betriebsmittel freigegeben hat, auf die er Zugriff hatte.
Ein Busläufer ist ein Programm, das für das Laden der HRM- Datenbank auf eine vom System definierte Weise verantwortlich ist. Jeder Bus hat einen zugehörigen Busläufer, der seine Konfigurationsinformationen für das bestimmte System erhält.
Dieses System gestattet es, dass der HRM vollständig unabhängig von dem Verfahren ist, mit dem die Konfigurationsinformationen für jedes bestimmte System bereitgestellt wird. Der HRM muss nur die Einzelheiten für die Busse kennen, die er unterstützt.
Ein Beispiel für einige unterschiedliche Arten von Busläufern für einen Bustyp wird in Fig. 5 dargestellt. Dieses Beispiel zeigt den Bus auf der Rückwandplatine, welche der Anschlussbereich für die Mehrzahl der I/O-Betriebsmittel bei einem Rechnersystem ist. Dieser Bus hat üblicherweise Steckplätze, um Erweiterungs- oder Adapterkarten einzustecken. Zusätzlich schließt der Bus auf der Rückwandplatine auch I/O- Einheiten, die sich auf der Hauptplatine des Rechnersystems befinden.
In einigen Systemen, wie sie in Fig. 5 gezeigt werden, gibt es kein direktes Mittel zum Ermitteln der Hardware- Konfiguration 300. Daher müssen sich diese Systeme auf eine Datei mit Daten verlassen, die eine Darstellung der Hardware- Konfiguration enthält, oder sie müssen das I/O-Register nach einer Ermittlung abfragen, ob die Hardware vorhanden ist. Der Busläufer kann entweder eines oder beide Verfahren benutzen, um die HRM-Datenbank mit der aktuellen Hardware-Konfiguration zu laden.
In anderen Fällen hält das System die Hardware-Konfiguration in einem dauerhaften Mittel 320 fest, beispielsweise einem Speicher mit wahlfreiem Zugriff, der eine batteriegetriebene Sicherung hat. Diese Informationen sind jedoch gewöhnlich codiert und erfordern deshalb Hilfsdateien, um die Hardware- Konfiguration zu übersetzen. Diese Informationen können dann vom Busläufer benutzt werden, um die HRM-Datenbank zu laden.
Der HRM stellt die Schnittstelle zum Busläufer bereit, so dass der Busläufer die HRM-Datenbank laden kann. Das Busläufersystem isoliert jedoch den HRM von den Einzelheiten der Konfiguration eines einzelnen Systems. Daher wird der HRM eher einfacher an unterschiedliche Systemkonfigurationen und -arten angeschlossen.
Obgleich die Erfindung in Begriffen einer einzelnen bevorzugten Ausführungsform beschrieben worden ist, wird der Fachmann erkennen, dass die Erfindung innerhalb des Umfanges der anhängenden Ansprüche mit Veränderung ausgeführt werden kann.

Claims

1. Hardware-Betriebsmittelverwalter zum Verwalten von Pfadinformation von Eingabe-/Ausgabe(I/O)-Betriebsmitteln, um es Gerätetreibern zu ermöglichen, auf physische Hardware-Betriebsmittel eines Rechnersystems zuzugreifen, der das Folgende umfasst:

eine Datenbank von I/O-Betriebsmitteln, auf die von Gerätetreibern zugegriffen werden kann und die Information enthält, welche die Pfade der Eingabe-/Ausgabe- Betriebsmittel definiert, wobei die Datenbankinformation kennzeichnet, welche Betriebsmittel im System vorhanden sind und welche Betriebsmittel im System derzeit benutzt werden, wobei die Datenbankinformation physische Hardware- Betriebsmittel vom gleichem Typ (60,70) logisch verknüpft;

Mittel zum dynamischen Aktualisieren der Pfadinformation der Eingabe-/Ausgabebetriebsmittel in der Datenbank, um es zu ermöglichen, dass dem Hardware-Betriebsmittelverwalter neue Geräte hinzugefügt werden; und

Mittel zum Verfolgen und Zuordnen von Betriebsmitteln, um zu ermöglichen, dass mehrere Gerätetreiber eine gleiche physische Gruppe von Hardware-Betriebsmitteln gemeinsam nutzen, wobei der Hardware-Betriebsmittelverwalter einem oder mehreren Gerätetreibern Pfadinformation der Eingabe-/ Ausgabebetriebsmittel bereitstellt.

2. Hardware-Betriebsmittelverwalter nach Anspruch 1, bei dem der Hardware-Betriebsmittelverwalter eine Sammlung von Rechnerprogrammen enthält, bei denen eines der Rechnerprogramme für jede Art von Pfad eines Eingabe-/ Ausgabebetriebsmittels Information über die Hardwarekonfiguration ergibt.

3. Hardware-Betriebsmittelverwalter nach Anspruch 1 oder Anspruch 2, wobei das Mittel zum Verfolgen und Zuordnen ein Gewährungs-/Abtretungsprotokoll (Fig. 4a bis 4d) einrichtet, in dem die Pfade der Eingabe-/ Ausgabebetriebsmittel zwischen einer Vielzahl von Gerätetreibern angeordnet und zugeordnet werden können.

4. Hardware-Betriebsmittelverwalter nach Anspruch 3, wobei das Mittel zum Verfolgen und Zuordnen das Folgende umfasst:

Mittel, die auf einen ersten Gerätetreiber reagieren, der einen der Pfade der Eingabe-/Ausgabebetriebsmittel anfordert;

Mittel, die feststellen, ob der eine der Pfade der Eingabe-/Ausgabebetriebsmittel derzeit von einem zweiten Gerätetreiber benutzt wird; und

Mittel, die auf das Feststellmittel zum Zuordnen eines der Pfade der Eingabe-/Ausgabebetriebsmittel zu dem ersten Gerätetreiber reagieren, wenn der Betriebsmittelpfad derzeit nicht von einem zweiten Gerätetreiber benutzt wird, und die den zweiten Gerätetreiber abfragen, ob er den Pfad des Eingabe-/Ausgabebetriebsmittels freigeben will, wenn der Betriebsmittelpfad derzeit in Gebrauch ist, und die den ersten Gerätetreiber davon benachrichtigen, ob er auf den Pfad des Eingabe-/Ausgabebetriebsmittels zugreifen kann.

5. Verfahren, das durch einen Hardware- Betriebsmittelverwalter zum Verwalten von Pfadinformation von Eingabe-/Ausgabe(I/O)-Betriebsmitteln eingerichtet wird, um es Gerätetreibern zu ermöglichen, auf physische Hardware-Betriebsmittel eines Rechnersystems zuzugreifen, das die folgenden Schritte umfasst:

Definieren von Information in einer Datenbank über Pfade von Eingabe-/Ausgabetriebsmitteln, wobei auf die Datenbankinformation durch Gerätetreiber zugegriffen werden kann und gekennzeichnet wird, welche Betriebsmittel in dem System vorhanden sind und welche Betriebsmittel derzeit im System benutzt werden, wobei die Datenbankinformation physische Hardware-Betriebsmittel des gleichen Typs (60, 70) logisch verknüpft;

dynamisches Aktualisieren von Pfadinformation von Eingabe-/Ausgabebetriebsmitteln in der Datenbank, um es zu ermöglichen, dass dem Hardware-Betriebsmittelverwalter neue Geräte hinzugefügt werden; und

Verfolgen und Zuordnen von Betriebsmitteln, um es zu ermöglichen, dass mehrere Gerätetreiber eine gleiche physische Gruppe von Hardware-Betriebsmitteln gemeinsam nutzen und Bereitstellen von Pfadinformation von Eingabe-/ Ausgabebetriebsmitteln an einen oder mehrere Gerätetreiber.

6. Verfahren nach Anspruch 5, bei dem der Schritt des Definierens von Information den Gebrauch eines oder mehrerer Rechnerprogramme enthält, wobei eines der Rechnerprogramme für jeden Typ von Eingabe-/ Ausgabebetriebsmittel Information über die Hardwarekonfiguration ergibt.

7. Verfahren nach Anspruch 5 oder Anspruch 6, wobei der Schritt des Verfolgens und Zuordnens den Schritt des Einrichtens eines Gewährungs-/Abtretungsprotokolls (Fig. 4a bis 4d) enthält, in dem die Pfade der Eingabe-/ Ausgabebetriebsmittel zwischen einer Vielzahl von Gerätetreibern angefordert und zugeordnet werden können.

8. Verfahren nach Anspruch 7, wobei das Gewährungs-/ Abtretungsprotokoll (Fig. 4a bis 4d), das durch den Schritt des Verfolgens und Zuordnens der Pfade der Eingabe-/Ausgabebetriebsmittel eingerichtet wird, folgende Schritte umfasst:

durch einen ersten Gerätetreiber Anfordern eines der Pfade der Eingabe-/Ausgabebetriebsmittel;

Feststellen, ob der eine Pfad der Eingabe-/ Ausgabebetriebsmittel derzeit durch einen zweiten Gerätetreiber in Gebrauch ist; und

Benutzen der Ergebnisse des Feststellungsschrittes zum Zuordnen eines der Pfade der Eingabe-/ Ausgabebetriebsmittel zu dem ersten Gerätetreiber, wenn der Betriebsmittelpfad derzeit nicht von dem zweiten Gerätetreiber benutzt wird, oder den zweiten Gerätetreiber abfragen, ob er den Eingabe-/Ausgabepfad freigeben will, wenn das Betriebsmittel derzeit in Gebrauch ist und Benutzen der Ergebnisse der Abfrage, um den ersten Gerätetreiber zu benachrichtigen, ob er auf den Pfad des Eingabe-/Ausgabebetriebsmittels zugreifen kann.