DE102005040075A1

DE102005040075A1 - Dynamisches Verbinden von Modulen in einer Vorbetriebssystemumgebung

Info

Publication number: DE102005040075A1
Application number: DE102005040075A
Authority: DE
Inventors: Gregory T. Andersen; Alexander Folsom Jizrawi
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 2004-09-24
Filing date: 2005-08-24
Publication date: 2006-04-06
Also published as: US20060070053A1; JP2006092544A; US7730472B2

Abstract

Ein dynamisches Verbindungsladeprogramm ist für eine Vorbetriebssystem-Umgebung vorgesehen. Ein derartiges Ladeprogramm kann eine einfache, flexible und kostenwirksame Weise zum Laden von Modulen in Laufzeit in einer Vorbetriebssystem-Umgebung liefern.

Description

Bevor ein Hersteller ein Betriebssystem auf einem Computersystem installiert, testet und verifiziert derselbe typischerweise den Betrieb sowohl der Hardware als auch der Firmware.

Vorbetriebssystemumgebungen

Für viele Computersysteme mit zentralen Verarbeitungseinheiten von Intel ist die Vorbetriebssystem-Verifizierungsumgebung die Extensible Firmware Interface (erweiterbare Firmware-Schnittstelle) (EFI). Die EFI-Umgebung wird typischerweise bei Verifizierungswerkzeugen verwendet, um Wechselwirkungen zwischen Chipsätzen, Systembussen, I/O-Bussen, Peripheriegeräten, einer Systemfirmware und anderen Entitäten auf Systemebene zu testen. EFI ist eine Industrienorm und gilt für alle IPF-Systeme. Genauer gesagt stellt die EFI-Firmware eine Schnittstelle mit der Systemabstraktionsschicht (SAL = System Abstraction Layer) her, die wiederum eine Schnittstelle mit der Prozessorabstraktionsschicht (PAL = Processor Abstraction Layer) herstellt, die eine Schnittstelle mit einem Hardware-IPF-Prozessor herstellt.

Die EFI-Umgebung verwaltet einen Speicher eines Computersystems, bis ein Betriebssystem gebootet wird. Vorbetriebssystem-Verifizierungsanwendungen können sowohl im Inneren einer EFI (EFI-Anwendungen) als auch auf einer EFI (Nicht-EFI-Anwendungen) als ein Teil der EFI-Umgebung unter Verwendung der EFI-Bibliothek von Funktionen, wie beispielsweise des Echtzeittakts und Tabellen von EFI-Parametern und Variablennamen ausgeführt werden. Die EFI-Bibliothek ist ferner durch das Betriebssystem zugreifbar, nachdem dasselbe gebootet ist.

Kompilierung

Computer führen typischerweise Maschinensprachen auf niedriger Ebene aus, die ohne weiteres durch Computerprozessoren verarbeitet werden, aber die schwierig und zeitraubend für Programmierer zu verwenden sind, während ein Programmieren typischerweise in einer Sprache auf hoher Ebene vorgenommen wird, die einfacher und weniger zeitraubend für Programmierer zu verwenden ist. Ein Kompilierer bzw. Compiler ist ein Übersetzer, dessen Quellsprache eine Sprache auf hoher Ebene ist und dessen Objektsprache nahe der Maschinensprache eines tatsächlichen Computers ist, wobei dieselbe entweder eine Assembly-Sprache oder irgendeine Varietät einer Maschinensprache (verschiebbar bzw. relativ oder absolut) ist. Eine Übersetzung einer Quellsprache auf hoher Ebene in ausführbare Maschinensprachprogramme betrifft häufig mehr als einen Übersetzungsschritt. Zum Beispiel ist es nicht ungewöhnlich, dass ein Programm zuerst in eine maschinenabhängige Assembly-Sprache kompiliert wird, dann zusammengefügt wird, um einen verschiebbaren Maschinencode zu erzeugen, und schließlich geladen und verbunden wird, um einen ausführbaren Maschinencode zu erzeugen. Außerdem betrifft der Kompilierungsschritt selbst typischerweise eine Anzahl von Durchläufen, die das Programm vor einem Erzeugen des endgültigen Objektprogramms progressiv in verschiedene Zwischenformen übersetzen.

Ladeprogramme

Ein Ladeprogramm (Loader) oder Verbindungsladeprogramm ist ein Übersetzerschritt, dessen Objektsprache der tatsächliche ausführbare Maschinencode ist und dessen Quellsprache beinahe identisch ist, aber gewöhnlich aus Maschinensprachprogrammen in verschiebbarer Form zusammen mit Tabellen von Daten besteht, die Punkte spezifizieren, wo der verschiebbare Code multipliziert werden muss, um wirklich ausführbar zu werden. Dieser Schritt wird gerade vor einer Ausführung durchgeführt, nachdem der tatsächliche Speicher zugewiesen wurde.

