DE69903629T2 - Prüfung der funktionsfähigkeit eines gerätetreibers - Google Patents

Description

HINTERGRUND DER ERFINDUNG
• Die vorliegende Erfindung bezieht sich auf das Testen von Gerätetreibern und insbesondere auf das Testen des Härtens von Gerätetreibern.
• Die europäische Patentanmeldung EP-A-0 558 865 beschreibt ein Diagnosesystem eines Multimedia-Computersystems für die Fehlerisolation in einer harten Realzeitumgebung mit mehreren Aufgaben bzw. Zwecken. Harte Vorgänge in Realzeit mit mehreren Aufgaben bzw. Zwecken, insbesondere diejenigen, die für Signalverarbeitungsaufgaben einzigartig sind, können überwacht werden, ohne eine Überlast der Aufgabenverarbeitung zu erzeugen und ohne die Ergebnisse über harte Zeitbegrenzungen der Realzeitaufgaben hinaus zu verzögern, indem ein Verzweigungsbefehl in die Ausführungsanweisungen der Aufgabe eingefügt wird, welche untersucht werden, was bewirkt, daß die Aufgabe sich zu einem diagnostischen Programm hin verzweigt. Das Diagnoseprogramm führt einen Diagnosebefehlssatz aus und fängt einen oder mehrere digitale Abtast- bzw. Probewerte ein, die für den Betrieb der harten Realzeitaufgabe charakteristisch sind, und zwar in dem Punkt in seiner Programmausführung, wo die Verzweigungsanweisung lokalisiert ist. Die digitalen Datenprobewerte, die auf diese Weise erhalten wurden, können in einer Schlange angeordnet werden und graphisch auf dem Bildschirm einer Anzeige gezeichnet werden, welche zu dem Computersystem gehört, um eine graphische Wiedergabe der Leistungsfähigkeit des Algorithmus oder der Signalverarbeitungsaufgabe zu erzeugen, die gerade untersucht wird, um Aufgaben-Mehrfachfunktionen schnell zu isolieren, ohne eine große Menge digitaler Datenprobewerte zu durchsuchen. Alternativ können vorab ausgewählte Probewerte in die Aufgabenausführung eingefügt werden, indem Aufgabenregister mit vorbestimmten Daten geladen werden, indem eine Verzweigung zu einer Diagnosefunktion ausgeführt wird, welche die Probewerte einfügt.
• Traditionelle Gerätetreiber sind mit Betonung auf guter Leistungsfähigkeit und dem korrekten Betrieb bei Abwesenheit von Fehlern geschrieben worden. Wenn man Anleitungen und Trainingsmaterial für das Schreiben von Treibern betrachtet, so findet man wenig (wenn überhaupt) Erwähnung, wie mit fehlerhaften Hardwaregeräten umzugehen ist. Ein fehlerhaftes Gerät kann oft einen Absturz des Systems verursachen und tut dies auch oft. Im Ergebnis kann eine PCI-Karte für $ 50,-- einen Server im Wert von o$ 500.000,-- zerstören.
• Ein Standardansatz zur Verbesserung der Systemverfügbarkeit in Anbetracht von I/O- Fehlern besteht darin, daß man das System abstürzen läßt, dann erneut hochfährt und das fehlerhafte Gerät aus der Konfiguration des Systems heraus entfernt. Dies gilt nicht immer, ist jedoch ein akzeptabler Ansatz.
• Ein wesentlich besserer Ansatz besteht darin, Treiber zu modifizieren, so daß sie I/O-Fehler überleben und die Treiber neu konfigurieren, ohne daß ein neues Herauffahren erforderlich ist. Ein Gerätetreiber, der dafür ausgelegt worden ist, gegen derartige Fehler nachgiebig zu sein bzw. diese aufzufangen, wird als ein "gehärteter Treiber" bezeichnet. Ein gehärteter Gerätetreiber wird definiert als ein Gerätetreiber mit minimalem Potential an Beeinträchtigung der Integrität des Systems, von welchem er einen Teil darstellt.
• Die Techniken des Härtens von Treibern haben das Potential, in hohem Maße zu der Zuverlässigkeit, Verfügbarkeit und Wartungsfähigkeit bzw. Bedienbarkeit des Systems (RAS) beizutragen. Gehärtete Gerätetreiber vermindern das Potential, daß fehlerhafte Geräte einen vollständig zerstörerischen Systemverlust verursachen. Die fehlerhafte Komponente kann dann als Teil einer planmäßigen Wartung ersetzt werden. Um auf diese Weise einen Gerätetreiber zu härten, muß ein Entwickler die vielfältigen Folgen bedenken, die eine fehlerhafte Hardware für deren Code haben kann.
• Die Philosophie hinter einer erfolgreichen Härtung von Treibern ist die einer totalen Paranoia. Ein fehlerhaftes Gerät kann man sich vorstellen als eines, welches einen bösartigen Saboteur enthält, dessen Ziel darin besteht, das Serversystem, von welchem er ein Teil ist, vollständig zu zerstören. Es kann dieses in einem Bereich von abwegigen bzw. verschlagenen und erfindungsreichen Wegen versuchen. Es kann sich weigern, auf Zugriffe zu reagieren, um so Aussetzungsausnahmen des Busses zu bewirken. Es kann versuchen, einen Prozessor mit der Bearbeitung bzw. Bedienung von Scherzunterbrechungen vollständig zu absorbieren. Es kann versuchen, dem Systemkern vorzuspiegeln, daß eine Selbstmordaktion vorgenommen wird. Es kann einfach in den Ruhezustand gehen und wesentliche Dienste zurückhalten. Es kann die Daten, die es liefert, verfälschen.
• Der gehärtete Treiber muß die Fähigkeit haben, einen Fehler schnell zu identifizieren und einzugrenzen. Eine schnelle Erfassung ist notwendig, wenn die Folgen eines Gerätefehlers unter Kontrolle bleiben sollen. Die Bewahrung der Systemintegrität erfordert, daß Fehler erfaßt werden, bevor sie den Systemzustand in unkontrollierbarer Weise verändern. Konsequenterweise müssen Schritte unternommen werden, um Überprüfungen auf Fehler vorzunehmen, wann immer von dem Gerät zurückgelieferte Daten durch das System verwendet werden sollen.
• Wie bei irgendeinem anderen Aspekt eines Computersystems ist es wünschenswert, in der Lage zu sein, einen Gerätetreiber zu testen und insbesondere das Härten eines Gerätetreibers, um mit Fehlern umzugehen, die der Gerätetreiber in einem Computersystem bewältigen muß. Das Härten von Gerätetreibern kann bis zu einem gewissen Grad getestet werden, indem das System und die Gerätehardware physikalisch modifiziert werden, um das Eindringen der Fehler zu ermöglichen, die man zu testen wünscht. Dies ist jedoch eine teure und zeitraubende Aufgabe und mag letzten Endes nur eine begrenzte Fähigkeit liefern, mögliche Fehler zu testen.
• Dementsprechend besteht ein Ziel der vorliegenden Erfindung darin, ein effizienteres Testen dahingehend bereitzustellen, daß Gerätetreiber korrekt und gründlich gehärtet worden sind.
ZUSAMMENFASSUNG DER ERFINDUNG
• Gemäß einem ersten Aspekt der Erfindung wird ein Testmechanismus bereitgestellt für das Testen bzw. Überprüfen der Härtung von Gerätetreibern, wobei der Testmechanismus einen Abfangmechanismus aufweist, der so betreibbar ist, daß er Aufrufe für einen Gerätezugriff von einem Gerätetreiber, der sich in der Überprüfung befindet, abfängt, und eine Schnittstelle aufweist, die so betreibbar ist, daß sie den Abfangmechanismus so konfiguriert, daß er entsprechend einem bestimmten Testmuster in Reaktion auf die Aufrufe für einen Gerätezugriff Fehler injiziert werden.
• Gemäß einer Ausführungsform stellt die Erfindung einen Testmechanismus für gehärtete Treiber bereit. Dieser Testmechanismus stellt ein Gerüst bzw. Geschirr bereit, welches die willkürliche Einführung typischer Fehler ermöglicht. Diese Fehler können vollständig asynchron eingeführt werden, um die tatsächlichen Bedingungen wiederzuspiegeln.
• Der Abfangmechanismus kann ein Testmodul aufweisen, welches in das Betriebssystem geladen werden kann. Wenn das Testmodul geladen ist, so kann es alle Gerätezugriffsaufrufe abfangen. Er ahmt die normalen Funktionen dieser Aufrufe nach, greift auf die versetzte bzw. verschobene Adresse zu und leitet die passenden Daten weiter. Dieses Testmodul kann einen Testtreiber und eine Mehrzahl von Abfangroutinen aufweisen. Die Schnittstelle kann in Form einer programmierbaren Schnittstelle (API) vorliegen, die es ermöglicht, daß Benutzertestanwendungen Information für den Treiber zuführen, um die Abfangroutinen zu konfigurieren, um eine spezielle Verfälschung von Daten bereitzustellen, die durch diese Gerätezugriffe erhalten werden.
• Die Gerätezugriffsaufrufe werden umgeleitet bzw. zugeordnet zu den Abfangroutinen durch eine Infrastruktur des Gerätezugriffs. Diese Umlenkung/Zuordnung könnte erreicht werden unter Verwendung einer Nachschlagetabelle. Alternativ können auch andere als Umlenk- /Zuordnungsmechanismen verwendet werden.
• Die Infrastruktur des Gerätezugriffs eines Schnittstellenmechanismus eines Gerätetreibers kann auf eine Zugriffsanforderung der Schnittstelle des Gerätetreibers reagieren, um die Anforderung nach selektiver Einfügung von Fehlern abzufangen, wodurch der nachfolgende Ruf nach einem Gerätetreiberzugriff einen Gerätezugriff bewirkt mit der Ausführung eines zusätzlichen, vorher spezifizierten logischen/arithmetischen Vorganges mit den so erhaltenen Daten oder keinen Gerätezugriff bewirkt, sondern stattdessen die Rückgabe einer emulierten Gerätereaktion.
• Eine Ausführungsform der Erfindung überwindet das Problem, daß es normalerweise nicht möglich ist, einen ausreichenden Zugriff auf die Hardwareausgestaltung eines Gerätes zu haben, um in der Lage sein zu können, einen geeignet variablen Fehlerbereich einzufügen. Moderne Gerätetreiber greifen auf Hardware über einen Satz spezieller Funktionen zu. Die Verwendung dieser Funktionen mit einem konformen Treiber kann den Aufbau eines Testmechanismus für einen gehärteten Treiber erleichtern.
• Der vorliegende Testmechanismus ermöglicht es einem Testingenieur, eine Bezugnahme auf (beispielsweise) ein spezielles Gerät zu spezifizieren, einen speziellen Registersatz auf dem Gerät, einen Verschiebungsbereich, einen Datenmaskenwert, einen logischen/arithmetischen Operator (gleich, NOT, AND, OR, XOR, +, -) und eine Zugriffszählung. Abfangroutinen überprüfen dann jede Verwendung der Gerätezugriffsaufrufe durch die Gerätetreiberschnittstelle, um zu erkennen, ob sie sich innerhalb der spezifizierten Parameter befindet. Eine Zählung bzw. Zahl wird bei jedem Auftreten eines Zusammenpassens herabgezählt. Sobald die Zählung beendet (auf null herabgezählt) ist, können die gelesenen Daten durch einen zuvor spezifizierten Operator und Operanden bearbeitet werden. Dies ermöglicht, daß ein Testmechanismus einen weiten Bereich unterschiedlicher Fehler einführt. Gemäß einem anderen Aspekt der Erfindung wird ein Computerprogrammprodukt auf einem Trägermedium bereitgestellt, wobei das Computerprogrammprodukt einen Testmechanismus aufweist, wie er oben beschrieben wurde.
• Gemäß einem weiteren Aspekt der Erfindung wird eine Testanwendung auf einem Trägermedium für einen Testmechanismus bereitgestellt, wie er oben beschrieben wurde. Die Testanwendung weist Computercode auf, der so ausgestaltet ist, daß er in der Weise betreibbar ist, daß er den Testmechanismus mit einer Testkonfiguration versieht, um die Reaktion eines Treibers auf einen Testzustand zu erfassen, welcher durch den Testmechanismus eingefügt wird, um die erfaßte Reaktion mit einer erwarteten Reaktion zu vergleichen, die in einem Testskriptum dargelegt ist, und Unterschiede bzw. Diskrepanzen zwischen der erfaßten Reaktion und der erwarteten Reaktion zu bestimmen bzw. zu identifizieren. Die Testanwendung kann auch so betreibbar sein, daß sie einen Eintrag der erfaßten Reaktionen beibehält.
• Gemäß einem weiteren Aspekt der Erfindung wird ein Computer bereitgestellt, der einen Prozessor, einen Speicher, einen I/O-Buscontroller, zumindest eine I/O-Einrichtung, einen Gerätetreiber für den Zugriff auf die I/O-Einrichtung und einen Testmechanismus aufweist, wie er oben beschrieben wurde.
• Gemäß einem weiteren Aspekt der Erfindung wird ein Verfahren zum Testen des Härtens eines Gerätetreibers bereitgestellt, wobei das Verfahren das Abfangen von Zugriffsaufrufen auf einen Gerätetreiber von dem Gerätetreiber und das Injizieren bzw. Einfügen eines Fehlers in den Zugriff eines Gerätetreibers aufweist, und zwar entsprechend einem gewünschten Testmuster.
KURZE BESCHREIBUNG DER FIGUREN
• Beispielhafte Ausführungsformen der vorliegenden Erfindung werden nachstehend beschrieben, und zwar lediglich anhand von Beispielen, unter Bezug auf die beigefügten Figuren, in denen gleiche Bezugszeichen sich auf gleiche Elemente beziehen und von denen:
• Fig. 1 ein schematisches Blockdiagramm einer Busstruktur für ein Verarbeitungssystem ist,
• Fig. 2 eine Konfigurationsdatei für das System nach Fig. 1 veranschaulicht,
• Fig. 3 eine schematische Wiedergabe einer I/O-Karte ist,
• Fig. 4 eine schematische Wiedergabe von Software- und Hardwareelementen des Systems eines Prozessors nach Fig. 1 ist,
• Fig. 5 ein schematisches Blockdiagramm eines Teiles eines Testmechanismus für einen Gerätetreiber gemäß einer Ausführungsform der Erfindung ist,
• Fig. 6 ein schematisches Diagramm ist, welches den Betrieb der Anordnung nach Fig. 5 zeigt,
• Fig. 7 ein Flußdiagramm des Betriebes der Anordnung nach Fig. 6 ist, und
• Fig. 8 ein Flußdiagramm der Anwendung einer Benutzeranwendung ist.
BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
• Eine Ausführungsform der vorliegenden Erfindung wird im Kontext eines lokalen peripheren Komponentenverbindungsbusses (PCI-Bus) beschrieben. Es versteht sich, daß die Anwendung einer Ausführungsform der Erfindung nicht auf eine lokale PCI-Busarchitektur beschränkt ist, sondern auch mit anderen Busarchitekturen verwendet werden könnte.
• Fig. 1 ist eine schematische Übersicht eines Computersystems mit einem lokalen PCI- Bussystem. Ein PCI-Bus ist üblicherweise auf der Hauptplatine eines Computersystems angelegt. Wie in Fig. 1 dargestellt, werden ein Prozessor 12, ein Hauptspeicher 14 und ein PCI-Bus 20 über eine PCI-Host-Brücke 16 miteinander verbunden. Durch eine Kaskade von PCI-Busbrücken (von denen hier nur eine PCI-Busbrücke 26 dargestellt ist) wird eine Baumstruktur von miteinander verbundenen I/O-Bussen unterstützt. Mit anderen Worten, untergeordnete PCI-Busbrücken können unterhalb der PCI-Host-Brücke 16 ergänzt bzw. erweitert werden, um zu ermöglichen, daß ein einzelnes Bussystem zu einem komplexen System mit mehreren sekundären Bussen, wie z. B. dem sekundären Bus 30, erweitert wird. PCI-Geräte können mit einem dieser sekundären Busse 30 verbunden werden (z. B. einer Schnittstelle eines Kleincomputersystems (SCSI) 28), ebenso wie mit dem Haupt-PCI-Bus (z. B. ein Grafikadapter 22 und ein Adapter 24 für ein lokales Bereichsnetzwerk (Local Area Network - LAN)). Ebenso wie die oben erwähnten Eigenschaften kann das Computersystem andere typische Elemente eines Computersystems aufweisen, einschließlich einer Anzeige 23 und Dateneingabeeinrichtungen, wie z. B. einer Tastatur etc. (nicht dargestellt).
• Jedes PCI-Gerät hat eine eindeutige Anbieterkennung (Anbieter-ID) und eine Geräte-ID. Mehrere Geräte derselben Art werden weiterhin identifiziert durch eine eindeutige Gerätenummer auf dem Bus, auf welchem sie angelegt sind. Typische PCI-Geräte umfassen SCSI-Adapter, Grafik- und/oder Anzeigeadapter, Netzwerkcontroller etc. (beispielsweise den Grafikadapter 22, den Adapter 24 für das lokale Netzwerk (LAN) und den SCSI-Adapter 28, die in Fig. 1 dargestellt sind).
• Die PCI-Host-Brücke 16 stellt eine Verbindung zwischen dem Prozessor 12 und den peripheren Komponenten, wie z. B. den Geräten 22, 24, 28 her. Durch die PCI-Host-Brücke 16 kann der Prozessor direkt auf den Hauptspeicher 14 zugreifen, und zwar unabhängig von anderen PCI- Bussteuerungen bzw. -Mastern. Die PCI-Host-Brücke 16 stellt auch Zuordnungen für den Datenzugriff zwischen dem Prozessor 12 und den peripheren I/O-Geräten bereit, wie z. B. den Geräten 22, 24 und 28. Sie ordnen jedes periphere Gerät zu der Domäne der Hostadresse zu, so daß der Prozessor auf das Gerät durch über den Speicher zugeordnete I/O- oder spezielle I/O-Anweisungen zugreifen kann. Die PCI-Host-Brücke 16 kann den Systemspeicher 14 innerhalb einer Hostadreßdomäne 34 einer PCI-Adreßdomäne 36 zuordnen, so daß ein PCI-Gerät, wie z. B. die Geräte 22, 24, 26 und 28 als ein Busmaster auf den Hauptspeicher 14 zugreifen können.
• Der Konfigurationsadreßraum innerhalb der PCI-Domäne wird graphisch definiert. Mit anderen Worten, die Zuordnung eines peripheren Gerätes wird bestimmt durch seine physikalische Position innerhalb eines Verbindungsbaumes der PCI-Busbrücken. Ein Gerät wird üblicherweise durch seine Busnummer und eine Geräte-(Slot-)Nummer gekennzeichnet. Jedes periphere Gerät enthält einen Satz von vordefinierten Konfigurationsregistern in seinem PCI-Konfigurationsraum bzw. - Speicherplatz. Die Register werden nicht nur verwendet, um Geräte zu identifizieren, sondern auch, um die Gerätekonfiguration durch Systemsoftware aufzuteilen. Beispielsweise müssen die Basisadreßregister in dem Gerätekonfigurationsraum zugeordnet werden, bevor ein Gerät auf einen Datenzugriff reagieren kann.
• Ein Beispiel eines Formates für die Konfigurationsregister ist in Fig. 2 dargestellt. Der Adreßraum 34 ist zwischen I/O-Adressen 36, Speicheradressen 37 und Konfigurationsadressen 38 aufgeteilt, wobei ein spezifisches Beispiel eines Konfigurationsraumregisters 40 genauer wiedergegeben ist. Wie in Fig. 2 dargestellt, enthalten die Konfigurationsregister eine Geräte-ID 42, eine Anbieter-ID 44, Status- und Befehlsinformation 46 und 48, einen Klassencode 50, einen Satz von Basisadressen 52, Information 54 über die Erweiterung der ROM-Basis, und eine Kennung 56 für einen Interruptanschluß und eine Kennung 58 für eine Interruptleitung.
• Das tatsächliche Verfahren zum Erzeugen von Konfigurationszyklen ist von dem Host abhängig. In Prozessoren vom x86-Typ werden spezielle I/O-Ports verwendet. Bei anderen Befehlssatzarchitekturen kann der PCI-Konfigurationsraum über einen Speicher bestimmten Adreßpositionen zugeordnet werden, welche der PCI-Host-Brücke 16 in der Host-Adreßdomäne 34 entsprechen. Wenn durch den Prozessor 12 auf das Gerätekonfigurationsregister 40 zugegriffen wird, so wird die Anforderung dann zu der PCI-Host-Brücke 16 geleitet. Die PCI-Host-Brücke 16 übersetzt dann den Zugriff in passende Konfigurationszyklen auf den Bus 20.
• Prozessoren mit speziellen I/O-Anweisungen, wie z. B. die Prozessorfamilie x86, greifen auf die I/O mit "In"- und "Aus"-Befehlen zu. Maschinen ohne spezielle I/O-Anweisungen sind üblicherweise über einen Speicher den Adreßpositionen zugeordnet, welche der PCI-Host-Brücke in der Hostadreßdomäne entsprechen. Wenn der Prozessor 12 auf die über den Speicher zugeordneten Adressen zugreift, wird die I/O-Anforderung an die PCI-Host-Brücke gesendet. Sie übersetzt dann die Adressen in I/O-Zyklen und gibt sie auf den PCI-Bus 20. Speicherzugeordnete I/O (Eingabe/Ausgabe) wird durch die ursprünglichen bzw. natürlichen Lade-/Speicherbefehle des Prozessors durchgeführt. Beispielsweise kann das Lesen aus oder das Schreiben in ein über den Speicher zugeordnetes Datenregister durch einen Lade- oder Speicherbefehl an die I/O-Adresse dieses Registers erfolgen.
• I/O-Gerätekomponenten können wiedergegeben werden durch ein unabhängiges Geräteinformationsparadigma (Musterbeispiel). Ein "Name.Wert"- (name.value-) Mutationspaar, welches Eigentum genannt wird, wird verwendet. Beispielsweise wird ein "reg"-Eigentum verwendet, um Geräteregister und Speicher auf der Platine zu repräsentieren.
• Fig. 3 ist eine schematische Wiedergabe einer PCI-I/O-Gerätekarte 60 mit Registern (regs) 62 und Speicher (RAM) 64. Andere Komponenten werden selbstverständlich auf der Gerätekarte bereitgestellt, je nach der Art der Karte, sind jedoch aus Gründen der Klarheit der Erläuterung nicht dargestellt. Der Kartenanschluß 66 ist mit einem Interruptstift 68 versehen. Dementsprechend codiert der reg-Eigentumswert das Geräteregister, die Adresse und Größe. Demnach kann beispielsweise reg = DD,addr1,size1 die Adresse und Größe der Register 62 und reg = DD,addr2,size2 die Adresse und Größe des Speichers 64 in dem I/O-Gerät repräsentieren. Ein "Interrupt"-Eigentum bzw. eine "Interrupt"-Eigenschaft kann verwendet werden, um den Interruptstift 68 des Gerätes zu repräsentieren (beispielsweise Interrupt = a).
• Die PCI-Busanbindung erweitert das Paradigma der Standardgeräteinformation für den lokalen PCI-Bus. PCI-Eigenschaften werden entsprechend der lokalen PCI-Busspezifikation definiert. Beispielsweise umfaßt die "reg"-Eigenschaft eine Sequenz von physikalischen Adreß-, Größe- Paaren. Der Wert jedes Paares besteht aus fünf Zellen und gibt eine Adreßposition und die Größe innerhalb der PCI-Adreßdomäne wieder. Die verschiedenen Eigenschaften in den Adreßkonfigurationsregistern werden gemäß standardmäßigen PCI-Techniken bereitgestellt, wie es sich für die Fachleute versteht.
• Es gibt viele detaillierte Unterschiede zwischen verschiedenen Systemen für PCI- Implementierungen. Dementsprechend ist für die Definition von Gerätetreibern, die in verschiedene Umgebungen transportiert werden können, eine flexible Struktur erforderlich.
• Fig. 4 ist eine schematische Übersicht einer Gerätetreiberimplementierung, die eine Flexibilität gewährleistet. Fig. 4 gibt das Interface zwischen der Prozessorhardware 70, dem Betriebssystem 72 und einer Anwendung 74 wieder. Eine Hardwareschnittstelle 76 stellt Lade- /Speicherfunktionen auf niedrigem Niveau an der Schnittstelle zwischen dem Betriebssystem 72 und der Hardware 70 bereit. Eine Schnittstelle für Anwendungsprogrammierung (API) 80 stellt eine Schnittstelle auf hohem Niveau für Anwenderprogramme bereit. Zwischen der Hardwareschnittstelle 76 und der API 80 findet man logisch lokalisiert den Hauptteil 78 der Betriebssystemkomponenten. In das Niveau bzw. die Ebene des Hauptteiles der Betriebssystemkomponenten ist eine Gerätetreiberdomäne 82 einbezogen, die eine oder mehrere Gerätetreiber 84 aufweist. Zwischen den Gerätetreibern und der Hardwareschnittstelle ist ein Schnittstellenmechanismus 88 der Gerätetreiber vorgesehen, welcher eine Infrastruktur 90 für den Gerätezugriff und busspezifische Gerätezugriffsroutinen 92 umfaßt, die es ermöglichen, daß die übertragbaren (busunabhängigen) Gerätetreiber 84 auf die betreffenden Geräte zugreifen.
• Ein Gerätetreiber 84 definiert die Eigenschaften und Zugriffsattribute eines Datenobjektes durch eine Datenstruktur, die Gerätezugriffsattribute 86 genannt werden. Die Datenobjekte können Geräteobjekte, wie z. B. ein Geräteregister/-speicher, oder ein DMA-fähiges Speicherobjekt sein, wie z. B. ein Ethernet-Ringpuffer oder ein Befehlssteuerblock eines SCSI-Adapters. Die Gerätezugriffsattribute werden in Byteordnungsanzeigen und Datenordnungsattribute aufgetrennt. Der Gerätetreiber 84 gibt das Byteordnungsformat seiner Gerätedatenstruktur an unter Verwendung der Anzeigen der Gerätezugriffsattribute 86, und spezifiziert die Datenordnungseigenschaften gemäß den Datenordnungsattributen. Der Gerätetreiber 84 ist so betreibbar, daß er eine Zugriffsanforderung 91 einer Gerätetreiberschnittstelle für den Schnittstellenmechanismus des Gerätetreibers erstellt.
• Der Schnittstellenmechanismus 88 des Gerätetreibers umfaßt eine Infrastruktur 90 des Gerätezugriffs, die auf den Gerätetreiber 84 und auch auf busspezifische Gerätezugriffsroutinen bzw.- unterprogramme 92 reagiert, um einen Gerätezugriff innerhalb der Betriebsumgebung des betreffenden Computersystems zu definieren. Die Infrastruktur 90 des Gerätezugriffs ist so betreibbar, daß sie auf Gerätezugriffsanforderungen 91 reagiert, die dem Schnittstellenmechanismus 88 des Gerätetreibers zugeführt werden, um einen Gerätezugriffsaufruf 93 an eine oder mehrere geeignete busspezifische Gerätezugriffsroutinen 92 zu machen bzw. auszuführen, um den Gerätezugriffsbetrieb zu handhaben. Dies kann dadurch erreicht werden, daß die Infrastruktur 90 des Gerätezugriffs eine Tabelle umfaßt, die auf eine Gerätezugriffsanforderung 91 reagiert, um die passende busspezifische Gerätezugriffsroutine(n) 92 für die Handhabung der Anforderung 91 zu identifizieren. Die busspezifischen Gerätezugriffsroutinen 92 definieren die Funktionalität für die Schnittstellenbildung zwischen einem übertragbaren Gerätetreiber 84 und der Hardware des Computersystems. Dementsprechend müssen die Gerätetreiber keine Kenntnis von Hardwarefaktoren, wie z. B. Anordnungsreihenfolge (Endianness) (Byteaustausch), Datenordnung, Gerätezugriffsraum, Zuordnung des direkten Speicherzugriffs (DMA) und Eigenschafts- bzw. Besitzdatentypen zu haben.
• Eine Ausführungsform der Erfindung verwendet den Schnittstellenmechanismus 88 des Gerätetreibers, um Gerätezugriffsaufrufe 93 an die busspezifischen Gerätezugriffsroutinen 92 abzufangen, um einen fehlerhafte Hardware zu simulieren. Kommunikationen zwischen der Infrastruktur 90 des Gerätezugriffs und den Gerätezugriffsroutinen können dadurch über ein Testgeschirr bzw. eine Testeinrichtung in Form eines Testmoduls aufgeteilt werden, damit auf dieser Ebene Fehler eingeführt bzw. injiziert werden können. Dies hat den Vorteil der einfacheren Verfügbarkeit als im Falle von Hardwaretechniken. Der modifizierte Gerätezugriffsmechanismus ermöglicht eine deterministische Fehlereinfügung, um so den Test wiederholbar zu machen.
• Der Testmechanismus einer Ausführungsform der Erfindung kann verwendet werden, um eine Vielfalt von "zufälligen" Fehlern zu indizieren, so daß eine unabhängige Systemtestgruppe einen Zuverlässigkeitstest ausführen kann, daß der Treiber gehärtet ist. Diese Fehler können vollständig asynchron eingeführt werden und so die reale Situation emulieren bzw. abbilden. Ein geeigneter breiter Bereich unterschiedlicher Typen von "typischen" Hardwarefehlern kann in einer kontrollierten und wiederholbaren Art und Weise injiziert werden, was typischerweise nicht möglich ist, indem man die Hardwaregerätetreiber modifiziert.
• Eine Ausführungsform eines Testmechanismus, die auch als ein Testgeschirr bzw. eine Teststruktur zur Fehlerinjektion beschrieben werden kann, arbeitet gemäß der Erfindung durch Abfangen von Gerätezugriffsvorgängen an der Infrastruktur 90 des Gerätezugriffs, und verfälscht dann das Ergebnis der Aufrufe für die busspezifische Gerätezugriffsroutine, als wenn die Hardware die Verfälschung verursacht hätte. Der Testmechanismus kann auch dafür ausgelegt werden, zu erfassen, ob Routinen bzw. Unterprogrammaufrufe ausgeführt werde, die nicht über die Zugriffssteuerung hindurchlaufen (das heißt über Speicher zugeordneter externer Zugriff durch direkten Zeigerbezug, eine Praxis, die inzwischen abgelehnt wird).
• Dementsprechend ist Fig. 5 eine schematische Übersicht einer Erweiterung einer Struktur nach Fig. 4, um einen Testmechanismus gemäß einer Ausführungsform der vorliegenden Erfindung bereitzustellen. In der Struktur nach Fig. 5 wird zusätzlich zu den bereits in Fig. 4, welche in Fig. 5 wiederholt wird, dargestellten Elementen ein Testmodul 94 bereitgestellt, einschließlich eines Testtreibers 96 und eines Satzes von Abfangroutinen 98. Das Testmodul arbeitet mit der Infrastruktur 90 für den Gerätezugriff zusammen, um einen Abfangmechanismus zu bilden für das Abfangen von busspezifischen Funktionsaufrufen eines Gerätezugriffs. Die Infrastruktur 90 des Gerätezugriffs nach Fig. 5 ist so betreibbar, daß sie mit dem Testmodul zusammenwirkt, um spezielle Gerätezugriffsaufrufe abzufangen, um geeignete Reaktionen zu injizieren.
• Demnach kann die Infrastruktur 90 des Gerätezugriffs auf dem Schnittstellenniveau des Gerätetreibers auf einen Gerätezugriffsaufruf (93) reagieren, um den Aufruf zwecks einer gezielten Einfügung von Fehlern abzufangen, wodurch die Gerätezugriffsaufforderung nicht direkt zu den Gerätezugriffsroutinen 92 weiterläuft (wie es durch die gepunktete Linie 93 wiedergegeben wird), sondern stattdessen über die Abfangroutinen 98 weiterläuft (wie es durch die durchgezogenen Liniert 97 und/oder 99 wiedergegeben wird). Der Gerätzugriffsaufruf kann dann möglicherweise nicht zu einem Gerätezugriff führen, sondern kann stattdessen zu der Rücklieferung einer emulierten Gerätereaktion führen aufgrund des Testgeschirrs 94 über den Pfad 97. Alternativ kann der Gerätezugriffsaufruf in der Tat zu einem Gerätezugriff führen mit einer zusätzlichen, vorher festgelegten logischen und/oder arithmetischen Operation mit fehlerhaften Daten, bevor sie über die Daten 99 und 95 an die Geräte weitergeleitet wird.
• Eine Benutzertestanwendung 71 kann mit dem Testtreiber 96 in Wechselwirkung treten, um die Abfangroutinen 98 für speziell angegebene oder bestimmte Verfälschung von Daten zu konfigurieren, die durch die Schnittstellenzugriffsfunktionen des Gerätetreibers erhalten wurden. Demnach kann der Schreiber eines gehärteten Gerätetreibers 84 einen Satz von Testskripten erzeugen, welche den Testmechanismus verwenden, um die Nachgiebigkeit bzw. Auffangfähigkeit des Treibers zu demonstrieren. Diese Skripte können die Kenntnis der Interna des Treibers 84 verwenden, um diese Typen von Fehlern zu erzeugen, die am wahrscheinlichsten Probleme verursachen (beispielsweise Registerzugriffe, welche Werte zurückliefern, die außerhalb des erwarteten Bereiches liegen). Der Testmechanismus erlaubt es, daß Zugriffe auf spezielle Register einer Verfälschung ausgesetzt sind, ebenso wie er eher zufällige Typen einer Verfälschung, die zu definieren sind, erlaubt. Die Testskripte können zu einem späteren Zeitpunkt nochmals laufen, wenn neue Versionen des Treibers oder der Plattform verfügbar werden. Der Testmechanismus kann als einer betrachtet werden, der durch die Kombination der Testschnittstelle 81 und des Abfangmechanismus gebildet wird, wobei letzterer durch das Testmodul 94 gebildet wird, welches mit dem Schnittstellenmechanismus 88 des Gerätetreibers zusammenarbeitet.
• Beispielsweise ist ein Testingenieur mit Hilfe des Testmechanismus in der Lage, für das System eine Bezugnahme auf das zu testende Gerät, das auf dieses Gerät gesetzte Register, einen Offsetbereich, einen Datenmastenwert, einen logischen Operator (= , UND, ODER etc.) und eine Zugriffsanzahl spezifizieren. Die Abfangroutinen überprüfen dann jede Verwendung der Gerätezugriffsaufrufe an die Gerätezugriffsroutinen durch den Gerätetreiber 84, um zu erkennen, ob dieses innerhalb spezifizierter Parameter liegt. Eine Zählung (COUNT 1 - Fig. 6) bzw. Zahl wird bei jedem Auftreten eines spezifizierten Gerätezugriffsaufrufes herabgezählt. Wenn die Zahl vollständig herabgezählt ("erloschen") ist, so können die gelesenen Daten durch einen Operator und Operanden verarbeitet werden. Dies ermöglicht es, daß ein Testmechanismus einen weiten Bereich unterschiedlicher Fehler einführt.
• Der Testtreiber 96 unterstützt eine Anzahl von I/O-Steuerungsvorgängen ("ioctls") 83 von der Testschnittstelle 81, welche erlaubt, daß Fehlerdefinitionen ("errdefs") definiert und nachfolgend verwaltet werden. Der Testtreiber ist ein geklonter Treiber, so daß jedesmal dann, wenn er geöffnet wird, ein anderer Aufruf erzeugt wird. Jegliche Fehlerdefinitionen, die durch Verwendung von I/O- Steuerungsanweisungen an einen gegebenen Aufruf erzeugt werden, werden automatisch gelöscht, wenn der Aufruf bzw. der Anruf beendet bzw. abgeschlossen wird. Der Testtreiber 96 ist so betreibbar, daß er von einer Benutzertestanwendung 81 mit Hilfe von ioctls 95, die über eine Schnittstelle in Form einer Testschnittstelle API 81 zugeführt werden, eine Testkonfiguration empfängt. Die Testkonfiguration spezifiziert eine Bezugnahme bzw. einen Aufruf an ein zu testendes Gerät, das auf dieses Gerät gesetzte Register, einen Offsetbereich, einen Operanden, einen Operator (= , UND, ODER, etc.), eine Zahl bzw. Zählung für den Offsetzugriff, einen Zugriffstyp (R (Lesen), W (Schreiben) oder Lesen oder Schreiben (RW)), und eine Zählung bzw. Zahl für die Anzahl von Malen, um welche Fehler injiziert werden sollen. Dies definiert die Parameter für den Test.
• Die Infrastruktur 90 des Gerätezugriffs ist so betreibbar, daß sie auf Gerätezugriffsvorgänge in der Weise reagiert, daß sie eine Umleitung der Anforderung über die geeigneten Abfangroutinen 98 bewirkt, von denen für jeden Typ eines Buszugriffsvorgangs eine vorhanden ist. Dies kann erreicht werden durch Modifizieren eines Tabellenmechanismus in der Infrastruktur 90 des Gerätezugriffs, die normalerweise auf einen Buszugriffsvorgang in der Weise reagieren würde, daß sie eine oder mehrere der busspezifischen Treiberzugriffsroutinen 92 kennzeichnet. Im Testbetrieb jedoch ist der Tabellenmechanismus dahingehend modifiziert, daß er Abfangroutinen kennzeichnet. In einer Ausführungsform der Erfindung werden die Abfangroutinen 98 über den Testtreiber 96 verwaltet.
• Eine Benutzertestanwendung 71, welche die oben erwähnte Testkonfiguration an den Treiber 96 des Testgeschirrs bzw. der Testeinrichtung weiterleitet, kann mit einem Testhilfsmittel ausgestattet werden, welches so ausgestaltet ist, daß es ein Testskript interpretiert und die Reaktion eines Treibers auf die Testbedingungen (Fehler) erfaßt, die durch das Testmodul 94 eingefügt wurden. Die Reaktion kann mit einer erwarteten Reaktion verglichen werden, die in dem Testskript beschrieben ist. Abweichungen können markiert werden. Das Testhilfsmittel kann ein Protokoll der es ergebenden Systemnachrichten von dem durch im Test befindlichen Treiber aufbewahren bzw. speichern, versehen mit einer Kennzeichnung der zu diesem Zeitpunkt aktiven Testkonfiguration. Das Testhilfsmittel sollte in der Lage sein, den betreffenden Treiber wieder in Betrieb zu setzen, um nicht überwachte Testbereiche zu ermöglichen.
• Das Testmodul führt auf der Basis der für dieses Gerät erzeugten Fehlerdefinitionen Fehlerinjektionen bzw. -einfügungen aus. Der Zeitpunkt der Fehlerinjektion kann gesteuert werden, um echte Fehler nachzubilden. Dies kann erreicht werden, indem bestimmte Buszugriffsanforderungen gezählt werden und dann auf den Zählwert entsprechend einem vordefinierten Plan reagiert wird, um zu bestimmen, wann die Fehler zu injizieren sind. Getrennte Zähler (COUNT 1) können für die entsprechenden Zugriffstypen, Gerätebauteile etc. bereitgestellt werden. Fehler können in DMA injiziert werden (wobei Daten für DMA zu/von Speicherbereichen verfälscht werden, welche durch DMA-Aufrufe der Gerätetreiberschnittstelle definiert sind), in physikalische I/O injiziert werden (wobei Daten verfälscht werden, die über Heranhol- und Abgabeaufrufe der Gerätetreiberschnittstelle gesendet/empfangen werden), und in Interrupts injiziert werden (wobei fehlerhafte Interrupts, verlorengehende Interrupts, verzögerte Interrupts erzeugt werden).
• Standardmäßig werden Zugriffsanforderungen auf die Gerätetreiberschnittstelle, welche von allen Treibern aufgerufen werden, abgefangen und es werden potentiell Fehler injiziert. Jedoch kann ein Testfeld in der Testkonfigurationsdatei des Testtreibers 96 auf eine Liste von Treibern eingestellt werden, die entweder getestet werden oder nicht getestet werden, je nach dem Zustand einer Testanzeige.
• Zusätzlich zu der Fehlerinjizierung kann der Testmechanismus eine Anzahl statischer Überprüfungen vornehmen, die durch Eigenschaften in der Testkonfigurationsdatei gesteuert werden. Diese können Validierungsüberprüfungen umfassen, wie: DMAs in dem Hauptspeicher werden nur ausgeführt in nicht gemeinsam verwendete I/O-MMU-Seiten; es gibt keine Prozessor-I/O-Zugriffe außer denjenigen, die Aufrufe an Schnittstellenroutinen des Gerätetreibers verwenden, wie z. B. ddi_get(), ddi_put8() etc., die nicht dazu gebracht werden, Adressen außerhalb eines Adreßzugriffsbereiches zu spezifizieren; und Aufrufe an DMA-Synchronisierungsroutinen werden korrekt ausgeführt.
• Fig. 6 ist eine schematische Wiedergabe der Betriebsweise des Testgeschirrs oder des Abfangmechanismus 94, wobei ein ddi- (Gerätetreiberschnittstelle-) Aufruf, wie z. B. ddi_get8() wird bei 950 abgefangen. Der Aufruf wird in einem Testbetrieb verwendet, um auf eine Testnachschlagtabelle 910 zuzugreifen, die durch das Testmodul 94 bereitgestellt wird. Diese Tafel wird durch die Infrastruktur 90 des Gerätezugriffs aufgerufen in Reaktion auf eine Gerätezugriffsanforderung. Das Testmodul ermöglicht damit, daß Gerätezugriffsaufrufe abgefangen werden. Diese Testtabelle 910 ersetzt die Standardtabelle, die verwendet wird für den Zugriff auf busspezifische Gerätezugriffsroutinen für den normalen Betrieb des Systems. Die Tabelle 910 identifiziert eine geeignete Abfangroutine 980, um zu bestimmen, ob ein Fehler in Reaktion auf den Zugriffsaufruf injiziert werden soll.
• Die Entscheidung, ob etwas injiziert wird oder nicht, hängt von der bestimmten bzw. festgelegten Abfangroutine 98 ab, die ein Testmuster auf Basis der potentiellen Fehler, die getestet werden sollen, bereitstellt, wie es über die Testschnittstelle 81 und den Gerätetreiber 96 durch die Testanwendung 71 konfiguriert ist. Für jeden Typ eines Aufrufs kann ein Zähler (COUNT 1) bereitgestellt werden, wobei ein Fehler bei jedem n-ten Aufruf injiziert wird, wobei n ein Wert zwischen 1 und einer großen Zahl ist, je nach den Testerfordernissen. Ein zweiter Zähler (COUNT 2) kann vorgesehen werden, wenn festgelegt wird, daß der Fehler zu seiner Injizierung eine bestimmte Anzahl von Malen nacheinander injiziert werden muß. Alternativ könnte ein vollständiger Zuordnungsalgorithmus bereitgestellt werden für bestimmte Injizierungsereignisse in einer Sequenz. Irgendeine geeignete Codierungstechnik könnte verwendet werden wie z. B. eine mehrdimensionale Anordnung, bei welcher Bits für Fehlerinjizierungsereignisse gesetzt sind und Bits nicht gesetzt sind, soweit eine Fehlerinjizierung nicht erforderlich ist. Alternativ könnte eine Codierungstechnik, beispielsweise eine Laufstrecken- bzw. eine Laufzeitcodierung, verwendet werden, um die Größe des für das Testzuordnungsmuster erforderlichen Speichers zu reduzieren.
• Wenn ein Fehler bei 990 injiziert werden soll, so wird dieser Schritt durch die Abfangroutine 980 ausgeführt. Eine Reaktion mit einem Fehler wird emuliert und von der Zugriffssteuerung an den Gerätetreiber zurückgeliefert. Durch Überwachung unter der Steuerung des Testtreibers 96 und/oder der Testanwendungssoftware für diesen Zweck kann dann bestimmt werden, ob der Gerätetreiber 84 gehärtet ist, um mit dem Fehler umzugehen, der injiziert worden ist. Durch Überwachen des Ergebnisses des Leitens des Fehlers zu dem Gerätetreiber auf dem einfachsten Niveau, um zu bestimmen, ob das Computersystem zusammenbricht, kann man erkennen, ob die Gerätehärtung beim Eingrenzen bzw. Einfangen des Fehlers und der Erholung von dem Fehler versagt. Wie oben beschrieben kann der Gerätezugriff alternativ mit den durch die Intercept-Routine(n) 98 injizierten Fehlerparameter weiterfahren.
• Da dieser Vorgang durch den Testmechanismus ausgeführt wird, ist es möglich, eine vollständige Sequenz von programmierten Tests bereitzustellen, ohne daß das System neu gebootet werden muß und/oder die Hardware modifiziert werden muß, um das Testen der Gerätehärtung zu erreichen. Dies kann das Testen der Gerätehärtung wesentlich schneller, zuverlässiger und vollständiger machen, als es früher möglich gewesen wäre.
• Fig. 7 ist ein Flußdiagramm, welches eine Übersicht über den Vorgang des Abfangens von Gerätezugriffen und des Injizierens von Fehlern bietet.
• In Schritt S1 wird eine Zugriffsanforderung an die Zugriffssteuerung abgefangen.
• In Schritt S2 bestimmt die Injektionsroutine, ob ein Fehler für diesen Aufruf injiziert werden soll. Dies kann beispielsweise dadurch bestimmt werden, daß festgestellt wird, ob ein erster Zähler (982 - siehe Fig. 6) für den Typ der betreffenden Injektionsroutine abgelaufen bzw. vollständig herabgezählt worden ist. Wenn er noch nicht vollständig herabgezählt worden ist, so soll zu diesem Zeitpunkt kein Fehler injiziert werden und die Steuerung geht weiter zu Schritt S3, wo die Zahl bzw. Zählung in dem Zähler 982 herabgesetzt wird. Die Steuerung läuft dann zurück zu Schritt S1.
• Wenn der erste Zähler seinen unteren Grenzwert unterschritten hat (herabgezählt worden ist, so werden in Schritt S4 die fehlerhaften Daten durch die Abfangroutinen injiziert. Die Fehler werden an den Herausgeber der Gerätezugriffsanforderung zurückgeliefert, um einen echten Fehler zu emulieren bzw. nachzubilden.
• In Schritt S5 wird eine Überprüfung vorgenommen, ob eine weitere Injizierung beim nächsten Aufruf der Injektionsroutine erforderlich ist. Dies wird bestimmt durch Überprüfen, ob ein zweiter Zähler herabgezählt worden ist.
• Wenn der zweite Zähler herabgezählt worden ist, so ist keine weitere Injizierung erforderlich. Dementsprechend wird in Schritt S6 der zweite Zähler 982 auf einen Wert herabgesetzt, welcher der Anzahl von Malen entspricht, um welche die Injektion für aufeinanderfolgende Aufrufe der betreffenden Abfangroutine wiederholt werden soll. Der erste Zähler 982 wird in Schritt S7 ebenfalls auf die Anzahl von Aufrufen der betreffenden Intercept-Routine zurückgesetzt, die erfolgen muß, bevor die nächste Fehlerinjektion ausgeführt werden soll. Die Steuerung geht dann zurück zu Schritt S1.
• Wenn der zweite Zähler noch nicht herabgezählt worden ist, so wird die Zählung bzw. Zahl in dem zweiten Zähler 984 in Schritt S8 herabgesetzt, bevor die Steuerung zu Schrift S1 zurückgeleitet wird.
• Es versteht sich, daß das in Fig. 7 dargestellte Flußdiagramm nur ein möglicher Weg der Steuerung des Abfangens und des Abfangvorgangs ist. Man kann sich viele Änderungen vorstellen. Beispielsweise könnte die Tabelle 960 einen Teil der Infrastruktur des Gerätezugriffs bilden anstatt durch die Infrastruktur des Gerätezugriffs in Reaktion auf die Zugriffsanforderung aufgerufen zu werden. Auch könnten statt herabzählender Zähler heraufzählende Zähler verwendet werden. Außerdem könnten anstelle von einfachen Zählern komplexere Zuordnungstechniken als die oben erwähnten für die Bestimmung verwendet werden, ob und wo Fehler injiziert werden sollten.
• Fig. 8 ist ein Flußdiagramm, welches die Funktionen der Testhilfsmittel zusammenfaßt, die durch eine Benutzeranwendung bereitgestellt werden können.
• In Schritt S11 leitet die Benutzeranwendung 99 eine Testkonfigurierung an einen Testtreiber 96, wobei die Testkonfigurierung das Gerät (die Geräte) identifiziert, die getestet werden sollen, sowie die Parameter des Tests festlegt.
• In Schritt S12 überwacht ein Testhilfsmittel in der Benutzeranwendung eine Reaktion eines Treibers für die durch den Testmechanismus eingefügten Testbedingungen.
• In Schritt S13 vergleicht das Testhilfsmittel dieses mit einem erwarteten Ergebnis, wie es in einem Testskriptum definiert ist.
• In Schritt S14 markiert das Testhilfsmittel irgendwelche Abweichungen. Optional könnten die Abweichungen auf einer Anzeige dargestellt werden, die mit dem Grafikadapter nach Fig. 1 verbunden ist oder sie könnten auf einem Ausdruck gedruckt werden. Alternativ könnten sie einfach in Schritt S15 gespeichert bzw. protokolliert werden.
• In Schritt S15 protokolliert das Testhilfsmittel die Reaktionen mit jeglichen markierten Abweichungen und mit der aktuellen Testkonfigurierung.
• In Schritt S16 kehrt das Testhilfsmittel für eine nächste Reaktion zurück.
• Das Testhilfsmittel kann weiterhin in dem Fall betrieben werden, daß ein Fehler dazu führt, daß die Systemsicherung den Treiber erneut anhängt, um das Testen fortzusetzen.
• Es folgt nunmehr eine Zusammenfassung von Beispielen möglicher I/O-Steuervorgänge (ioctls), die unterstützt werden könnten.
• Ein erster I/O-Steuerungsvorgang (HARNESS_ADD_DEF) stellt einen Zeiger zu einer Struktur für die Fehlerdefinition eines Testgeschirrs bzw. einer Testausrüstung bereit. Die Struktur wird in der nachstehenden Tabelle 1 gekennzeichnet: TABELLE 1
• Die Fehlerdefinition ("errdef") wird an den Treiber weitergeleitet (wird jedoch nicht ausgeführt, bis ein Steuerungsvorgang HARNESS-START I/O zugeführt wird). Dies liefert eine Fehlerdefinitionshandhabung oder einen Zeiger zurück, wenn es erfolgreich verläuft. Eine Handhabe ist ein Zeiger zu der passenden Funktion eines Gegenstandes, der eine kompakte Definition der Funktion oder Einheit liefert. Mehrere gleichzeitige Fehlerdefinitionen können unterstützt werden, wenn sie sich auf dasselbe oder auf unterschiedliche Geräte beziehen. Wenn mehrere Fehler jedoch schließlich in demselben Zugriff eingefügt werden, kann das Ergebnis undefiniert sein. Der durch den "Operator" definierte Fehler wird in den n-ten Zugriffsanwärter injiziert, wobei n durch "access_count" gegen ist und er wird dann weiterhin für eine Anzahl aufeinanderfolgender Zugriffsanwärter injiziert, die durch die Variable "fail_count" definiert wird. Auch wenn keine Fehler mehr injiziert werden, sobald der "fail_count"-Wert auf Null gegangen ist, bleibt eine Zugriffsüberprüfung eingestellt, bis die Fehlerdefinition gelöscht ist oder ein geeigneter I/O-Steuerungsvorgang für den geeigneten Namen und das Ereignis bereitgestellt wird, um dieses zu löschen. Ein Zugriffsanwärter ist definiert durch "access_type", der einer der folgenden Typen sein kann:
• HARNESS-PIO-R - Dies ist ein Zugriffsanwärter in Form eines physikalischen I/O- Lesezugriffs, wobei eine Zugriffshandhabe der Schnittstelle des Gerätetreibers unter Verwendung von Geräteinformation mit einem spezifizierten "Namen" und "Ereignis", einer spezifizierten "RNummer", mit einer angeforderten Adresse innerhalb eines spezifizierten "Offset" und "len" verwendet wird. Wenn die Länge "len" Null ist, so ist das übrige des Registersatzes qualifiziert (ein Anwärter). Wenn "RNummer" -1 ist, so sind alle Registersätze Anwärter. Der "Operator" kann einer der folgenden sein:
• HARNESS_EQUAL - Die Daten werden von der I/O-Karte gelesen, jedoch ignoriert, und der Inhalt des "Operanden" wird stattdessen an den Anrufer zurückgeliefert.
• HARNESS_AND - Die Daten werden von der I/O-Karte gelesen und mit dem "Operanden" durch UND verknüpft, bevor sie an den Anrufer zurückgeliefert werden.
• HARNESS_OR - Die Daten werden von der I/O-Karte gelesen und mit dem "Operanden" mit ODER verknüpft, bevor sie an den Anrufer zurückgeliefert werden.
• HARNESS_XOR - Die Daten werden von der I/O-Karte gelesen und durch AUSSCHLIEß-LICH ODER mit dem "Operanden" verknüpft, bevor sie an den Aufrufer zurückgeliefert werden.
• HARNESS_NO_TRANSFER - Keine Daten werden von der I/O-Karte gelesen und stattdessen wird der "Operand" an den Anrufer zurückgeliefert.
• HARNESS-PIO-W - Dies ist ein Zugriffsanwärter in Form eines physikalischen I/O-Schreibezugriffs, wobei eine Zugriffshandhabe der Schnittstelle des Gerätetreibers zugeordnet wird unter Verwendung von Geräteinformation mit einem spezifizierten "Namen" und "Ereignis", einer spezifizierten "RNummer", mit einer angeforderten Adresse innerhalb eines spezifizierten "Offset" und "len". Wenn die Länge "len" Null ist, so ist das übrige des Registersatzes ein Anwärter. Wenn "RNummer" -1 ist, so sind alle Registersätze Anwärter. Der "Operator" kann einer der folgenden sein:
• HARNESS_EQUAL - Der Inhalt des "Operanden" wird anstelle der angeforderten Daten auf die I/O-Karte gelesen.
• HARNESS_AND - Der "Operand" wird mit den angeforderten Daten durch UND verknüpft, bevor sie auf die I/O-Karte geschrieben werden.
• HARNESS_OR - Der "Operand" wird mit den angeforderten Daten durch ODER verknüpft, bevor sie in die I/O-Karte geschrieben werden.
• HARNESS_XOR - Der "Operand" wird mit den angeforderten Daten durch AUSSCHLIEß-LICH ODER verknüpft, bevor sie auf die I/O-Karte geschrieben werden.
• HARNESS_NO_TRANSFER - Keine Daten werden auf die I/O-Karte geschrieben.
• HARNESS-DMA-R - Dies ist ein Zugriffsanwärter in Form eines impliziten oder expliziten DMA- Synchronisationszugriffs der Gerätetreiberschnittstelle für die CPU oder für den Kem des Betriebssystems, wobei eine DMA-Handhabung der Gerätetreiberschnittstelle unter Verwendung von Geräteinformation mit einem spezifizierten "Namen" und "Ereignis" zugeordnet wird, wobei "RNummer" gleich -1 ist oder der sequentiellen Zuordnungsnummer der DMA-Handhabung der Gerätetreiberschnittstelle entspricht und wobei es ein oder mehrere mit doppelt langen ausgerichtete Doppellange innerhalb eines spezifizierten Offsets und Längenbereiches innerhalb des Raumbereiches gibt, der durch die DMA-Handhabung der Gerätetreiberschnittstelle zugeordnet ist. Die Verfälschung gilt auch für alle derartigen doppelt langen Anwärter. Ein "doppelt langes" ist ein Wort doppelter Länge. Der "Operator" kann eines der folgenden sein:
• HARNESS_EQUAL - Die Daten werden von der I/O-Karte in den Speicher gelesen, jedoch wird dann der spezifizierte Bereich des Speichers durch den Inhalt des "Operanden" überschrieben.
• HARNESS_AND - Die Daten werden von der I/O-Karte in den Speicher gelesen und dann wird der spezifizierte Bereich des Speichers durch UND mit dem "Operanden" verknüpft.
• HARNESS_OR - Die Daten werden von der I/O-Karte in den Speicher gelesen und dann wird der spezifizierte Speicherbereich mit dem "Operanden" durch ODER verknüpft.
• HARNESS_XOR - Die Daten werden von der I/O-Karte in den Speicher gelesen und dann wird der spezifizierte Bereich des Speichers mit dem "Operanden" durch AUSSCHLIEßLICH ODER verknüpft.
• HARNESS_DMA_W - Dies ist ein Zugriffsanwärter in Form eines impliziten oder expliziten DMA- Synchronisationszugriffs der Gerätetreiberschnittstelle für ein Gerät, bei welchem die DMA- Handhabung der Gerätetreiberschnittstelle zugeordnet wird unter Verwendung von Geräteinformation mit einem spezifizierten "Namen" und "Objekt" ("instance"), und die "Registernummer" ist -1 oder entspricht der sequentiellen Zuordnungsnummer des DMA der Gerätetreiberschnittstelle, und wobei es ein oder mehrere mit doppelt langen ausgerichtete doppelt lange innerhalb eines spezifizierten Offsets und Längenbereiches innerhalb des Raumgebietes gibt, welches durch die DMA- Handhabung der Gerätetreiberschnittstelle zugeordnet ist. Die Verfälschung gilt für alle derartigen doppelt langen Anwärter. Der "Operator" kann einer der folgenden sein:
• HARNESS_EQUAL - Eine Kopie der Daten wird genommen und der angegebene Bereich des Speichers wird dann durch den Inhalt des "Operanden" überschrieben. Der DMA ist dann auf die Kopie der Daten gerichtet anstatt auf das Original.
• HARNESS_AND - Es wird eine Kopie der Daten genommen und der angegebene Bereich des Speichers wird dann mit dem Inhalt des "Operanden" durch UND verknüpft. Der DMA wird dann auf die Kopie der Daten anstatt auf das Original gerichtet.
• HARNESS_OR - Es wird eine Kopie der Daten genommen und der angegebene Bereich des Speichers wird dann mit dem Inhalt des "Operanden" durch ODER verknüpft. Der DMA wird dann auf die Kopie der Daten gerichtet anstatt auf das Original.
• HARNESS_XOR - Es wird eine Kopie der Daten genommen und der angegebene Bereich des Speichers wird dann mit dem Inhalt des "Operanden" durch AUSSCHLIEßLICH ODER verknüpft. Der DMA wird dann auf die Kopie der Daten gerichtet anstatt auf das Original.
• HARNESS_INTR - Dies ist ein Zugriffsanwärter in Form einer Interrupt-Serviceroutine, die aufgerufen wird, wenn eine Interruptspezifikation zugeordnet wird unter Verwendung der Geräteinformation mit einem spezifizierten "Namen" und "Objekt". Argumente, die sich auf "RNummer", "Offset" und "len" beziehen, werden in diesem Fall ignoriert. Der "Operator" kann einer der folgenden sein:
• HARNESS_DELAY_INTR - Dies bewirkt, daß ein Interrupt für eine gewisse Zahl von Mikrosekunden zurückgehalten wird, die durch einen Operanden spezifiziert werden (mit Ausnahme von "hilevel"-Interrupts).
• HARNESS_LOSE_INTR - Dies bewirkt, daß ein Interrupt dauerhaft verloren geht. Ein Operand wird in diesem Fall ignoriert.
• HARNESS_EXTRA_INTR - Dies bewirkt, daß eine Anzahl zusätzlicher fehlerhafter Interrupts, welche durch einen Operanden angezeigt werden, erzeugt werden.
• Ein zweiter I/O-Steuervorgang löscht eine Definition (HARNESS_DEL_DEF). Dies liefert einen Zeiger zu dem in Tabelle 2 dargestellten Gegenstand. TABELLE 2
• Das Feld errdef_handle sollte den Wert haben, der in das Feld errdef_handle der Fehlerdefinitionsstruktur gefügt wurde, wie er von einem HARNESS_ADD_DEF I/O-Steuervorgang zurückgeliefert wird. Dies löscht die spezifizierte Fehlerdefinition.
• Ein dritter I/O-Steuerungsvorgang (HARNESS_START) hat ein Argument eines Zeigers auf den in Tabelle 3 dargestellten Gegenstand. TABELLE 3
• Dies setzt alle Fehlerdefinitionen (errdefs) mit dem spezifizierten "Namen" und "Objekt" in Lauf. Die errdefs werden nicht automatisch durch die HARNESS-ADD-DEF-I/O-Steuervorgänge in Lauf gesetzt, so daß der HARNESS_START-I/O-Steuerungsvorgang immer aufgerufen werden muß.
• Ein vierter I/O-Steuervorgang (HARNESS_STOP) hat als Argument einen Zeiger auf die in Tabelle 3 dargestellte Struktur. Dies setzt alle Fehlerdefinitionen (errdefs) mit dem spezifizierten "Namen" und "Objekt" aus. Die errdefs können durch einen nachfolgenden HARNESS_START-I/O- Steuervorgang erneut gestartet werden.
• Ein fünfter I/O-Steuervorgang (HARNESS_BROADCAST) hat als Argument einen Zeiger auf den in Tabelle 3 dargestellten Gegenstand. Alle Vorgänge, die in einem HARNESS_CHK_STATE_W-I/O-Steuerungsvorgang für eine Fehlerdefinition mit den spezifizierten "Namen" und "Objekt" ruhen oder schlafen, werden aufgeweckt.
• Ein sechster I/O-Steuerungsvorgang (HARNESS_CLEAR_ACC_CHK) hat als Argument einen Zeiger auf den in Tabelle 3 dargestellten Gegenstand. Für alle Fehlerdefinitionen mit dem spezifizierten "Namen"/"Objekt" wird, wenn "access_count" und "fall_count" bereits Null sind, hierdurch das "acc_chk"-Feld auf Null gesetzt. Jegliche Prozesse, welche in einem HARNESS_CHK_STATE_W-I/O-Steuerungsvorgang für eine Fehlerdefinition mit diesem "Namen" und "Objekt" ruhen bzw. schlafen, werden aufgeweckt.
• Ein siebter I/O-Steuerungsvorgang (HARNESS_CLEAR_ERRORS) hat als Argument einen Zeiger auf den in Tabelle 3 dargestellten Gegenstand. Für alle Fehlerdefinitionen mit dem spezifizierten "Namen" und "Objekt" werden, wenn "access_count" bereits Null ist, hierdurch die "acc-chk"- und "fail-count"-Felder auf Null gesetzt. Jegliche Prozesse bis dahin, welche in einem HARNESS_CHK_STATE_W-Steuerungsvorgang für eine Fehlerdefinition mit diesem "Namen"/"Objekt" schlafen, werden aufgeweckt.
• Ein achter I/O-Steuerungsvorgang (HARNESS_CLEAR_ERRDEFS) hat als Argument einen Zeiger auf den in Tabelle 3 dargestellten Gegenstand. Für alle Fehlerdefinitionen in dem spezifizierten "Namen" und "Objekt" werden hierdurch die "ace-chk"-, "fall-count"- und "access-count"-Felder auf Null gesetzt. Jegliche Vorgänge, die in einem HARNESS_CHK_STATE_W-I/O- Steuerungsvorgang für eine Fehlerdefinition mit diesem "Namen" und "Objekt" schlafen, werden aufgeweckt.
• Ein neunter I/O-Steuerungsvorgang (HARNESS_CHK_STATE) hat als Argument einen Zeiger auf den in Tabelle 4 dargestellten Gegenstand. TABELLE 4
• Das Handhabungsfeld errdef sollte den in das Handhabungsfeld errdef eingefügten Wert der in Tabelle 1 dargestellten errdef-Struktur haben, wie er von einem HARNESS_ADD_DEF-ioctl zurückgeliefert wird. Bei der Rücklieferung von den HARNESS_CHK_STATE-I/O-Steuervorgängen werden die anderen Felder aufgefüllt.
• "msg-time", "buffer" und "severity" sind für das erste Auftreten der Fehlernachricht mit dem höchsten "Gewicht" ("severity"), die berichtet wurde, seit "access-count" für diese Fehlerdefinition auf Null ging.
• Ein zehnter I/O-Steuerungsvorgang (HARNESS_CHK_STATE_W) hat als Argument einen Zeiger auf den in Tabelle 4 dargestellten Gegenstand. Wenn "access_count" für diese Fehlerdefinition auf Null gegangen ist und ein u4ft-ddi_report_error() aufgetreten ist, seitdem zum letzten Mal HARNESS_CHK_STATE_W aufgerufen wurde, so kehren die I/O-Steuerungsvorgänge sofort zurück. Ansonsten ruht der I/O-Steuerungsvorgang, bis "access count" für die Handhabung dieser Fehlerdefinition auf Null gegangen ist und das nächstfolgende u4ft_ddi_report_error() auftritt (oder bis einer der I/O-Steuerungsvorgänge HARNESS_BROADCAST, HARNESS_CLEAR_ACC_CHK, HARNESS_CLEAR_ERROR oder HARNESS_CLEAR_ERRDEFS für denselben "Namen" und dasselbe "Objekt" aufgerufen wird.
• Ein elfter I/O-Steuerungsvorgang (HARNESS_DEBUG_OFF) hat als Argument einen Zeiger auf den in Tabelle 2 dargestellten Gegenstand. Dies schaltet Debug-Information (Fehlersuchinformation) für die spezifizierte Fehlerdefinition ein (so daß der Treiber Information ausgibt).
• Ein zwölfter I/O-Steuerungsvorgang (HARNESS_DEBUG_OFF) hat als Argument einen Zeiger auf den in Fig. 2 dargestellten Gegenstand. Dies schaltet die Debug-Information für die spezifizierte Fehlerdefinition ab.
• Ein dreizehnter I/O-Steuerungsvorgang (HARNESS_GET_HANDLES) hat als Argument einen Zeiger auf den in Tabelle 5 dargestellten Gegenstand. TABELLE 5
• Hierdurch wird ein Strang von bis zu "count" Bytes an ASCII-Information kopiert, welcher die verschiedenen ddi-, Zugriffs- und Interrupt-Handhabungen für ein Gerät (Geräte mit dem spezifizierten "Namen" und "Objekt" in einem Zeichenspeicher auflistet, welcher durch "buffer" gekennzeichnet ist.
• Es folgt nunmehr eine Beschreibung eines Verfahrens oder Mechanismus (th_define) für die Bereitstellung einer Fehlerdefinition für die Treibertestausrüstung. th_define(1) ermöglicht, daß eine Fehlerdefinition ("errdef") spezifiziert wird.
• Die errdef wird an den Testtreiber weitergeleitet, wird jedoch nicht ausgeführt, bis th_manage(1) aufgerufen wird, um mit dem Testen zu beginnen. th_define(1) ruht, bis entweder ein u4ft_ddi_report_error(9) für das in Rede stehende Gerät auftritt oder bis th_manage(1) es aufweckt. th_define(1) gibt dann an einen Standardausgang die Parameter aus, mit denen es aufgerufen worden war sowie den aktuellen Zustand der Fehlerdefinition. Wenn "access count" oder "fail count" oder "acc-chk" noch immer nicht Null sind, so geht th_define(1) zurück, um weiter im Ruhezustand zu bleiben. Wenn th_define(1) schließlich aufgeweckt worden ist, wobei "access_count", "fall_count" und "acc_chk" allesamt Null sind, so schaltet es ab, was bewirkt, daß die Fehlerdefinition def gelöscht wird.
• Wenn der optionale Debug-Parameter eine Zahl ist, die nicht gleich Null ist, so wird das Debugging (Fehlersuchen) für diese Fehlerdefinition eingeschaltet, was bewirkt, daß Information durch den Testtreiber angezeigt wird. Mehrere gleichzeitig auftretende Fehlerdefinitionen können unter Bezug auf dieselben oder auch auf unterschiedliche Geräte unterstützt werden. Wenn jedoch schließlich mehrere Fehler in demselben Zugriff injiziert werden, kann das Ergebnis undefiniert sein.
• Der durch "Operator" definierte Fehler wird in den n-ten Zugriffsanwärter injiziert, wobei n durch "access count" gegeben ist und er wird dann weiterhin für eine aufeinanderfolgende Zahl von Zugriffsanwärtern entsprechend "fail-count" weiterhin injiziert. Der Wert in "acc_chk" kann NULL, U4FT_ACC_NO_PIO, U4FT_ACC_NO_DMA oder U4FT_ACC_NO_IRQ sein und wird durch ODER-Verknüpfung im Anschluß an den ersten injizierten Fehler zurückgegeben. Auch wenn keine Fehler mehr injiziert werden, sobald "fail count" auf Null gegangen ist, bleibt "acc_chk" besetzt (bis th_define(1) abschaltet oder th_manage(1) aufgerufen wird, um Fehler etc. für dieses Gerät zu löschen).
• Zugriffsanwärter werden definiert durch "access_type", welcher einer der folgenden sein kann:
• PIO-R - Dies ist ein Zugriffsanwärter in Form eines physikalischen I/O-Lesezugriffs, wobei die Zugriffshandhabung einer Gerätetreiberschnittstelle zugeordnet wird unter Verwendung von Geräteinformation mit einem spezifizierten "Namen" und "Objekt", einer spezifizierten "RNummer", mit einer angeforderten Adresse innerhalb eines spezifizierten "Offset" und "len". Wenn die Länge "len" Null ist, so ist das übrige des Registersatzes ein Anwärter. Wenn "RNummer" gleich -1 ist, so sind alle Registersätze Anwärter. Der "Operator" kann einer der folgenden sein:
• EQ - Die Daten werden von der I/O-Karte gelesen, jedoch ignoriert, und der Inhalt des "Operanden" wird stattdessen an den Anrufer zurückgegeben.
• AND - Die Daten werden aus der I/O-Karte gelesen und durch UND mit dem "Operanden" verknüpft, bevor sie an den Anrufer zurückgeliefert werden.
• OR - Die Daten werden von der I/O-Karte gelesen und mit dem "Operanden" durch ODER verknüpft, bevor sie an den Anrufer zurückgeliefert werden.
• XOR - Die Daten werden von der I/O-Karte gelesen und mit dem "Operanden" durch AUSSCHLIEßLICH ODER verknüpft, bevor sie an den Anrufer zurückgeliefert werden.
• NO - Keine Daten werden von der I/O-Karte gelesen und stattdessen wird der "Operand" an den Anrufer zurückgeliefert.
• PIO-W - Dieses ist ein Zugriffsanwärter in Form eines physikalischen I/O-Schreibzugriffs, wobei eine Zugriffshandhabung der Gerätetreiberschnittstelle zugeordnet wird unter Verwendung von Geräteinformation mit einem spezifizierten "Namen" und "Objekt", einer spezifizierten "RNummer", mit einer angeforderten Adresse innerhalb eines spezifizierten "Offset" und "len". Wenn die Länge "len" Null ist, so ist der verbleibende Teil des Registersatzes ein Anwärter. Wenn "RNummer" gleich -1 ist, so sind alle Registersätze Anwärter. Der "Operator" kann einer der folgenden sein:
• EQ - Der Inhalt des "Operanden" wird anstelle der angeforderten Daten in die I/O- Karte geschrieben.
• AND - Der "Operand" wird mit den angeforderten Daten durch UND verknüpft, bevor dies in die I/O-Karte geschrieben wird.
• OR - Der "Operand" wird mit den angeforderten Daten durch ODER verknüpft, bevor dies in die I/O-Karte geschrieben wird.
• XOR - Der "Operand" wird mit den angeforderten Daten durch AUSSCHLIEßLICH ODER verknüpft, bevor dies in die I/O-Karte geschrieben wird.
• NO - Keine Daten werden in die I/O-Karte geschrieben.
• DMA-R - Dies ist ein Zugriffsanwärter in Form eines impliziten oder expliziten DMA- Synchronisationszugriffs der Gerätetreiberschnittstelle für die CPU oder den Kern des Betriebssystems, wobei eine DMA-Handhabung der Gerätetreiberschnittstelle zugeordnet wird unter Verwendung von Geräteinformation mit einem spezifizierten "Namen" und "Objekt", wobei "RNummer" gleich -1 ist oder der in einer Sequenz dargebotenen Zuordnungsnummer der DMA-Handhabung der Gerätetreiberschnittstelle und wobei es ein oder mehrere mit doppelt langen ausgerichtete doppelt lange innerhalb eines spezifizierten Offsets und Längenbereichs in dem Speicherbereich gibt, der durch die DMA-Handhabung der Gerätetreiberschnittstelle zugeordnet wurde. Die Verfälschung gilt für alle derartigen doppelt lang- Anwärter. Der "Operator" kann einer der folgenden sein:
• EQ - Die Daten werden von der I/O-Karte in den Speicher gelesen, jedoch wird dann der spezifizierte Bereich des Speichers durch den Inhalt des "Operanden" überschrieben.
• AND - Die Daten werden von der I/O-Karte in den Speicher gelesen und dann wird der spezifizierte Bereich des Speichers mit dem "Operanden" durch UND verknüpft.
• OR - Die Daten werden von der I/O-Karte in den Speicher gelesen und dann wird der spezifizierte Bereich des Speichers mit dem "Operanden" durch ODER verknüpft.
• XOR - Die Daten werden von der I/O-Karte in den Speicher gelesen und dann wird der spezifizierte Bereich des Speichers mit dem "Operanden" durch AUSSCHLIEß-LICH ODER verknüpft.
• DMA_W - Dies ist ein Zugriffsanwärter in Form eines impliziten oder expliziten DMA- Synchronisationszugriffs der Gerätetreiberschnittstelle für bzw. auf ein Gerät, wobei die DMA-Handhabung der Gerätetreiberschnittstelle unter Verwendung von Geräteinformation mit einem spezifizierten "Namen" und "Objekt" zugeordnet wird und wobei die "Registernummer" -1 ist oder der sequentiellen Zuordnungsnummer des DMA der Gerätetreiberschnittstelle entspricht, und wobei es eines oder mehrere mit doppelt langen ausgerichtete doppelt lange innerhalb eines spezifizierten Offsets und Längenbereichs innerhalb des Raumbereiches gibt, welcher durch die DMA-Handhabung der Gerätetreiberschnittstelle zugeordnet wurde. Die Verfälschung gilt auch für alle derartigen doppelt langen Anwärter. Der "Operator" kann einer der folgenden sein:
• EQ - Es wird eine Kopie der Daten genommen und der angegebene Bereich des Speichers wird dann durch den Inhalt des "Operanden" überschrieben. Der DMA wird dann statt auf das Original auf die Kopie der Daten gerichtet.
• AND - Es wird eine Kopie der Daten genommen und der spezifizierte Bereich des Speichers wird dann durch UND mit dem Inhalt des "Operanden" verknüpft. Der DMA wird dann anstatt auf das Original auf die Kopie der Daten gerichtet.
• OR - Es wird eine Kopie der Daten genommen und der angegebene Bereich des Speichers wird dann mit dem Inhalt des "Operanden" durch "ODER" verknüpft. Die DMA wird dann anstatt auf das Original auf die Kopie der Daten gerichtet.
• INTR - Dies ist ein Zugriffsanwärter in Form einer Interrupt-Serviceroutine, die aufgerufen wird, wenn eine Interruptspezifikation unter Verwendung von Geräteinformation mit einem spezifizierten "Namen" und "Objekt" zugeordnet wird. Argumente, die sich auf "RNummer", "Offset" und "len" beziehen, werden in diesem Fall ignoriert. Der "Operator" kann einer der folgenden sein:
• DELAY - Dies bewirkt, daß ein Interrupt für eine Anzahl von Mikrosekunden zurückgehalten wird, welche durch einen Operanden spezifiziert wird (Ausnahme für "hilevel"-Interrupts).
• LOSE - Dies bewirkt, daß ein Interrupt dauerhaft verlorengegangen ist. Ein Operand wird in diesem Fall ignoriert.
• EXTRA - Dies bewirkt, daß eine Anzahl von zusätzlichen fehlerhaften Interrupts, welche durch einen Operanden angezeigt werden, erzeugt werden.
• Es folgt jetzt eine Beschreibung eines Vorgangs oder Mechanismus (th_manage) für das Verwalten des Testmechanismus für ein bestimmtes Gerät. th_manage(1) wirkt auf alle Fehlerdefinitionen ("errdefs") für einen spezifizierten "Namen" und ein "Objekt". Es unterstützt die folgenden "Befehls"-Werte.
• START - Dies setzt alle errdefs für den spezifizierten "Namen" und "Objekt" in Lauf oder nimmt sie wieder auf.
• STOP - Dies setzt alle errdefs für diesen "Namen" und "Objekt" aus.
• BROADCAST - Dies weckt alle th_define(1)-Vorgänge für diesen "Namen" und "Objekt" auf, was bewirkt, daß sie ihren aktuellen Status anzeigen und sich abschalten, wenn der errdef nunmehr gelöscht bzw. außer Funktion ist (das heißt "access-count", "fail-count" und "accchk" sind allesamt Null).
• CLEAR_ACC_CHK - Dies weckt alle th_define(1)-Vorgänge für diesen dann eingestellten "Namen" und das "Register" auf. Wenn "access_count" und "fail_count" bereits Null sind, so wird "acc_chk" ebenfalls auf Null gesetzt, so daß th_define(1) abschaltet, sobald es seinen Status angezeigt hat.
• CLEAR_ERRORS - Dies weckt alle th_define(1)-Vorgänge für diesen "Namen" und "Objekt" auf. Wenn "access_count" bereits Null ist, so werden "fail_count" und "acc_chk" ebenfalls auf Null herabgesetzt, so daß th_define(1) in den Aus-Zustand geht, sobald es seinen Status angezeigt hat.
• CLEAR_ERRDEFS - Dies weckt alle th_define(1)-Vorgänge für diesen "Namen" und "Objekt" auf. "access_count", "fail_count" und "acc_chk" werden alle auf Null gesetzt, so daß alle th_define(1)-Befehle in den Aus-Zustand gehen, sobald sie ihren Zustand angezeigt haben.
• GET-HANDLES - Dies zeigt alle die Handhabungen an, die aktuell durch den Testmechanismus für diesen "Namen" und "Objekt" abgefangen wurden.
• Es folgen nunmehr Beispiele des Gebrauchs der Testausrüstung.
• Man betrachte Fehlerdefinitionen für ein Objekt 0 des "foo"-Gerätes, Typs
• Starte den Test durch Eingabe:
• th_manage foo 0 START
• Der Zustand der Fehlerdefinitionen kann durch die Eingabe überprüft werden:
• th_manage foo 0 BROADCAST
• Dies bewirkt, daß jeder th_define-Prozeß seinen aktuellen Status bzw. Zustand ausdruckt. Wenn der Treiber einen schweren Fehler berichtet hat, so kann der Treiber abgekoppelt werden, um den Fehler durch Eingabe des folgenden zu löschen:
• Das Testen kann beendet werden durch Eingabe:
• Beispiele von Fehlerdefinitionen werden unten wiedergegeben:
• Dies bewirkt, daß 0X100 in den nächsten physikalischen I/O-Lesezugriff von irgendeinem Register in dem Registersatz 1 des Objektes 3 des foo-Treibers durch ODER-Verknüpfung gegeben wird. Anschließende Aufrufe in dem Treiber nach u4fft_ddi_check_access() setzen das U4FT_ACC_NO_PIO-Bit.
• Dies bewirkt, daß die nächsten 100 physikalischen I/O-Schreibvorgänge in das Register beim Offset 0X8100 in dem Registersatz 1 des Objektes 3 des foo-Treibers wie normal stattfinden. Bei jedem der drei nachfolgenden Zugriffe jedoch ist das 0X1000-Bit nicht gesetzt.
• Dies bewirkt, daß 0X7 mit jedem doppelt langen (Wort) in dem Bereich von Offset 256 bis Offset 512 des nächsten DMA-Schreibens unter Verwendung irgendeiner DMA-Handhabung für das Objekt 3 des foo-Treibers durch ODER verknüpft wird. Nachfolgende Aufrufe in dem Treiber nach u4ft_ddi_check_access() führen dazu, daß das U4FT_ACC_NO_DMA-Bit gesetzt wird.
• Dies bewirkt, daß die nächsten sechs Interrupts für das Objekt 3 des foo-Treibers verlorengehen.
• Dies bedeutet, daß dann, wenn der dreißigste nachfolgende Interrupt für das Objekt 3 des foo- Treibers auftritt, außerdem noch zusätzliche 10 Byte Interrupts erzeugt werden. Nachfolgende Aufrufe in dem Treiber von u4ft_ddi_check_access() U4FT_ACC_NO_IRQ-Bit gesetzt wird.
• Dies bewirkt, daß der nächste Interrupt für das Objekt 3 des foo-Treibers um 1024 Mikrosekunden verzögert wird.
• Es versteht sich, daß dies lediglich Beispiele von Fehlerdefinitionen sind und daß eine breite Vielfalt von Fehlerdefinitionen in einer Ausführungsform der Erfindung erzeugt werden kann, ohne daß es notwendig ist, die Fehler in der Hardware physikalisch zu verursachen.
• In einer Ausführungsform der Erfindung ist der Testmechanismus als Computersteuerungscode implementiert oder als Software, die in den Speicher 14 des Computersystems nach Fig. 1 gespeichert wird und die auf dem Prozessor 12 nach Fig. 1 ausgeführt wird. Es versteht sich jedoch, daß der Testmechanismus auf irgendeinem anderen Trägermedium, wie z. B. einer Festplatte, einem Band oder in Form elektrischer, optischer, drahtloser oder sonstiger Signale auf einem Telekommunikationsmedium bereitgestellt werden könnte. Der Testmechanismus könnte auch, zumindest teilweise, mit Hilfe einer speziellen Hardware implementiert werden, beispielsweise in einem ASIC implementiert sein.
• Die Benutzeranwendung kann ebenfalls als Computersteuerungscode oder als Software implementiert sein, welche in dem Speicher 14 des Computersystems nach Fig. 1 gespeichert und auf dem Prozessor 12 nach Fig. 1 ausgeführt wird. Es versteht sich jedoch, daß der Testmechanismus auch auf anderen Trägermedien, wie z. B. einer Platte bzw. Diskette, einem Band oder in Form elektrischer, optischer, drahtloser oder sonstiger Signale auf einem Telekommunikationsmedium bereitgestellt werden könnte. Die Benutzeranwendung könnte ebenso zumindest teilweise mit Hilfe von spezieller Hardware implementiert werden, beispielsweise auf einem ASIC implementiert sein. Es versteht sich weiterhin, daß, auch wenn spezielle Ausführungsformen der Erfindung beschrieben worden sind, viele Modifikationen/Ergänzungen und/oder Ersetzungen innerhalb des Rahmens der beanspruchten Erfindung vorgenommen werden können.

Claims (26)

1. Testmechanismus zum Testen des Härtens eines Gerätetreibers, wobei der Testmechanismus einen Abfangmechanismus (94) aufweist, der so betreibbar ist, daß er Zugriffsaufrufe auf ein Gerät von einem sich im Test befindlichen Gerätetreiber abfängt, und mit einer Schnittstelle (88), die so betreibbar ist, daß sie den Abfangmechanismus derart konfiguriert, daß in Reaktion auf Gerätezugriffsaufrufe Fehler entsprechend einem vorbestimmten Testmuster injiziert werden.

2. Testmechanismus nach Anspruch 1, wobei der Abfangmechanismus eine Mehrzahl von Abfangroutinen (98) aufweist.

3. Testmechanismus nach Anspruch 2, wobei jede Abfangroutine für einen gegebenen Typ von Gerätezugriffsaufruf vorgesehen ist.

4. Testmechanismus nach Anspruch 2 oder 3, mit einem Zuordnungsmechanismus zum Zuordnen von Gerätezugriffsaufrufen zu Abfangroutinen.

5. Testmechanismus nach Anspruch 4, wobei der Zuordnungsmechanismus eine Nachschlagetabelle aufweist.

6. Testmechanismus nach einem der vorstehenden Ansprüche, wobei der Abfangmechanismus so betreibbar ist, daß er Gerätezugriffsaufrufe überwacht, um zu bestimmen, wann ein Fehler einzubringen ist.

7. Testmechanismus nach einem der vorstehenden Ansprüche mit einem Zähler (982), der zumindest einem vorbestimmten Typ von Gerätezugriffsaufruf zugeordnet ist, wobei der Abfangmechanismus (94) so betreibbar ist, daß er den Zähler überwacht, der für jeden Gerätezugriffsaufruf dieses Typs modifiziert wird und so betreibbar ist, daß er einen Fehler in Reaktion auf eine festgestellte Zählung des Zählers einbringt.

8. Testmechanismus nach Anspruch. 8 mit einem Zähler (984), um eine Anzahl von Malen zu bestimmen, um welche ein Fehler für aufeinanderfolgende Gerätezugriffsaufrufe des vorbestimmten Typs eingebracht werden soll.

9. Testmechanismus nach Anspruch 3 oder einem der davon abhängigen Ansprüche 4 bis 7, wobei jeder Typ eines Gerätezugriffaufrufs separat überwacht wird.

10. Testmechanismus nach einem der vorstehenden Ansprüche, wobei eine Gerätezugriffsinfrastruktur auf einen Gerätezugriffsaufruf so reagiert, daß sie den Aufruf für die wahlweise Einfügung von Fehlern abfängt und der Abfangmechanismus so betreibbar ist, daß er eine emulierte Geräteantwort zurückliefert.

11. Testmechanismus nach einem der vorstehenden Ansprüche, wobei eine Zugriffsinfrastruktur für das Gerät auf einen Gerätezugriffsaufruf so reagiert, daß sie den Aufruf abfängt und der Abfangmechanismus so betreibbar ist, daß er eine wahlweise Einfügung von Fehlern bereitstellt, bevor der Gerätezugriff bewirkt wird.

12. Testmechanismus nach Anspruch 11, wobei der Abfangmechanismus mit Daten eines Gerätezugriffsaufrufs mit bestimmtem Operator und Operanden arbeitet.

13. Testmechanismus nach Anspruch 6, wobei die Schnittstelle so betreibbar ist, daß sie den Abfangmechanismus so konfiguriert, daß er bestimmt, wann der Abfangmechanismus einen Fehler einbringt.

14. Testmechanismus nach einem der vorstehenden Ansprüche, mit einem Computerprogrammcode, der so betreibbar ist, daß er den Abfangmechanismus und die Schnittstelle bildet.

15. Testmechanismus nach Anspruch 14 auf einem Trägermedium.

16. Testmechanismus nach einem der vorstehenden Ansprüche, wobei die Schnittstelle eine Anwenderprogrammschnittstelle aufweist, die auf eine Testanwendung reagiert, um ein Testmuster festzulegen.

17. Testanwendung auf einem Trägermedium für einen Testmechanismus nach Anspruch 14, wobei die Anwendung Computercode aufweist, der so ausgestaltet ist, daß er in folgender Weise betreibbar ist,

um die Schnittstelle mit einer Testkonfiguration zu versehen,

die Reaktion eines Gerätetreibers auf einen Testzustand, der durch den Abfangmechanismus eingefügt wurde, zu erfassen,

die erfaßte Reaktion mit einer in einem Testskript dargelegten, erwarteten Reaktion zu vergleichen, und

Unterschiede zwischen der erfaßten Reaktion und der erwarteten Reaktion zu identifizieren bzw. zu kennzeichnen.

18. Testanwendung nach Anspruch 17, wobei die Testanwendung Computercode aufweist, der so ausgestaltet ist, daß er in der Weise betreibbar ist, daß er eine Aufzeichnung der erfaßten Reaktionen aufrechterhält.

19. Computer mit einem Gerätetreiber für den Zugriff auf eine I/O-Einrichtung und mit einem Testmechanismus nach einem der Ansprüche 1 bis 16 zum Testen der Härtung von Gerätetreibern.

20. Verfahren zum Testen des Härtens eines Gerätetreibers, wobei das Verfahren das Abfangen von Zugriffsaufrufen auf den Gerätetreiber von dem Gerätetreiber aufweist und das Injizieren eines Fehlers in den Gerätetreiberzugriff entsprechend einem gewünschten Testmuster.

21. Verfahren nach Anspruch 20, welches das Zuordnen des Gerätezugriffsaufrufs zu zumindest einer Abfangroutine für das Handhaben des Gerätezugriffsaufrufs aufweist.

22. Verfahren nach Anspruch 21, welches das Zuordnen eines Gerätezugriffsaufrufs an eine Abfangroutine entsprechend einem Typ des Gerätezugriffsaufrufs aufweist.

23. Verfahren nach Anspruch 20, welches das Überwachen des Gerätezugriffsaufrufs aufweist, um zu bestimmen, wann ein Fehler einzuführen ist.

24. Verfahren nach Anspruch 23, welches das Modifizieren einer Zählung für einen Gerätezugriffsaufruf eines gegebenen Typs sowie das Injizieren eines Fehlers in Reaktion darauf aufweist, daß eine vorbestimmte Zahl erreicht worden ist.

25. Verfahren nach Anspruch 24, welches das getrennte Überwachen jedes Typs von Aufruf aufweist.

26. Verfahren nach Anspruch 24, welches weiterhin einen Schritt des Überwachens für eine Anzahl von Malen aufweist, um welche der Fehler in die Sequenz eingeführt werden soll.