PatentDe  


Dokumentenidentifikation DE69926712T2 02.03.2006
EP-Veröffentlichungsnummer 0001010087
Titel SICHERHEIT FÜR PLATTFORMUNABHÄNGIGE GERÄTETREIBER
Anmelder Sun Microsystems, Inc., Palo Alto, Calif., US
Erfinder SLAUGHTER, L., Gregory, Palo Alto, US;
SAULPAUGH, E., Thomas, San Jose, US;
TRAVERSAT, A., Bernard, San Francisco, US;
SCHMIDT, A., Jeffrey, Boulder Creek, US
Vertreter HOFFMANN & EITLE, 81925 München
DE-Aktenzeichen 69926712
Vertragsstaaten DE, FR, GB
Sprache des Dokument EN
EP-Anmeldetag 29.06.1999
EP-Aktenzeichen 999320690
WO-Anmeldetag 29.06.1999
PCT-Aktenzeichen PCT/US99/14759
WO-Veröffentlichungsnummer 0000000901
WO-Veröffentlichungsdatum 06.01.2000
EP-Offenlegungsdatum 21.06.2000
EP date of grant 17.08.2005
Veröffentlichungstag im Patentblatt 02.03.2006
IPC-Hauptklasse G06F 13/10(2006.01)A, F, I, ,  ,  ,   
IPC-Nebenklasse G06F 9/44(2006.01)A, L, I, ,  ,  ,      

Beschreibung[de]
GEBIET DER ERFINDUNG

Die vorliegende Erfindung betrifft allgemein das Gebiet der Computertechnik und insbesondere eine Computer Betriebssystemarchitektur. Noch spezieller betrifft die vorliegende Erfindung Software, Verfahren und Systeme, mit Hilfe derer auf Computersystemressourcen für Gerätetreiber zugegriffen werden kann. Die Erfindung findet Anwendung in den Gebieten von Elektronik und Computertechnik.

HINTERGRUND

Ein Gerätetreiber ist eine Software, die verwendet wird, um einen Austausch von Daten zwischen einem Computersystem (oder Plattform) und einem Peripheriegerät zu ermöglichen, das mit dem Computersystem verbunden ist. Üblicherweise funktioniert das Peripheriegerät, um eine Dateneingabe und/oder Datenausgabe (I/O) zu dem Computersystem zu bewirken. Beispiele von Peripheriegeräten umfassen Tastaturen, Drucker, Scanner, Netzwerkschnittstellenkarten und Grafikkarten, Modems und Bildschirme. Allgemein verarbeiten Gerätetreiber Daten, die durch das Computersystem zu dem Peripheriegerät gesendet oder von diesem empfangen werden, so dass die Daten in einem Format übertragen werden, das geeignet ist, um durch das Peripheriegerät oder das Computersystem verarbeitet werden zu können.

Die enge Beziehung zwischen dem Gerätetreiber und der Hardware sowie Software von sowohl dem Peripheriegerät als auch dem Computersystem, mit dem das Gerät gekoppelt ist, macht es erforderlich, dass Gerätetreiber in einer stark plattformabhängigen Weise geschrieben werden.

Beispielsweise müssen Gerätetreiber allgemein Speicherplatz erhalten, wenn die Durchführung ihrer Funktion aufgerufen wird. Normalerweise erfordert dies die Zuteilung von Speicherplatz, die durch den Treiber beschrieben werden muss. Der Treiber muss daher spezielle Kenntnis von der Plattform haben, um eine solche Anforderung durchzuführen. Daher erfordert das gleiche Peripheriegerät, z.B. ein Drucker, verschiedene Versionen von Treibersoftware für das Gerät (Drucker) für jede Plattform.

Die Plattformabhängigkeit der Treibersoftware erhöht somit die Kosten für die Entwicklung von Plattformen und Peripheriegeräten, da Hersteller von Peripheriegeräten und Computerbetriebssystemen neue Versionen und Aktualisierungen der Treibersoftware für neue Peripheriegeräte, neue Softwareplattformen und neue Betriebssystemausgaben bereitstellen müssen. Durch die plattformabhängige Treibertechnologie werden außerdem die Kosten für die Instandhaltung von Computersystemen erhöht, insbesondere von verschiedenen Computersystemen, die über Netzwerken verwendet werden, da Systemmanager neue und aktualisierte Gerätetreiber erhalten und installieren müssen, um den Benutzern den Zugriff auf Peripheriegeräte zu ermöglichen.

Es wäre daher vorteilhaft, Gerätetreiber zur Verfügung zu stellen, die plattformunabhängig sind, d.h. Treiber, die als eine Voraussetzung für den Betrieb keine Informationen über spezielle Plattformen erfordern. Solche plattformunabhängigen Gerätetreiber wären in der Lage, auf irgendeiner Plattform zu laufen, wodurch die Kosten und die Schwierigkeiten stark vermindert werden, die mit dem Gerätetreiber-Management verbunden sind.

ZUSAMMENFASSUNG DER ERFINDUNG

Mit Hilfe der vorliegenden Erfindung werden diese Forderungen erfüllt, indem ein plattformunabhängiger Gerätetreiber zur Verfügung gestellt wird. Wie vorstehend erläutert, resultiert die Plattformunabhängigkeit des Gerätetreibers der Erfindung aus der Verwendung von abstrakten Speicherobjekten, die die Beschreibung von Speicher ohne tatsächliche Ressourcenzuteilung durch das Computersystem ermöglichen. Indem ein allgemeines plattformunabhängiges Mittel beziehungsweise ein plattformunabhängiges Verfahren für Gerätetreiber zum Anfordern von Speicher zur Verfügung gestellt wird, wird die Notwendigkeit für die Einfügung eines sehr komplizierten, plattformspezifischen Codes vermieden, um zu vermeiden, dass Treiber Speicher anfordern müssen. Darüber hinaus ermöglicht es die vorstehende Erfindung in einigen speziellen Aspekten, dass eine solche Zuteilung auf sichere Weise erfolgt, so dass Datensicherheit nicht durch fehlerhafte Treiber gefährdet werden kann. In anderen speziellen Aspekten erleichtert die vorliegende Erfindung das Endianness-Prüfen und stellt zugeteilten Speicher zur Verfügung, der das geeignete Endianness für den Gerätetreiber beinhaltet.

Gemäß einem Aspekt stellt die vorliegende Erfindung eine Vorrichtung zum Zuteilen von Computerspeicher zu einem plattformunabhängigen Gerätetreiber zur Verfügung, umfassend: einen Busmanager, der dafür konfiguriert ist, Anforderungen für die Zuteilung des Computerspeichers von einem Gerätetreiber zu verarbeiten; einen plattformunabhängigen Gerätetreiber, der dafür konfiguriert ist, Anforderungen für die Zuteilung von Computerspeicher unter Verwendung eines abstrakten Adressraumes des Computerspeichers zu erzeugen; einen Mechanismus zum Verifizieren der Identität des Gerätetreibers; und einen Mechanismus für die Zuteilung des Computerspeichers in Reaktion auf die Anforderung.

In einem Ausführungsbeispiel beinhaltet das Verifizieren das Lokalisieren des Gerätetreibers in einer System-Datenbank, die den Gerätetreiber dem Busmanager zuordnet. In einem anderen Ausführungsbeispiel wird eine innere Klasse erzeugt, und die Verifizierung wird durchgeführt, wenn ein Lademittel des Systems den Treiber lädt. In noch einem anderen Ausführungsbeispiel ist eine Vielzahl von Busmanagern von solchen inneren Klassen für eine Vielzahl von Gerätetreibern vorgesehen. Die Busmanager der inneren Klasse sind mit eindeutigen Zuweisungen zu den Gerätetreibern ausgestattet, um eine eins-zu-eins Entsprechung zwischen den Gerätetreibern und den Busmanagern der inneren Klasse zu erzeugen. Da die Busmanager der inneren Klasse die gleichen Verfahren zur Verfügung stellen, um Speicherzuteilungsanforderungen zu verarbeiten, wie der Busmanager der äußeren Klasse, denkt jeder Gerätetreiber, dass er mit einem Busmanager der äußeren Klasse kommuniziert. Daher ist eine spezielle Kodierung, die über die Kenntnis des Busmanagers der äußeren Klasse hinausgeht, nicht erforderlich.