Bibliotheken

Ein Bereich ist typischerweise als dynamisch oder statisch klassifiziert. Eine Dynamikbereichregel defi niert einen Bereich hinsichtlich einer Programmausführung bei Laufzeit. Eine Statikbereichregel definiert einen Bereich hinsichtlich der Struktur des Programms bei einer Bauzeit (Übersetzungszeit). Programme enthalten typischerweise Funktionsrufe zu Modulen in einer Bibliothek, die dem Kompilierer verfügbar ist. In einer Statisch-Bibliothek-Umgebung werden die Module, die durch die Programmfunktionsrufe referenziert werden, bei einer Bauzeit (build time) verbunden bzw. verknüpft und geladen und können in Laufzeit nicht verändert werden. Bei einer dynamischen Umgebung ist die Bibliothek in Laufzeit verfügbar und das Verbinden und Laden der Bibliothekmodule wird gerade vor einer Initialisierung einer Ausführung vorgenommen.

Referenzen

Referenzieren ist die Operation eines Wiedererlangens des Daten- oder Programmobjekts, das gegenwärtig einem gegebenen Identifizierer zugeordnet ist, unter Verwendung der eindeutigen aktuell aktiven Zuordnung für den Identifizierer. Referenzen zu Identifizierern sind als Lokalreferenzen klassifiziert, falls dieselben eine Zuordnung verwenden, die lediglich innerhalb des aktuell ausgeführten Teilprogramms aktiv ist. Eine globale Referenz ist eine Referenz zu einer Zuordnung, die eine Programmausführung hindurch aktiv ist. Eine lokale Umgebung oder lokale Referenzierumgebung wird verwendet, um diese lokalen Zuordnungen zu bezeichnen, die bei der letzten Veränderung bei der Referenzierumgebung eingebracht wurden.

Die oben beschriebenen Konzepte sind unten in Verbindung mit 1A – 3 erörtert und dargestellt.

Mit Bezug auf 1A ist eine statische Vorbetriebssystem-Bauzeitumgebung 10 gezeigt, die eine EFI-Anwendung 2 und eine Nicht-EFI-Anwendung 4 umfasst, die beide Funktionsrufe zu einem EFI-Bibliothekmodul 8 umfassen. Das Bibliothekmodul 8 ist in der Form eines verschiebbaren Maschinencodes mit einer Tabelle von Daten, die Punkte spezifizieren, wo der verschiebbare Code modifiziert werden muss, um ein wirklich ausführbarer Maschinencode zu werden. Die statische Vorbetriebssystem-Bauzeitumgebung 10 umfasst ein statisches Ladeprogramm 6. Während des letzten Schritts der Kompilierung der Anwendung 2 verbindet das statische Ladeprogramm 6 eine erste Kopie des Moduls 8 mit der Anwendung 2 und modifiziert alle der Plätze, wo eine relative Adresse mit einer absoluten Adresse ersetzt werden muss. Auf eine ähnliche Weise verbindet das statische Ladeprogramm 6 während des letzten Schritts der Kompilierung der Nicht-EFI-Anwendung 4 eine zweite Kopie des Moduls 8 mit der Anwendung 4 und modifiziert alle der Plätze, wo eine relative Adresse mit einer absoluten Adresse ersetzt werden muss. Bei einer derartigen statischen Vorbetriebssystem-Bauzeitumgebung erfordert jeder Funktionsruf bei jeder Anwendung 2 und 4 eine Kopie des verschiebbaren Bibliotheksmoduls 8. Irgendeine Veränderung an dem Quellcode bei den Anwendungen 2 und 4 oder dem gerufenen Modul 8 erfordert eine vollständige Rekompilierung der Anwendungen.

Mit Bezug auf 1B weist die statische Vorbetriebssystem-Laufzeitumgebung 12, die der statischen Vorbetriebs-Bauumgebung 10 (1A) zugeordnet ist, keinen Zugriff mehr auf ein Ladeprogramm auf. Die kompilierte EFI-Anwendung 2, die mit dem kompilierten EFI-Bibliothekmodul 8 verbunden ist, ist in einem nicht verschiebbaren Maschinencodeformat und ist in einen Speicher geladen, um ausgeführt zu werden.

