DE102008024521A1

DE102008024521A1 - Dynamisches Linken und Laden von Nachbearbeitungskerneln

Info

Publication number: DE102008024521A1
Application number: DE200810024521
Authority: DE
Inventors: Guei-Yuan San Jose Leuh; Xuefeng Zhang; Yuenian Granite Bay Yang; Ping Sunnyvale Liu; Janet He; Hong El Dorado Hills Jiang; Maxim Lukyanov
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2007-06-05
Filing date: 2008-05-21
Publication date: 2008-12-11
Anticipated expiration: 2028-05-22
Also published as: CN101320332A; CN101320332B; US20080307404A1; US20150143387A1; US8843913B2; DE102008024521B4; US9465629B2; JP4984303B2; TWI400665B; JP2008305398A; TW200912796A

Abstract

Ein Computersystem kann eine Vielzahl von Komponentenkerneln erzeugen, die während der Laufzeit gelinkt werden sollen. Das System kann bestimmen, ob ein kombinierter Kernel K in Antwort auf das Empfangen einer ersten Anforderung zum Abrufen des kombinierten Kernels K vorhanden ist. Das System kann den kombinierten Kernel K aus den ausgewählten Komponentenkerneln der Vielzahl von Komponentenkerneln während der Laufzeit zusammensetzen, falls der kombinierte Kernel nicht schon vorhanden ist.

Description

