DE69330691T2

DE69330691T2 - Dynamisch konfigurierbares Kernsystem

Info

Publication number: DE69330691T2
Application number: DE69330691T
Authority: DE
Inventors: Tom Allen; William F. Pittore; Joseph E. Provino
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1992-06-03
Filing date: 1993-05-21
Publication date: 2002-07-04
Anticipated expiration: 2013-05-22
Also published as: EP0573190A2; EP0573190A3; EP0573190B1; JPH06295237A; DE69330691D1; US5634058A

Description

HINTERGRUND DER ERFINDUNG

1. GEBIET DER ERFINDUNG:

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.

2. TECHNISCHER HINTERGRUND:

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.

ZUSAMMENFASSENDE DARSTELLUNG DER ERFINDUNG

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.

KURZBESCHREIBUNG DER ZEICHNUNG

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.

DETAILLIERTE BESCHREIBUNG DER ERFINDUNG

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

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.