Gemäß einem weiteren Aspekt stellt die vorliegende Erfindung ein computerlesbares Medium mit computerlesbaren Programmcodeeinrichtungen zum Zuteilen von Speicherressourcen in einem Computer zur Verfügung, wobei die computerlesbaren Programmcodeeinrichtungen so konfiguriert sind, dass sie einen Computer veranlassen, die folgenden Schritte auszuführen: Bereitstellen eines Busmanagers, der dafür konfiguriert ist, auf Anforderungen für eine Speicherzuteilung von einem Gerätetreiber unter Verwendung einer abstrakten Adressraumdarstellung des Computerspeichers zu reagieren; Bereitstellen eines plattformunabhängigen Gerätetreibers, der dafür konfiguriert ist, Anforderungen für eine Speicherzuteilung anhand der abstrakten Adressraumdarstellung des Speichers zu erzeugen; Erzeugen einer Anforderung für eine Speicherzuteilung von dem Gerätetreiber an den Busmanager; Erzeugen einer inneren Klassendarstellung des Busmanagers in Reaktion auf die erzeugte Anforderung; Verifizieren der Identität des Gerätetreibers; und Verarbeiten der Anforderung unter Verwendung des Busmanagers der inneren Klasse.

In einem noch anderen Aspekt stellt die vorliegende Erfindung ein Computerdatensignal auf einer Trägerwelle mit auf einem Computer ausführbaren Befehlen zum Zuteilen von Speicherressourcen in einem Computer zur Verfügung, wobei die Befehle so konfiguriert sind, dass sie einen Computer veranlassen, folgende Schritte auszuführen: Bereitstellen eines Busmanagers, der dafür konfiguriert ist, auf Anforderungen für eine Speicherzuteilung von einem Gerätetreiber unter Verwendung einer abstrakten Adressraumdarstellung des Computerspeichers zu reagieren; Bereitstellen eines plattformunabhängigen Gerätetreibers, der dafür konfiguriert ist, Anforderungen für eine Speicherzuteilung anhand der abstrakten Adressraumdarstellung des Speichers zu erzeugen; Bereitstellen einer inneren Klassendarstellung des Busmanagers, der dafür konfiguriert ist, Speicherzuteilungsanforderungen von dem Gerätetreiber zu Verarbeiten; Erzeugen einer Anforderung für eine Speicherzuteilung von dem Gerätetreiber an den Busmanager; Erzeugen einer inneren Klassendarstellung des Busmanagers in Reaktion auf die erzeugte Anforderung; Verifizieren der Identität des Gerätetreibers; und Verarbeiten der Anforderung unter Verwendung des Busmanagers der inneren Klasse.

In einem noch weiteren Aspekt stellt die vorliegende Erfindung ein Verfahren für die Zuteilung von Speicherressourcen in einem Computer zur Verfügung, wobei das Verfahren Folgendes umfasst: Bereitstellen eines Busmanagers, der dafür konfiguriert ist, auf Anforderungen für eine Speicherzuteilung von einem Gerätetreiber unter Verwendung einer abstrakten Adressraumdarstellung des Computerspeichers zu reagieren; Bereitstellen eines plattformunabhängigen Gerätetreibers, der dafür konfiguriert ist, Anforderungen für eine Speicherzuteilung anhand der abstrakten Adressraumdarstellung des Speichers zu erzeugen; Erzeugen einer Anforderung für eine Speicherzuteilung von dem Gerätetreiber an den Busmanager; Erzeugen einer inneren Klassendarstellung des Busmanagers in Reaktion auf die erzeugte Anforderung; Verifizieren der Identität des Gerätetreibers; und Verarbeiten der Anforderung unter Verwendung des Busmanagers der inneren Klasse.

Diese und weitere Aspekte und Vorteile der vorliegenden Erfindung werden deutlich, wenn die nachfolgende Beschreibung zusammen mit den beiliegenden Zeichnungen gelesen wird.

KURZBESCHREIBUNG DER ZEICHNUNGEN

1 ist eine schematische Darstellung von einem Computersystem oder einer "Plattform" gemäß der vorliegenden Erfindung.

2 ist eine Darstellung, die ein objektorientiertes Betriebssystem gemäß einem Ausführungsbeispiel der vorliegenden Erfindung darstellt, wie zum Beispiel JavaOS von Sun Microsystems, Inc. (Mountain View, CA).

3 ist eine Darstellung, die eine Anordnung von Gerätetreibern, Busmanagern und einem Plattformmanager darstellt, der mit einem Bus gekoppelt ist, gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.

4 ist eine Darstellung, die eine Speicherobjekt-Hierarchie gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt.

5 ist ein Flussdiagramm, das den Vorgang der Speicherzuteilung für einen Gerätetreiber gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt.

6 ist ein Flussdiagramm, das Schritt 508 aus 5 im größeren Detail zeigt.

7A und 7B zeigen die nominalen und aktuellen Beziehung zwischen einem Busmanager, Busmanagern der inneren Klasse, die mit dem Busmanager in Beziehung stehen, und Gerätetreibern, die dem Busmanager zugewiesen sind, gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.

8 ist ein Flussdiagramm, das die Zuteilung von Systemressourcen zu einem Gerätetreiber in einer sicheren Weise zeigt.

9 ist eine Darstellung von einem Java-System-Datenbank-Eintrag gemäß einem Ausführungsbeispiel der Erfindung.

10 ist ein Flussdiagramm, das Schritt 804 aus 8 in größerem Detail darstellt.

11 ist ein Flussdiagramm, das ein Verfahren zum Handhaben von Veränderungen in Endianness gemäß einem Ausführungsbeispiel der Erfindung darstellt.

BESCHREIBUNG SPEZIELLER AUSFÜHRUNGSBEISPIELE

Die vorliegende Erfindung beinhaltet Software, Verfahren und eine Vorrichtung, mit Hilfe derer plattformunabhängige Gerätetreiber zur Verfügung gestellt werden. Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung, das nachfolgenden in größerem Detail beschrieben wird, ist ein Gerätetreiber vorgesehen, der lediglich für eine bestimmte Busarchitektur konfiguriert ist. Der Gerätetreiber erhält Speicher durch Anfordern von Speicherobjekten von einem Busmanager, der für die gleiche Busarchitektur konfiguriert ist wie der Gerätetreiber. Die Anforderung von dem Gerätetreiber erfolgt durch Spezifizieren eines Speicherbeschreibungsobjekts, das abstrakte Speicheradressen bezüglich eines abstrakten Adressraums spezifiziert, der von dem Treiber des Busmanagers verwaltet wird. Das Speicherbeschreibungsobjekt hat jedoch keine realen Systemspeicherressourcen, die ihm zugeteilt sind. Der Busmanager und ein Plattformmanager teilen ein reales Speicherobjekt, dem reale Systemspeicherressourcen in einem realen Speicheradressraum zugeteilt sind, für den Treiber zu. Die zugeteilten Speicherressourcen entsprechen den abstrakten Adressen, die durch die Speicherbeschreibung spezifiziert sind. Der Busmanager kann auch mit einem oder mehreren zusätzlichen gekoppelt sein, die zwischen dem Busmanager und den Plattformmanagern angeordnet sind. Daher benötigt der Gerätetreiber der Erfindung keine "Kenntnis" von der (d.h. keine spezielle Konfiguration für die) Plattform, auf der er betrieben wird, die über die Kenntnis der durch die Plattform verwendeten Systemarchitektur hinausgeht.