HINTERGRUND
Ein Computersystem umfasst im allgemeinen Bearbeitungseinrichtungen, Speichereinrichtungen, Schnittstelleneinrichtungen und Eingabe-/Ausgabe-(I/O)-Geräte. Wenn Videosignale bearbeitet werden, kann das Computersystem Nachbearbeitungsfunktionen durchführen, wie etwa Filmmodusdetektion, Deinterlacing, ProcAmp-Kontrollanpassung, Videoskalierung, Alpha-Bending und Farbraumumwandlung. Es kann eine Mehrzahl unabhängiger Kernel entwickelt werden, von denen jeder eine oder mehrere der oben aufgeführten Nachbearbeitungsfunktionen umfasst. Jeder aus der Mehrzahl der Kernel kann dedizierte Speicherräume im Speicher besetzen, um Eingabedaten zu lesen und Ergebnisse zu schreiben. Allerdings kann das Kommunizieren von Daten zwischen verschiedenen Nachbearbeitungsfunktionen über den Speicher höhere Prozessorzyklen verbrauchen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die hier beschriebene Erfindung wird in den beigefügten Zeichnungen beispielhaft und nicht einschränkend dargestellt. Zur Einfachheit und Klarheit der Darstellung sind in den Figuren gezeigte Elemente nicht notwendigerweise maßstabsgetreu. Beispielsweise können die Abmessungen einiger Elemente im Verhältnis zu anderen Elementen zwecks besserer Klarheit übertrieben dargestellt sein. Außerdem wurden Bezugszeichen zwischen den Figuren, wo es nötig erschien, wiederholt, um korrespondierende oder analoge Elemente zu bezeichnen.
1 zeigt eine Ausführungsform eines Computersystems.
2 zeigt eine Ausführungsform eines „Graphics Memory Controller Hub" (GMCH) von 1.
3 zeigt eine Funktionsweise einer Ausführungsform eines Codepatch-Erzeugers von 2.
4 zeigt eine Funktionsweise einer Ausführungsform eines Code-Managers aus 2.
5 zeigt eine Funktionsweise einer Ausführungsform eines Kernel-Composers aus 2.
AUSFÜHRLICHE BESCHREIBUNG
Die folgende Beschreibung beschreibt ein System zum dynamischen Linken und Laden von Nachbearbeitungskerneln. In der folgenden Beschreibung werden zahlreiche spezielle Details, wie logische Implementierungen, sowie Implementierungen zum Einteilen, Teilen oder Verdoppeln von Ressourcen, Typen und Zusammenhänge zwischen Systemkomponenten, sowie Logikpartitionierungen oder Integrationsmöglichkeiten benutzt, um ein näheres Verständnis der vorliegenden Erfindung zu vermitteln. Ein Fachmann wird jedoch erkennen, dass die Erfindung ohne solche speziellen Details ausgeführt werden kann. In anderen Beispielen wurden Kontrollstrukturen, Schaltkreise auf Gatterebene und vollständige Software-Befehlssequenzen nicht im Detail gezeigt, um die Erfindung nicht zu verschleiern.
Fachleute werden mit den enthaltenen Beschreibungen in der Lage sein, die entsprechende Funktionalität ohne unangemessenes Experimentieren zu implementieren.
Bezüge auf „eine (1) Ausführungsform", „eine Ausführungsform", „eine beispielhafte Ausführungsform" in der Beschreibung zeigen, dass die beschriebene Ausführungsform ein bestimmtes Merkmal, eine Struktur oder ein Charakteristikum umfassen kann; aber nicht jede Ausführungsform muss notwendigerweise das bestimmte Merkmal, die Struktur oder das Charakteristikum umfassen. Vielmehr beziehen sich solche Phrasen nicht notwendigerweise auf die gleiche Ausführungsform. Ferner wird, sobald ein bestimmtes Merkmal, eine Struktur oder ein Charakteristikum in Verbindung mit einer Ausführungsform beschrieben wird, vorausgeschickt, dass es innerhalb des Wissens von Fachleuten liegt, ein solches Merkmal, eine Struktur oder ein Charakteristikum in Verbindung mit anderen Ausführungsformen anzubringen, sei es nun ausführlich beschrieben oder nicht.
Ausführungsformen der Erfindung können in Hardware, Firmware, Software oder irgendeiner Kombination derselben implementiert werden. Ausführungsformen der Erfindung können außerdem als Befehle implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind, welches von einem oder mehreren Prozessoren gelesen und ausgeführt werden kann. Ein maschinenlesbares Medium kann einen beliebigen Mechanismus zum Speichern oder Übertragen von Information in eine durch eine Maschine (zum Beispiel Recheneinrichtungen) lesbare Form umfassen.
Beispielsweise kann ein maschinenlesbares Medium umfassen: schreibgeschützten Speicher (Read Only Memory (ROM)); direkt zugreifbaren Speicher (Random Access Memory (RAM)); Magnetspeichermedien; optische Speichermedien; Flash-Speichereinrichtungen; elektrische, optische, akustische oder andere Formen von sich ausbreitenden Signalen (zum Beispiel Trägerwellen, Infrarotsignale und digitale Signale). Ferner können Firmware, Software, Routinen und Befehle im folgenden so beschrieben werden, dass sie gewisse Handlungen ausführen. Es sollte allerdings zur Kenntnis genommen werden, dass solche Beschreibungen eher der Bequemlichkeit dienen und dass solche Handlungen eigentlich von Recheneinrichtungen, Prozessoren, Controller und anderen Einrichtungen herrühren, welche Firmware, Software, Routinen und Befehle ausführen.
Eine Ausführungsform eines Computersystems 100 ist in 1 gezeigt. Das Computersystem 100 kann einen Prozessor 110, einen Speicher 120, einen Chipsatz 130, ein oder mehrere I/O-Einrichtungen 160, eine Videografikkartenschnittstelle (Video Graphics Array (VGA)) 170 und eine beschleunigte Grafikschnittstelle (Accelerated Graphics Port (AGP)) 180 umfassen.
Der Prozessor 110 kann verschiedene Ressourcen und Prozesse innerhalb des Computersystems 100 steuern und auch Softwarebefehle ausführen. Der Prozessor 110 kann zum Beispiel einen oder mehrere Mikroprozessoren der Pentium^®- oder Itanium^®-Familien von Intel^®-Mikroprozessoren umfassen. Der Prozessor 110 kann mit dem Chipsatz 130 gekoppelt sein, um aus dem Speicher 120 zu lesen und in den Speicher 120 zu speichern.
Der Speicher 120 kann Daten und Befehle speichern und einen oder mehrere Typen von Speichereinrichtungen, wie DRAM(Dynamic Random Access Memory)-Einrichtungen, SDRAM(Synchronous DRAM)-Einrichtungen, DDR (Double Data Rate) oder andere flüchtige und nichtflüchtige Speichereinrichtungen umfassen, die in Computer genutzt werden.
Die I/O-Einrichtung 160 kann Einrichtungen wie eine Tastatur, Maus, eine Netzwerkkarte und andere Einrichtungen umfassen. Die Dateneinheiten können zwischen dem Chipsatz 130 und den I/O-Einrichtungen 160 über Busse übertragen werden, die „Peripheral Component Interconnect" (PCI), „Serial Advanced Technology Attachment" (SATA), „Low Pin Count" (LPC), „Integrated Device Electronics" (IDE) und andere solche Verbindungstechnologien umfassen.
Der Chipsatz 130 kann einen oder mehrere integrierte Schaltkreise oder Chips umfassen, die den Prozessor 110, den Speicher 120, die I/O-Einrichtungen 160, die VGA-Schnittstelle 170 und die AGP-Schnittstelle 180 koppeln. Der Chipsatz 130 kann einer aus den Intel^®-Familien von Chipsätzen sein. In einer Ausführungsform kann der Chipsatz 130 einen Speicher-Kontroll-Hub 143, einen Grafik- und Speicher-Kontroll-Hub (Graphics and Memory Controller Hub (GMCH)) 145 und einen I/O-Kontroll-Hub (ICH) 150 umfassen. Der ICH 150 kann eine Schnittstelle zwischen den I/O-Einrichtungen 160 bereitstellen, die an den ICH 150 und den Prozessor 110 und den Speicher 120 gekoppelt ist. Beispielsweise kann der ICH 150 Festplattenlaufwerk, Diskettenlaufwerk, CD-Laufwerke, Modems, Tastaturen, Drucker, Mäuse, Endpunkte, Ethernet und SCSI-Einrichtungen unterstützen. Der MCH 143 kann eine Schnittstelle zwischen dem Prozessor 110 und dem Speicher 130 bereitstellen.
In einer Ausführungsform kann der GMCH 145 die Übertragungen und den Transfer der entsprechenden Daten zwischen dem Speicher 120, dem ICH 150, dem Prozessor 110 und den Einrichtungen, die an die VGA-Schnittstelle 170 und die AGP-Schnittstelle 180 gekoppelt sind, durchführen. In einer Ausführungsform kann der GMCH 145 dynamisches Linken und Laden von Nachbearbeitungskerneln unterstützen. In einer Ausführungsform können die Videonachbearbeitungskernel eine geordnete Sequenz von zwei oder mehr Nachbearbeitungsfunktionen, wie Filmmodusdetektion, Deinterlacing, ProcAmp-Kontrollanpassung, Videoskalierung, Alpha-Bending und Farbraumumwandlung, umfassen.
Beispielsweise kann ein erster kombinierter Kernel K1 Nachbearbeitungsfunktionen, wie Filmmodusdetektion, Deinterlacing und Alpha-Bending, in dieser Reihenfolge umfassen. Ein zweiter kombinierter Kernel K2 kann Nachbearbeitungsfunktionen, wie etwa Filmmodusdetektion, Deinterlacing, Videoskalierung und Farbraumumwandlung, in dieser Reihenfolge umfassen. In einer Ausführungsform können die kombinierten Kernel K1 und K2 zusammengesetzt werden, bevor der Kernel aufgerufen wird. Als Ergebnis kann vermieden werden, dass ein dedizierter Platz benötigt wird, um jeden der statisch zusammengesetzten Kernel zu speichern. In einer Ausführungsform können die Nachbearbeitungsfunktionen, die zum Bilden eines kombinierten Kerns benötigt werden, während der Übersetzungszeit identifiziert werden, und die Nachbearbeitungsfunktionen können dynamisch zusammengelinkt werden, um einen kombinierten Kernel während der Laufzeit zu bilden.
Eine Ausführungsform des GMCH 145, der dynamisches Linken und Laden von Nachbearbeitungskerneln unterstützt, ist in 2 abgebildet. In einer Ausführungsform kann der GMCH 145 Anwendungen 210, eine Programmierschnittstelle 220, einen Codepatch-Erzeuger 230, einen Treiber 250 und eine Grafikhardware 280 umfassen. In einer Ausführungsform kann die Grafikhardware 280 mit dem Treiber 250 gekoppelt sein, um die Funktionen durchzuführen, die von dem Treiber 250 aufgezeigt werden. In einer Ausführungsform kann die Grafikhardware 280 einen integrierten Grafik-Controller aus einer Intel^®-Familie umfassen.
In einer Ausführungsform können die Anwendungen 210 Multimediaanwendungen umfassen, mit denen der Benutzer des Computersystems 100 interagieren kann. In einer Ausführungsform kann die Programmierschnittstelle 220 eine oder mehrere Routinen umfassen, die von den Anwendungen 210 benutzt werden können, um mit den Diensten niedrigerer Ebene zu interagieren, welche von einem darunter liegenden Betriebssystem zur Verfügung bereitgestellt werden.
In einer Ausführungsform kann die Programmierschnittstelle 220 eine Programmierschnittstelle zwischen den Anwendungen 210 und dem Codepatch-Erzeuger 230 und dem Treiber 250 bereitstellen. In einer Ausführungsform kann die Programmierschnittstelle 220 eine Nachbearbeitungsfunktionsanfrage an den Treiber 250 stellen, welche auf den Eingabewerten basiert, die von den Anwendungen 210 empfangen wurden. In einer Ausführungsform kann die Programmierschnittstelle 220 eine Microsoft^®-DxVA-(Direct X Video Acceleration)-Programmierschnittstelle umfassen.
In einer Ausführungsform kann der Codepatch-Erzeuger 230 jede Kernelkomponente statisch zu einem Binary kompilieren, gemeinsam mit einem Ersatz-Codepatch, der ein dynamisches Linken während der Laufzeit ermöglicht. Das Binary und der Ersatz-Codepatch können während der Startzeit des Treibers 250 in den Kernel-Composer 258 des Treibers 250 geladen werden. In einer Ausführungsform kann der Codepatch-Erzeuger 230 I/O-Bereiche spezifizieren, die eine erste Kernelkomponente zum Lesen und Schreiben von Daten benutzen kann. Allerdings kann der Codepatch-Erzeuger 230 nicht angeben, mit welchen anderen Komponentenkerneln der erste Komponentenkernel zusammengebunden werden kann, und dieses Linken von Komponentenkerneln kann während der Laufzeit stattfinden.
Der Treiber 250 kann obere Schichten, wie die Anwendungen 210, an die Grafikhardware 280 koppeln. In einer Ausführungsform kann der Treiber 250 einen Code-Manager 254 und einen Code-Composer 258 umfassen. In einer Ausführungsform kann der Treiber 250 einen Grafiktreiber aus einer Intel^®-Familie umfassen.
In einer Ausführungsform kann der Code-Manager 254 eine Suchanfrage von der Programmierschnittstelle 220 empfangen, um einen spezifizierten kombinierten Kernel abzurufen. Der Code-Manager 254 kann bestimmen, ob der spezifizierte kombinierte Kernel in der Datenbank, die durch den Code-Manager 254 unterstützt wird, vorhanden ist. Der Code-Manager 254 kann ein Signal an die Programmierschnittstelle 220 senden, die das Vorhandensein des spezifizierten kombinierten Kernels anzeigt, falls der spezifizierte Kernel in der Datenbank vorhanden ist. Der Code-Manger 254 kann eine Anfrage an den Code-Composer 258 senden, um den spezifizierten Kernel zusammenzustellen, falls der spezifizierte kombinierte Kernel nicht vorhanden ist. In einer Ausführungsform kann der Code-Manager 254 auch bestimmen, welche Komponentenkernel benötigt werden, um den spezifizierten kombinierten Kernel zusammenzustellen.
In einer Ausführungsform kann der Code-Manager 254 Speicherplatz zur Verfügung stellen, um den neu zusammengestellten spezifizierten kombinierten Kernel als Antwort auf das Empfangen einer Anfrage zum Zuordnen von Platz für den neu zusammengestellten spezifizierten kombinierten Kernel zu speichern. In einer Ausführungsform kann der Code- Manager 254 den neu zusammengestellten spezifizierten kombinierten Kernel speichern und außerdem dem neu zusammengestellten spezifizierten kombinierten Kernel einen eindeutigen Bezeichner als Antwort auf das Empfangen eines Signals zuordnen, das angibt, dass der angegebene kombinierte Kernel zusammengesetzt wurde. In einer Ausführungsform kann der Code-Manager 254 auch den Platz zum Speichern der kombinierten Kernel verwalten, indem die veralteten kombinierten Kernel gelöscht werden.
In einer Ausführungsform kann der Code-Composer 258 ein Signal zum Zusammensetzen des spezifizierten kombinierten Kernels empfangen. Der Code-Composer 258 kann außerdem die Komponentenkernel empfangen, die zum Zusammenstellen des spezifizierten kombinierten Kernels benötigt werden. In einer Ausführungsform kann der Code-Composer 258 den Platz bestimmen, der benötigt wird, um den neu zusammengesetzten spezifizierten kombinierten Kernel zu speichern, und kann eine Anfrage versenden, um Speicherplatz zur Verfügung zu stellen.
In einer Ausführungsform kann der Code-Composer 258 den kombinierten Kernel zusammenstellen, indem die I/O-Registerbereiche bestimmt werden, die für jede Kernelkomponente angegeben sind. In einer Ausführungsform kann der Code-Composer 258 die binären Dateien der Komponentenkernel abrufen und an den zugewiesenen Platz kopieren. Der Code-Composer 258 kann auch assoziierte Codepatches anwenden, um die binären Dateien dazu zu bringen, Eingabedaten aus den Eingaberegisterbereichen zu lesen und Ausgaben an die Ausgaberegisterbereiche zu schreiben. Der Code-Composer 258 kann ein Signal senden, das anzeigt, dass der spezifizierte kombinierte Kernel zusammengesetzt wurde.
Eine Ausführungsform einer Funktionsweise eines Codepatch-Erzeugers 230 ist in 3 gezeigt. In Block 310 kann der Codepatch-Erzeuger 230 Komponentenkernel zusammensetzen, um Binaries sowie Ersatz-Codepatches zu erzeugen, die ein Linken während der Laufzeit ermöglichen. In einer Ausführungsform kann der Codepatch-Erzeuger 230 einen Gen4-Assembler umfassen, der eine „.declare"-Syntax benutzen kann. In einer Ausführungsform kann der Gen4-Assembler „.declare"-Syntax verwenden, um die Befehle, die Daten von dem vorherigen Kernel lesen, sowie die Befehle, die Daten an den nachfolgenden Kernel schreiben, zu identifizeren. In einer Ausführungsform kann die „.declare"-Syntax für Eingabe- und Ausgabe-Bereiche wie folgt aussehen:
.declareINBase=r4,Elementsize=4,Type=d,Width(8),Height(4)PP_IN
.declareOUTBase=r8,Elementsize=4,Type=d,Width(8),Height(4)PP_OUT
In einer Ausführungsform zeigen PP_IN und PP_OUT an, dass „.declare" benutzt wird, um auf die Daten, die von dem vorherigen Kernel erzeugt werden, und auf den zum Schreiben von Daten vorgesehenen Bereich zuzugreifen, um die Ausgabedaten zu schreiben, die von dem nachfolgenden Kernel gelesen werden können. Der Inhalt von PP_IN und PP_OUT kann bis zur Laufzeit auf einen Standardwert gesetzt werden. Die tatsächlichen Werte, die während der Laufzeit bestimmt werden, können benutzt werden, um den Inhalt von PP_IN und PP_OUT zu konfigurieren. In einer Ausführungsform kann der Gen4-Assembler „.declare" mit PP_IN und PP_OUT verfolgen, bevor er einen Ersatz-Codepatch erzeugt.
In Block 350 kann der Codepatch-Erzeuger 230 die Binaries und die Ersatz-Codepatches in den Treiber 250 laden.
Eine Ausführungsform der Funktionsweise des Code-Managers 254 ist in 4 gezeigt. In Block 410 kann der Code-Manger 254 eine erste Anfrage zum Abrufen eines kombinierten Kernels K empfangen. In Block 420 kann der Code-Manager 254 prüfen, ob der kombinierte Kernel K vorhanden ist, und wird die Kontrolle an Block 425 übergeben, falls der kombinierte Kernel K vorhanden ist, andernfalls an Block 430.
In Block 425 kann der Code-Manager 254 das Alter aller existierenden kombinierten Kernel erhöhen. Ein solcher Ansatz kann die Identifikation der kombinierten Kernel erlauben, die zuletzt benutzt worden sind. In einer Ausführungsform sind die kombinierten Kernel mit geringerem Alterswert die zuletzt benutzten kombinierten Kernel.
In Block 430 kann der Code-Manager 254 bestimmen, ob der Kernelspeicherplatz wieder beansprucht werden kann, und geht die Kontrolle über an Block 435, falls der Kernelspeicherplatz beansprucht werden kann, andernfalls an Block 440.
In Block 435 kann der Code-Manager 254 kombinierte Kernel mit einem Alter, das größer als ein Schwellenwertalter ist, löschen. In einer Ausführungsform kann der Code-Manager 254 das Alter jedes kombinierten Kernels mit einem Schwellenwertalter vergleichen, um zu bestimmen, ob das Alter des kombinierten Kernels größer ist als das Schwellenwertalter.
In Block 440 kann der Code-Manager 254 die ausgewählten Kernelkomponenten bestimmen, die benötigt werden, um den kombinierten Kernel K zu erzeugen. In Block 450 kann der Code-Manager 254 eine zweite Anfrage senden, um den kombinierten Kernel K sowie die ausgewählten Komponentenkernel zusammenzusetzen. In einer Ausführungsform kann der Code-Manager 254 die zweite Anfrage an den Code-Composer 258 in Form eines booleschen Arrays senden. Beispielsweise kann der boolesche Array wie bool component_kernels [Liste der Komponentenkernel] aussehen. Die Komponentenkernel können ausgewählt werden, falls die booleschen Werte der Komponentenkernel wahr sind.
In Block 460 kann der Code-Manager 254 Platz zur Verfügung stellen, um den kombinierten Kernel K als Antwort auf das Empfangen eines ersten Signals vom Code-Composer 258 zu speichern. In Block 470 kann der Code-Manager 254 ein zweites Signal senden, das anzeigt, dass der Platz zum Speichern des kombinierten Kernels K zugewiesen ist.
In Block 480 kann der Code-Manager 254 prüfen, ob ein drittes Signal empfangen wurde, das anzeigt, ob der kombinierte Kernel zusammengesetzt ist, und geht die Kontrolle an Block 490 über, falls der kombinierte Kernel K zusammengesetzt ist, andernfalls an Block 480.
In Block 490 kann der Code-Manager 254 den kombinierten Kernel K gemeinsam mit einem eindeutigen Bezeichner, der dem kombinierten Kernel K zugewiesen wurde, zwischenspeichern oder speichern.
Eine Ausführungsform der Funktionsweise des Code-Composers 258 ist in 5 gezeigt. In Block 510 kann der Code-Composer 258 die erste Anfrage empfangen, um den kombinierten Kernel K zu erzeugen. In Block 520 kann der Code-Composer 258 den Platz bestimmen, der benötigt wird, um den kombinierten Kernel K zu speichern.
In Block 530 kann der Code-Composer 258 das erste Signal senden, um Platz für den kombinierten Kernel K zur Verfügung zu stellen. In Block 540 kann der Code-Composer 258 die Reihenfolge der ausgewählten Komponentenkernel bestimmen, um den kombinierten Kernel K zu erzeugen, nachdem das zweite Signal empfangen wurde, welches angibt, dass der Platz, der zum Speichern des kombinierten Kernels K benötigt wird, zur Verfügung gestellt wurde.
In Block 550 kann der Code-Composer 258 die Eingabe- und Ausgaberegisterbereiche bestimmen, die von den ausgewählten Komponentenkernel benutzt werden. In Block 560 kann der Code-Composer 258 die Binaries der ausgewählten Kernelkomponenten abrufen.
In Block 570 kann der Code-Composer 258 die Binaries in den zugewiesenen Speicherbereich kopieren. An Block 580 kann der Code-Composer 258 die Codepatches anwenden, um die Binaries zu veranlassen, die Eingabedaten aus dem Eingaberegisterbereich zu lesen und die Ausgabedaten in den Ausgaberegisterbereich zu schreiben.
An Block 590 kann der Code-Composer 258 ein drittes Signal senden, welches angibt, dass der kombinierte Kernel K zusammengesetzt wurde. Ein solches Signal kann an den Code-Manager 254 gesendet werden.
Gewisse Merkmale der Erfindung wurden unter Bezug auf beispielhafte Ausführungsformen beschrieben. Allerdings soll die Beschreibung nicht in einschränkender Weise gedeutet werden. Verschiedene Modifikationen der beispielhaften Ausführungsformen, ebenso wie andere Ausführungsformen der Erfindung, welche für Fachleute auf dem Gebiet, auf das sich die Erfindung bezieht, offensichtlich sind, gelten als innerhalb von Geist und Schutzbereich der Erfindung liegend.

