DE69330691T2 - Dynamisch konfigurierbares Kernsystem - Google Patents
Dynamisch konfigurierbares KernsystemInfo
- Publication number
- DE69330691T2 DE69330691T2 DE69330691T DE69330691T DE69330691T2 DE 69330691 T2 DE69330691 T2 DE 69330691T2 DE 69330691 T DE69330691 T DE 69330691T DE 69330691 T DE69330691 T DE 69330691T DE 69330691 T2 DE69330691 T2 DE 69330691T2
- Authority
- DE
- Germany
- Prior art keywords
- module
- kernel
- requested
- kernel memory
- modules
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 230000015654 memory Effects 0.000 claims description 94
- 238000000034 method Methods 0.000 claims description 29
- 238000009434 installation Methods 0.000 claims description 22
- 230000006870 function Effects 0.000 description 42
- 230000008569 process Effects 0.000 description 15
- 238000010586 diagram Methods 0.000 description 6
- 238000012545 processing Methods 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 5
- 230000008901 benefit Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000004886 process control Methods 0.000 description 2
- 230000003111 delayed effect Effects 0.000 description 1
- 238000003379 elimination reaction Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Hardware Redundancy (AREA)
Description
- Die vorliegende Erfindung bezieht sich auf dynamisch konfigurierbare Kerneis. Insbesondere bezieht sich die vorliegende Erfindung auf ein Verfahren und eine Einrichtung zum automatischen Laden und Installieren von Modulen in einem Kernelspeicher auf der Grundlage des Bedarfs.
- Eine zentrale Komponente eines Computersystems ist sein Betriebssystem-Kernel. Das Kernel besteht typischerweise aus einer Mehrzahl von Modulen, wie beispielsweise Treibern, einschließlich Streams-Treibern und Gerätetreibern, Dateisystemmodulen, Scheduling-Klassen, Streams-Modulen und Systemaufrufen. Diese Module werden kombiniert und nachfolgend miteinander verknüpft, so daß sie das Kernel bilden. Wenn nachfolgend das System gestartet oder "gebootet " wird, wird das Kernel in den Speicher geladen. In dem Maße jedoch, wie die Technologie voranschreitet und ausgeklügeltere und komplexe Module, die eine größere Funktionalität bereitstellen, erzeugt werden und neue Module geschaffen werden, erhöht sich die zum Speichern des Kernels erforderliche Speichermenge dramatisch.
- Eine Technik, um die Speichereinschränkungen des Computersystems zu über Winden, ist ein seitenweise auslagerbares Kernel. Ein Seitenauslagerungsmechanismus wird implementiert, bei welchem der Kernelspeicher in Übereinstimmung mit der Speicherverwendung des Kernelspeichers auf eine Platte ausgelagert wird. Es wurde jedoch gefunden, daß ein beträchtlicher Teil des Kernels nicht in Form von Seiten auslagerbar ist und daß die Schwierigkeit beim Aufteilen des Kernels in als Seiten auslagerbare Abschnitte bei weitem · irgendwelche möglichen Vorteile überwiegt.
- Computersysteme sind typischerweise für jede projektierte Art der Benutzung des Computers statisch konfiguriert. Einige Computer werden für Aufgaben benutzt, welche möglicherweise nur die Basismodule erfordern. Andere Computer könnten für komplizierte Verarbeitungen benutzt werden und zusätzliche Module erfordern. Jedoch ist die Aufgabe des Konfigurierens oder Neu-Konfigurieren eines Kernels nicht einfach und übersteigt typischerweise die Fähigkeiten eines typischen Benutzers.
- Ein Beispiel eines bekannten dynamischen Treibers, bei welchem Ansteuerungen (drives) dynamisch geladen werden können, wird in den Proceedings of the Spring 1990 EEUG Conference, 23. April 1990, München, DE, Seiten 133-138, Dieter Konnerth et al. in einem Artikel mit dem Titel "Dynamic Driver Loading for UNIX System V" diskutiert. Hier wird das automatische Laden eines Treibers beschrieben, wobei das Laden ausgeführt wird, wenn auf ein Gerät unter Verwendung eines Standardaufrufs zugegriffen wird. Dies wird durch Binden der Treiberobjektdatei und ihr Kopieren in den Kerneladreßraum ausgeführt. Kernel-Tabellen werden angepaßt (patched), und der Abschluß der Anforderung wird dem Client bestätigt. Siehe auch Doktors Dobb's Journal of Software Tools, Band 15, Nummer 5, Mai 1990, US, Seiten 30-109, in einem Artikel mit dem Titel "Dynamit Link Libraries for DOS" von Gary Syck.
- Bei der vorliegenden Erfindung wird eine Funktionalität eines virtuellen Kernels zur Verfügung gestellt. Dies wird erreicht, indem Module in dem Kernelspeicher auf Anforderung und in Abhängigkeit vom Bedarf zur Verfügung gestellt werden. So wird anfänglich ein minimaler Satz von Modulen in das Kernel geladen, und die übrigen Module werden nur dann hinzugefügt, wenn sie benötigt werden. Es wurde herausgefunden, daß dies die für das Kernel erforderliche Speichermenge drastisch absenkt, da typischerweise die meisten Benutzer eines Computersystems nicht sämtliche verfügbaren Module benötigen. Darüber hinaus vermeidet diese Technik das Erfordernis des Neukonfigurierens, d.h. des Neuaufbauen des Kerneis, wenn irgendwelche in das Kernel zu ladenden Module geändert werden.
- Obwohl es im Stand der Technik gut bekannt ist, daß Treiber von einem Benutzer geladen werden können, indem ausdrücklich Kommandos zum Laden eines Treibermoduls ausgeführt werden, sorgt dies nicht für ein automatisches Laden von Modulen in bedarfsabhängiger Weise, um die zum Halten des Kerneis erforderliche Speichermenge. zu minimieren.
- Ein System und ein Verfahren zum Bereitstellen einer Funktionalität eines virtuellen Kernels gemäß der vorliegenden Erfindung werden in den Ansprüchen 7 bzw. 1 angegeben. Jedes Modul wird separat in ein ausführbares Abbild kompiliert. Diese Module werden in den Speicher gebracht, bis sie von dem Kernel angefordert werden. Die Systemkonfigurationstabellen, die in dem Kernelspeicher zur Verfügung gestellt werden, werden benutzt, um zu bestimmen, daß entweder ein Modul in dem Kernel angeordnet ist oder daß ein Modul nicht in dem Kernel angeordnet ist und folglich in den Kernelspeicher geladen und mit den bereits in den Kernelspeicher geladenen Modulen verknüpft werden muß. Die virtuelle Funktionalität wird zur Verfügung gestellt, indem Anforderungen zum Zugreifen auf die Modulkonfigurationstabellen, wenn auf ein Modul Bezug genommen wird, erfaßt werden und die Anforderung zum Zugriff abgefangen wird, um zu bestimmen, ob das Modul in dem Speicher angeordnet ist. Wenn das Modul nicht in dem Kernelspeicher ist, werden Prozeduren ausgeführt, um das Modul in den Kernelspeicher zu laden, das Modul dynamisch mit den sich im Kernelspeicher aufhaltenden Modulen zu verknüpfen und das Modul in die richtige Konfigurationstabelle derart zu installieren, daß nachfolgende Zugriffe anzeigen, daß das Modul in dem Kernel geladen und installiert ist.
- Die Aufgaben, Merkmale und Vorteile der vorliegenden Erfindung werden aus der folgenden detaillierten Beschreibung der Erfindung klar, in welcher:
- Fig. 1 eine Darstellung ist, die die Zustände der Module bei dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
- Fig. 2 ist eine Blockdarstellung, die die Interaktion des Modulsubsystems der vorliegenden Erfindung mit dem Kernel veranschaulicht.
- Fig. 3a und 3b sind Blockveranschaulichungen der Komponenten des Modulsubsystems.
- Fig. 4 ist eine Veranschaulichung beispielhafter Modulkonfigurationstabellen.
- Fig. 5 ist ein Ablaufdiagramm, das den Prozeß der vorliegenden Erfindung zum dynamischen Laden von Modulen veranschaulicht.
- Fig. 6a veranschaulicht den Prozeßablauf für Stubs (Stümpfe), Fig. 6b veranschaulicht Stub-Datenstrukturen und Fig. 6c-1, 6c-2 und 6c-3 veranschaulichen Makros, die verwendet werden, um die Datenstrukturen zu erzeugen.
- Fig. 7a veranschaulicht eine beispielhafte Verknüpfungsstruktur, und die Fig. 7b-1 und 7b-2 geben verschiedene Arten der Verknüpfungsstrukturen an.
- Fig. 8 veranschaulicht eine beispielhafte Hülle (Wrapper) für ein Dateisystemmodul.
- Fig. 9a, 9b, 9c, und 9e veranschaulichten einen beispielhaften Zeichentreiber, der so ausgebildet ist, daß er in Übereinstimmung mit dem System der vorliegenden Erfindung arbeitet.
- In der folgenden Beschreibung werden aus Gründen der Erläuterung spezielle Speicher, Organisationen, Architekturen, Datenraten, etc. angegeben, um ein besseres Verständnis der vorliegenden Erfindung zu erreichen. Für ein Fachmann ist es jedoch klar, daß die vorliegende Erfindung ohne diese speziellen Details ausgeführt werden kann. An anderen Stellen werden gut bekannte Schaltungen oder Hardware in Blockdarstellungsform gezeigt, um die vorliegende Erfindung. nicht unnötigerweise zu verdecken.
- Das dynamisch konfigurierbare Betriebssystem der vorliegenden Erfindung wird unten unter Bezugnahme auf das UNIX®- Betriebssystem beschrieben (UNIX ist eine eingetragene Marke der AT&T). Angesichts der nachfolgenden Beschreibung ist es für einen Fachmann klar, daß die vorliegende Erfindung als solche nicht eingeschränkt ist und auf andere Betriebssysteme angewendet werden kann.
- Es wird ein Zwei-Schritt-Prozeß zum dynamischen Konfigurieren des Kernels offenbart. Ein Satz von Systemkonfigurationstabellen, die in dem Kernel angeordnet sind, wird benutzt, um den Zustand eines Moduls zu identifizieren. Wenn ein Modul aufgerufen wird oder auf es Bezug genommen wird, wird die Konfigurationstabelle für diese Modulart überprüft, um zu bestimmen, ob das Modul installiert ist. Sofern das Modul nicht installiert ist, wird das Modul geladen und installiert, wodurch die Konfigurationstabelle entsprechend aktualisiert wird.
- Um ein zugreifbares Modul in dem Kernel bereitzustellen, wird das Modul in das Kernel geladen und installiert. Während des Ladeprozesses wird virtueller und physikalischer Speicher für das Modul reserviert. Das Modul wird in den physikalischen Speicher geschrieben, zu seiner verknüpften virtuellen Adresse verschoben und sämtliche Symbolreferenzen werden aufgelöst. Während der Installation wird das Modul mit der geeigneten Konfigurationstabelle derart verknüpft, daß ein Eintrag in der Tabelle für das Modul zugewiesen und mit den richtigen Informationen gefüllt wird.
- Gemäß Fig. 1 kann ein Modul folglich in einem von drei Zuständen sein. Anfänglich ist das Modul nicht geladen oder installiert, und es ist kein Eintrag in der Konfigurationstabelle zugewiesen (sofern nicht die Konfigurationstabelle vorab-zugewiesene Einträge aufweist) (1). Das Modul kann dann geladen sein, aber das Modul ist nicht installiert, und es ist kein Eintrag in der Konfigurationstabelle zugewiesen (2). Ein Eintrag für das Modul kann in der Konfigurationstabelle zugewiesen und mit den geeigneten Informationen gefüllt werden, und das Modul ist geladen und in dem Kernel installiert (3). In diesem dritten Zustand kann auf das Modul zugegriffen werden, und die von dem Modul zur Verfügung gestellten Operationen sind für das System verfügbar. Wie unten erörtert wird, kann ein Eintrag in der Konfigurationstabelle zugewiesen werden, wenn das Modul erstmalig installiert wird. Alternativ ist es bei einigen Konfigurationstabellen, wie beispielsweise der. Gerätetreiber-Konfigurationstabelle, vorteilhaft, daß Einträge derart vorab zugewiesen werden, daß sie zuvor zugewiesenen Identifikationsnummern für jedes Modul entsprechen.
- Das Kernel besteht aus einer Mehrzahl von Modulen, welche die Funktionalität für den Betrieb der Hardware bereitstellen. Module enthalten Gerätetreiber, Systemaufrufmodule, Dateisystemmodule, Streams-Module, Scheduling-Klassen-Module und andere verschiedenartige Module. Diese Module werden separat kompiliert und gespeichert. Das Kernel wird anfänglich mit einem Basissatz von Modulen konfiguriert. Der Basissatz von Modulen sollte zumindest das Modul zum Lesen von Modulen aus einer Speichereinrichtung und dasjenige Modulsubsystem enthalten, welches Module in den Kernel-Speicher lädt und ein zu ladendes Modul mit dem in den Kernel vorhandenen Modulen verknüpft. Indem nur gefordert wird, daß ein Basissatz von Modulen zur Startzeit geladen oder gebunden wird, wird das Binden des Restes der Module verzögert, bis das Modul benötigt wird, wodurch eine Flexibilität in dem System aufrechterhalten wird. Jedoch können gemäß den Anforderungen und Spezifikationen des Benutzers zusätzliche Module anfänglich geladen werden. Beispielsweise kann es vorteilhaft sein, das Speichermanagementmodul und bestimmte Gerätetreibermodule auf der Grundlage der Häufigkeit der Verwendung dieser Module zu laden.
- Wenn das System geschaffen wird, werden eine Mehrzahl von Modulkonfigurationstabellen erzeugt und in dem Kernel- Speicher gespeichert. Diese Konfigurationstabellen werden gemäß dem Typ der Module, die in das Kernel geladen werden sollen, gruppiert. Beispielsweise gibt es eine Konfigurationstabelle für die Gerätetreiber, eine Konfigurationstabelle für die Systemaufrufe, eine Konfigurationstabelle für die Streams-Module und ein Konfigurationstabelle für die Dateisystemmodule. Bei den bekannten Systemen, bei welchen die Module zur Startzeit statisch geladen und gebunden werden, werden diese Konfigurationstabellen mit Informationen über jedes Modul geladen, einschließlich Zeigern oder Handles für jede Struktur des Moduls. Bei dem UNIX-Kernel der SunOsTM-Betriebssystem (SunOs ist eine Marke der Sun Microsystems, Inc.) beispielsweise enthält jeder Eintrag in der Gerätetreiberkonfigurationstabelle devopsp ein Feld für das Handle zu der der ops-Struktur. In ähnlicher Weise enthält die Dateisystemkonfigurationstabelle vfssw ein Feld für den Namen des Dateisystems, ein Handle zu einer "init"-Routine für das Dateisystem, ein Handle zu der Struktur vfsops und eine zum Zugreifen auf das Dateisystem verwendete Verriegelung (lock).
- Bei dem System der vorliegenden Erfindung ist es bevorzugt, daß die Einträge für die Tabellen, die die verschiedenen Module identifizierten, nicht statisch an den Modulnamen gebunden sind, sondern daß sie bedarfsweise hergestellt und zugewiesen werden, wenn die Module in das Kernel installiert werden. Denjenigen Modultypen, welche eine gleichmäßige Identifikation, welche für den Benutzer zugreifbar ist, erfordern, wird ein Eintrag in der Konfigurationstabelle zuvor zugewiesen, um eine konsistente Identifikation oder Bindung über Boots und über Maschinen hinweg zu sichern. Wenn beispielsweise die Konfigurationstabelle eine für Gerätetreiber, "devopsp", ist, werden die Einträge für die Gerätetreibe vor-zugewiesen, so daß die Hauptnummer für jeden Gerätetreiber konsistent zugewiesen wird. Dieselbe Anforderung existiert für Systemaufrufe; die "sysint"-Tabelle muß konsistent jedes Systemaufrufmodul durch seine Systemaufrufnummer identifizieren.
- Obwohl das System als solches nicht beschränkt ist, wird es bevorzugt, daß, sobald ein Modul einem Eintrag in der Konfigurationstabelle zugewiesen ist, der Eintrag zugewiesen bleibt, bis das System neu gebootet wird.
- In jeder Konfigurationstabelle wird ein vorgegebenes Feld für jeden Eintrag in der Tabelle verwendet, um den Zustand des Moduls zu identifizieren. Vorzugsweise wird ein Handle-Feld verwendet. Wenn die Konfigurationstabelle mehrere Handles enthält, wird vorzugsweise das aktivste Handle benutzt, um den Zustand des Moduls zu identifizieren. Wenn das Handle ein vorgegebener Wert ist, wie beispielsweise ein Nullwert, ist das Modul in einem nicht installierten Zustand. Um einen Dereferenzierfehler zu vermeiden, welcher auftreten kann, wenn auf ein Nullfeld in der Tabelle Bezug genommen wird, ist es bevorzugt, daß der nicht-installierte Zustand des Moduls dadurch identifiziert wird, daß ein vorgegebener spezieller. Wert, der den nicht installierten Zustand des Moduls anzeigt, eingesetzt wird. Beispielsweise wird das Handle mit einer Adresse geladen, welche vorgegeben worden ist, um anzuzeigen, daß das Modul nicht in dem Kernel installiert ist. Wenn das Modul in das Kernel geladen ist, enthält das Handle-Feld ein gültiges Handle für das Modul.
- Diese Null- oder speziellen Einträge dienen als Kennzeichen (Flags) für das Modulsubsystem um anzuzeigen, daß ein Modul in das Kernel geladen und installiert werden soll. Wenn somit Code ausgeführt wird, der ein spezielles Modul aufruft, wird eine Überprüfung durchgeführt um zu bestimmen, ob das Modul in das Kernel geladen, mit den anderen Modulen, die in dem Kernel-Speicher vorhanden sind, verknüpft und in die Konfigurationstabelle installiert ist. Wenn das Modul nicht geladen und installiert ist, veranlaßt das Modulsubsystem, daß das Modul in das Kernel geladen und installiert wird, bevor die Verarbeitung fortgesetzt wird. Wenn festgestellt wird, daß das Modul installiert ist, wird die Verarbeitung in dem Kernel fortgesetzt. Alternativ können Kennzeichen (Flags) an verschiedenen Orten in dem Kernel vorhanden sein, an denen bestimmte. Module anfänglich aufgerufen werden oder auf diese Bezug genommen wird. Ein alternativer Mechanismus würde dann verwendet werden, um das Vorhandensein dieser Flags und den Zustand eines Moduls zu erfassen.
- Ein Modulsubsystem wird in dem Kernel zur Verfügung gestellt, um irgendwelche Aufrufe zu bestimmten Modulen in dem Kernel abzufangen und zu bestimmen, ob das Modul gegenwärtig in dem Kernel geladen und installiert ist oder ob es erforderlich ist, daß das Modul in den Kernel-Speicher geladen, verknüpft und installiert wird. Eine Blockdarstellung eines beispielhaften Modulsubsystems und der Interaktion mit dem Kernel ist in Fig. 2 veranschaulicht. Das Modulsubsystem 20 fängt jeden Aufruf zu einem Modul ab, um zu bestimmen, ob das Modul in den Kernel-Speicher geladen und installiert worden ist. Das Modulsubsystem fängt außerdem solche Aufrufe aus anderen Modulen ab, welche Module aufrufen, um zu bestimmen, ob die aufgerufenen Module geladen und installiert sind. Gemäß Fig. 2 geben Benutzerprogramme und Bibliotheken Systemaufrufe aus, welche in dem Kernel von dem Systemaufrufmodul 10 empfangen werden. Das Modulsubsystem 20 bestimmt, ob der bestimmte Aufruf von einem Modul unterstützt wird, das in dem Kernel installiert worden ist, indem das Systemaufrufkonfigurationstabellensystem 30 überprüft wird. Wenn das Modul geladen und installiert ist, werden die ihm entsprechenden Operationen ausgeführt. In ähnlicher Weise folgt, daß dann, wenn das Dateisubsystem 33 oder Prozeßkontrollsystem 35 erforderlich sind, die Installation der Module des Dateisubsystems 30 überprüft werden, indem die Tabelle vfssw 37 referenziert wird, oder im Falle des Prozeßkontrollsubsystems 35 die Tabellen class 39 und execsw 40 10º referenziert werden. Diese werden von dem Modulsubsystem 20 überprüft, um zu bestimmen, ob das Modul geladen und installiert ist. Die Tabelle deveopsp 42 wird von dem Modulsubsystem 20 überprüft, wenn ein Gerätetreibermodul 43 erforderlich ist, und die Tabelle fmodsw 45 wird in ähnlicher Weise von dem Modulsubsystem 20 überprüft, wenn ein Streams- Subsystemmodul 44 erforderlich ist.
- Gemäß Fig. 4 besteht das Modulsubsystem aus einem Steuermodul 70, einem Installiermodul 74 und einem Laufzeitverknüpfer 72. Das Steuermodul 70 fängt Zugriffsanforderungen nach Modulen ab und überprüft die geeignete Modulkonfigurationstabelle, um zu bestimmen, ob das Modul in dem Kernel installiert worden ist. Das Installiermodul 74 bewirkt, daß das Modul in das Kernel geladen und installiert wird, wenn das Steuermodul 70 feststellt, daß ein Modul nicht in dem Kernel vorhanden ist, und der Laufzeitverknüpfer 72, der von dem geladenen und installierten Modul aufgerufen wird, löst Referenzen zwischen den bereits in dem Kernel vorhandenen und dem zu ladenden Modul auf.
- Bei dem bevorzugten Ausführungsbeispiel bestimmt das Modulsubsystem 20 den Zustand des Moduls durch Bezugnahme auf die zugehörige Modulkonfigurationstabelle. Module werden automatisch geladen und installiert, wenn sie benötigt werden. Module werden benötigt, wenn auf die durch sie zur Verfügung gestellte Funktionalität durch einen Namen Bezug genommen wird (wie beispielsweise ein Anstoß (push) eines Streams-Moduls oder das Zusammensetzen (mount) eines Dateisystems) oder wenn ein Modul benötigt wird, um eine Kernel- Referenz zu einer sich nicht in dem Kernel aufhaltenden Funktion befriedigt werden soll. Beispielkonfigurationstabellen sind in den Fig. 3a und 3b gezeigt. Bei dem bevorzugten Ausführungsbeispiel sind diese Tabellen in dem Kernel-Speicher angeordnet und es wird auf sie an einem Ort Bezug genommen, der durch einen speziellen symbolischen oder variablen Namen identifiziert wird, welcher wiederum den Typ des Moduls (z. B. fmodsw) identifiziert. Beispielsweise wird die Konfigurationstabelle für die Dateisystemmodule 33 gemäß Fig. 2 als "vfssw" identifiziert. Die verwendeten Namen und die Orte, an denen die Tabellen angeordnet sind, sind vorzugsweise dieselben, wie sie bei vorhandenen UNIX-Kernels zu finden sind.
- Der Prozeß zum dynamischem Laden der Module in das Kernel wird durch das Ablaufdiagramm gemäß Fig. 5 veranschaulicht. Wenn ein Zugriff auf ein Modul angefordert und/oder versucht wird, wird ein Zugriff auf die Prozeßtabelle ausgeführt, das Modulsubsystem 20, wie es in Fig. 4 gezeigt ist, fängt die Zugriffsanforderung ab, Schritt 100, und überprüft den Tabelleneintrag für das Modul, um zu bestimmen, ob er den speziellen vorgegebenen oder Nulleintrag enthält, Schritt 105, welcher anzeigt, daß das Modul nicht in dem Kernel installiert ist. Wenn festgestellt wird, daß das Modul installiert ist, Schritt 110, weil der spezielle oder Nullwert nicht vorhanden ist, kehrt das Modulsubsystem 20 zurück, um dem anfordernden Prozeß den Zugriff zu gewähren und der normalen Verarbeitung zu gestatten, fortzufahren, Schritt 115. Wenn ein spezieller oder Nulleintrag vorhanden ist, gewinnt das Steuermodul 70, wie es in Fig. 4 gezeigt ist, aus dem Speicher die Datei, die das kompilierte Modul enthält, Schritt 120, und überprüft die Datei, um die Dateigröße zu bestimmen, Schritt 125. Dann wird der Datei Speicher in dem Kernel-Speicher zugewiesen (Schritt 130). Vorzugsweise wird dies unter Verwendung des Kernel-Speicher- Zuweisers ausgeführt, der bei gegenwärtigen UNIX-Kernels vorhanden ist. Die das kompilierte Modul enthaltende Datei wird dann in den zugewiesenen Speicher kopiert, Schritt 135, und es wird der zur. Verfügung gestellte Laufzeitverknüpfer 72 initiiert, um das Modul zu verknüpfen und die Referenzen zu den anderen in dem Kernel-Speicher angeordneten Module aufzulösen, Schritt 140.
- Der Laufzeitverknüpfer 72 fixiert Referenzen im Code in dem Modul, so daß diese auf die richtige Adresse Bezug nehmen oder diese aufrufen. Somit bestimmt der Laufzeitverknüpfer 72 unter Verwendung eines Namens eines aufzurufenden Moduls die Adresse in dem Modul, wo sich die Funktion aufhält. Diese Adresse wird dann in das Modul bei der Funktionsreferenz geschrieben, so daß dann, wenn der Code ausgeführt wird, die richtige Adresse identifiziert wird. Die Verknüpfertechnologie ist Fachleuten gut bekannt und wird hier nicht im Detail erörtert. Bei dem bevorzugten Ausführungsbeispiel enthält das Kernel einen Verknüpfer, welche eine Funktionalität zur Verfügung stellt, die ähnlich der von dlopen, dlclose und dlsym ist, die indem UNIX-Dateisystem implementiert sind, mit der Ausnahme, daß nur ein Modul jeweils verknüpft wird. Für Informationen über dlopen, dlclose und dlsym siehe Sun Microsystems, Inc., SunOs Betriebssystem-Handbuchseiten, "Miscellaneous Library Functions" (1990). Darüber hinaus ist es bevorzugt, daß der Verknüpfer die Moduldatei an eine spezifizierte Adresse verschiebt, dann gemeinsame Variablen zuweist und Referenzen aus dem Modul zu dem Kernel auflöst.
- Da das Modul eine Objektdatei ist, kann es nicht-aufgelöste Referenzen haben. Diese Referenzen werden befriedigt, wenn das Modul geladen wird, indem in der Kernel-Symboltabelle nachgesehen wird. Folglich wird es bevorzugt, daß Symbole in anderen Modulen nicht verwendet werden, um diese Referenzen aufzulösen, sofern nicht das Modul speziell angibt, daß es andere Module erfordert. Dies kann auftreten, wenn ein gemeinsamer Code von verschiedenen unterschiedlichen Modulen benötigt wird. Beispielsweise besteht ein Weg des speziellen Angebens, daß andere Module erforderlich sind, darin, daß eine Zeichenarrayvariable " depends on" deklariert wird und sie mit < sübdir/filename> -Paaren anderer Module, von denen dieses Modul abhängt, initialisiert werden. Dies funktioniert ähnlich der erforderlichen Bibliotheksliste in einem ausführbaren Abbild, welches auf gemeinsame bzw. geteilte Bibliotheken zugreift. Wenn somit ein Modul geladen wird, wird zunächst die Liste der Module in der depends-on-Variable geladen.
- Es kann keine nicht definierten Referenzen in dem statischen verknüpften Teil des Kernels geben; folglich kann das Kernel keine direkten Referenzen auf Modulsymbole machen. Ein Modul kann Referenzen auf Kernel-Symbole enthalten, weil dann, wenn ein Modul geladen wird, der Kernel-Laufzeitverknüpfer Referenzen aus dem Modul zu dem Kernel auflöst. Jedoch kann es sein, daß das Kernel auf Funktionen Bezug nehmen muß, die aus dem residenten Teil des Kernels hinausbewegt worden sind. Beispielsweise ruft die exit()-Routine indem Kernel stets shmexit() auf, um in dem Falle zu säubern, wenn der verlassende Prozeß geteilten Speicher des UNIX-Systems V benutzte. Die shmexit()-Routine ist aber jetzt in einem ladbaren Modul und nicht mit dem residenten Teil des Kernels verknüpft. Folglich würde das Kernel ein nicht definiertes Symbol empfangen, wenn shmexit() nicht definiert ist. Die Lösung besteht darin, eine Dummy-Routine für shmexit() zur Verfügung zu stellen, die mit dem residenten Teil des Kernels verknüpft ist. Diese Routine weiß, wie das richtige Modul zu laden ist und überträgt die Steuerung auf die Zielroutine shmexit() in dem Modul. Eine deartige residente Dummy-Funktion wird ein Stub (Stumpf) genannt. Ein Stub kann als indirekte Adressierungsfunktion angesehen werden oder wie ein PLT(Procedure Linkage Table)-Eintrag, aber mit einer größeren Flexibilität. Alternativ kann die PLT modifiziert werden, so daß sie die Stub-Funktionalität bereitstellt. Bei dem SunOs-Betriebssystem beispielsweise werden dann, wenn die Steuerung zu der Zielroutine in dem Modul übertragen wird, die Stapel-Rahmen (stack frames) angeordnet, so daß es erscheint, als ob die aufgerufene Routine des Stub den Aufruf direkt zu der Zielmodulroutine gemacht hat. Somit werden die Argumente des Aufrufers zu der Zielroutine weitergeleitet. Fig. 6a ist ein Ablaufdiagramm, welches die Verarbeitung von Stubs veranschaulicht.
- Sämtliche Stubs sind in einer Datei definiert. Sie stellen einen Mechanismus zur Verfügung, der erforderlich ist, um eine vorhandene Funktionalität aus dem Kernel heraus und in die Module zu bewegen. Es gibt zwei Arten von Stubs - stark und schwach. Ein starker Stub versucht ein Modul, wenn es erforderlich ist, zu laden, und ein schwacher Stub macht dies nicht. Bei dem obigen Beispiel wird shmexit() in dem Kernel als schwacher Stub definiert. Typischerweise wird ein schwacher Stub für Module benutzt, welche einen resultierenden Zustand einfach dadurch anzeigen, daß sie nicht in das Kernel geladen werden. Wenn beispielsweise das Modul des geteilten Speichers nicht bereits resident ist, gibt es keine Segmente des geteilten Speichers, so daß es kein Erfordernis gibt, das Modul zu laden, um lediglich zu prüfen und herauszufinden, daß es keine geteilten Segmente gibt.
- Gemäß Fig. 6b werden zwei Stub-Datenstrukturen angegeben, eine zum Beschreiben eines Moduls und die andere, um seine Stub-Funktionen zu beschreiben. Die Fig. 6c-1, 6c-2 und 6c-3 geben veranschaulichende Stub-Makros an, die verwendet werden, um die Datenstrukturen gemäß Fig. 6b zu erzeugen.
- Es wird wieder auf Fig. 5 Bezug genommen; sobald das Modul in den Kernel-Speicher geladen und mit den anderen Modulen verknüpft ist, Schritt 145, wird der Installierprozeß ausgeführt, bei welchem die Konfigurationstabelleneinträge für das geladene Modul aktualisiert werden, so daß sie wiedergeben, daß das Modul jetzt in dem Kernel-Speicher angeordnet ist. Wenn kein Eintrag in der zugehörigen Konfigurationstabelle für das Modul zugewiesen worden ist, wird ein Eintrag zugewiesen und die Informationen werden in die Felder für diesen Eintrag eingegeben. Wenn zuvor ein Eintrag für das Modul zugewiesen worden ist, wird das Handle-Feld, das gegenwärtig einen speziellen oder Nulleintrag enthält, der anzeigt, daß das Modul nicht in das Kernel geladen ist, so aktualisiert, daß er das richtige Handle für das Modul enthält. Die Steuerung wird dann zu dem abgefangenen Prozeß zurückgegeben und die normale Verarbeitung fortgesetzt.
- Das Kernel benutzt über das Modulsubsystem vorzugsweise drei Funktionen, eine Funktion zum Laden und Installieren des Moduls, eine Funktion zum Entladen und Deinstallieren des Moduls und eine Funktion zum Anfordern von Informationen bezüglich des Zustands des Moduls. Um bezüglich der Typen der Module, welche in das System gemäß der vorliegenden Erfindung geladen werden können, eine Flexibilität aufrechtzuerhalten, wird es bevorzugt, daß das Kernel entsprechende modulspezifische Funktionen aufruft, um die gewünschte Funktion auszuführen. Folglich enthält bei dem bevorzugten Ausführungsbeispiel jedes Modul eine Hülle (wrapper), welche als Schnittstelle zwischen dem Kernel und dem Modul fungiert. Die Modulhülle definiert drei Funktionen, welche von dem Kernel aufrufbar sind. Die "_init"-Routine" wird ohne Argumente aus dem Kernel aufgerufen, wenn das Modul geladen und installiert ist. Diese Routine ist für das Einhaken (hooking) des Moduls in das System verantwortlich. Wie unten detaillierter erörtert werden wird, wird die "_fini"-Routine aus dem Kernel äufgetufen, wenn eine Anforderung vorgenommen wurde, ein Modul zu entladen und zu deinstallieren. Die "_fini"-Routine bestimmt, ob das Modul zur Verfügung steht, entladen und deinstalliert zu werden, um dann, wenn es verfügbar ist deinstalliert und entladen zu werden, das Modul aus dem System auszuhacken (unhooking). Die "_info"-Routine wird aus dem Kernel aufgerufen, wenn eine Anforderung nach Modulinformationen gemacht worden ist.
- Eine Verknüpfungsstruktur modlinkage identifiziert vorzugsweise die in dem Modul definierten Verknüpfungsstrukturen. Die Verknüpfungsstrukturen enthalten die modulspezifischen Informationen für das Modul. Aus Gründen der Erläuterung wird nur eine Verknüpfungsstruktur pro Modul definiert. Für einen Fachmann ist es jedoch klar, daß eine Mehrzahl von TO Verknüpfungsstrukturen pro Modul definiert werden kann. Eine veranschaulichende Struktur ist in Fig. 7a gezeigt. Die Variable "ml-rev" identifiziert die Überarbeitung (Revision) des Systems. Wenn die Definition der Hülle (wrapper) geändert wird, wird die Revision geändert. Dies vereinfacht die Unterstützung vorhandener Module. Die Variable "ml_linkage[4]" ist ein null-abgeschlossenes Array von Zeigern auf Verknüpfungsstrukturen. Die Verknüpfungsstruktur enthält Informationen, welche verwendet werden, um das Modul zu installieren bzw. zu entfernen. Ein bevorzugtes Ausführungsbeispiel der verschiedenen Arten von Verknüpfungsstrukturen ist durch die Fig. 7b-1 und 7b-2 veranschaulicht. Die ersten beiden Elemente der Verknüpfungsstruktur enthalten bei sämtlichen Modulen die gleiche Art von Informationen. Der Rest der Struktur ist modulspezifisch. Fig. 7b-1 und 7b-2 nehmen auf Module als Beispiele Bezug, wie beispielsweise solche, die in dem UNIX-System-Kernel zu finden sind.
- Die Module werden vor dem Verknüpfen in ein Objektcodeformat kompiliert, wie beispielsweise das ELF-Format (Extensible Linker Format). Die kompilierten Module werden in einem vorgegebenen Abschnitt des Speichers angeordnet. Jeder Modul wird durch einen Namen oder ein Handle identifiziert, welcher bzw. welches dem bestimmten Modul speziell zugeordnet ist, wie beispielsweise der Name des. Dateisystems oder des Systemaufrufs. Einige Module werden durch eine Aufrufnummer identifiziert. Beispielsweise können Systemaufrufe oder Gerätetreiber durch eine Nummer identifiziert werden. Da diese Nummern für die verschiedenen Arten der Module nicht eindeutig sind, ist es erforderlich, einen speziellen Identifizierer für diese numerischen Identifizierer zur Verfügung zu stellen. Folglich ist es bevorzugt, daß eine Tabelle zur Verfügung gestellt wird, um den numerischen Identifizierer für einen bestimmen Typ eines Moduls in einen speziellen Modulnamen zu übersetzen, welcher die das Modul repräsentierende kompilierte Datei identifiziert. Jedoch brauchen diejenigen Module, die bereits durch einen speziellen Namen identifiziert sind, wie beispielsweise die Dateisysteme, nicht übersetzt zu werden, und es werden die von dem System benutzten Namen verwendet, um auf die Datei des Moduls zuzugreifen.
- Als "Hülle" ("wrapper") bezeichnete Kopfteilinformationen werden mit jeder Datei zur Verfügung gestellt, um bestimmte Informationen bezüglich der Datei und des Moduls zur Verfügung zu stellen. Eine beispielhafte Hülle für ein Dateisystem ist in Fig. 8 veranschaulicht. Die Hülle gibt an, daß die Datei ein ladbares Modul ist, den Typ des Moduls und einen Zeiger auf den richtigen Installationscode für den Typ des Moduls. Der Installationscode in dem Kernel stellt spezielle Befehle bezüglich der Installation des Moduls in der richtigen Konfigurationstabelle zur Verfügung. Die Hülle (wrapper) wird gebildet, indem Code in den Quellcode des Moduls eingesetzt wird, um die Hülleninformationen zu erzeugen.
- Beispielsweise veranschaulicht Fig. 8 eine Hülle für ein Dateisystem mit dem Namen "device filesystem". Der interne Name dieses Typs des Dateisystems ist "devfs", die vfssw-Struktur definiert eine init-Routine, devfsinit, welche Funktionen enthält, die ausgeführt werden, wenn das Modul erstmalig geladen wird. Die Routinen init, fini und info sind für jedes Modul spezifisch. Vorzugsweise rufen die Routinen _init, _fini oder _info, wie es in Fig. 8 veranschaulicht ist, die Modulsubsystemroutinen mod_install, mod_remove bzw. mod_info auf, wobei die Struktur modlinkage für das Modul als Parameter weitergeleitet wird.
- Die Struktur modlfs ist die für dieses Modul definierte Verknüpfungsstruktur. Die Struktur modlfs definiert die modops für das Dateisystem "mod-fsops", welche die Zeiger zu den Routinen _init, _fini und _info für die Module enthält. Das nächste Element von modlfs ist ein Zeiger zu dem Namen des Dateisystems, welcher in Abhängigkeit von Informationen bezüglich des Moduls angezeigt wird. Das dritte Element "vfw" identifiziert die Struktur vfssw über das Handle, das das Modul zu den Kernel exportiert.
- Die nächsten beiden Zeilen der Hülle (wrapper) definieren die Mödulverknüpfungsstruktur und identifizieren die Überarbeitung (revision) des Systems, "modrev_1" und die einzelne Verknüpfungsstruktur "modlfs". Die übrigen Elemente der Hülle enhalten Zeiger auf die modulspezifischen Routinen init, fini und info.
- Fig. 9a, 9b, 9c, 9d und 9e sind ein beispielhafter Zeichentreiber, der so ausgebildet ist, daß er auf einer Sun Microsystem, Inc. SPARCstation-Workstation (SPARCstation ist eine eingetragene Marke der SPARC International), die unter dem UNIX-Betriebssystem von Sun Microsystems läuft.
- Folglich werden über das System der vorliegenden Erfindung Module bedarfsweise geladen und installiert. Dies senkt die Menge des für ein System erforderlichen Kernel-Speichers, insbesondere für solche Benutzer, die einen kleinen, allgemeinene Satz von Modulen benutzen. Bei denjenigen Benutzern, die zusätzliche Module verwenden, werden nur die Erforderlichen geladen. Zusätzlich zum Verringern des Kernel-Speicherverbrauchs kann das Kernel ohne ein Neubooten konfiguriert werden, und die Neukonfiguration des Kernels ist beträchtlich vereinfacht.
- Wenn ein Modul installiert wird, exportiert es ein Handle für Dienste, die es zur Verfügung stellt. Wenn es nicht installiert ist, nimmt es den Export des Handles zurück (unexports the handle). Das Handle, welches ein Treibermodulelement exportiert, wenn es sich selbst installiert, ist ein Zeiger zu seiner Struktur dev_ops. Vorzugsweise werden allgemeine Treiberroutinen mod_installdrv() und mod_removedrv() zur leichten Implementierung der treiberspezifischen Installier- und Beseitigungs- (oder "Deinstallier"-) Operationen zur Vefügung gestellt.
- Die Fuktion von mod_installdrv() besteht darin, ein Treibermodulelement in dem System zu installieren. Dies wird ausgeführt, indem der der Hauptnummer des Treibers entsprechende devopsp-Eintrag so gesetzt wird, daß er auf die dev_ops-Struktur des Treibers verweist. Die Hauptnummer des Treibers wird zugewiesen, wenn das den Treiber enthaltende Modul auf das Speichermedium (d.h. die Festplatte) installiert wird.
- Die Funktion von mod_removedrv() besteht darin, ein Treibermodulelement aus dem System zu deinstallieren. Dies wird ausgeführt, indem der der Hauptnummer des Treibers entsprechende devopsp-Eintrag so eingestellt wrid, daß er auf die mod_nodev ops-Struktur (eine spezielle Adresse, die verwendet wird um anzuzeigen, daß das Modul nicht installiert ist) zeigt und die Referenz zu dem Treiber aus irgendeiner Kernel-Datenstruktur, wie beispielsweise der dev info-Struktur beseitigt wird. Sofern der Treiber nicht deinstallierbar ist, gibt mod_removedrv() EBUSY zurück.
- Ein Treiber ist nicht deinstallierbar, wenn seine Abtrennroutine fehlschlägt, wenn sie für irgendeinen dem Treiber eigenen dev_info-Knoten aufgerufen wird, oder wenn seine dev_ops für eine Benutzung durch das System gehalten werden. Die Abtrennroutine des Treibers ist für die Rückgabe eines von DDI_SUCCESS abweichenden Werts verantwortlich, wenn der Treiber aus irgendeinem anderen Grund besetzt ist, beispielsweis, wenn er geöffnet ist, oder wenn es irgendeinen ausstehenden Rückruf zu dem Treiber gibt.
- Die Handles, welche ein exec-Systemmodul exportiert, wenn es sich selbst installiert, sind seine magische Zahl, ein Zeiger zu seiner exec-Funktion und ein Zeiger zu seiner Kernfunktion (d.h. die ersten drei Felder einer execsw- Struktur). Vorzugsweise werden allgemeine exec-Routinen, mod_installexec() und mod_removeexec(), zur einfachen Implementierung exec-spezifischer Installations- und Beseitigungsoperationen zur Verfügung gestellt.
- Die Funktion von mod_installexec().besteht darin, ein exec-Modulelement in dem System zu installieren. Dies wird ausgeführt, indem ein verfügbarer Eintrag in der execsw- Tabelle zugewiesen und die Felder exec_magic, exec_fung und. exec_core dieses Eintrags auf diejenigen eingestellt werden, die in der execsw-Struktur enthalten sind, aufdie in der modlexec-Struktur des Modulelements gezeigt wird. Die Funktion von mod_removeexec() besteht darin, ein exec-Modulelement aus dem System zu deinstallieren. Dies wird ausgeführt, indem die Felder exec_magic, exec_funcund exec_core des zugewiesenen Eintrag auf NULL gesetzt werden.
- Ein Zugriff auf die exportierten Handles eines exec_ist durch eine Lese/Schreib-Verriegelung (lock) in dem execsw- Eintrag, welcher das Modulelement zuweist, wenn er installiert wird, geschützt. Eine Schreibverriegelung (write lock) wird gewonnen, wenn die Handles exportiert oder deexportiert (unexported) werden, und eine Leseverriegelung (read lock) wird während Aufrufen zu den exec_fung()- und exec_core()- Einträgen des Modulelements gehalten. Ein exec_ist folglich dann nicht deinstallierbar, wenn die Lese_ Schreib-Verriegelung, die in dem zugehörigen execsw-Eintrag enthalten ist, nicht für ein Schreiben eingegeben werden kann.
- Die Handles, welche ein Dateisystemmodul exportiert, sind sein Name, seine vsw_init() -Funktion, sein vsw_flag und vfsops (d.h. die Felder einer vfssw-Struktur). Vorzugsweise werden allgemeine Dateisystemroutinen, mod_installfs() und mod_removefs(), zur einfachen Implementierung dateisystemspezifischer Installations- und Beseitigungsoperationen zur Verfügung gestellt.
- Die Funktion von mod_installfs() besteht darin, ein Dateisystemmodulelement in dem System zu installieren. Dies wird ausgeführt, indem der ihm durch das Gerüst (framework) zugewiesene vfssw-Tabelleneintrag gesucht und die Felder vsw_mit, vsw_vfsops und vsw_flag dieses Eintrags auf diejenigen gesetzt werden, die in der vfssw-Struktur enthalten sind, auf die in der modlfs-Struktur des Modulelements gezeigt wird. Die Funktion von mod_removefs() besteht darin, ein Dateisystemmodulelement aus dem System zu deinstallieren. Dies wird ausgeführt, indem die Felder vsw_mit und vsw_vfsops des zugewiesenen Vf ssw-Eintrags auf NULL gesetzt und das vsw_flag-Feld auf Null gesetzt wird:
- Zugriffe auf sämtliche exportierten Handles des Dateisystems werden durch eine einzige Lese/Schreib-Verriegelung geschützt. Die Schreib-Verriegelung wird gehalten, während der vfssw-Eintrag zugewiesen wird, während in den vfssw-Eintrag geschrieben wird und während die Liste der montierten Dateisysteme in mod_removefs() überprüft wird, um zu bestimmen, ob ein Dateisystem nicht ladbar ist. Die Lese-Verriegelung wird gehalen, während die vfssw durchsucht wird und über den Aufruf der Funktionen vsw_init(), vfs_mount(), vfssync() und vfs_unmount() des Dateisystems hinweg. Das Gerüst (framework) hindert folglich ein Dateisystem daran, deinstalliert zu werden, wenn es einen aktiven Thread der Ausführung in den Funktionen vsw_init(), vfs_mount(), vfs_sync() und vfs_unmount() gibt, und das Dateisystem hindert sich selbst daran, deinstalliert zu werden; wenn es auf andere Weise besetzt ist.
- Die Handles, welche ein Scheduler-Modulelement exportiert, sind sein Klassenname, die Klasseninitialisierungsfunktion und seine Klassenfunktionen (d.h. die ersten drei Felder einer Klassenstruktur). Vorzugsweise werden allgemeine Routinen, mod_installsched() und mod_removesched(), zur einfachen Implementierung scheduler-spezifischet Inställations- und Beseitigungsoperationen zur Verfügung gestellt. Die Funktion von mod_installsched() besteht darin, ein Scheduler-Modulelement in dem System zu installieren. Dies wird erreicht, indem der Eintrag in der Klassentabelle, der dem Scheduler entspricht (wobei ggf. einer zugewiesen wird) lokalisiert wird und die Felder cl_init und cl_funcs auf diejenigen gesetzt werden, die in der Klassenstruktur enthalten sind, auf die durch die modlsched-Struktur des Modulelements gezeigt wird, und dann dispinit() aufgerufen wird, um die Klasse zu initialisieren. Die Felder cl_name und cl_lock werden initialisiert, wenn der Klasseneintrag zugewiesen wird. Die Funktionen von mod_removesched() besteht darin, ein Scheduler-Modulelement aus dem System zu deinstallieren. Dies wird ausgeführt, indem die Felder cl_mit und cl_funcs des zugewiesenen Eintrags auf NULL gesetzt werden.
- Der Zugriff auf die exportierten Handles des Schedulers sind durch eine Lese/Schreib-Verriegelung, die pro Scheduler-Klasse zugewiesen ist, geschützt. Die Verriegelung wird zugewiesen und initialisiert, wenn der Klasseneintrag zugewiesen wird. Die Verriegelung wird für ein Schreiben des Klasseneintrags in mod_installsched() und mod_removesched() gehalten; die Verriegelung wird darüber hinaus zum Lesen gehalten.
- Das Handle, welches ein Streams-Modulelement exportiert, ist ein Zeiger auf seine streamtab. Vorzugsweise werden allgemeine Routinen mod_installstrmod() und mod_removestrmod() zur einfachen Implementierung von streams-spezifischen Installations- und Beseitigungsoperationen zur Verfügung gestellt.
- Die Funktion von mod_installstrmod() besteht darin, ein Streams-Modulelement in das System zu installieren. Dies wird ausgeführt, indem ein Eintrag in der fmodsw-Tabelle zugewiesen oder der bereits für das Streams-Modul zugewiesene Eintrag lokalisiert wird und die Felder f_str und f_flag mit den Werten initialisiert werden, die in der fmodsw-Struktur enthalten sind, auf die durch die modlstrmod-Struktur des Moduls gezeigt wird. Die Felder f_name und f_lock werden initialisiert, wenn der fmodsw-Eintrag zugewiesen wird. Die Funktion von mod_removestrmod() besteht darin, das Streams-Modulelement aus dem System zu deinstallieren. Dies wird ausgeführt, indem das Feld f_str des zugewiesenen fmodsw-Eintrags auf NULL und das.f_flag- Feld auf Null gesetzt wird.
- Der Zugriff auf das exportierte Handle des Streams wird geschützt durch eine Lese/Schreib-Verriegelung in deni fmodsw-Tabelleneintrag. Die Schreib-Verriegelung wird gehalten, während in den Eintrag in mod_installstrmod() und mod_removestrmod() geschrieben wird. Die Lese-Verriegelung wird während Aufrufen zu den Routinen qi_open() und qi_close() des Streams gehalten.
- Das Handle, welches ein Systemaufruf-Modulelement exportiert, ist ein Zeiger auf eine Funktion. Vorzugsweise werden allgemeinen Routinen mod_installsys() und mod_removesys() zur einfachen Implementierung von systemaufruf-modulspezifischen Installations- und Beseitigungsoperationen zur Verfügung gestellt.
- Die Funktion von mod_installsys() besteht darin, ein Systemaufrufmodulelement in das System zu installieren. Dies wird ausgeführt, indem der diesem Systemaufruf zugewiesene sysent-Eintrag lokalisiert und die Felder sy_narg und sycall des Eintrags gleich denjenigen gesetzt werden, die in der sysent-Struktur enthalten sind, auf die durch seine modlsys-Struktur gezeigt wird. Sysent-Einträge werden den Systemaufrufen zur Anfangsladezeit (Boot-Zeit) zugewiesen. Die Funktion von mod_removesys() besteht darin, ein Systemaufrufmodulelement aus dem System zu deinstallieren. Dies wird ausgeführt, indem das sy_call-Feld des zugewiesenen sysent-Eintrags auf die Adresse der nosys-Funktionen gesetzt und der Wert des sy_narg-Felds auf Null gesetzt wird.
- Der Zugriff auf das exportierte Handle des Systemaufrufs wird durch eine Lese/Schreib-Verriegelung in dem sysent-Eintrag geschützt. Die Schreibverriegelung wird gehalten, während in die sysent-Struktur bei mod_installsys() und mod_removesys() geschrieben wird, und die Lese-Verriegelung wird über Aufrufe der sy_call-Funktion hinweg gehalten.
- Um die Ausnutzung des Kernel-Speichers weiter zu optimieren, während ein System mit einer ausgeklügelten Funktionalität zur Verfügung gestellt wird, ist es bevorzugt, daß ein System mit einem Prozeß, welcher Module entlädt, zur Verfügung gestellt wird. Obwohl andere Techniken, wie beispielsweise das manuelle Entladen der Module, verwendet werden könnten, ist es bevorzugt, daß das innovative System des automatischen Entladens von Modulen, das unten beschrieben wird, benutzt wird.
- Wenn es erwünscht ist, weiteren Kernel-Speicher zu gewinnen, wird das Modulsubsystem aufgerufen, um Module zu entladen. Obwohl viele verschiedene Regeln angewendet werden können, um zu bestimmen, ob es erforderlich wie wünschenswert ist, Kernel-Speicher freizugeben, ist es bevorzugt, das Module entladen werden, wenn kein ausreichender Speicher vorhanden ist, um zusätzliche Module zu laden. Vorzugsweise wird dies ausgeführt, indem der Kernel-Seitenauslägerungsmechanismus, der bei bekannten Systemen zu finden ist (und als der "swapper" bezeichnet wird), derart modifiziert wird, daß das Modulsubsystem benachricht wird, irgendwelche Module, welche gegenwärtig nicht benutzt werden, zu deinstallieren und zu entladen. Das Auto-Entlade-Modul des Modulsubsystems fordert jedes geladene Modul auf, anzuzeigen, ob das Modul deinstalliert und entladen werden kann oder nicht. Das Modul ruft eine Funktion fini, die in der Hülle jedes Moduls angeordnet ist, auf. Die fini-Funktion überprüft den Status des Moduls unter Verwendung von Kriterien für diesen Typ des Moduls.
- Das Modul und das System, d.h. das Kernel, bestimmen miteinander, ob das Modul entladen und deinstalliert werden kann. Allgemein kann gesagt werden, daß ein Modul deinstallierbar und entladbar ist, wenn es nicht in Benutzung ist. Insbesondere, wenn ein Modul installiert ist, exportiert es ein Handle für Dienste, die es zur Verfügung stellt. Wenn es deinstalliert ist, deexportiert (unexports) es das Handle. So greift das System auf das Handle jedes Moduls zu, um auf die Operationen des Moduls zuzugreifen. Wenn auf das Handle durch das System zugegriffen wird, dann ist das Modul in Benutzung und kann nicht deinstalliert werden. Es können andere Kriterien vorhanden sein, die von der Art des Moduls abhängig sind. Zusätzlich kann ein Verriegelungsmechanismus, wie beispielsweise ein Semaphor, benutzt werden, um speziell den Zustand der Verwendung des Moduls zu identifizieren. So würde das System Routinen einschließen, um die Verriegelung zu erzeugen, die Verriegelung zu beseitigen und den Status der Verriegelung zu überprüfen, um zu bestimmen, ob die Verriegelung beseitigt werden kann.
- Wenn beispielsweise das Modul ein Treiber ist, verfolgt das System, welche Treiber geöffnet sind. Wenn ein Treiber geöffnet ist, ist der Treiber nicht deinstallierbar. Wenn der Treiber nicht geöffnet ist, wird eine Überprüfung dann ausgeführt, um zu bestimmen; ob der Treiber von den mit ihm befestigten Geräten abgetrennt werden kann. Die Abtrennroutine führt die entgegengesetzte Funktion gegenüber der Befestigungsroutine (attach routine) aus, die gegenwärtig bei dem UNIX-Betriebssystem verfügbar ist. Die Abtrennroutine wird dann bezüglich sämtlicher Geräte, mit denen der Treiber gegenwärtig verbunden ist, ausgeführt. Wenn irgendeine Abtrennroutine fehlgeht, was auftreten würde, wenn das Gerät gegenwärtig den Treiber benutzt, bleiben sämtliche Geräte für diesen Treiber befestigt und der Treiber wird als nicht installierbar identifiziert.
- Vorzugsweise wird eine Modultabelle in dem Kernel zur Verfügung gestellt. Die Modultabelle identifiziert jedes Modul, den Status der Verriegelung an jedem Modul (d.h. verriegelt, entriegelt) und den Status des Moduls (z. B. geladen/entladen/laden-findet-gerade-statt, etc. ). Dienstroutinen würden dann zur Verfügung gestellt werden, um die Informationen in der Modultabelle zu halten und auf diese zuzugreifen.
- Wenn das Modul dem Auto-Entlade-Modul anzeigt, daß das Modul deinstalliert werden kann, vernichtet das Auto-Entlade-Modul die richtigen Konfigurationstabelleneinträge. Vorzugsweise wird dies erreicht, indem eine Null oder ein spezieller Wert in das Handle eingesetzt wird, auf das von dem Modulsubsystem verwiesen wird, um den Zustand des Moduls zu bestimmen. Eine Entladefunktion wird dann ausgeführt, wodurch der von dem Modul belegte Speicher dann neu zugewiesen wird, wodurch der Speicherraum in dem Kernel freigegeben wird.
- Vorzugsweise bleiben die zugehörigen Einträge in der Konfigurationstabelle zugewiesen, während das Modul sich in seinem Nicht-Installiert-Zustand befindet. Die Speichermenge, die in der Konfigurationstabelle erforderlich ist, ist relativ gering, und die Aufrechterhaltung der Einträge wird minimiert, indem die Schritte des Aufhebens der Zuweisung und des Neuzuweisens von Einträgen in der Tabelle beseitigt werden.
- Bei einem alternativen Ausführungsbeispiel wird ein Zwei-Schritt-Beseitigungsprozeß benutzt, um die Häufigkeit des Ladens und Entladens von Modulen zu minimieren. Ein Modul, von dem festgestellt wird, daß es zur Deinstallation und zum Entladen zur Verfügung steht, wird zunächst deinstalliert. Wenn der Kernel-Speicher nachfolgend benötigt wird, werden die Module, welche noch geladen aber nicht mehr installiert sind, entladen, um Raum in dem Kernel freizugeben. In ähnlicher Weise folgt, daß ändere Module deinstalliert aber geladen bleiben, wenn das nächste Mal Kernel- Speicher benötigt wird. Wenn ein Modul deinstalliert aber geladen ist und ein Zugriff auf das Modul erforderlich ist, wird einfach der Installierprozeß durchgeführt, um einen Zugriff auf das Modul zur Verfügung zu stellen.
- Eine Reihe von Vorteilen werden bei diesem Prozeß verwirklicht. Das Thrashing wird minimiert. Die zum Zugreifen auf ein Modul erforderliche Zeitdauer wird minimiert, da Entladeoperationen nur dann durchgeführt werden, wenn sie erforderlich sind, wodurch die Häufigkeit des Durchführens zeitraubender Ladeoperationen abgesenkt wird. Darüber hinaus kann der Zwei-Schritt-Prozeß mit einem Speicherersetzungsalgorithmus, wie beispielsweise einem Least-Recently- Used(LRU)-Algorithmus, benutzt werden, um die Benutzung der Lade/Installier- und Deinstallier/Entlade-Prozesse weiter zu optimieren.
- Obwohl die Erfindung im Kontext des bevorzugten Ausführungsbeispiels beschrieben worden ist, ist es klar, daß zahlreiche Alternativen, Modifikationen, Variationen und Verwendungen Fachleuten im Lichte der vorstehenden Beschreibung klar werden. Insbesondere ist es klar, daß das System des automatischen Ladens von Modulen zusammen mit oder unabhängig von dem System zum automatischen Entladen von Modulen, das hier beschrieben wurde, benutzt werden kann und noch die Vorteile bei der Kernel-Speicherausnutzung verwirklicht.
Claims (18)
1. Ein Verfahren zum dynamischen Konfigurieren eines
Kernels eines Computerbetriebssystems, wobei das Kernel
einen Kernel-Speicher aufweist, der eine Mehrzahl von Modulen
aufnehmen kann und anfänglich mit einem Basissatz von
Modulen als zugreifbare Module konfiguriert ist, wobei das
Computerbetriebssystem eine Mehrzahl von Modulen speichert und
in der Lage ist, zugreifbare Module auszuführen, wobei jedes
Modul ein angefordertes Modul sein kann, wobei jedes
angeforderte Modul eine Hülle (wrapper) aufweist, zum
Identifizieren, ob das Modul eine ladbare Datei ist, und zum
Identifizieren eines Zeigers auf einen Installationscode, der in
dem Betriebssystemmittel für den Typ des Moduls angeordnet
ist, wobei der Installationscode so ausgebildet ist, daß er
spezielle Befehle bezüglich der Installation der
Modulinformationen in der Modulkonfigurationstabelle zur Verfügung
stellt, wobei das Verfahren die Schritte umfaßt:
Erfassen einer Zugriffsanforderung auf eine
Konfigurationstabelle, zum Bezugnehmen auf das angeforderte Modul;
Abfangen der Zugriffsanforderung auf die
Konfigurationstabelle;
Überprüfen der Konfigurationstabelle hinsichtlich des
Konfigurationszustandes des angeforderten Moduls durch ein
Modul-Subsystem (20), um zu bestimmen, ob das angeforderte
Modul in den Kernel-Speicher konfiguriert ist;
automatisches Konfigurieren des angeforderten Moduls in
den Kernel-Speicher durch das Modul-Subsystem (20), wobei
das automatische Konfigurieren die Schritte des Ladens des
angeforderten Moduls in den Kernel-Speicher durch ein
Installationsmodul (74) und des Auflösens der Verknüpfungen
zwischen jedem Modul in dem Kernel-Speicher und dem
angeforderten Modul durch einen Laufzeitverknüpfer (72) umfaßt,
wenn das angeforderte Modul in den Kernel-Speicher geladen
wird; und
Zuweisen zugehöriger Daten in die Konfigurationstabelle,
wenn der Konfigurationszustand des angeforderten Moduls
anzeigt, daß das angeforderte Modul nicht in den Kernel-
Speicher konfiguriert ist.
2. Das Verfahren nach Anspruch 1, ferner umfassend die
Schritte:
Abfangen von Anforderungen zum Zugreifen auf ein Modul
als angefordertes Modul aus der Ausführung durch das
Computerbetriebssystem; und
Bewerten des dem angeforderten Modul zugeordneten
Eintrags in der Konfigurationstabelle, um zu bestimmen, ob das
angeforderte Modul in den Kernel-Speicher konfiguriert ist.
3. Das Verfahren nach Anspruch 1, ferner umfassend die
Schritte:
Installieren des angeforderten Moduls in den Kernel-
Speicher durch das Installationsmodul (74), um eine
zugreifbares Modul zu bilden.
4. Das Verfahren nach Anspruch 3, ferner umfassend die
Schritte:
Lesen des angeforderten Moduls aus den Speicher in dem
Computerbetriebssystem;
Bestimmen der Dateigröße des angeforderten Moduls;
Reservieren virtuellen und physikalischen Speichers in
dem Kernel-Speicher, um das angeforderte Modul in den
Kernel-Speicher zu schreiben;
Schreiben des angeforderten Moduls in den physikalischen
Speicher des Kernel-Speichers.
5. Das Verfahren nach Anspruch 4, ferner umfassend die
Schritte:
Bestimmen, ob ein nicht ausreichender Kernel-Speicher
vorhanden ist, um das angeforderte Modul in den
Kernel-Speicher zu schreiben;
Deinstallieren wenigstens eines Moduls aus dem Kernel-
Speicher als nicht-installiertes Modul, wenn festgestellt
worden ist, daß ein nicht ausreichender Kernel-Speicher
vorhanden ist;
Ändern des Konfigurationszustandes des deinstallierten
Moduls; und
Entladen jedes deinstallierten Moduls aus dem Kernel-
Speicher, um ausreichenden Kernel-Speicher zur Verfügung zu
stellen, wenn bestimmt worden ist, daß ein nicht
ausreichender Kernel-Speicher vorhanden ist.
6. Das Verfahren nach Anspruch 3, ferner umfassend die
Schritte:
Aktualisieren des Konfigurationszustandes jener
angeforderten Module, die in den Kernel-Speicher konfiguriert
worden sind, um anzuzeigen, daß das angeforderte Modul in den
Kernel-Speicher konfiguriert worden ist; und
Gestatten der Anforderung, daß sie auf ein Modul
zugreift, um das zugreifbare Modul zur Ausführung des
zugreifbaren Moduls durch das Computerbetriebssystem zu
erreichen,
7. Ein Computersystem, aufweisend:
ein Computerbetriebssystem;
ein dynamisch konfigurierbares Kernel, wobei das Kernel
aufweist:
einen Kernel-Speicher, der so ausgebildet ist, daß er
eine Mehrzahl von Modulen, die in dem Computerbetriebssystem
gespeichert sind, aufnehmen kann, wobei das Kernel
anfänglich mit einem Basissatz von Modulen als zugreifbare Module
konfiguriert ist, wobei das Computerbetriebssystem in der
Lage ist, zugreifbare Module auszuführen, und wobei jedes
Modul ein angefordertes Modul sein kann, wobei ferner jedes
angeforderte Modul eine Hülle (wrapper) aufweist, wobei die
Hülle Informationen aufweist, die identifizieren, ob das
Modul eine ladbare Datei ist, und die einen Zeiger zu einem
Installationscode, der in dem Computerbetriebssystem für den
Typ des Moduls angeordnet ist, spezifizieren, wobei der
Installationscode so ausgebildet ist, daß ein spezielle
Befehle bezüglich der Installation der Modulinformationen in
der Modulkonfigurationstabelle zur Verfügung stellt, wobei
das Kernel ferner aufweist:
ein Steuermodul (70) als Mittel zum Erfassen einer
Zugriffsanforderung auf eine Konfigurationstabelle, zur
Bezugnahme auf das angeforderte Modul, und als Mittel zum
Abfangen der Zugriffsanforderung auf die
Konfigurationstabelle,
ein Modul-Subsystem (20) als Mittel zum Überprüfen der
Konfigurationstabelle hinsichtlich des
Konfigurationszustandes des angeforderten Moduls, um festzustellen, ob das
angeforderte Modul in den Kernel-Speicher konfiguriert ist, und
als Mittel zum automatischen Konfigurieren des angeforderten
Moduls in das Kernel, wobei das Mittel zum automatischen
Konfigurieren Mittel zum Laden des angeforderten Moduls in
den Kernel-Speicher durch ein Installationsmodul (74) und
Mittel zum Auflösen der Verknüpfungen zwischen jedem Modul
in dem Kernel-Speicher und dem angeforderten Modul durch
einen Laufzeitverknüpfer (72), wenn das angeforderte Modul
in den Kernel-Speicher geladen wird, umfaßt, und
Mittel zum Zuweisen zugehöriger Daten in die
Konfigurationstabelle, sofern der Konfigurationszustand des
angeforderten Moduls anzeigt, daß das angeforderte Modul nicht in
den Kernel-Speicher konfiguriert ist.
8. Das Computersystem nach Anspruch 7, ferner aufweisend
wenigstens eine Modulkonfigurationstabelle in dem Kemel-
Speicher, die Informationen bezüglich der Module aufweist,
wobei das Steuermodul (70) so ausgebildet ist, daß es den
Zustand des angeforderten Moduls durch Lesen der
Modulkonfigurationstabelle bestimmt.
9. Das Computersystem nach Anspruch 8, wobei die Hülle
(wrapper) ferner zum Identifizieren des Typs des Moduls
dient.
10. Das Computersystem nach Anspruch 8, wobei das
wenigstens eine Modul wenigstens einen Datensatz für jedes Modul
aufweist, wobei der wenigstens eine Datensatz wenigstens
einen Eintrag in einem vorgegebenen Feld enthält, wobei der
wenigstens eine Eintrag einen Wert aufweist, um den Zustand
des angeforderten Moduls zu identifizieren.
11. Das Computersystem nach Anspruch 7, wobei das
Installationsmodul ferner so ausgebildet ist, daß es die
Größe einer Datei eines kompilierten Modulcodes bestimmt, um
Kernel-Speicher für die Plazierung der Datei zuzuweisen und
um die Datei in den so zugewiesenen Speicher einzuschreiben.
12. Das Computersystem nach Anspruch 11, wobei dann,
wenn das Installationsmodul feststellt, daß nicht
ausreichender Kernel-Speicher zum Schreiben der Datei vorhanden
ist, ein Modul aus dem Kernel-Speicher entladen wird, um
ausreichenden Kernel-Speicher zum Schreiben der Datei zur
Verfügung zu stellen.
13. Das Computersystem nach Anspruch 10, wobei das
Steuermodul (70) so ausgebildet ist, daß es den Zustand des
angeforderten Moduls bestimmt, indem es feststellt, ob der
wenigstens eine Eintrag in dem vorgegebenen Feld des
wenigstens einen Datensatzes einen Wert enthält, der anzeigt, daß
das Modul ein zugreifbares Modul ist.
14. Das Computersystem nach Anspruch 10, wobei das
Installationsmodul einen Datensatz in der
Modulkonfigurationstabelle für das angeforderte Modul zuweist, wenn das
angeforderte Modul erstmals in den Kernel-Speicher geladen
und installiert wird.
15. Das Computersystem nach Anspruch 10, wobei ein
Datensatz in der Modulkonfigurationstabelle für jedes Modul,
das geladen und installiert werden kann, vorab zugewiesen
wird.
16. Das Computersystem nach Anspruch Z0, wobei das
Installationsmodul einen Datensatz in der
Modulkonfigurationstabelle für das geladene Modul einrichtet, wenn das
geladene Modul erstmals in den Kernel-Speicher installiert wird,
wobei der Datensatz den Eintrag aufweist, der den Wert
enthält, der anzeigt, daß das geladene Modul in dem
Betriebssystem installiert ist.
17. Das Computersystem nach Anspruch 10, wobei eine
Mehrzahl von Modulen geladen und installiert ist und das
Modul-Subsystem ferner aufweist:
Mittel zum Auswählen eines geladenen und installierten
Moduls für ein Entladen und Deinstallieren aus dem Kernel-
Speicher;
Mittel zum Annullieren des Eintrags in der
Modulkonfigurationstabelle, der anzeigt, daß das ausgewählte Modul in
dem Betriebssystem geladen und installiert ist, so daß der
Eintrag in der Modulkonfigurationstabelle anzeigt, daß das
ausgewählte Modul nicht mehr geladen oder installiert ist;
und
Mittel zum Neu-Zuweisen des von dem ausgewählten
geladenen und installierten Moduls belegten Kernel-Speichers um so
das ausgewählte geladene und installierte Modul zu entladen,
um zu ermäglichen, daß der Speicher zum Laden eines weiteren
Moduls in den Kernel-Speicher benutzt wird.
18. Das Computersystem nach Anspruch 16, wobei das
Steuermodul (70) ferner so ausgebildet ist, daß es bestimmt, ob
das angeforderte Modul geladen und installiert ist, indem es
feststellt, ob ein Datensatz für das angeforderte Modul in
der Modulkonfigurationstabelle vorhanden ist, und es dann,
wenn ein Datensatz vorhanden ist, bestimmt, ob der Eintrag
in dem Datensatz einen Wert enthält, der anzeigt, daß das
Modul geladen und in dem Kernel-Speicher installiert ist.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US89333792A | 1992-06-03 | 1992-06-03 |
Publications (2)
Publication Number | Publication Date |
---|---|
DE69330691D1 DE69330691D1 (de) | 2001-10-11 |
DE69330691T2 true DE69330691T2 (de) | 2002-07-04 |
Family
ID=25401397
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE69330691T Expired - Fee Related DE69330691T2 (de) | 1992-06-03 | 1993-05-21 | Dynamisch konfigurierbares Kernsystem |
Country Status (4)
Country | Link |
---|---|
US (1) | US5634058A (de) |
EP (1) | EP0573190B1 (de) |
JP (1) | JPH06295237A (de) |
DE (1) | DE69330691T2 (de) |
Families Citing this family (88)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6357000B1 (en) * | 1993-01-29 | 2002-03-12 | Microsoft Corporation | Method and system for specified loading of an operating system |
DE59509530D1 (de) * | 1994-06-30 | 2001-09-27 | Siemens Ag | Programmierverfahren für einen Remanentspeicher einer speicherprogrammierbaren Steuerung |
US5915265A (en) * | 1995-12-22 | 1999-06-22 | Intel Corporation | Method and apparatus for dynamically allocating and resizing the dedicated memory in a shared memory buffer architecture system |
US5838972A (en) * | 1996-02-09 | 1998-11-17 | Sun Microsystems, Inc. | Method and apparatus for dynamically loading an input run-time module and an output run-time module |
US6112025A (en) * | 1996-03-25 | 2000-08-29 | Sun Microsystems, Inc. | System and method for dynamic program linking |
US5721824A (en) * | 1996-04-19 | 1998-02-24 | Sun Microsystems, Inc. | Multiple-package installation with package dependencies |
US5857106A (en) * | 1996-05-31 | 1999-01-05 | Hewlett-Packard Company | Runtime processor detection and installation of highly tuned processor specific routines |
US6408329B1 (en) * | 1996-08-08 | 2002-06-18 | Unisys Corporation | Remote login |
JPH10111792A (ja) * | 1996-10-03 | 1998-04-28 | Nec Corp | 画像処理装置 |
US6112020A (en) * | 1996-10-31 | 2000-08-29 | Altera Corporation | Apparatus and method for generating configuration and test files for programmable logic devices |
US6363436B1 (en) * | 1997-01-27 | 2002-03-26 | International Business Machines Corporation | Method and system for loading libraries into embedded systems |
US5938766A (en) * | 1997-03-21 | 1999-08-17 | Apple Computer, Inc. | System for extending functionality of a digital ROM using RAM/ROM jump tables and patch manager for updating the tables |
JPH11110194A (ja) * | 1997-10-06 | 1999-04-23 | Toshiba Corp | 外部ライブラリ関数との結合方法ならびに同方法がプログラムされ記録される記録媒体 |
US6845508B2 (en) * | 1997-12-19 | 2005-01-18 | Microsoft Corporation | Stream class driver for computer operating system |
US5953534A (en) * | 1997-12-23 | 1999-09-14 | University Of Washington | Environment manipulation for executing modified executable and dynamically-loaded library files |
US6427178B2 (en) * | 1998-03-04 | 2002-07-30 | Conexant Systems, Inc. | Software modem having a multi-task plug-in architecture |
US6314475B1 (en) | 1998-03-04 | 2001-11-06 | Conexant Systems, Inc. | Method and apparatus for monitoring, controlling and configuring local communication devices |
US6330597B2 (en) | 1998-03-04 | 2001-12-11 | Conexant Systems, Inc. | Method and apparatus for monitoring, controlling, and configuring remote communication devices |
FR2777673B1 (fr) | 1998-04-15 | 2001-09-21 | Bull Cp8 | Dispositif de traitement de l'information comprenant des moyens pour gerer une memoire virtuelle, et procede de stockage d'informations associe |
US6226627B1 (en) * | 1998-04-17 | 2001-05-01 | Fuji Xerox Co., Ltd. | Method and system for constructing adaptive and resilient software |
US6694366B1 (en) | 1998-04-29 | 2004-02-17 | Symbol Technologies, Inc. | Data reconciliation between a computer and a mobile data collection terminal |
US6826756B1 (en) | 1998-06-30 | 2004-11-30 | Symbol Technologies, Inc. | Automatic transfer of data from an input device to a software application |
US6237053B1 (en) | 1998-06-30 | 2001-05-22 | Symbol Technologies, Inc. | Configurable operating system having multiple data conversion applications for I/O connectivity |
US6430569B1 (en) | 1998-08-14 | 2002-08-06 | Sun Microsystems, Inc. | Methods and apparatus for type safe, lazy, user-defined class loading |
US6374312B1 (en) * | 1998-09-25 | 2002-04-16 | Intel Corporation | System for dedicating a host processor to running one of a plurality of modem programs and dedicating a DSP to running another one of the modem programs |
US6351781B1 (en) * | 1998-09-25 | 2002-02-26 | Intel Corporation | Code swapping techniques for a modem implemented on a digital signal processor |
US6502138B2 (en) * | 1998-09-25 | 2002-12-31 | Intel Corporation | Modem with code execution adapted to symbol rate |
US6490628B2 (en) * | 1998-09-25 | 2002-12-03 | Intel Corporation | Modem using a digital signal processor and a signal based command set |
US6661848B1 (en) | 1998-09-25 | 2003-12-09 | Intel Corporation | Integrated audio and modem device |
US6711206B1 (en) | 1998-09-25 | 2004-03-23 | Intel Corporation | Modem using a digital signal processor and separate transmit and receive sequencers |
US6625208B2 (en) * | 1998-09-25 | 2003-09-23 | Intel Corporation | Modem using batch processing of signal samples |
US6711205B1 (en) | 1998-09-25 | 2004-03-23 | Intel Corporation | Tone detector for use in a modem |
US7206849B1 (en) | 1998-10-05 | 2007-04-17 | Symbol Technologies, Inc. | Communication in a wireless communications network when a mobile computer terminal may be unreachable |
US6675203B1 (en) | 1998-10-05 | 2004-01-06 | Symbol Technologies, Inc. | Collecting data in a batch mode in a wireless communications network with impeded communication |
US6262726B1 (en) | 1998-10-09 | 2001-07-17 | Dell U.S.A., L.P. | Factory installing desktop components for an active desktop |
US6442682B1 (en) * | 1999-02-18 | 2002-08-27 | Auspex Systems, Inc. | Characterization of data access using file system |
DE19919674A1 (de) * | 1999-04-30 | 2000-11-16 | Motorola Inc | Simulator für elektronische Systeme, sowie Verfahren |
US6618769B1 (en) * | 1999-05-27 | 2003-09-09 | Sun Microsystems, Inc. | Module-by-module verification |
US6601114B1 (en) * | 1999-05-27 | 2003-07-29 | Sun Microsystems, Inc. | Fully lazy linking with module-by-module verification |
GB9921720D0 (en) * | 1999-09-14 | 1999-11-17 | Tao Group Ltd | Loading object-oriented computer programs |
US6530077B1 (en) * | 1999-09-15 | 2003-03-04 | Powerquest Corporation | Device and method for releasing an in-memory executable image from its dependence on a backing store |
US6763034B1 (en) * | 1999-10-01 | 2004-07-13 | Stmicroelectronics, Ltd. | Connection ports for interconnecting modules in an integrated circuit |
US6983315B1 (en) | 2000-01-18 | 2006-01-03 | Wrq, Inc. | Applet embedded cross-platform caching |
US7988559B2 (en) * | 2001-03-08 | 2011-08-02 | Igt | Computerized gaming system, method and apparatus |
US7043641B1 (en) | 2000-03-08 | 2006-05-09 | Igt | Encryption in a secure computerized gaming system |
CA2402389A1 (en) * | 2000-03-08 | 2002-09-19 | Shuffle Master, Inc. | Computerized gaming system, method and apparatus |
AU2001237704A1 (en) * | 2000-06-01 | 2001-12-11 | Aduva Inc. | A virtual system configurator for client systems |
US7076647B2 (en) * | 2000-06-09 | 2006-07-11 | Hewlett-Packard Development Company, L.P. | Dynamic kernel tunables |
US6983464B1 (en) * | 2000-07-31 | 2006-01-03 | Microsoft Corporation | Dynamic reconfiguration of multimedia stream processing modules |
US7203841B2 (en) * | 2001-03-08 | 2007-04-10 | Igt | Encryption in a secure computerized gaming system |
US7302462B2 (en) * | 2001-03-12 | 2007-11-27 | Mercury Computer Systems, Inc. | Framework and methods for dynamic execution of digital data processor resources |
WO2003023647A1 (en) * | 2001-09-10 | 2003-03-20 | Igt | Method for developing gaming programs compatible with a computerized gaming operating system and apparatus |
US7931533B2 (en) * | 2001-09-28 | 2011-04-26 | Igt | Game development architecture that decouples the game logic from the graphics logics |
US6902481B2 (en) | 2001-09-28 | 2005-06-07 | Igt | Decoupling of the graphical presentation of a game from the presentation logic |
US8708828B2 (en) | 2001-09-28 | 2014-04-29 | Igt | Pluggable modular gaming modifiers and configuration templates for gaming environments |
US20030074487A1 (en) * | 2001-10-17 | 2003-04-17 | Tankut Akgul | Dynamic operating system |
US6811085B2 (en) * | 2001-10-26 | 2004-11-02 | Symbol Technologies, Inc. | Miniature imager |
EP1463569A4 (de) * | 2001-11-26 | 2010-06-02 | Igt Reno Nev | Vorrichtung und verfahren zur unverzögerten durchgangsvalidierung |
US20030203755A1 (en) * | 2002-04-25 | 2003-10-30 | Shuffle Master, Inc. | Encryption in a secure computerized gaming system |
US7509485B2 (en) * | 2002-09-04 | 2009-03-24 | Chou Hui-Ling | Method for loading a program module in an operating system |
US20040093359A1 (en) * | 2002-11-12 | 2004-05-13 | Sharpe Edward J. | Methods and apparatus for updating file systems |
US7634770B2 (en) * | 2003-05-19 | 2009-12-15 | Hewlett-Packard Development Company, L.P. | Kernel module interface dependencies |
US7954086B2 (en) | 2003-05-19 | 2011-05-31 | Hewlett-Packard Development Company, L.P. | Self-describing kernel modules |
US7167974B2 (en) | 2003-05-19 | 2007-01-23 | Hewlett-Packard Development Company, L.P. | Multiple saved kernel configurations |
US7171550B1 (en) * | 2003-06-18 | 2007-01-30 | Hewlett-Packard Development Company, Lp, | Data structure and method for managing modules associated with a kernel |
US20050071856A1 (en) * | 2003-09-26 | 2005-03-31 | Kumar C.P. Vijay | Dynamically loadable stub modules |
KR100544674B1 (ko) * | 2003-11-11 | 2006-01-23 | 한국전자통신연구원 | 커널 기반의 침입탐지시스템에서의 침입탐지규칙 동적변경 방법 |
US7900194B1 (en) * | 2004-03-25 | 2011-03-01 | Verizon Corporate Services Group Inc. | Kernel-based intrusion detection using bloom filters |
US8117607B2 (en) * | 2004-08-18 | 2012-02-14 | International Business Machines Corporation | Administration of kernel extensions |
US20060070089A1 (en) * | 2004-08-20 | 2006-03-30 | Shahid Shoaib | Method and apparatus for dynamic replacement of device drivers in the operating system (OS) kernel |
US20060048128A1 (en) * | 2004-09-01 | 2006-03-02 | Roth Steven T | Module preparation scripts |
US7853927B2 (en) * | 2005-02-03 | 2010-12-14 | Hewlett-Packard Development Company, L.P. | Methods and tools for executing and tracing user-specified kernel instructions |
US8490082B2 (en) * | 2005-11-03 | 2013-07-16 | International Business Machines Corporation | System and method for representing user processes as software packages in a software package management system |
US7756893B2 (en) | 2005-11-09 | 2010-07-13 | Microsoft Corporation | Independent computation environment and data protection |
US8112798B2 (en) * | 2005-11-09 | 2012-02-07 | Microsoft Corporation | Hardware-aided software code measurement |
US8595747B2 (en) * | 2005-12-29 | 2013-11-26 | Sony Computer Entertainment Inc. | Efficient task scheduling by assigning fixed registers to scheduler |
US7996848B1 (en) * | 2006-01-03 | 2011-08-09 | Emc Corporation | Systems and methods for suspending and resuming threads |
US7987512B2 (en) * | 2006-05-19 | 2011-07-26 | Microsoft Corporation | BIOS based secure execution environment |
US20080005560A1 (en) * | 2006-06-29 | 2008-01-03 | Microsoft Corporation | Independent Computation Environment and Provisioning of Computing Device Functionality |
KR100916301B1 (ko) * | 2007-10-01 | 2009-09-10 | 한국전자통신연구원 | 커널 api 대화식 실행 장치 및 방법 |
CN101546260B (zh) | 2008-03-28 | 2012-07-11 | 国际商业机器公司 | 用于重构面向服务的应用的方法及其设备 |
US8627306B2 (en) * | 2008-08-06 | 2014-01-07 | Caterpillar Inc. | Method and system for updating an information management system configuration |
US9111036B2 (en) * | 2010-04-30 | 2015-08-18 | Red Hat, Inc. | Preloading unwind data for non-intrusive backtracing |
US8495601B2 (en) * | 2010-06-09 | 2013-07-23 | Lear Corporation | Shared memory architecture |
US8397245B2 (en) * | 2010-07-12 | 2013-03-12 | International Business Machines Corporation | Managing loading and unloading of shared kernel extensions in isolated virtual space |
KR101895453B1 (ko) * | 2011-11-09 | 2018-10-25 | 삼성전자주식회사 | 이기종 컴퓨팅 환경에서 보안 강화 방법 및 장치 |
US9436791B1 (en) * | 2015-03-24 | 2016-09-06 | International Business Machines Corporation | Optimizing placement of circuit resources using a globally accessible placement memory |
US20170353476A1 (en) * | 2016-06-06 | 2017-12-07 | Google Inc. | Disabling Malicious Browser Extensions |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4445190A (en) * | 1981-06-16 | 1984-04-24 | International Business Machines Corporation | Program identification encoding |
US4787034A (en) * | 1984-11-14 | 1988-11-22 | Pal Szoke | Program access system |
JPS6378231A (ja) * | 1986-09-22 | 1988-04-08 | Nec Corp | 部分的プログラム結合方式 |
US5175828A (en) * | 1989-02-13 | 1992-12-29 | Hewlett-Packard Company | Method and apparatus for dynamically linking subprogram to main program using tabled procedure name comparison |
US5291601A (en) * | 1989-06-01 | 1994-03-01 | Hewlett-Packard Company | Shared libraries implemented with linking program loader |
US5226160A (en) * | 1989-07-18 | 1993-07-06 | Visage | Method of and system for interactive video-audio-computer open architecture operation |
US5247678A (en) * | 1989-10-12 | 1993-09-21 | Texas Instruments Incorporated | Load time linker for software used with a multiprocessor system |
US5303392A (en) * | 1992-02-27 | 1994-04-12 | Sun Microsystems, Inc. | Accessing current symbol definitions in a dynamically configurable operating system |
-
1993
- 1993-05-21 EP EP93303987A patent/EP0573190B1/de not_active Expired - Lifetime
- 1993-05-21 DE DE69330691T patent/DE69330691T2/de not_active Expired - Fee Related
- 1993-06-03 JP JP5156393A patent/JPH06295237A/ja active Pending
-
1995
- 1995-10-11 US US08/540,875 patent/US5634058A/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
EP0573190A2 (de) | 1993-12-08 |
JPH06295237A (ja) | 1994-10-21 |
US5634058A (en) | 1997-05-27 |
EP0573190B1 (de) | 2001-09-05 |
EP0573190A3 (de) | 1994-02-02 |
DE69330691D1 (de) | 2001-10-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE69330691T2 (de) | Dynamisch konfigurierbares Kernsystem | |
DE68916853T2 (de) | Unabhängige Programmlader für virtuelle Maschinenarchitektur. | |
DE69503056T2 (de) | Selbstkonfigurierendes rechnersystem | |
DE3689961T2 (de) | Verfahren zur Verarbeitung von Unterbrechungen in einem digitalen Rechnersystem. | |
DE69321255T2 (de) | Vorrichtung zur ausführung vom mehreren programmteilen mit verschiedenen objektcodetypen in einem einzigen programm oder in einer prozessorumgebung | |
DE69023499T2 (de) | Rechner mit erweitertem virtuellem Speicher. | |
DE69723286T2 (de) | Echtzeitprogramm-sprachbeschleuniger | |
DE69737709T2 (de) | Verfahren und Vorrichtung für Informationsverarbeitung und Speicherzuordnungsanordnung | |
DE112012004893B4 (de) | Implementieren eines Software-Abbildes auf mehreren Zielen unter Verwendung einer Datenstromtechnik | |
DE69534867T2 (de) | Verfahren und System zur Lieferung geschützter Gerätetreiber | |
DE69404166T2 (de) | Automatisches start-fachwerk | |
DE69427174T2 (de) | Dynamische Hochleistungsprogrammverknüpfung durch Cachespeicherung | |
DE69227774T2 (de) | Speicherverwaltungsverfahren | |
DE10047266B4 (de) | Verfahren und Vorrichtung zum Booten einer Workstation von einem Server | |
DE69627814T2 (de) | System zum bereitstellen eines bios für den hauptrechner | |
DE10393920B4 (de) | Verfahren und Systeme zur Steuerung virtueller Maschinen | |
DE69604734T2 (de) | Client-Server-Computersystem und Verfahren zum Verwenden eines lokalen Plattenlaufwerks als Daten-Cache | |
DE69936162T2 (de) | Verfahren und Gerät für ein objektorientiertes Unterbrechungssystem | |
DE60213606T2 (de) | Anwendungsprogrammserver mit einem laufwerkaufteilungsschema zur anpassung der wachstumsgrösse des anwendungsprogramms | |
DE69618221T2 (de) | Mechanismus zur wartung objektorientierter "methoden" der keine unterbrechung des computersystems erfordert | |
DE69231176T2 (de) | Verfahren zum Integrieren eines diskreten Unterprogramms in ein Hauptprogramm | |
DE4215063A1 (de) | Einrichtung und verfahren zum seitenwechsel bei einem nicht-fluechtigen speicher | |
DE19847133A1 (de) | System und Verfahren zum Aktualisieren von Zuordnungen von Partitionen zu logischen Laufwerken in einem Computerspeichergerät | |
DE19518529A1 (de) | Vorrichtung und Verfahren zum Rekonfigurieren eines eine inkompatible CPU enthaltenden Computersystems | |
DE19846398C2 (de) | Verfahren zum Simulieren eines Computerspeichergeräts |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8364 | No opposition during term of opposition | ||
8339 | Ceased/non-payment of the annual fee |