5.1 Einleitung

1 zeigt ein Beispiel von einem Computersystem 100, das für die Implementierung der vorliegenden Erfindung geeignet ist. Das Computersystem 100 enthält eine zentrale Verarbeitungseinheit (CPU) 102, die beispielsweise einen Sun Microsystems SPARC, Motorola PowerPC oder Intel Pentium Prozessor. Die CPU 102 ist wiederum mit einem Speicher 104 gekoppelt. Der Speicher 104 kann irgendeinen Typ von Speichereinrichtung enthalten, der in einem Computersystem verwendet wird, einschließlich ein Speicher mit wahlfreiem Zugriff (RAM) und ein Nur-Lese-Speicher (ROM). Die CPU 102 ist außerdem mit einem Bus 106 gekoppelt, wie zum Beispiel ein PCI-Bus oder ein S-Bus. Eine Vielzahl von Eingabeeinrichtungen 108 und 110 sowie Ausgabeeinrichtungen 112 ist ebenfalls mit dem Bus 106 gekoppelt. Beispiele solcher Eingabe- und Ausgabeeinrichtungen beinhalten, sind aber nicht darauf beschränkt, Drucker, Monitore, Modems und/oder Netzwerk/Telefonverbindungen. Normalerweise hat jede dieser Einrichtungen einen zugehörigen Treiber, wie nachfolgend in größerem Detail beschrieben wird. Daher kann die Eingabeeinrichtung 108 beispielsweise eine Netzwerkschnittstellenkarte sein, durch die das Computersystem 100 mit einem lokalen Netzwerk (LAN) verbunden ist, die Eingabeeinrichtung 110 kann eine Tastatur sein, und die Ausgabeeinrichtung 112 kann ein Monitor sein. Die CPU 102 kann außerdem mit einem Massenspeicher 114, wie z.B. eine Festplatte oder eine CD-ROM-Platte, und einer DMA-Steuerung 116 gekoppelt sein. Die Verbindung zwischen der CPU 102 und dem Massenspeicher 114 kann über einen zweiten Bus 118 erfolgen, wie z.B. ein kleiner Computersystemschnittstellenbus (SCSI).

Obwohl das Computersystem 100 unter Verwendung einer bestimmten Konfiguration von Hardwareelementen dargestellt ist, ist offensichtlich, dass die Erfindung nicht auf den Betrieb auf einer solchen Konfiguration alleine beschränkt ist. Daher ist das Computersystem 100 repräsentativ für Computersysteme allgemein und umfasst eine breite Vielfalt von Computereinrichtungen einschließlich, aber nicht darauf begrenzt, Personalcomputer, Mainframes oder Minicomputer, sowie Smart-Systeme, wie zum Beispiel Set-Top-Boxen, die bei hochauflösenden Fernsehgeräten, Kabel- oder Satellitenübertragung sowie auch bei Zellulartelefonen verwendet werden. Weitere Beispiele von Computersystemen, die für die Verwendung mit der vorliegenden Erfindung geeignet sind, sind für den Fachmann auf dem Gebiet der Computertechnik und Elektronik offensichtlich.

2 zeigt bei 200 ein Beispiel von einer Software, die beispielsweise im Speicher 104 gespeichert ist und/oder auf der CPU 102 läuft, und die in einer Anzahl von Schichten angeordnet ist. Die beiden obersten Schichten 202 beinhalten Software, die plattformunabhängig ist, d.h. Software, die nicht speziell konfiguriert ist, um auf einem bestimmten Computersystem zu laufen, sondern die auf irgendeinem von mehreren Computersystemen laufen kann. Die übrigen unteren Schichten 204 sind plattformabhängige Software, d.h. Software, die speziell für ein bestimmtes Computersystem geschrieben werden muss.

Die Schichten 202 beinhalten eine Anwendungsschicht 206. Die Schicht 206 enthält Software-Anwendungen, die üblicherweise von Computerbenutzern verwendet werden. Eine solche Software beinhaltet Textverarbeitung, Grafikprogramme, Datenbankprogramme und Desktop-Publishing-Programme. Diese Anwendungen laufen zusammen mit einem Laufzeit-System 208. Das Laufzeit-System 208 beinhaltet in einem Ausführungsbeispiel eine Java Virtual Maschine (JVM) 210, die Befehle in Form von maschinenunabhängigen Byte-Codes empfängt, die durch die Anwendung erzeugt werden, die in der Anwendungsschicht 206 läuft, und interpretiert die Befehle, indem sie konvertiert werden, und führt sie aus. Andere Typen von virtuellen Maschinen können mit der vorliegenden Erfindung verwendet werden, wie dies jedoch für den Fachmann in der Computertechnik und Elektronik offensichtlich ist.

Das Laufzeit-System 208 enthält einen Satz von zusätzlichen Funktionen 212, die Leistungsmerkmale unterstützt, wie zum Beispiel I/O, Netzwerkoperationen, Grafiken, Drucken und ähnliches. In dem Laufzeit-System 208 sind außerdem eine Geräteschnittstelle 214, die die Funktion der Busse 106 und 118 unterstützt, sowie Geräte 108, 110 und 112 enthalten. Die Geräteschnittstelle 214 enthält Gerätetreiber 216, die objektorientierte Programme sind, die geschrieben sind, um die verschiedenen Geräte zu unterstützen, die mit dem Computersystem 100 verbunden sind, wie zum Beispiel die Geräte 108, 110 und 112, Gerätemanager 218, ein plattformunabhängiger Speicher 220 und plattformunabhängige Busmanager 222, die die Busse 106 und 118 unterstützen. Es ist daher offensichtlich, dass die Gerätetreiber 216 und Busmanager 222 mit jeder Plattform verwendet werden können, einschließlich Plattformen, die noch entwickelt werden. Andere verschiedene Manager und Komponenten (nicht gezeigt) sind normalerweise mit einer Geräteschnittstelle 214 versehen und sind dem Fachmann auf dem Gebiet der Computertechnik und Elektronik bekannt.

Plattformabhängige Schichten 204 beinhalten eine Plattform-Schnittstelle 224, die DMA-Klassen 226, Busmanager 228 und Speicherklassen 230 sowie zusätzliche weitere Merkmale enthält, die das Laufzeit-System 208 unterstützen. Außerdem können in der Plattformschnittstelle 224 zusätzliche enthalten sein, einschließlich Unterbrechungsklassen (nicht gezeigt), um das Computersystem 100 zu unterstützen. In einem Ausführungsbeispiel sind diese Klassen, Manager und Funktionen in der Java-Programmiersprache geschrieben. Weitere Details bezüglich dieser Merkmale können in der vorstehend genannten anhängigen US-Patentanmeldung Nr. 09/048,333 gefunden werden.

OS-spezifische Verfahren 232 beinhalten DMA-spezifische Verfahren 234 und speicherspezifische Verfahren 236, die in einer für die CPU 102 spezifischen Sprache geschrieben sind (und somit spezifisch sind). Diese Verfahren arbeiten mit Microkernel 238 zusammen. Schließlich ist die unterste Schicht eine Boot-Schnittstelle 240, die unter anderem das Laden und das Initialisieren von Software in einem Speicher unterstützt, wenn das Computersystem 100 gestartet wird. Zusätzliche Details über diese Merkmale können in der oben genannten anhängigen US-Patentanmeldung Nr. 09/048,333 gefunden werden.