1C zeigt die statische Vorbetriebssystem-Laufzeitumgebung 12, die der statischen Vorbetriebs-Bauumgebung 10 zugeordnet ist, während einer Ausführung. Die kompilierte Anwendung 2 enthält Funktionsrufe 14, denen durch die kompilierte und verbundene Kopie des EFI-Moduls 8 genüge geleistet wird. Die Variablen im Inneren des Bibliothekmoduls 8 mit globalen Referenzen weisen einen Zugriff auf alle Variablen auf, die der kompilierten Anwendung 2 zugeordnet sind. Die Referenzumgebung ist statisch und ist bei Bauzeit festgelegt und kann nicht ohne eine Rekompilie rung verändert werden. Falls es ferner irgendeine Veränderung bei dem Code für die Anwendung 2 gibt, muss das gesamte Paket rekompiliert werden, und falls es irgendeine Veränderung bei dem Code für das Modul 8 gibt, muss das gesamte Paket rekompiliert werden. Falls es deshalb irgendeine zusätzliche erforderliche Funktionalität gibt, muss die Funktionalität in einer statischen Vorbetrieb-Bauumgebung hinzugefügt werden und das gesamte Paket muss rekompiliert werden.

Mit Bezug auf 2A umfasst eine statische Vorbetriebssystem-Bauzeitumgebung 20 eine Anzahl (hier vier) von Anwendungen AA-DD, von denen einige EFI-Anwendungen sind und von denen einige Nicht-EFI-Anwendungen sind und die alle eine Funktionalität von einem EFI-Bibliothekmodul NN benötigen. Das statische Ladeprogramm 6 kopiert das Modul NN in jede der Anwendungen, verbindet den verschiebbaren Maschinencode NN mit dem Maschinencode der Anwendungen AA-DD und erzeugt vier Anwendungen in einem absoluten Maschinencodeformat, das ausgeführt werden kann.

Mit Bezug auf 2B weist die statische Vorbetriebssystem-Laufzeitumgebung 22, die der statischen Vorbetriebs-Bauumgebung 20 (2A) zugeordnet ist, keinen Zugriff mehr auf ein Ladeprogramm auf. Die absoluten Binärzahlen der Anwendungen AA-DD können ausgeführt werden. Es kann keine Veränderungen an den Anwendungen oder den gemeinschaftlich verwendeten Bibliothekmodul ohne ein Rekompilieren geben. Ferner gibt es ohne eine vollständige Rekompilierung des gesamten Satzes keine Weise, eine Funktionalität zu irgendeiner der Anwendungen AA-DD hinzuzufügen oder von derselben zu entfernen.

Mit Bezug auf 3 umfasst ein Vorbetriebssystemumgebung-Hochrüstprozess 112 eine statische Bauzeitumgebung 112, eine statische Laufzeitumgebung 114 und eine Hochrüstumgebung 120. Wie vorhergehend beschrieben, werden während einer statischen Bauzeit 110 EFI-Anwendungen 100 und Nicht-EFI- Anwendungen 104 unter Verwendung der EFI-Bibliothek 102 kompiliert, um Funktionsrufreferenzen genüge zu leisten. Dies wird durch das statische Ladeprogramm 106 vorgenommen, das Module aus der EFI-Bibliothek 102 in die Anwendungen kopiert und dieselben in einem absoluten Maschinencodeformat verbindet. Während der statischen Laufzeit 114 wird die kompilierte EFI-Anwendung 116 mit verbundenen Bibliotheksmodulen ausgeführt. Während der statischen Laufzeit 114 wird ferner die kompilierte Nicht-EFI-Anwendung 118 mit verbundenen Bibliotheksmodulen ausgeführt. Falls es eine Codehochrüstung 122 an einer EFI-Anwendung oder einer Nicht-EFI-Anwendung während einer Hochrüstzeit 120 gibt, kehrt der Prozess zu der Bauzeitumgebung 110 über den Weg 124 zurück und rekompiliert die Anwendungen. Falls es eine Codehochrüstung an einem referenzierten Bibliothekmodul gibt, kehrt der Prozess zu der Bauzeitumgebung 110 über den Weg 124 zurück und rekompiliert die Anwendungen nach einem Rekompilieren der EFI-Bibliothek mit dem hochgerüsteten Modul. Es gibt keine Einrichtung, um die statischen Umgebungen zu verändern, ohne den Prozess von Beginn an wieder zu starten. Dies ist unzweckmäßig, kostspielig, prozessmäßig komplex, unflexibel und zeitintensiv.

Es ist die Aufgabe der vorliegenden Erfindung, ein elektronisches System und ein Verfahren mit verbesserten Charakteristika zu schaffen.

Diese Aufgabe wird durch ein System gemäß Anspruch 1 und ein Verfahren gemäß Anspruch 11 gelöst.