Claims

Verfahren, umfassend: Erzeugen einer Mehrzahl von Komponentenkernel in einem Codepatch-Erzeuger, wobei die Mehrzahl der Komponentenkernel während der Laufzeit gelinkt werden, Bestimmen, ob ein kombinierter Kernel in einem Code-Manager vorhanden ist, und Erzeugen des kombinierten Kernels in einem Code-Composer, wobei der kombinierte Kernel aus ausgewählten Komponentenkerneln aus der Vielzahl von Komponentenkerneln erzeugt wird, falls der kombinierte Kernel nicht im Code-Manager vorhanden ist.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Erzeugen der Mehrzahl der Komponentenkernel ferner umfasst: Zusammensetzen der Mehrzahl der Komponentenkernel, um Binaries mit Codepatches zu erzeugen, die Daten von einem vorhergehenden Kernel lesen und während der Laufzeit Daten in einen nachfolgenden Kernel lesen, und Laden der Binaries und der Codepatches in einen Treiber.
Verfahren nach Anspruch 2, wobei das Erzeugen des kombinierten Kernels ferner umfasst: Bestimmen eines Speichers, der zum Speichern des kombinierten Kernels benötigt wird, Identifizieren der Eingabe- und Ausgaberegisterbereiche, die von den ausgewählten Komponentenkerneln der Vielzahl der Komponentenkernel benutzt werden, und Anwenden der Codepatches, um die Binaries einzusetzen, um Daten aus den Eingaberegisterbereichen zu lesen und Daten in die Ausgaberegisterbereiche zu schreiben.
Verfahren nach Anspruch 3, wobei das Bestimmen des Speichern zum Speichern des kombinierten Kernels ferner umfasst: Senden eines Signals an den Code-Manager und Bestimmen einer Reihenfolge von Komponentenkernel, welche benötigt werden, um den kombinierten Kernel zu erzeugen.
Verfahren nach Anspruch 3, wobei das Erzeugen des kombinierten Kernels ferner umfasst: Abrufen der Binaries der Komponentenkernel, Kopieren der Binaries in den Speicherraum, und Anzeigen, dass der kombinierte Kernel zusammengesetzt ist, nachdem die Codepatches angewendet wurden, um die Binaries einzusetzen, um Daten aus den Eingaberegisterbereich zu lesen und Daten in die Ausgaberegisterbereiche zu schreiben.
Verfahren nach Anspruch 4, wobei das Bestimmen, ob der kombinierte Kernel vorhanden ist, ferner das Senden einer Anfrage an den Code-Composer umfasst, um den kombinierten Kernel zu erzeugen, falls der kombinierte Kernel noch nicht vorhanden ist.
Verfahren nach Anspruch 5, ferner umfassend: Empfangen des gesendeten Signals durch den Code-Composer, wobei das Signal dazu dient, den Code-Manager zu veranlassen, den Speicher zum Speichern des kombinierten Kernels zuzuweisen, Zuweisen des Speichers, der benötigt wird, um den kombinierten Kernel zu speichern, und Speichern des kombinierten Kernels und eines eindeutigen Bezeichners, der mit dem kombinierten Kernel assoziiert ist, nachdem der kombinierte Kernel durch den Code-Composer erzeugt wurde.
Vorrichtung, umfassend: einen Codepatch-Erzeuger zum Erzeugen einer Vielzahl von Komponentenkerneln, wobei die Vielzahl der Komponentenkernel während der Laufzeit verlinkt werden soll, einen Code-Manager, der an den Codepatch-Erzeuger gekoppelt ist, wobei der Code-Manager dazu dient, zu bestimmen, ob ein kombinierter Kernel im Code-Manager vorhanden ist, und einen Code-Composer, der an den Code-Manager gekoppelt ist, um den kombinierten Kernel zu erzeugen, wobei der kombinierte Kernel aus ausgewählten Komponentenkerneln der Vielzahl der Komponentenkernel erzeugt wird, falls der kombinierte Kernel nicht im Code-Manager vorhanden ist.
Vorrichtung nach Anspruch 8, dadurch gekennzeichnet, dass der Codepatch-Erzeuger dazu dient, die Vielzahl von Komponentenkerneln zusammenzusetzen, um Binaries mit Codepatches zu erzeugen, die Daten aus dem vorherigen Kernel lesen und während der Laufzeit Daten in den nachfolgenden Kernel schreiben, und um die Binaries und Codepatches in einen Treiber zu laden.
Vorrichtung nach Anspruch 9, dadurch gekennzeichnet, dass der Code-Composer dazu dient, einen Speicher zu bestimmen, der zum Speichern des kombinierten Kernels benötigt wird, die Eingabe- und Ausgaberegisterbereiche zu identifizieren, die von den ausgewählten Komponentenkerneln der Vielzahl von Komponentenkerneln benutzt werden, und die Codepatches anzuwenden, um die Binaries zu veranlassen, Daten aus den Eingaberegisterbereichen zu lesen und Daten in die Ausgaberegisterbereiche zu schreiben.
Vorrichtung nach Anspruch 10, dadurch gekennzeichnet, dass der Code-Composer ein Signal an den Code-Manager sendet und eine Reihenfolge der Komponentenkernel bestimmt, die benötigt wird, um den kombinierten Kernel zu erzeugen.
Vorrichtung nach Anspruch 10, dadurch gekennzeichnet, dass der Code-Composer die Binaries der Komponentenkernel abruft, die Binaries in den Speicherraum kopiert und anzeigt, dass der kombinierte Kernel zusammengesetzt ist, nachdem die Codepatches angewendet wurden, um die Binaries zu veranlassen, Daten aus den Eingaberegisterbereichen zu lesen und Daten in die Ausgaberegisterbereiche zu schreiben.
Vorrichtung nach Anspruch 11, dadurch gekennzeichnet, dass der Code-Manager dazu dient, eine Anfrage an den Code-Composer zu übertragen, um den kombinierten Kernel zu erzeugen, falls der kombinierte Kernel nicht schon vorhanden ist.
Einrichtung nach Anspruch 12, dadurch gekennzeichnet, dass der Code-Manager dazu dient, Speicher zum Speichern des kombinierten Kernels zuzuweisen, nachdem das Signal empfangen wurde, das von dem Code-Composer gesendet wurde, und den kombinierten Kernel und einen eindeutigen Bezeichner, der mit dem kombinierten Kernel assoziiert ist, zu speichern, nachdem der kombinierte Kernel von dem Code-Composer erzeugt wurde.
Ein maschinenlesbares Medium, das eine Vielzahl von Befehlen umfasst, um ein Recheneinrichtung dazu zu bringen: eine Vielzahl von Komponentenkerneln in einem Codepatch-Erzeuger zu erzeugen, wobei die Vielzahl von Komponentenkerneln während der Laufzeit verlinkt werden sollen, zu bestimmen, ob ein kombinierter Kernel in einem Code-Manager vorhanden ist, und den kombinierten Kernel in einem Code-Composer zu erzeugen, wobei der kombinierte Kernel aus ausgewählten Komponentenkerneln der Vielzahl von Komponentenkerneln erzeugt wird, falls der kombinierte Kernel nicht im Code-Manager vorhanden ist.
Maschinenlesbares Medium nach Anspruch 15, wobei das Erzeugen der Vielzahl von Komponentenkernel ferner umfasst: Zusammensetzen der Vielzahl von Komponentenkerneln, um Binaries mit Codepatches zu erzeugen, die Daten aus einem vorhergehenden Kernel lesen und während der Laufzeit Daten in einen nachfolgenden Kernel schreiben, und Laden der Binaries und der Codepatches in einen Treiber.
Maschinenlesbares Medium nach Anspruch 16, wobei das Erzeugen des kombinierten Kernels ferner umfasst: Bestimmen eines Speichers, der zum Speichern des kombinierten Kernels benötigt wird, Identifizieren der Eingabe- und Ausgaberegisterbereiche, die von den ausgewählten Komponentenkerneln der Vielzahl von Komponentenkerneln benutzt werden, und Anwenden der Codepatches, um Binaries zu veranlassen, Daten aus den Eingaberegisterbereichen zu lesen und Daten in die Ausgaberegisterbereiche zu schreiben.
Maschinenlesbares Medium nach Anspruch 17, wobei das Bestimmen des Speichers zum Speichern des kombinierten Kernels ferner umfasst: Senden eines Signals an den Code-Manager, und Bestimmen einer Reihenfolge von Komponentenkerneln, die zum Erzeugen des kombinierten Kernels benötigt werden.
Maschinenlesbares Medium nach Anspruch 17, wobei das Erzeugen des kombinierten Kernels ferner umfasst: Abrufen der Binaries aus den Komponentenkerneln, Kopieren der Binaries in den Speicherraum, und Anzeigen, dass der kombinierte Kernel zusammengesetzt ist, nachdem die Codepatches angewendet wurden, um die Binaries zu veranlassen, Daten aus den Eingaberegisterbereichen zu lesen und Daten in die Ausgaberegisterbereiche zu schreiben.
Maschinenlesbares Medium nach Anspruch 19, ferner umfassend: Empfangen des gesendeten Signals durch den Code-Composer, wobei das Signal dazu dient, den Code-Manager zu veranlassen, den Speicher zum Speichern des kombinierten Kernels zuzuweisen, Zuweisen des Speichers, der zum Speichern des kombinierten Kernels benötigt wird, und Speichern des kombinierten Kernels und eines eindeutigen Bezeichners, der mit dem kombinierten Kernel assoziiert ist, nachdem der kombinierte Kernel von dem Code-Composer erzeugt wurde.