5.2 Zuteilung von Gerätetreiberspeicher

Die Beziehung zwischen den plattformunabhängigen Busmanagern 222 und Gerätetreibern 216 ist im größeren Detail bei 300 in 3 gezeigt. Hier befindet sich der Plattformmanager 302 ganz oben in einer Hierarchie von m Busmanagern für m Busse, einschließlich Busmanager 1 bei 304 bis Busmanager m bei 306. Der Busmanager 1 ist mit dem Bus 106 gekoppelt, der mit jedem von n Gerätetreibern für n Geräte gekoppelt ist, die allgemein als Gerätetreiber 1 308 bis Gerätetreiber n 310 gezeigt ist. Alternativ kann nur ein Busmanager und ein Gerätetreiber mit dem Bus 106 gekoppelt sein. Der Plattformmanager 302 funktioniert, um realen Speicher (d.h. physikalischer Speicher, wie zum Beispiel I/O-Anschluss-Speicher, virtueller Speicher oder DMA-Speicher) im Gegensatz zu abstraktem Speicher zuzuteilen. Die Busmanager 304 und 306 sowie die Treiber 308 und 310 funktionieren allgemein so, wie vorstehend beschrieben wurde. Es wird nun ein Ausführungsbeispiel der Erfindung beschrieben, bei dem die Kommunikation zwischen Treibern 308 und 310 über Busmanager 304 und 306 zu dem Plattformmanager 302 erfolgt, um Speicher für Gerätetreiber in plattformunabhängiger Weise zuzuweisen.

Gemäß einem Aspekt der vorliegenden Erfindung sind ein Verfahren, ein System und Software für die Zuteilung von Speicher zu einem plattformunabhängigen Gerätetreiber vorgesehen, wobei ein plattformunabhängiger Gerätetreiber seine Anforderung für die Zuteilung von Speicher anhand eines abstrakten Adressraums spezifiziert, der mit einem Busmanager in Beziehung steht. Der Busmanager empfängt die Anforderung und übersetzt dann die Anforderung von dem Busmanager in abstrakten Adressraum zu entweder einen abstrakten Adressraum von einem höheren Busmanager, wenn einer Hierarchie von Busmanagern vorhanden ist, oder zu dem Busmanager der höchsten Ebene, der Plattformmanager, der einen realen Adressraum verwendet. Wenn die Anforderung den Plattformmanager erreicht, dann wird realer Speicher zugeteilt, und die angeforderten Adressen werden über den (die) Busmanager einer niederen Ebene zu dem Gerätetreiber zurückgeleitet. Daher ist es nicht erforderlich, dass der Gerätetreiber mit dem Plattform-Manager hinsichtlich eines realen Speichers kommuniziert, was eine plattformabhängige Kodierung des Gerätemanagers erforderlich machen würde. Statt durch Kommunikation mit dem Plattformmanager über Busmanager kann der Gerätetreiber seine Anforderung für die Speicherzuweisung bezüglich eines abstrakten Adressraums eines einzelnen Busmanagers verarbeiten, was plattformunabhängig ist.

Bei einem Ausführungsbeispiel wird die vorstehend beschriebene Kommunikation unter Verwendung einer hierarchischen abstrakten Speicherobjektklasse und damit in Beziehung stehenden Unterklassen durchgeführt, die durch die Java-Programmiersprache vorgesehen sind. Diese Klassen und Unterklassen sind im Detail in der vorstehend genannten anhängigen US-Patentanmeldung Nr. 09/048,333 beschrieben. Es ist jedoch offensichtlich, dass die hier beschriebenen Verfahren, Systeme und Software unter Verwendung irgendeiner ähnlichen Programmiersprache ermöglicht werden können, und zwar unter Verwendung von Techniken, die dem Fachmann auf dem Gebiet der Computertechnik bekannt sind.

Es wird nun auf 4 Bezug genommen, in der die oben beschriebene Hierarchie von abstrakten (non-instantiable) und instantiablen Speicherklassen in größerem Detail bei 400 dargestellt ist. An der Spitze der Hierarchie 400 steht die abstrakte Speicherklasse 402. Diese Klasse enthält lediglich die allgemeinen Attribute einer Basisadresse, Länge und Randbedingungen, wobei jedes dieser Attribute auch ein Objekt ist. Die Basisadressen- und Längen-Attribute sind dem Fachmann auf dem Gebiet der Computertechnik bekannt. Die Randbedingungs-Attribute beinhalten verschieden Speicherzuteilungs- und Speicherbedingungen. Die abstrakte Unterklasse Hauptspeicher 404 und die instantiablen Unterklassen Speicherbeschreibung 406 und DMA-Speicher 408 leiten sich direkt aus dem Speicher ab.

Der Hauptspeicher 404 ist eine abstrakte Klasse, die jene Attribute enthält, die sich aus den abstrakten Verfahren des Speichers 402 zum Verwalten des Zwischenspeichers ableiten, die schließlich in dem instantiablen physikalischen Speicher 412, dem Anschluss-IO-Speicher 414 und dem virtuellen Speicher 416 implementiert sind. Die letzteren beiden Klassen leiten sich aus dem Hauptspeicher durch die abstrakte Klasse des zugreifbaren Speichers 410 ab, der sich ebenfalls aus dem Hauptspeicher ableitet. Zwischenspeicher-Managementverfahren sind notwendigerweise plattformspezifisch; aber diese plattformspezifischen Speicher-Managementfunktionen können unter Verwendung der abstrakten Klasse Hauptspeicher in plattformunabhängiger Weise zugegriffen werden. In einem Ausführungsbeispiel enthält der zugreifbare Speicher nur plattformunabhängige Verfahren und wird von Busmanagern zu Treibern geleitet. Treiber sind außerdem konfiguriert, um lediglich die plattformunabhängigen Verfahren in Hauptspeicher und Speicher zu verwenden. Die plattformspezifischen Verfahren in physikalischer Speicher, Anschluss-IO-Speicher, virtueller Speicher und DMA-Speicher werden von den Busmanager verwendet, der plattformspezifische Informationen hat, um es dem Treiber zu ermöglichen, in plattformunabhängiger Weise auf den Speicher zuzugreifen, wie nachstehend beschrieben wird.

Die Speicherbeschreibung 406 ist eine nicht-abstrakte Klasse, die die Objekte Adressraum und DevInfo zusätzlich zu Basis, Länge und Bedingungsobjekten enthält, die sich aus dem Speicher ableiten. Der Adressraum enthält Bus-spezifische Informationen und Verfahren bezüglich des abstrakten Adressraums, die von dem Busmanager verwendet werden. DevInfo enthält Bus-spezifische Informationen, die von dem Busmanager erhalten werden, und enthält Verfahren, die es dem Gerätetreiber ermöglichen, das korrekte Speicherbeschreibungsobjekt aus einem Array von solchen Objekten auszuwählen, wie nachstehend beschrieben wird. DMA-Speicher 408 stellt Verfahren zum Errichten von DMA-Abbildungen zu physikalischem Speicher und zur Durchführung der entsprechenden Rück-Abbildungen zur Verfügung. Daher können die Gerätetreiber DMA-Speicherobjekte verwenden, um eine Basisadresse zu erhalten, um in plattformunabhängiger Weise zu einer DMA-Steuerung 116 geführt zu werden.