Ein dynamisches Verbindungsladeprogramm ist für eine Vorbetriebssystemumgebung vorgesehen.

Ein derartiges Ladeprogramm kann eine einfache, flexible und kostenwirksame Weise zum Laden von Modulen in Laufzeit in einer Vorbetriebssystemumgebung liefern.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:

1A (Stand der Technik) ein Blockdiagramm, das eine statische Bauzeitumgebung mit einem statischen Ladeprogramm zeigt;

1B (Stand der Technik) ein Blockdiagramm der Laufzeitumgebung der Anwendungen von 1A;

1C (Stand der Technik) ein Blockdiagramm der Laufzeitumgebung von 1B, das die herkömmliche Weise zeigt, auf die Funktionsrufe vorgenommen werden und globale Variablen verfügbar gemacht werden;

2A (Stand der Technik) ein Blockdiagramm einer statischen Bauzeitumgebung, das mehrere Anwendungen zeigt, die das gleiche Bibliothekmodul benötigen;

2B (Stand der Technik) ein Blockdiagramm einer statischen Laufzeitumgebung, das die mehreren Anwendungen von 2A zeigt, wobei das gleiche Bibliothekmodul geladen ist;

3 (Stand der Technik) ein Funktionsdiagramm eines Systemverifizierungsprozesses mit einem statischen Ladeprogramm;

4A ein Blockdiagramm, das eine Bauzeitumgebung mit einem dynamischen Ladeprogramm gemäß einem Ausführungsbeispiel der Erfindung zeigt;

4B ein Blockdiagramm der Laufzeitumgebung der Anwendungen von 4A gemäß einem Ausführungsbeispiel der Erfindung;

4C ein Blockdiagramm der Laufzeitumgebung von 4B, das die Weise zeigt, auf die Funktionsrufe vorgenommen werden und auf globale Variablen zugegriffen wird, gemäß einem Ausführungsbeispiel der Erfindung;

5A ein Blockdiagramm einer Bauzeitumgebung, das mehrere Anwendungen zeigt, die das gleiche Bibliothekmodul benötigen, gemäß einem Ausführungsbeispiel der Erfindung;

5B ein Blockdiagramm einer Laufzeitumgebung der mehreren Anwendungen von 5A, wobei das gleiche Bibliotheksmodul geladen ist, gemäß einem Ausführungsbeispiel der Erfindung;

5C ein Blockdiagramm einer nachfolgenden Laufzeitumgebung, das die mehreren Anwendungen von 5A zeigt, wobei ein hochgerüstetes Bibliothekmodul dynamisch geladen ist, gemäß einem Ausführungsbeispiel der Erfindung;

5D ein Blockdiagramm einer nachfolgenden Laufzeitumgebung, das mehrere hochgerüstete Anwendungen relativ zu 5B zeigt, wobei ein gemeinsames Bibliothekmodul dynamisch geladen ist, gemäß einem Ausführungsbeispiel der Erfindung;

6A ein Blockdiagramm einer Bauzeitumgebung, das eine Anwendung zeigt, die mit mehreren unterschiedlichen Sätzen von Bibliothekmodulen aufgebaut ist, gemäß einem Ausführungsbeispiel der Erfindung;

6B ein Blockdiagramm einer Laufzeitumgebung, das die Anwendung von 6A zeigt, die zu mehreren unterschiedlichen Anwendungen wird, basierend auf unterschiedlichen Sätzen von Bibliothekmodulen, gemäß einem Ausführungsbeispiel der Erfindung; und

7 ein Funktionsdiagramm, das einen Systemverifizierungsprozess mit einem dynamischen Ladeprogramm gemäß einem Ausführungsbeispiel der Erfindung zeigt.