Ein Ausführungsbeispiel von einem Verfahren, bei dem die oben beschriebenen Treiber, Manager und Objekte zusammen arbeiten, um plattformunabhängige Treiber zur Verfügung zu stellen, wird unter Bezugnahme auf 5 bei 500 beschrieben. In Schritt 502 leitet der Gerätetreiber eine Anforderung für eine Speicherzuteilung zu einem Busmanager der niedrigsten Ebene. Der Busmanager erzeugt ein Array von Speicherbeschreibungsobjekten, die von dem Gerätetreiber verwendet werden können. Die Anzahl an Speicherbeschreibungsobjekten in dem Array hängt von der Anzahl von Typen von Speicherobjekten ab, die der bestimmte Gerätetreiber zuweisen möchte. Das heißt, in dem beschriebenen Ausführungsbeispiel enthält die Liste nur Speicherbeschreibungsobjekte, die der Gerätetreiber tatsächlich verwenden muss. Obwohl in der Theorie irgendeine Anzahl von Speicherbeschreibungsobjekten durch ein bestimmtes Gerät verwendet werden kann, ist diese Anzahl in der Praxis normalerweise recht klein. Jeder der Einträge in den Speicherbeschreibungsobjekten enthält plattformabhängige Informationen in dem Adressraum und DevInfo-Objektfelder. Das Array kann auch ein "nur-lese"-Array sein, so dass der Gerätetreiber die Speicherbeschreibungsobjekte nicht modifizieren kann. Das Array kann in vielerlei Weise konstruiert sein. In einem Ausführungsbeispiel wird das JavaOS-Betriebssystem verwendet, und der Busmanager konstruiert das Array, indem zuerst mit dem Java-Systemlademittel Kontakt aufgenommen wird, das beim Starten eine Liste von allen zugehörigen Speicherbeschreibungsobjekten erzeugt. In einem anderen Ausführungsbeispiel wird das Array zu dem Zeitpunkt konstruiert, zu dem der Gerätetreiber geladen wird. In Schritt 504 verwendet der Gerätetreiber wie in dem DevInfo-Objektfeld enthaltenen Informationen, um das geeignete Speicherbeschreibungsobjekt zu identifizieren. In einem Ausführungsbeispiel verwendet der Gerätetreiber die in den Basis-, Länge- und Adressraum-Objektfeldern gespeicherten Informationen, um das geeignete Speicherbeschreibungsobjekt auszuwählen. In einem weiteren Ausführungsbeispiel verwendet der Gerätetreiber die in den Basis-, Länge-, Adressraum- und DevInfo-Objektfeldern gespeicherten Informationen, um das geeignete Speicherbeschreibungsobjekt auszuwählen.

Wenn das geeignete Speicherbeschreibungsobjekt bestimmt ist, werden in Schritt 506 verschiedene Speicherzuteilungswege durchlaufen, und zwar abhängig davon, ob der gewünschte Speicher ein zugreifbarer Speicher oder ein DMA-Speicher ist. Wenn ein zugreifbarer Speicher gewünscht ist, dann geht der Ablauf weiter zu Schritt 508, wo zugreifbarer Speicher durch den Plattformmanager zugeteilt und dem Speicherbeschreibungsobjekt in dem Adressraumfeld des Objekts die Adressen zur Verfügung gestellt werden. Das Speicherbeschreibungsobjekt, das die realen Speicheradressen enthält (oder eine Referenz zu diesem Objekt, wie zum Beispiel eine Objektreferenz), wird in Schritt 510 wird durch den Gerätetreiber empfangen, um durch den Treiber verarbeitet zu werden. Alternativ, wenn der zuzuteilende Speicher ein DMA-Speicher ist, dann geht die Steuerung weiter zu Schritt 512, wo der DMA-Speicher zugeteilt wird, und bei Schritt 514 wird ein geeignetes Speicherobjekt (oder Objektreferenz) von dem Gerätetreiber empfangen.

Die Details der Schritte 508 und 512, die auf die Bestimmung in Schritt 506 folgen, sind größtenteils identisch, mit Ausnahme der Details zur Zuteilung von zugreifbarem Speicher oder DMA-Speicher, und werden zusammen unter Bezugnahme auf 6 bei 600 beschrieben. Beginnend bei Schritt 602 empfängt der Busmanager die Zuteilungsanforderung von dem Gerätetreiber. In einem Ausführungsbeispiel wählt der Gerätetreiber auch das geeignete Speicherbeschreibungsobjekt. In Schritt 604 bestimmt der Busmanager, ob er der Busmanager der höchsten Ebene ist, d.h. der Plattformmanager. Wenn der Busmanager nicht der Plattformmanager ist (d.h. die Antwort in Abfrage 604 ist nein), dann übersetzt der Busmanager in Schritt 606 die Adressen in dem Speicherbeschreibungsobjekt, um mit den Anforderungen des Busmanagers der höheren Ebene übereinzustimmen. In Schritt 608 wird das übersetzte Speicherbeschreibungsobjekt zu dem Busmanager der nächst höheren Ebene geleitet, und bei Schritt 604 wird die Schleife wiederholt. Die Schleife kann mehrere Male wiederholt werden, einmal für jeden Bus zwischen dem ersten Busmanager und dem Plattformmanager. Es ist offensichtlich, dass der Schritt zur Bestimmung, ob ein bestimmter Manager ein Busmanager oder ein Plattformmanager ist, für den Manager inhärent ist, und so gibt es normalerweise keine aktuelle Überprüfung. Stattdessen ist der Schritt nur beschrieben, um das Verständnis der Funktion der Erfindung zu erleichtern.

In Schritt 605, wenn der Busmanager die Adressen in dem Speicherbeschreibungsobjekt übersetzt, um den Anforderungen des Busmanagers der höheren Ebene zu entsprechen, wird die Adresse innerhalb des Adressraumobjekts nicht übersetzt. Stattdessen ist es die Adresse innerhalb des Speicherbeschreibungsobjektes, die übersetzt wird. In einem noch spezielleren Beispiel, wenn der Busmanager eine Speicherbeschreibung (in diesem Beispiel bezeichnet als "MD1") erhält, dann enthält das Speicherbeschreibungsobjekt eine Basisadresse "BA1" und eine Basislänge "BL1" (da die Speicherbeschreibung eine Unterklasse des Speichers ist, siehe oben). Diese Adressen sind alle Adressen des abstrakten Adressraums, der durch den Busmanager verwendet wird (in diesem Beispiel als "AS1" bezeichnet). Der Busmanager übersetzt diese Adressen in einen neuen Adressraum ("AS2") von einem übersetzten Speicherbeschreibungsobjekt ("MD2"), wenn die Anforderung nach einem Adressraum zu einem zweiten Busmanager geleitet wird, der von diesem Busmanager verwaltet wird. Daher wird BA1 als eine Adresse in dem Adressraum AS1 zu BA2 des Adressraums AS2 übersetzt (ähnlich wie für BL1). Dies wird fortgesetzt, bis der Plattformmanager erreicht ist und wo der Adressraum ein realer Adressraum der Plattform ist.

Hier wird ein konkreteres Beispiel angegeben. Ein Gerätetreiber wird für einen PCI-Bus geschrieben, der keinen eingreifenden Busmanager zwischen dem PCI-Busmanager und der Plattform hat. Der Treiber fordert einen Speicher an, der die Adresse 0x300 von dem "config"-Adressraum des PCI-Busses spezifiziert. Der PCI-Busmanager weiß, dass config am Anschluss 0x2000 startet und bildet 1-zu-1 ab, so übersetzt er 0x300 des config-Adressraums in 0x2300 des "Anschluss-IO"-Adressraums. Bei einer SPARC-Plattform wird die 0x300 Adresse vom Gerätetreiber (plattformunabhängig) angefordert, aber zu diesem Zeitpunkt weiß der Busmanager, dass der config-Adressraum auf die physikalische Adresse 0x14000 abgebildet ist, so dass die Übersetzung zu 0x14300 des physikalischen Speicheradressraums sein würde.

Wenn der Busmanager, der von dem Gerätetreiber aufgerufen wird, der Plattformmanager ist, oder wenn das übersetzte Speicherbeschreibungsobjekt den Plattformmanager erreicht, dann teilt der Plattformmanager in Schritt 610 die realen Speicheradressen zu. Die zugeteilten Adressen sind zugreifbare Speicheradressen, wenn die Auswahl des Speicherbeschreibungsobjektes mit einer bestätigenden Antwort bei Schritt 506 übereinstimmt. Andererseits sind die zugeteilten Adressen BMA-Adressen. In jedem Fall leitet der Plattformmanager das geeignete Speicherobjekt (zugreifbarer Speicher oder DMA-Speicher) an den nächst niedrigen Busmanager, und so weiter, bis das Speicherbeschreibungsobjekt zum Gerätetreiber geleitet ist. Wenn es hier keine Busmanager-Hierarchie gibt, dann wird das Speicherbeschreibungsobjekt direkt zum Gerätetreiber geleitet. Der Treiber führt dann seine Funktion aus, die unter Verwendung der realen Speicheradressen definiert ist, die durch den indirekten Adressanforderungsvorgang erhalten werden, wie gerade beschrieben wurde.

Die Verwendung des vorstehend beschriebenen Speicherbeschreibungsobjekts als ein Mittel zur Zuteilung von Speicher bietet zwei Vorteile. Erstens sind Speicherbeschreibungsobjekte Speicherobjekte in einem abstrakten Adressraum. Dieser Adressraum existiert nicht real auf der Plattform, sondern lediglich in der Welt des Busmanagers. Daher können Speicherressourcen, die zugeteilt werden können, vollständig charakterisiert werden; es müssen keine Systemressourcen zugeteilt werden. Zweitens, Speicherbeschreibungsobjekte, Speicher-Unterklassen, erscheinen dem Gerätetreiber bezüglich der Form sehr ähnlich zu den Speicherobjekten (d.h. zugreifbarer Speicher oder DMA-Speicher), die möglicherweise dem Gerätetreiber zugewiesen werden. Dadurch wird das Treiber-Design auf ähnliche Weise vereinfacht.

5.3 Sichere Zuteilung von Gerätetreiberspeicher

In einigen Fällen ist es gewünscht, die vorstehend beschriebene Zuteilung von Gerätetreiberspeicher oder irgendwelche anderen Aufrufe von einem Gerätetreiber zu einem Busmanager (z.B. für andere Systemdienste, wie Verbinden, Trennen oder Abfrageunterbrechungen) in einer sicheren Weise zu implementieren. Dies ist insbesondere dann wichtig, wenn netzwerkbasierte Treiber, wie zum Beispiel Treiber, die in der Java-Programmiersprache von Sun Microsystems geschrieben sind, von Parteien verfügbar sind, die andere sind als der Betriebssystem-Entwickler. Es kann beispielsweise gewünscht sein, einen fremden Gerätetreiber daran zu hindern, sich selbst gegenüber einem Busmanager als ein anderer legitimierter Treiber zu identifizieren. Dies kann praktisch sein, um die Robustheit des Systems zu verbessern, indem es z.B. ermöglicht wird, dass das System ungewünschte Gerätetreiber identifiziert und isoliert, um somit einen Systemzusammenbruch zu verhindern. Ein solcher Sicherheitsmechanismus kann außerdem praktisch sein, um zu verhindern, dass betrügerische Gerätetreiber empfindliche Daten von dem System unerlaubt löschen, verändern und/oder kopieren. Anhand eines Beispiels kann ein fehlerhafter betrügerischer Gerätetreiber als ein Druckertreiber getarnt sein und die zu druckenden Daten an eine entfernte Stelle kopieren.

Ein Ausführungsbeispiel von einem solchen Sicherheitsmechanismus, der durch die vorliegende Erfindung zur Verfügung gestellt wird, ist unter Bezugnahme auf die in 7A und 7B dargestellte Gerätetreiber/Busmanager-Architektur dargestellt. 7A zeigt eine Reihe von Gerätetreibern: Gerätetreiber 1 702, Gerätetreiber 2 704, bzw. Gerätetreiber n 706. Die Gerätetreiber sind jeweils nominal zugewiesen, um mit dem Busmanager 710 zu kommunizieren, der wiederum mit einer Reihe von Busmanagern der inneren Klasse (IC) in Beziehung steht: IC-Busmanager 1 712, IC-Busmanager 2 714 und IC-Busmanager n 716, d.h. jeder IC-Busmanager ist ein innere Klassen-Instantiation des Busmanagers 710 und beinhaltet alle Verfahren des Busmanagers 710. Jeder IC-Busmanager wird nur einem der Gerätetreiber zugewiesen und erscheint seinem Busmanager 710 als zugewiesener Gerätetreiber. Daher ist der aktuelle Vorgang der Kommunikation zwischen jedem der Gerätetreiber und seinem eindeutig zugewiesenen IC-Busmanager in 7B dargestellt. Durch Verwendung eines sicheren Verfahrens zum Zuweisen jedes Gerätetreibers zu jedem IC-Busmanager verhindert die vorliegende Erfindung die Probleme von herumirrenden, fehlerhaften Gerätetreibern, damit solche Treiber nicht auf die Systemressourcen zugreifen können.

Ein Ausführungsbeispiel von einem Verfahren zum Bereitstellen der vorstehend beschriebenen sicheren Busmanagerunterstützung ist in 8 gezeigt. Das in diesem Ausführungsbeispiel beschriebene Verfahren beinhaltet die Verwendung von Prozeduren und Merkmalen, die durch JavaOS unterstützt werden, aber äquivalente Prozeduren und Merkmale für andere Betriebssysteme sind für den Fachmann auf dem Gebiet der Computertechnik offensichtlich. Wie bei 800 gezeigt, wird in einem ersten Schritt 802, wenn der Gerätetreiber durch das Java-System-Lademittel (JFL) geladen wird, die Gerätetreiber-Objektreferenz zu dem Busmanager geleitet, der zugewiesen ist, um den Gerätetreiber zu unterstützen. Das Busmanagerverfahren "getServingParent" wird aufgerufen und leitet die Gerätetreiber-Objektreferenz weiter. Die Gerätetreiber-Objektreferenz und die Busmanager-Zuweisung wird durch das JSL bestimmt, das auf einem Gerätebaum nach unten wandert, der durch die Java-System-Datenbank (JSD) konstruiert ist, wie bei 900 in 9 dargestellt. Dort beinhaltet ein beispielhafter Baum einen Eintrag für Plattformmanager 902, der eine Elternbeziehung mit dem Busmanager 2 904 und dem Busmanager 1 906 hat. Der Busmanager 2 hat wiederum eine Elternbeziehung mit den Gerätetreibern Gerätetreiber 1 908, Gerätetreiber n 910. Der Busmanager 1 hat wiederum eine Elternbeziehung mit den Gerätetreibern Gerätetreiber n + 1 912, Gerätetreiber m 912. Auf diese Weise wird jeder registrierte Gerätetreiber einem geeigneten Busmanager zugewiesen.

Es wird nun wieder auf 8 Bezug genommen, wobei in Schritt 804 der IC-Busmanager konstruiert ist. Dieser Schritt ist in größerem Detail in 10 bei 1000 dargestellt. Wenn die Objektreferenz für den Gerätetreiber erhalten wurde, dann wird die innere Klasse des Busmanagers bei Schritt 1002 durch einen Aufruf des Konstruktionsverfahrens der inneren Klasse des Busmanagers instantiated. Die Objektreferenz für den zugewiesenen Gerätetreiber wird dem Konstrukteur des IC-Busmanagers zugeführt, und in Schritt 1004 werden Informationen bezüglich des Gerätetreibers vom JSD unter Verwendung der Gerätetreiber-Objektreferenz erhalten. In Schritt 1006 wird diese Information zu einem Behälterobjekt kopiert, der in dem IC-Busmanager verfügbar ist, um den IC-Busmanager mit dem Gerätetreiber in Beziehung zu setzen.