Mit Bezug auf 4A ist eine dynamische Vorbetriebssystem-Bauzeitumgebung 40 gezeigt, die eine EFI-Anwendung 42 und eine Nicht-EFI-Anwendung 44 umfasst, die beide Funktionsrufe zu einem EFI-Bibliothekmodul 48 umfassen. Das Bibliothekmodul 48 ist in der Form eines verschiebbaren Maschinencodes mit einer Tabelle von Daten, die Punkte spezifizieren, wo der verschiebbare Code modifiziert werden muss, um ein wirklich ausführbarer Maschinencode zu werden. Die dynamische Vorbetriebssystem-Bauzeitumgebung 40 umfasst ein dynamisches Ladeprogramm 46. Das dynamische Ladeprogramm 46 ist als ein Teil der EFI-Anwendung 42 und auch der Nicht-EFI-Anwendung 44 hergestellt. Das Bibliothekmodul 48 ist in einem ABI-Format (ABI = Application Binary). Das ABI, das durch Intel für EFI-Systeme definiert ist, ist ELF64. Während der Kompilierung der EFI-Anwendung 42 wird eine Referenz zu dem ABI-konformen Bibliothekmodul 48 gemacht und eingefügt, aber nicht geladen. Während der Kompilierung der Nicht-EFI-Anwendung 44 wird eine andere Referenz zu dem ABI-konformen Bibliothekmodul 48 gemacht und eingefügt, aber nicht geladen.
Mit Bezug auf 4B umfasst die dynamische Vorbetriebssystem-Laufzeitumgebung 49, die der dynamischen Vorbetrieb-Bauumgebung 40 (4A) zugeordnet ist, das dynamische Ladeprogramm 46 als Teil jeder Anwendung. Das dynamische Ladeprogramm 46 ist ein Stück eines Codes, das versteht, wie ein Modul in einem Speicher zu laden ist, die Bibliothekmodulinhalte zu parsen bzw. syntaktisch zu analysieren sind, die notwendigen Verschiebungen durchzuführen sind und schließlich irgendwelche Abhängigkeiten zwischen der Lade anwendung und dem Modul, das geladen wird, zu verbinden bzw. verknüpfen sind. Das dynamische Ladeprogramm 46 verbindet die geladene Kopie des ABI-konformen Bibliothekmoduls 48 mit der EFI-Anwendung 42 und modifiziert alle Plätze, wo eine relative Adresse mit einer absoluten Adresse ersetzt werden muss. Auf eine ähnliche Weise verbindet während des Ladens der Nicht-EFI-Anwendung 44 das dynamische Ladeprogramm 46 eine zweite geladene Kopie des ABI-konformen Bibliothekmoduls 48 mit der Nicht-EFI-Anwendung 44 und modifiziert alle Plätze, wo eine relative Adresse mit einer absoluten Adresse ersetzt werden muss. Die kompilierte EFI-Anwendung 42, die mit dem kompilierten ABI-konformen EFI-Bibliothekmodul 48 verbunden ist, ist in einem verschiebbaren Maschinencodeformat und ist bereit, ausgeführt zu werden. Auf eine ähnliche Weise ist die kompilierte Nicht-EFI-Anwendung 44, die mit dem kompilierten ABI-konformen EFI-Bibliothekmodul 48 verbunden ist, in einem nicht verschiebbaren Maschinencodeformat und ist bereit, ausgeführt zu werden.
Nach der ersten Ausführung der kompilierten, verbundenen und geladenen Anwendungen kann es irgendeine Anzahl von zusätzlichen Ausführungen bei nachfolgenden dynamischen Laufzeiten geben. Falls es eine Hochrüstung an dem Bibliothekmodul 48 gibt und das hochgerüstete Bibliothekmodul rekompiliert wird, dann ersetzt das hochgerüstete ABI-konforme Bibliothekmodul 48 die nicht hochgerüstete Version des Moduls in der Bibliothek und bei der nächsten dynamischen Laufzeit verbindet und lädt das dynamische Ladeprogramm 46 das hochgerüstete ABI-konforme Bibliothekmodul 48 mit der referenzierenden Anwendung ohne einen Bedarf, die Anwendung zu rekompilieren.
4C zeigt eine dynamische Vorbetriebssystem-Laufzeitumgebung 49, die der dynamischen Vorbetrieb-Bauumgebung 40 (4A) zugeordnet ist, während einer Ausführung. Die kompilierte Anwendung 42 enthält Funktionsrufe 43, denen durch die kompilierte und verbundene Kopie des ABI-konformen EFI-Moduls 48 genüge geleistet wird. Die Variablen im Inneren des Bibliothekmoduls 48 mit globalen Referenzen weisen einen Zugriff auf alle Variablen auf, die der kompilierten Anwendung 42 zugeordnet sind. Die Referenzumgebung ist dynamisch und ist bei Laufzeit festgelegt und kann somit ohne eine Rekompilierung der Anwendung verändert werden, falls die Bibliothek hochgerüstet wird. Obwohl ein dynamisches Ladeprogramm 46 während einer Ausführung der Anwendung 42 vorhanden ist, wird dasselbe zu einer nachfolgenden Ladeoperation, die einer nachfolgenden Ausführung vorhergeht, nicht verwendet. Und obwohl lediglich eine der Anwendungen 42 gezeigt ist, ist die Ausführung der Anwendung 44 ähnlich.
Unter Bezugnahme auf 5A umfasst eine dynamische Vorbetriebssystem-Bauzeitumgebung 50 eine Anzahl (hier vier) von Anwendungen A1-D1, von denen einige EFI-Anwendungen sind und denen einige Nicht-EFI-Anwendungen sind und die alle eine Funktionalität von einem ABI-konformen EFI-Bibliothekmodul N1 benötigen. Das dynamische Ladeprogramm 46 wird als ein Teil des Kompilierungsprozesses in jede Anwendung eingebaut. Dann kopiert das dynamische Ladeprogramm 46 die ABI-konforme EFI-Bibliothek N1 in jede der Anwendungen.
Mit Bezug auf 5B weist die dynamische Vorbetriebssystem-Laufzeitumgebung 52, die der dynamischen Vorbetrieb-Bauumgebung 50 (5A) zugeordnet ist, weiterhin einen Zugriff auf das Ladeprogramm 46 auf. Das dynamische Ladeprogramm 46 jeder Anwendung verbindet den verschiebbaren Maschinencode des Moduls N1 mit dem Maschinencode der Anwendungen A1-D1 und erzeugt vier Anwendungen in einem absoluten Maschinencodeformat, das ausgeführt werden kann.
Mit Bezug auf 5C umfasst eine erste nachfolgende dynamische Vorbetriebssystem-Laufzeitumgebung 54 die gleichen vier Anwendungen A1-D1, von denen jede ein dynamisches Ladeprogramm 46 umfasst, das eine hochgerüstete ABI-konforme EFI-Bibliothek N2 vor einer Ausführung verbindet und lädt. Keine der Anwendungen muss rekompiliert werden, um die Funktionalität zu verändern, die der hochgerüsteten ABI-konformen EFI-Bibliothek N2 zugeordnet ist.
Mit Bezugnahme auf 5D umfasst eine zweite nachfolgende dynamische Vorbetriebssystem-Laufzeitumgebung 56 die gleichen vier Anwendungen, aber zwei der Anwendungen weisen eine unterschiedliche zusätzliche Funktionalität auf. Die Anwendung A2 ist eine Hochrüstung der Anwendung A1 (5B) und die Anwendung C2 ist eine Hochrüstung der Anwendung C1 (5B). Diese zwei Anwendungen werden getrennt rekompiliert und greifen, wenn dieselben verbunden und geladen sind, auf die neue Funktionalität aus der ABI-konformen Bibliothek zu. Es gibt keinen Bedarf nach einer Rekompilierung des gesamten Satzes von Anwendungen und Modulen.
Unter Bezugnahme auf 6A umfasst eine dynamische Vorbetriebssystem-Bauzeitumgebung 60 ein dynamisches Ladeprogramm 46, eine Basisanwendung E0, die zu einer unterschiedlichen Funktionalität in der Lage ist, basierend darauf, welche ABI-konformen Bibliothekmodule referenziert sind, und einen Satz von ABI-konformen Bibliothekmodulen X-Z. Der Kompilierer platziert eine Kopie des dynamischen Ladeprogramms 46 in jeder Version der Anwendung. Das dynamische Ladeprogramm 46 kopiert dann einen verschiebbaren Maschinencode der referenzierten ABI-konformen Bibliothekmodule in die Anwendungen.
Unter Bezugnahme auf 6B zeigt die dynamische Vorbetriebssystem-Laufzeitumgebung 62, die der dynamischen Vorbetriebssystem-Bauzeitumgebung 60 (6A) zugeordnet ist, drei unterschiedliche abgeleitete Anwendungen E1-E3, jede mit einem unterschiedlichen Satz von ABI-konformen Bibliothekmodulen X-Z. Die Anwendung E1 umfasst die Funktionalität des Moduls X und des Moduls Y, die Anwendung E2 umfasst die Funktionalität des Moduls Y und des Moduls Z und die Anwendung E3 umfasst die Funktionalität des Moduls X und des Moduls Z. Man kann die Funktionalität irgendeiner der Anwendungen E1-E3 bei irgendeiner nachfolgenden Laufzeit verändern, ohne die Anwendungen zu rekompilieren. Zum Beispiel kann man die Anwendung E3 modifizieren, um ebenfalls die Funktionalität des Moduls Y zu umfassen, indem das Ladeprogramm 46 das Modul Y bei dem Beginn einer nachfolgenden Laufzeit lädt.
Unter Bezugnahme auf 7 umfasst ein dynamischer Vorbetriebssystemumgebung-Hochrüstprozess 200 eine dynamische Bauzeitumgebung 202, eine dynamische Laufzeitumgebung 208 und eine Hochrüstumgebung 220. Wie vorhergehend beschrieben werden während der dynamischen Bauzeit 202 EFI-Anwendungen 204 und Nicht-EFI-Anwendungen 212 unter Verwendung der ABI-konformen EFI-Bibliothek 216 kompiliert, um Funktionsrufreferenzen zu genügen. Dies wird durch das dynamische Ladeprogramm 206 vorgenommen, das, nachdem dasselbe durch den Kompilierer zu einem Teil jeder Anwendung gemacht wurde, Module von der EFI-Bibliothek 216 in die Anwendungen kopiert. Während der nachfolgenden dynamischen Laufzeit 208 verbindet das dynamische Ladeprogramm 206 in der kompilierten EFI-Anwendung 210 alle referenzierten Bibliothekmodule und wird dann ausgeführt. Während der nachfolgenden dynamischen Laufzeit 208 verbindet ferner das dynamische Ladeprogramm 206 in der kompilierten Nicht-EFI-Anwendung 214 alle referenzierten Bibliothekmodule und wird dann ausgeführt. Falls es eine Codehochrüstung 222 an einer EFI-Anwendung oder einer Nicht-EFI-Anwendung während einer Hochrüstzeit 220 gibt, kehrt der Prozess zu der Bauzeitumgebung 202 über den Weg 224 zurück und rekompiliert die Anwendungen. Falls es eine Codehochrüstung an einem referenzierten Bibliothekmodul gibt, kehrt der Prozess zu der dynamischen Laufzeitumgebung 208 nach einem Rekompilieren der hochgerüsteten ABI-konformen EFI-Bibliothek 218 mit dem hochgerüsteten Modul über den Weg 226 zurück, wobei so eine Funktionalität verändert wird oder zu der Anwendung hinzugefügt wird, ohne die Anwendungen rekompilieren zu müssen.
Die vorgehende Erörterung ist vorgelegt, um zu ermöglichen, dass ein Fachmann auf dem Gebiet die Erfindung herstellt und verwendet. Verschiedene Modifikationen an den offenbarten Ausführungsbeispielen werden Fachleuten auf dem Gebiet ohne weiteres ersichtlich und die allgemeinen Prinzipien hierin können auf andere Ausführungsbeispiele und Anwendungen angewandt werden, ohne von der Wesensart und dem Schutzbereich der vorliegenden Erfindung abzuweichen. Somit soll die vorliegende Erfindung nicht auf die gezeigten Ausführungsbeispiele begrenzt sein, sondern derselben soll der breiteste Schutzbereich gewährt werden, der konsistent mit den Prinzipien und Merkmalen ist, die hierin offenbart sind.