Es wird nun noch einmal auf 8 Bezug genommen, wobei in Schritt 806 eine Objektreferenz des IC-Busmanagers, der gerade konstruiert wurde, dem Gerätetreiber zugeführt wird. Der Gerätetreiber funktioniert jedoch so, als wenn er direkt mit dem Busmanager verbunden wäre. Daher, unter Verwendung der inneren Klassendarstellungen des Busmanagers und unter Bezugnahme auf das JSD für Information auf dem Gerätetreiber können lediglich solche Gerätetreiber, von denen bekannt ist, dass sie mit Geräten in Beziehung stehen, die mit dem JSD registriert sind, auf Systemressourcen zugreifen. Eine weitere Ebene der Sicherheit kann erreicht werden, indem erzwungen wird, dass der Gerätetreiber das geeignete Speicherbeschreibungsobjekt aus einer Nur-Lese-Liste von solchen Objekten liest, die durch den Busmanager für den Gerätetreiber verfügbar gemacht sind.

5.4 Handhabung von Endianness

Die vorstehend beschriebenen Ausführungsbeispiele zum Bereitstellen von plattformunabhängigen sicheren Gerätetreibern müssen Situationen in Betracht ziehen, in denen ein Gerätetreiber auf Speicher einer bestimmten Endianness von einem Plattformmanager der entgegengesetzten Endianness zugreifen kann. Noch komplexer sind Systeme, die mehrere hierarchische Busmanager haben, wie in 3 dargestellt und wie vorstehend beschrieben. In solchen Situationen muss der Gerätetreiber konfiguriert sein, um seine Endianness-Anforderungen zu berücksichtigen, die Endianness von jedem Busmanager und die Endianness des Plattformmanagers, so dass der Speicher 'swapped' und 'unswapped' werden kann, falls erforderlich. Eine solche Anordnung erfordert jedoch einen plattformabhängigen Gerätetreiber. Die vorliegende Erfindung überwindet diese Beschränkung, wie nun beschrieben wird.

In einem Ausführungsbeispiel beinhaltet die vorliegende Erfindung ein Speicherbedingungsobjekt, das von dem Gerätetreiber zum Busmanager geleitet wird (oder der inneren Klasse davon). In einem Ausführungsbeispiel ist das Speicherbedingungsobjekt das Bedingungsobjektfeld von dem Speicherbeschreibungsobjekt, das verwendet wird, um die Speicherzuteilungsanforderung des Gerätetreibers zu verarbeiten, wie vorstehend beschrieben. Es ist jedoch offensichtlich, dass ein separates Objekt verwendet werden kann. Daher bezieht sich die nachstehende Diskussion allgemein auf ein Speicherbedingungsobjekt. Das Speicherbedingungsobjekt enthält zumindest zwei Objektfelder, ein variables Endianness-Feld und ein Swapped-Feld. Das variable Endianness-Feld gibt dem Busmanager an, ob das Endianness des durchgelassenen Objekts groß oder klein ist. Für ein großes Endian wird das höchstwertigste Byte in der niedrigsten Adresse des Speichers gespeichert. Für ein kleines Endian wird das niedrigstwertigste Byte in der niedrigsten Adresse des Speichers gespeichert. Die Swapped-Variable ist ein Boolean, um anzugeben, ob das Endianness des Speicherbedingungsobjekts zuvor geswappt wurde. Andere Zuteilungs- und Zugriffsbedingungen können in dem Speicherbedingungsobjekt enthalten sein, falls gewünscht.

Die Verwendung des Speicherbedingungsobjekts, um Veränderungen in dem Endianness bei der Zuteilung von Speicher für einen Gerätetreiber in Betracht zu ziehen, ist bei 1100 in 11 dargestellt. Dort, beginnend bei 1102, erstellt der Gerätetreiber ein Speicherbedingungsobjekt und stellt den Standardwert von Swapped auf falsch ein. Danach, in Schritt 1104, wird das Endianness des Treibers auf einen Wert eingestellt, der groß oder klein entspricht. Das Speicherbedingungsobjekt wird dann in Schritt 1106 dem geeigneten Busmanager als Teil eines Aufrufs durch den Gerätetreiber zugeführt, um auf Speicher zuzugreifen.

In Schritt 1108 wird das Endianness des Busmanagers mit dem Wert verglichen, der in dem Speicherbedingungsobjekt vorhanden ist, das durch den Gerätetreiber weitergeleitet wurde. Wenn die Werte gleich sind, dann ist in Schritt 1110 das Endianness gleich dem des Bustreibers, und der Wert von Swapped bleibt unverändert. Wenn das in dem Speicherbedingungsobjekt gespeicherte Endianness von dem des Busmanagers verschieden ist, dann ist das Endianness gleich dem des Busmanagers, und der Wert von Swapped wird in Schritt 1112 invertiert.

Als nächstes erfolgt in Schritt 1114 eine Bestimmung, ob der Busmanager in der Hierarchie der Busmanager der höchsten Ebene ist (d.h. der Busmanager ist der Plattformmanager). Wenn der Busmanager nicht der Manager der höchsten Ebene ist, dann wird eine Anforderung nach zugreifbarem Speicher zu dem nächsthöheren Manager in Schritt 1116 gesendet, und der Vorgang kehrt zurück zu Schritt 1118, wie vorstehend beschrieben. Daher wird das Speicherbedingungsobjekt in der Hierarchie der Busmanager nach oben geleitet, wobei die variablen Endianness- und Swapped-Objektfelder verändert werden, wie vorstehend beschrieben, bis der Plattformmanager erreicht ist. Wenn der Plattformmanager erreicht ist, dann wird in Schritt 1118 zugreifbarer Speicher unter Verwendung des aktuellen Status der Felder in dem Speicherbedingungsobjekt zugeteilt. Der Speicher wird zugeteilt, wie vorstehend beschrieben. Es ist offensichtlich, dass das hier beschriebene Verfahren eine Zuteilung von zugreifbarem Speicher mit geeignetem Endianness ermöglicht, ohne dass es erforderlich ist, dass der Gerätetreiber plattformabhängig ist.

6. Schlussfolgerung

Somit stellt die beschriebene Erfindung Verfahren, Software und Systeme für plattformunabhängige Gerätetreiber zur Verfügung. Solche Gerätetreiber können in einer sicheren Weise betrieben werden, wie vorstehend beschrieben, und ermöglichen eine größere Flexibilität und verminderte Kosten bei der Konstruktion und Wartung. Obwohl einige Ausführungen und Beispiele verwendet wurden, um die vorliegende Erfindung zu beschreiben, ist es für den Fachmann offensichtlich, dass verschiedene Veränderungen bezüglich dieser Ausführungen oder Beispiele erfolgen können. Es ist beispielsweise aus dem Vorstehenden offensichtlich, dass einige objektorientierte Betriebssysteme verwendet werden können, um Verfahren, Software und Systeme zu implementieren, die hier beschrieben wurden, und zwar lediglich unter Verwendung einiger Modifikationen, die für den Fachmann auf dem Gebiet der Computertechnik offensichtlich sind.