Claims

Elektronisches System, das folgende Merkmale aufweist: einen Bibliothekspeicherraum, der betreibbar ist, um eine Vorbetriebssystem-Bibliothek (216) zu speichern, die eine erste Instanz eines Bibliothekmoduls (48) umfasst; einen Anwendungsspeicherraum, der betreibbar ist, um eine Anwendung (42, 44) zu speichern, die ein Ladeprogramm (46) und eine zweite Instanz des Bibliothekmoduls (48) umfasst; und einen Prozessor, der mit dem ersten und dem zweiten Speicherraum gekoppelt ist und betreibbar ist, um das Ladeprogramm (46) in Laufzeit auszuführen, und unter der Steuerung des Ladeprogramms (46) die zweite Instanz des Bibliothekmoduls (48) aus der ersten Instanz zu erzeugen und die zweite Instanz des Moduls (48) mit der Anwendung (42, 44) zu verbinden.
System gemäß Anspruch 1, bei dem die Anwendung (42, 44) eine Vorbetriebssystem-Anwendung ist.
System gemäß Anspruch 1 oder 2, bei dem das Ladeprogramm (46) ferner betreibbar ist, um eine Funktionalität bei der ersten nachfolgenden Laufzeit zu der Anwendung (42, 44) zuzufügen.
System gemäß einem der Ansprüche 1 bis 3, bei dem das Ladeprogramm (46) ferner betreibbar ist, um eine Funktionalität bei einer zweiten nachfolgenden Laufzeit von der Anwendung (42, 44) zu entfernen.
System gemäß einem der Ansprüche 1 bis 4, bei dem das Ladeprogramm (46) ferner betreibbar ist, um eine Funktionalität der Anwendung (42, 44) bei einer dritten nachfolgenden Laufzeit zu modifizieren.
System gemäß einem der Ansprüche 1 bis 5, bei dem die Bibliothek (216) in einem binären Anwendungsformat ist.
System gemäß Anspruch 6, bei dem das binäre Format der Bibliothek (216) ELF64 ist.
System gemäß einem der Ansprüche 1 bis 7, bei dem das Verbinden ferner ein Parsen der Inhalte der zweiten Instanz des Moduls (48) aufweist.
System gemäß Anspruch 8, bei dem das Verbinden ferner ein Verschieben von Adressen aufweist.
System gemäß Anspruch 9, bei dem das Verbinden ferner ein Lösen von Abhängigkeiten zwischen der Anwendung (42, 44) und dem Modul (48) aufweist.
Verfahren, das folgende Schritte aufweist: Kompilieren einer Vorbetriebssystem-Anwendung (42, 44); und Hinzufügen eines dynamischen Ladeprogramms (46) zu der Anwendung.
Verfahren gemäß Anspruch 11, das ferner folgende Schritte aufweist: Zugreifen auf eine Laufzeitbibliothek (216); Laden eines Moduls (48) aus der Bibliothek (216) in die Anwendung (42, 44) in Laufzeit; und Ausführen der Anwendung (42, 44).
Verfahren gemäß Anspruch 12, das ferner folgende Schritte aufweist: Hochrüsten der Anwendung (42, 44); Rekompilieren der Anwendung (42, 44); nachfolgendes Wiederladen des Moduls (48) aus der Bibliothek (216) in die Anwendung (42, 44); und Wiederausführen der hochgerüsteten Anwendung.
Verfahren gemäß Anspruch 12 oder 13, das ferner folgende Schritte aufweist: Hochrüsten des Moduls (48); Rekompilieren des Moduls (48); nachfolgendes Laden des hochgerüsteten Moduls (48) aus der Bibliothek (216) in die Anwendung (42, 44); und Wiederausführen der Anwendung (42, 44).
Verfahren gemäß einem der Ansprüche 12 bis 14, das ferner ein Laden einer Mehrzahl von Modulen (48) aufweist.
Verfahren gemäß Anspruch 15, das ferner folgende Schritte aufweist: Hochrüsten der Module (48); Rekompilieren der Module (48); nachfolgendes Laden der Module (48) aus der Bibliothek (216) in die Anwendung (42, 44); und Wiederausführen der Anwendung (42, 44).
Verfahren gemäß Anspruch 15 oder 16, das ferner folgende Schritte aufweist: Hochrüsten eines Teilsatzes der Module (48); Rekompilieren des Teilsatzes der Module (48); nachfolgendes Wiederladen der Module (48) aus der Bibliothek (216) in die Anwendung (42, 44); und Wiederausführen der Anwendung (42, 44).
Verfahren gemäß einem der Ansprüche 12 bis 17, bei dem das Laden ferner ein Parsen der Inhalte der Module (48) aufweist.
Verfahren gemäß Anspruch 18, bei dem das Laden ferner ein Verschieben eines verschiebbaren binären Moduls aufweist.
Verfahren gemäß Anspruch 19, bei dem das Laden ferner ein Verbinden von Abhängigkeiten zwischen der Anwendung (42, 44) und dem Modul (48) aufweist.
Verfahren gemäß einem der Ansprüche 12 bis 20, das ferner ein Ausführen der Anwendung (42, 44) eine Mehrzahl von Malen aufweist.
Verfahren gemäß einem der Ansprüche 12 bis 21, bei dem das Ausführen ferner ein Referenzieren von globalen Variablen aus den Modulen (48) aufweist.
Verfahrengemäß einem der Ansprüche 15 bis 22, bei dem das Laden ferner folgende Schritte aufweist: Platzieren eines ersten Satzes der Module (48) in eine erste abgeleitete Anwendung; Platzieren eines zweiten Satzes der Module (48) in eine zweite abgeleitete Anwendung; und unabhängiges Wiederausführen der abgeleiteten Anwendung.
Verfahren gemäß Anspruch 23, bei dem es irgendeine Anzahl von nicht ordnungsgemäßen Sätzen und abgeleiteten Anwendungen gibt.
Verfahren gemäß einem der Ansprüche 12 bis 24, das ferner ein Verifizieren einer Firmware aufweist.
Verfahren gemäß einem der Ansprüche 12 bis 25, das ferner ein Verifizieren einer Hardware aufweist.
Verfahren gemäß einem der Ansprüche 11 bis 26, das ferner folgende Schritte aufweist: Schreiben der Anwendung (42, 44) zu Medien; Lesen der Medien zu einer späteren Zeit; und Ausführen der Anwendung (42, 44).
Verfahren gemäß Anspruch 27, das ferner folgende Schritte aufweist: Lesen der Medien; Zugreifen auf eine Laufzeitbibliothek (216) von den Medien; Laden eines Moduls (48) aus der Bibliothek (216) in die Anwendung (42, 44) in Laufzeit; und Ausführen der Anwendung (42, 44).