Anspruch[de]
  1. Vorrichtung zum Zuteilen von Computerspeicher zu einem plattformunabhängigen Gerätetreiber (702), umfassend:

    a. einen Busmanager (710), der dafür konfiguriert ist, Anforderungen für die Zuteilung des Computerspeichers von dem Gerätetreiber zu verarbeiten;

    b. einen plattformunabhängigen Gerätetreiber (702), der dafür konfiguriert ist, Anforderungen für die Zuteilung von Computerspeicher unter Verwendung eines abstrakten Adressraumes des Computerspeichers zu erzeugen;

    c. einen Mechanismus zum Verifizieren der Identität des Gerätetreibers; und

    d. einen Mechanismus für die Zuteilung des Computerspeichers in Reaktion auf die Anforderung.
  2. Vorrichtung nach Anspruch 1, die des Weiteren einen Mechanismus zum Erzeugen einer inneren Klassendarstellung (708) des Busmanagers (710) umfasst.
  3. Vorrichtung nach Anspruch 1 oder 2, wobei die Vorrichtung des Weiteren eine Datenbank umfasst, die jeden Gerätetreiber (702) in der Vorrichtung einem Busmanager (710) zuordnet.
  4. Vorrichtung nach Anspruch 3, wobei der Mechanismus zum Verifizieren der Identität des Gerätetreibers (702) dafür konfiguriert ist, die Datenbank für die Zuordnung zwischen dem Busmanager (710) und dem Gerätetreiber in Verbindung mit dem Erzeugen der inneren Klassendarstellung (708) des Busmanagers zu durchsuchen.
  5. Vorrichtung nach einem der Ansprüche 1 bis 4, die des Weiteren eine innere Klassendarstellung (708) des Busmanagers (710) umfasst.
  6. Vorrichtung nach Anspruch 5, wobei die innere Klassendarstellung (708) des Busmanagers (710) alle Speicheranforderungsverarbeitungsverfahren des Busmanagers beinhaltet.
  7. Vorrichtung nach Anspruch 5 oder 6, wobei die innere Klassendarstellung (708) des Busmanagers (710) dem Gerätetreiber eindeutig zugeordnet ist.
  8. Vorrichtung nach einem der Ansprüche 5 bis 7, die des Weiteren mehrere Gerätetreiber (702, 704, 706) und innere Klassendarstellungen des Busmanagers (708, 712, 714) umfasst, wobei jede der mehreren inneren Klassendarstellungen des Busmanagers jedem der mehreren Gerätetreiber eindeutig zugeordnet ist.
  9. Computerlesbares Medium mit computerlesbaren Programmcodeeinrichtungen zum Zuteilen von Speicherressourcen in einem Computer, wobei die computerlesbaren Programmcodeeinrichtungen so konfiguriert sind, dass sie einen Computer veranlassen, folgende Schritte auszuführen:

    a. Bereitstellen eines Busmanagers (710), der dafür konfiguriert ist, auf Anforderungen für eine Speicherzuteilung (501) von einem Gerätetreiber (702) unter Verwendung einer abstrakten Adressraumdarstellung des Computerspeichers zu reagieren;

    b. Bereitstellen eines plattformunabhängigen Gerätetreibers (702), der dafür konfiguriert ist, Anforderungen für eine Speicherzuteilung (502) anhand der abstrakten Adressraumdarstellung des Speichers zu erzeugen;

    c. Erzeugen einer Anforderung (502) für eine Speicherzuteilung von dem Gerätetreiber an den Busmanager;

    d. Erzeugen (804) einer inneren Klassendarstellung (708) des Busmanagers in Reaktion auf die erzeugte Anforderung;

    e. Verifizieren der Identität des Gerätetreibers; und

    f. Verarbeiten der Anforderung unter Verwendung des Busmanagers der inneren Klasse.
  10. Computerlesbares Medium nach Anspruch 9, wobei die computerlesbaren Programmcodeeinrichtungen des Weiteren dafür konfiguriert sind, eine innere Klassendarstellung (708) des Busmanagers (710) zu erzeugen (804).
  11. Computerlesbares Medium nach Anspruch 10, wobei die innere Klassendarstellung (708) erzeugt wird, wenn die Anforderung (502) an den Busmanager (710) ergeht, und die innere Klassendarstellung eindeutig dem Gerätetreiber (702) zugeordnet wird.
  12. Computerlesbares Medium nach Anspruch 11, wobei das Verifizieren in der Weise erfolgt, dass die Zuordnung des Gerätetreibers (702) zu dem Busmanager (710) in einem Datenbankspeicher in dem Betriebssystem des Computers lokalisiert wird.
  13. Computerdatensignal auf einer Trägerwelle mit auf einem Computer ausführbaren Befehlen zum Zuteilen von Speicherressourcen in einem Computer, wobei die Befehle so konfiguriert sind, dass sie einen Computer veranlassen, folgende Schritte auszuführen:

    a. Bereitstellen eines Busmanagers (710), der dafür konfiguriert ist, auf Anforderungen für eine Speicherzuteilung (502) von einem Gerätetreiber (702) unter Verwendung einer abstrakten Adressraumdarstellung des Computerspeichers zu reagieren;

    b. Bereitstellen eines plattformunabhängigen Gerätetreibers (702), der dafür konfiguriert ist, Anforderungen für eine Speicherzuteilung (502) anhand der abstrakten Adressraumdarstellung des Speichers zu erzeugen;

    c. Bereitstellen einer inneren Klassendarstellung (708) des Busmanagers, der dafür konfiguriert ist, Speicherzuteilungsanforderungen von dem Gerätetreiber zu verarbeiten;

    d. Erzeugen einer Anforderung (502) für eine Speicherzuteilung von dem Gerätetreiber an den Busmanager;

    e. Erzeugen (804) einer inneren Klassendarstellung des Busmanagers in Reaktion auf die erzeugte Anforderung;

    f. Verifizieren der Identität des Gerätetreibers; und

    g. Verarbeiten der Anforderung unter Verwendung des Busmanagers der inneren Klasse.
  14. Verfahren für die Zuteilung von Speicherressourcen in einem Computer, wobei das Verfahren Folgendes umfasst:

    a. Bereitstellen eines Busmanagers (710), der dafür konfiguriert ist, auf Anforderungen (502) für eine Speicherzuteilung von einem Gerätetreiber (702) unter Verwendung einer abstrakten Adressraumdarstellung des Computerspeichers zu reagieren;

    b. Bereitstellen eines plattformunabhängigen Gerätetreibers (702), der dafür konfiguriert ist, Anforderungen für eine Speicherzuteilung anhand der abstrakten Adressraumdarstellung des Speichers zu erzeugen;

    c. Erzeugen (502) einer Anforderung für eine Speicherzuteilung von dem Gerätetreiber an den Busmanager;

    d. Erzeugen (804) einer inneren Klassendarstellung (708) des Busmanagers in Reaktion auf die erzeugte Anforderung;

    e. Verifizieren der Identität des Gerätetreibers; und

    f. Verarbeiten der Anforderung unter Verwendung des Busmanagers der inneren Klasse.
  15. Verfahren nach Anspruch 14, das des Weiteren das Erzeugen (804) einer inneren Klassendarstellung (708) des Busmanagers umfasst.
  16. Verfahren nach Anspruch 15, wobei die innere Klassendarstellung (708) erzeugt wird, wenn die Anforderung (502) an den Busmanager (710) ergeht, und die innere Klassendarstellung eindeutig dem Gerätetreiber (702) zugeordnet wird.
  17. Verfahren nach Anspruch 16, wobei das Verifizieren in der Weise erfolgt, dass die Zuordnung des Gerätetreibers (702) zu dem Busmanager (710) in einem Datenbankspeicher in dem Betriebssystem des Computers lokalisiert wird.
Es folgen 12 Blatt Zeichnungen






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com