DE69736586T2

DE69736586T2 - Verfahren und Rechnerprogrammprodukt zur Verringerung von Interpufferdatenübertragungen zwischen getrennten Datenverarbeitungskomponenten

Info

Publication number: DE69736586T2
Application number: DE69736586T
Authority: DE
Inventors: George H.J. Woodinville Shaw; Thomas J. O'rourke; Bryan A. New Bend Woodruff
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 1997-04-04
Filing date: 1997-06-19
Publication date: 2007-08-30
Anticipated expiration: 2017-06-20
Also published as: JPH10283252A; DE69736586D1; JP2007128538A; JP3929551B2; EP0871116A2; CA2208297C; EP1619581A1; EP0871116A3; EP0871116B1; CA2208297A1; JP4889471B2; US6209041B1; US6601112B1

Description

Das Gebiet der Erfindung umfasst die Entwicklung von Computersoftwaretreibern. Die vorliegende Erfindung betrifft Werkzeuge (tools), Softwaresysteme, Konventionen und dergleichen zur Vereinfachung der Codeerzeugung bei Treibern und zur Bereitstellung standardisierter Zugangspunkte. Insbesondere betrifft die vorliegende Erfindung Verfahren und Computerprogrammerzeugnisse zur Verwaltung von Puffern, die von mehreren Entitäten, so beispielsweise von miteinander verbundenen Softwaretreibern, derart verwendet werden, dass die zwischen den Treibern erfolgende Datenübertragung zwischen den Entitäten während der Verarbeitung durch die in einem vergleichsweise ungeschützten Betriebssystemmodus arbeitenden Softwaretreiber auf eine Minimalmenge verringert wird.
Verarbeiten mehrere Komponenten einen Datenstream oder eine Datenmenge, so legen sie üblicherweise eine gewisse Datenmenge, so beispielsweise einen Frame (Rahmen), in einem Puffer ab, verarbeiten die Daten und kopieren die verarbeiteten Daten in einen weiteren Puffer, der mit einer weiteren Verarbeitungskomponente verbunden ist. Sind mehrere voneinander unabhängige Verarbeitungskomponenten vorhanden, so kann der bloße Umfang der Datenübertragungen zwischen den Puffern das Leistungsvermögen des Prozessors derart stark beeinträchtigen, dass die eigentliche Verarbeitung der Daten selbst zeitlich behindert wird.
Obwohl dieses Problem bei jeder Art von Datenverarbeitung zwischen verschiedenen Komponenten auftritt, ist es bei Mediendaten, die in multimedialen Anwendungen auftreten, besonders vordringlich. Dies liegt teilweise an den großen erzeugten Informationsmengen, die in vielen Fällen in einen Zeitrahmen eingebettet sind, um einen brauchbaren „Stream" kontinuierlicher Daten zum Zwecke der Verarbeitung effektiv zu erzeugen. Derartige Medieninformationen können aus einer live erfolgenden Zuleitung über ein Netzwerk, eine Telefonleitung, eine Digitalisierungshardware und dergleichen mehr oder aus einer beliebigen anderen Quelle, so beispielsweise einer Datei, stammen, und müssen üblicherweise in "Echtzeit" verarbeitet werden, damit sie für einen Zuschauer oder Zuhörer zusammenhängend erscheinen.
In einer Multimediaumgebung tritt bei der Verarbeitung eines Streams von Mediendaten mit der Beeinträchtigung der Prozessorleistung aufgrund von Datenübertragungen zwischen verschiedenen Puffern ein Latenzproblem auf, das die Medienverarbeitung und die Wandlungsleistung des Hardware-/Softwaresystems insgesamt beeinträchtigt. Das Latenzproblem kann derart stark werden, dass die Multimedialeistung, die ein bestimmtes System erbringen kann, begrenzt wird. Diese Umstände werden auf Allzweckcomputersystemen, so beispielsweise einem Prozessor, der mit Windows NT^TM von Microsoft^® läuft, aufgrund der bereits bestehenden Anforderungen an den Prozessor noch dringlicher. Die Verringerung der Latenzprobleme stellt vielerlei Möglichkeiten bereit, kostengünstige multimediale Anwendungen zu konzipieren, die ansonsten nicht zur Verfügung stünden. Wird die Latenz durch eine vergrößerte Systemverarbeitungseffizienz und andere Mittel in ausreichendem Maße verringert, so ist das Allzweckcomputersystem in der Lage, mit multimedialen Anwendungen umzugehen, die vorher nicht verfügbar waren.
Ein weiteres bei mehreren Puffern, die mehreren Verarbeitungskomponenten entsprechen, auftretendes Problem ist die Menge der Systemressourcen, die verwendet werden und deshalb für andere Anwendungen nicht zur Verfügung stehen. Mit anderen Worten, verfügt jede Verarbeitungskomponente über ihren eigenen Puffer, der Systemressourcen, so beispielsweise den Systemspeicher, belegt, so können die Systemressourcen knapp werden, woraus sich Ineffizienzen ergeben, die gegebenenfalls zu einer geringeren Systemleistung führen.
Ein von Prozessen und Komponenten gemeinsam benutzter Speicher soll das Problem der Ressourcenzuweisung lösen und gemeinsam benutzte Puffer bereitstellen. Die Möglichkeit eines gemeinsam benutzten Speichers ist üblicherweise in einem „Anwendermodus" („user mode") des Betriebssystems gegeben, bei dem ein merklicher Sicherheitsoverhead vorliegt, damit nur autorisierten verwendeten Anwendungen ein bestimmter Adressraum im Systemspeicher zur Verfügung gestellt wird, wo anwenderseitig geschriebene Anwendungen laufen. Die Sicherheitsmechanismen sollen gewährleisten, dass eine Anwendung oder ein Prozess eine andere Anwendung nicht beeinträchtigt.
In einer Multimediaumgebung ist von Vorteil, Softwaretreiber, an denen eine Verarbeitung erfolgen kann, mit Softwaretreibern zu verbinden, die in einem Betriebssystemmodus mit erheblich höherer Laufpriorität und geringerem Sicherheitsschutz laufen, um einen Zugriff auf die eigentliche Hardware zu ermöglichen, die die Treiber in vielen Fällen unmittelbar manipuliert. Viele Anwendungen profitieren davon, wenn sie in diesem mehr lockeren und leistungsorientierten Modus laufen, der in der Windows-NT-Terminologie allgemein als „Kernelmodus" („kernel mode") bezeichnet wird. Andere stabile Betriebssysteme verfügen über einen funktionell gleichwertigen Modus.
Ein Paradebeispiel für ein Programm, das derzeit nicht in der Lage ist, in dieser Anwendung Verwendung findende Kernelmodustreiber einzusetzen, umfasst eine Grapherstellungsfunktionalität, die einen Anwender in die Lage versetzt, verschiedene Verarbeitungsblöcke, so genannte Filter, auszuwählen und zu verbinden, um einen Stream multimedialer Daten sukzessiv zu verarbeiten. Die Daten stellen üblicherweise eine Reihe von Abtastungen (samples) dar, die Töne oder Bilder wiedergeben, wobei die Verarbeitungsblöcke eine Dekompressionsverarbeitung für komprimierte Daten, eine Verarbeitung im Zusammenhang mit Spezialeffekten, eine Daten in Analogsignale umwandelnde CODEC-Funktionalität und dergleichen mehr enthalten können.
Derartige Filter stehen üblicherweise in einem Anwendermodus zur Verfügung, sodass der Grapherstellungsteil des Programms deren Operationen verbinden und steuern sowie auf anwenderseitige Eingaben und eine Neuanordnung der Verarbeitungsblöcke reagieren kann. Aufgrund der konsistenten Streamnatur multimedialer Daten und der Erzeugung großer Datenmengen ist die Leistung ein kritischer Punkt. In einem Allzweckbetriebssystem kann sich die Leistung aufgrund eines wiederholten Durchreichens beziehungsweise Schaltens zwischen Anwendermodus und Kernelmodus derart verschlechtern, dass das Laufen bestimmter multimedialer Anwendungen, wie vorher bereits erwähnt, behindert wird.
Darüber hinaus verfügen die Verarbeitungsblöcke oftmals über damit verbundene Hardware, die mehrfache Übergänge zwischen Anwendermodus- und Kernelmoduskomponenten erfordert. Derartige Übergänge bringen eine weitere Form von Overhead, da dem Multimediaverarbeitungssystem insgesamt Leistung entzogen wird. Bei Übergängen zwischen Anwendermodus und Kernelmodus tritt gegebenenfalls auch ein Overhead auf, der mit dem Kopieren von Daten zwischen verschiedenen Puffern einhergeht, und der nicht auftreten würde, wenn die Verarbeitung gänzlich im Kernelmodus erfolgen würde.
In dem Beitrag „Micro-kernal support for continuous media in distribute systems" von Geoff Coulson et al., veröffentlicht bei "Computer Networks and IDSN Systems", Band 26, Nr. 10, Juli 1994 (1994-07), Seiten 1323 bis 1341, XP000453513, NLNorth Holland Publishing, Amsterdam, wird ein Aufbau für eine verteilte Multimediaunterstützung in einer Mikrokernelbetriebssystemumgebung beschrieben, durch den eine Echtzeitunterstützung bereitstellt wird. In dem Beitrag wird ausgeführt, dass die Güte der Dienstanforderungen auf allen Verarbeitungsstufen der Echtzeitdaten von Bedeutung ist. Der Beitrag offenbart „Vorrichtungen", die Hardware- oder Softwarekomponenten sind und als Erzeuger, Verbraucher und Filter von Echtzeitdaten arbeiten, sowie "RT-Ports" (rtports), die eine Echtzeitkommunikation zwischen den Vorrichtungen ermöglichen. Handler sind anwenderseitig definierte Prozeduren, die die von einem RT-Port kommenden und an einen RT-Port gehenden Echtzeitdaten manipulieren. Eine „Pipeline" von Vorrichtungen, die in Reihe über ihre RT-Ports verbunden sind, kann bereitgestellt werden, um Echtzeitdaten in einer Anzahl von Stufen zu verarbeiten. Bei einem Ausführungsbeispiel wird die Adresse eines einzelnen Puffers, in dem Echtzeitdaten gespeichert sind, von einer Stufe der Pipeline zur nächsten weitergegeben, um eine Verarbeitung der Echtzeitdaten zu ermöglichen.
Es besteht Bedarf an einem Mechanismus zur Erzeugung eines gemeinsam benutzten Puffers und zur an unabhängige Softwaretreiber erfolgenden Mitteilung von dessen Vor handensein derart, dass Daten in demselben Puffer in einer verbundenen Softwaretreiberumgebung von zwei oder mehr Komponenten verarbeitet werden können. Bei einem derartigen Mechanismus kann von Vorteil sein, auch die Pufferanforderungen eines Softwaretreibers mitzuteilen, um einen Fremdagenten (third party agent), so beispielsweise einen Graphersteller, in die Lage zu versetzen, verschiedene Softwaretreiber zur Bewerkstelligung einer bestimmten Medienstreamverarbeitungssequenz dynamisch zu verbinden.
Die vorliegende Erfindung bietet eine Technik zur Trennung von Puffern, die Daten zum Zwecke der Verarbeitung vorhalten, von einer Reihe unterschiedlicher Verarbeitungskomponenten derart, dass jede Verarbeitungskomponente die Daten sequenziell verarbeiten kann, ohne dass die Daten zwangsweise in einen mit der Verarbeitungskomponente verbundenen Puffer übertragen werden müssten.
Die Erfindung soll die Anzahl der zwischen den Puffern erfolgenden Datenübertragungen, die bei der Verarbeitung von Daten durch eine Mehrzahl getrennter und unterschiedlicher Verarbeitungskomponenten auftreten, verringern.
Die Erfindung soll darüber hinaus Latenzeffekte in einem Multimediasystem verringern.
Die Erfindung kann den Bedarf an Systemressourcen in Verarbeitungsanwendungen mit mehreren Verarbeitungskomponenten dadurch verringern, dass eine standardisierte Vorgehensweise zur Mitteilung von Pufferungsanforderungen und Pufferzuweisungsmöglichkeiten einer bestimmten Komponente bereitgestellt wird.
Die Erfindung kann eine Fremdkomponente (third party component) in die Lage versetzen, verfügbare Pufferzuweisungsmechanismen als Teil des wechselseitigen Verbindens separater Komponenten gemäß Bestimmung durch zunächst erfolgendes Abfragen und Empfangen der Anforderungen aller Komponenten vor dem Erstellen der Verbindungen zu erzeugen.
Entsprechend stellt die Erfindung in einem ersten Aspekt ein Verfahren zum Übertragen von Daten von einem vorhandenen ersten Puffer, der mit einer ersten Verarbeitungskomponente verbunden ist, an einen zweiten Puffer, der mit einer zweiten Verarbeitungskomponente verbunden ist, bereit, um eine Verarbeitung der Daten zu ermöglichen, wobei die Daten sequenziell durch die erste Verarbeitungskomponente, gefolgt von einer dritten Verarbeitungskomponente und anschließend der zweiten Verarbeitungskomponente verarbeitet werden, sich die Pufferanforderungen der ersten Verarbeitungskomponente von denen der zweiten und dritten Verarbeitungskomponente, die die gleichen Pufferanforderungen aufweisen, unterscheiden, in der zweiten Verarbeitungskomponente eine Pufferzuweisungseinrichtung vorhanden ist, um einen Datenpuffer entsprechend den Anforderungen der zweiten Verarbeitungskomponente zu erzeugen und zu verwalten, wobei das Verfahren die nachfolgenden Schritte umfasst: Zuweisen des zweiten Puffers unter Verwendung der Pufferzuweisungseinrichtung, die in der zweiten Verarbeitungskomponente vorhanden ist, Verarbeiten der Daten in dem vorhandenen Puffer und anschließendes Übertragen der verarbeiteten Daten an den zweiten Puffer durch die erste Verarbeitungskomponente; Verarbeiten der Daten in dem zweiten Puffer durch die dritte Verarbeitungskomponente; und Verarbeiten der Daten in dem zweiten Puffer durch die zweite Verarbeitungskomponente.
Die vorliegende Druckschrift beschreibt ein Verfahren und ein Computerprogrammerzeugnis zur Verringerung der zwischen Puffern erfolgenden Datenübertragungen zwischen separaten Verarbeitungskomponenten. Hierbei weist eine Verarbeitungskomponente, so beispielsweise ein Kernelmodustreiber, bestimmte unterstützbare Pufferungsanforderungen, so beispielsweise eine Byteausrichtung oder Frameverarbeitungsgrößen, wie auch Puffererzeugungs- und Verwaltungsfähigkeiten auf, um Puffer entsprechend den Anforderungen herzustellen. Ein Puffer kann sodann mittels einer bestimmten Bezugnahme (beispielsweise einer Bezugnahme auf die Pufferzuweisungseinrichtung oder den Puffer selbst), die vorher in der Verarbeitungskette an eine weitere Verarbeitungskomponente weitergegeben wurde, erzeugt werden. Wird kein neuer Puffer angefordert, so verarbeitet eine Verarbeitungskomponente einfach die Daten in dem vorhandenen Puffer (was eine Vor-Ort- oder In-situ-Verarbeitung darstellt) unabhängig vom Ort und der erstellenden Entität.
Eine Verarbeitungskomponente überträgt daher Daten nur dann an einen neuen Puffer, wenn ein solcher für die nächste Verarbeitungskomponente in der Kette notwendig ist. Da verschiedene Kombinationen von Ketten bei miteinander verbundenen Verarbeitungskomponenten möglich sind, ist unter gewissen Umständen eine Pufferzuweisungseinrichtung von Nöten, während diese unter anderen Umständen verzichtbar ist, was von der jeweiligen bestimmten Anordnung der Verarbeitungskomponenten abhängt. Die Verarbeitungskomponenten sollten deshalb die Fähigkeit unterstützen, Pufferanforderungen und -fähigkeiten einer Fremdkomponente mitzuteilen, die für die Erstellung der Verbindungen zwischen den Verarbeitungskomponenten und die Sicherstellung, dass die Pufferung zwischen den Verarbeitungskomponenten geeignet erfolgt, zuständig ist.
Ein Ausführungsbeispiel der vorliegenden Erfindung ist das auf standardisierte Weise erfolgende Verbinden von Kernelmodustreibern. Ein gegebener Treiber oder Filter unterstützt und definiert Stiftersteller (pin factories), die zur Instanzierung von Anschlussstiftinstanzen verwendet werden, die mit Anschlussstiftinstanzen an anderen Treibern verbunden werden können, um eine Verarbeitung von Mitteilungen nach Art einer konsekutiven Verarbeitung im Kernelmodus durch die Treiber zu ermöglichen, ohne dass der Umweg über einen Anwendermodusagenten genommen werden müsste.
Ein Fremdagent, der eine Verbindung normgerechter Treiber wünscht, fragt die Möglichkeiten der jeweiligen Treiber durch Bezugnahme auf die Anschlussstiftersteller (connection pin factories) ab. Zu diesen Fähigkeiten zählt unter anderem, welche Art von Verbindungsstiftinstanzen, darunter relevante Eigenschaften, so beispielsweise die Art der verarbeiteten Daten, die Datenformate, die Übertragungsraten, das Medium oder der Modus der Übertragung, die Eingabe oder Ausgabenatur der Anschlussstiftinstanz und dergleichen mehr, instanziert werden können. Darüber hinaus werden die Datenpufferungsan forderungen und die Fähigkeiten zur Zuweisung von Puffern, die bei jedem Verbindungsstiftersteller verfügbar sind, abgefragt.
Sobald ein Fremdagent, der üblicherweise im Anwendermodus arbeitet, die Fähigkeiten eines oder mehrerer normgerechter Treiber abgefragt hat, bestimmt der Agent die besten Verbindungseigenschaften für eine „Verkettung" mehrerer Treiber, damit die Daten darin optimal verarbeitet werden können. Dieser Schritt des Bestimmens erfolgt nach einer Abfrage sämtlicher Treiberfähigkeiten, damit die optimalen Verbindungskriterien ausgewählt werden können.
Für jede Verbindungsstiftinstanz bestimmt der Fremdagent darüber hinaus, ob ein Pufferzuweisungsbedarf an einer bestimmten Stiftinstanz erzeugt werden soll. Dies erfolgt wiederum nach einer Abfrage sämtlicher verschiedener Filter und Stiftersteller vor dem Herstellen der Verbindungen.
Der Fremdagent verbindet anschließend die Treiber durch Erzeugen der notwendigen Anschlussstiftinstanzen unter Verwendung der an den Filtern vorgefundenen Stiftersteller. Der Agent spezifiziert ein Datenformat und ein Anschlussformat als Teil der Erstellung der Verbindungsstiftinstanz. Darüber hinaus erzeugt der Fremdagent für den Fall, dass eine Pufferzuweisungseinrichtung für eine bestimmte Stiftinstanz benötigt wird, die Zuweisungseinrichtung mittels Einbau der Verbindungsstiftinstanz als Elternteil (parent). Bei einem Ausführungsbeispiel, das unter dem NT-Betriebssystem implementiert ist, wird die eigentliche Verbindungsstiftinstanz mittels einer I/O-Erzeugungsoperation (create I/O operation) erzeugt, die einen Handle an eine „Datei" ausgibt. Die I/O-Erzeugungsanforderung enthält den Treiberinstanzhandle und die entsprechende Bezugnahme auf eine Datenstruktur, die das Datenformat und das Anschlussformat für die Verbindungsstiftinstanz angibt.
Darüber hinaus wird die Bezugnahme auf vorher erstellte Verbindungsstiftinstanzen (beispielsweise Eingabestiftinstanzen oder IRP-Senken"-Stifte) in Anforderungen zur Erzeugung weiterer Anschlussstifte (beispielsweise Ausgabestiftinstanzen oder IRP-„Quellen"-Stifte) spezifiziert, um eine Verbindung zwischen Verbindungsstiftinstanzen zu bewerkstelligen. Nachdem eine Quellenstiftinstanz unter Verwendung einer Bezugnahme auf eine Eingabestiftinstanz seitens einer Pufferzuweisungseinrichtung erzeugt worden ist, wird ein Hinweis auf die Quellenstiftinstanz der Pufferzuweisungseinrichtung derart gegeben, dass Daten aus dem vorhandenen Puffer in den neuen Puffer übertra gen werden können. Wird keine Bezugnahme angegeben, so lässt der Quellenstift die Daten nach der Verarbeitung in den bestehenden Daten.
Zur Erzeugung eines normgerechten Treibers unterstützt ein Treiberentwickler bestimmte Standardeinrichtungen, um einen Anwendermodusagent in die Lage zu versetzen, Fähigkeiten abzufragen und Verbindungen zwischen den Treibern herzustellen. Bei einem in das Windows-NT-Betriebssystem eingebauten Ausführungsbeispiel erfolgt dies durch Verwendung von „Sätzen" (das heißt Sätzen betreffend Eigenschaft, Verfahren und Ereignis), die die gewünschte Funktionalität implementieren.
Ein Satz ist logisch derart definiert, dass er einen GUID (globally unique identifier GUID, global eindeutiger Identifizierer) zur Identifizierung des Satzes als Ganzes und einen RUID (relatively unique identifier RUID, relativer eindeutiger Identifizierer), wobei „relativ" innerhalb des Satzes selbst meint, für jedes Funktionalitätselement innerhalb des Satzes umfasst. Jeder Satz ist mit nur einem oder zwei IOCTLs (I/O-Steuerungen) verbunden, wobei eine IOCTL in Kombination mit einer eingestellten Spezifikation den gesamten Austausch mit dem Treiber steuert.
Gemäß dem vorliegenden Ausführungsbeispiel werden drei Arten von Sätzen verwendet, nämlich Eigenschaftssätze, Verfahrenssätze und Ereignissätze. Eigenschaftssätze werden zur Verwaltung von Werten und Einstellungen innerhalb des Treibers verwendet, so beispielsweise der Lautstärke, der Übertragungsrate und dergleichen, und bedienen sich einer einzelnen IOCTL mit einem Merker (flag), der angibt, ob der Aufruf einen Eigenschaftswert erhält oder einen Eigenschaftswert einstellt. Verfahrenssätze werden verwendet, um die Operationen, die ein Treiber ausführen kann, zu verwalten, so beispielsweise das Zuweisen von Speicher, das Leeren (flushing) von Puffern und dergleichen, und bedienen sich einer einzelnen IOCTL, um das spezifizierte Verfahren aufzurufen. Ereignissätze werden zum Verwalten von Ereignissen verwendet, die mit der Treiberverarbeitung in Verbindung stehen, so beispielsweise Vorrichtungsänderungsbenachrichtigungen, Datenauslichtungsbenachrichtigungen und dergleichen mehr und bedienen sich zweier IOCTLs, von denen die eine ein spezifiziertes Ereignis aktiviert und die andere ein spezifiziertes Ereignis deaktiviert.
Zur Verwendung eines Satzes wird eine I/O-Steuerungsoperation unter Verwendung der spezifizierten IOCTL und unter Bezugnahme auf eine Datenstruktur mit den eingestellten Werten für GUID, RUID und andere notwendige Daten initiiert. So geht beispielsweise mit dem Einstellen einer Lautstärkeeigenschaft an einem Soundkartentreiber eine I/O-Steuerungsoperation einher, die eine eingestellte Eigenschaft IOCTL verwendet, die den jeweiligen GUID für den Eigenschaftssatz mit der Lautstärkeeinstellung spezifiziert, den jeweiligen RUID innerhalb jenes Satzes mit der Angabe der Lautstärkeeigenschaft angibt und den neuen Lautstärkeeinstellungswert enthält.
Zur Abfrage der unterstützten Sätze wird ein Null-GUID zusammen mit einem Abfragemerker an einer spezifizierten IOCTL für einen bestimmten Satztyp (beispielsweise Eigenschaftssatz-IOCTL, Verfahrens-IOCTL oder Ereignisaktivierungs-IOCTL) verwendet, wobei eine Liste eingestellter unterstützter GUIDs ausgegeben wird. Zur Abfrage unterstützter Eigenschaften, Verfahren oder Ereignisse innerhalb eines gegebenen Satzes werden "GUID einstellen", „IOCTL-Art einstellen" und ein Abfragemerker verwendet, wobei die Operation eine Liste unterstützter RUIDs ausgibt.
Durch Verwendung des generischen Einstellmechanismus kann eine minimale Funktionalität implementiert werden, um einen normgerechten Treiber zu unterstützen und dennoch eine unbeschränkte Erweiterbarkeit zu ermöglichen. Ein Satz kann in einer niedergeschriebenen Spezifikation definiert werden, die unabhängig von einer Mehrzahl verschiedener Treiberentwickler kodiert werden kann, um ein System wechselseitig betreibbarer und verbindbarer Treiber zu erzeugen, wenn nur bestimmte Sätze implementiert sind. Darüber hinaus kann die Spezifizierung verpflichtende Eigenschaften, Verfahren und Ereignisse, die unterstützt werden müssen, wie auch optionale Eigenschaften, Verfahren und Ereignisse, die implementiert sein können, unterstützen, was von den Treiberfunktionen und den fortgeschrittenen Eigenschaften abhängt. Zusätzlich zu der erforderlichen grundlegenden minimalen Kommunalität können die Treiberentwickler zusätzliche Funktionalitäten miteinbeziehen, indem sie ihre eigenen Sätze definieren und diese einem GUID zuweisen. Indem ein Aufrufer in die Lage versetzt wird, unterstützte Funktionalitäten aufzuzählen (das heißt Abfragen nach unterstützten GUIDs und RUIDs durchzuführen), kann dieser Anrufer, so beispielsweise ein Fremdsteueragent, Erwartungen anpassen oder geeignete Ausgleichungen vornehmen, was wiederum von den Fähigkeiten der zugrundeliegenden Filter abhängt.
Um eine Pufferzuweisungsinstanz zu erzeugen, wird wieder eine I/O-Erzeugungsoperation verwendet, die die bestimmte Anschlussstiftinstanz mit ihrem Handle als Elternteil (parent) und der Ausgabe eines weiteren Handles, der die Pufferzuweisungseinrichtung darstellt, spezifiziert. Dieser Pufferzuweisungseinrichtungshandle wird anschließend in einer in einer Quellenanschlussstiftinstanz vorgefundenen Eigenschaft derart abgelegt, dass der Filter in die Lage versetzt wird, Daten an den neuen Puffer zu übertragen, der von der angezeigten Pufferzuweisungseinrichtung mittels geeigneter Stream-I/O-Operationen verwaltet wird.
Im Sinne der vorliegenden Beschreibung bezeichnet der Begriff „Anwendermodus" eine Operationsebene beziehungsweise Betriebsebene (operation level) in einem Betriebssystem, wo die meisten anwenderseitig verfassten Programme laufen. Die Betriebsebene „Anwendermodus" ist üblicherweise die sicherste Ebene und weist eine merkliche Menge an Overhead auf, um zu verhindern, dass ein Anwendungsprogramm oder Prozess ein anderes Anwendungsprogramm oder einen anderen Prozess beeinträchtigt. Darüber hinaus wird der Zugriff auf Systemressourcen durch spezifische Schnittstellen streng gesteuert, und die Laufpriorität ist üblicherweise eine der niedrigsten, wenn nicht die niedrigste.
Im Sinne der vorliegenden Beschreibung bezeichnet der Begriff „Kernelmodus" eine Operationsebene in einem Betriebssystem mit merklich weniger Einschränkungen, als dies bei der Betriebsebene des Anwendermodus der Fall ist. Beispiele für Kernelmodusprogramme oder Prozesse sind unter anderem Softwaretreiber zur Steuerung von Hardwarekomponenten. Üblicherweise sind Kernelmodusprogramme leistungsempfindlich und verfügen daher über weniger Betriebsoverhead, als dies bei Anwendermodusprogrammen der Fall ist. Darüber hinaus ist der Zugriff auf Hardware und viele Systemressourcen unbegrenzt oder zumindest erheblich weniger begrenzt, als dies bei Anwendermodusprogrammen der Fall ist. In vielen Fällen beruht der Programmcode, der im Kernelmodus läuft, auf der Disziplin des Programmierers und dem Einhalten von Konventionen, um ein gutes Systemverwalten zu ermöglichen (beispielsweise dadurch, dass der Adressraum eines anderen Programms nicht verwendet wird und dergleichen mehr). Ein anderer für Kerelmodus verwendeter Begriff ist „trusted code" („vertrauenswürdiger" Code)
Im Sinne der vorliegenden Beschreibung bezeichnet der Begriff „Treiber" Softwaretreiberprogramme, die üblicherweise im Kernelmodus laufen. Der Begriff „Treiber" bezeichnet gegebenenfalls auch ein tatsächlich ausführbares Programm, das in dem Betriebssystem oder in einem Teil desselben geladen ist und eine bestimmte Funktionalität beinhaltet. Treiber gehen in vielen Fällen, jedoch nicht notwendigerweise, mit irgendeiner Art von Hardware einher.
Im Sinne der vorliegenden Beschreibung bezeichnet der Begriff „Filter" einen Teil der innerhalb eines Softwaretreibers vorgefundenen Funktionalität, darunter den gesamten Treiber selbst, wobei Anschlusspunkte zum Zwecke des Sendens von Daten durch den Filter vorliegen können. So kann beispielsweise ein Softwaretreiber eine Anzahl verschiedener Filter unterstützen oder auch nur eine einzelne Funktion wahrnehmen. Darüber hinaus kann eine Anzahl von Filtern von verschiedenen Filtern, die untereinander verbunden sind und Anschlusspunkte für die Eingabe und Ausgabe nach außen hin aufweisen, zusammengefasst als ein einzelner Filter betrachtet werden. Darüber hinaus kann auf etwas stärker generische Weise der Begriff „Filter^„ eine vorgenommene Operation, so beispielsweise eine Dekomprimierung und ähnliches, bezeichnen, und zwar unabhängig davon, ob diese in einem im Kernelmodus laufenden Softwaretreiberfilter oder einem anderen Teil eines im Anwendermodus laufenden Programmcodes auftritt.
Im Sinne der vorliegenden Beschreibung bezeichnet der Begriff „Treiberobjekt" eine durch das Betriebssystem definierte Betriebssystementität zur Verwaltung und Bekanntmachung eines Softwaretreibers als Systemressource.
Im Sinne der vorliegenden Beschreibung bezeichnet der Begriff „Vorrichtungsobjekt" eine von dem System definierte Systemebenenentität zur Bekanntmachung eines Teils einer Treiberfunktionalität, die zur Verwendung als Systemressource verfügbar ist, und definiert die Treiberfunktionalität und die Verfügbarkeit für andere Systemkomponenten. Sowohl die Treiberobjekte wie auch die Vorrichtungsobjekte werden üblicherweise beim Laden und der Initialisierung der Treibersoftware erzeugt.
Im Sinne der vorliegenden Beschreibung bezeichnet der Begriff „Dateiobjekt" eine von dem System definierte Betriebssystementität zum Verwalten eines Aufrufs einer von einem Vorrichtungsobjekt spezifizierten Ressource. Ein Dateiobjekt stellt einen Kontext zur Verwendung eines Treiberobjektes bereit. Darüber hinaus kann ein Dateiobjekt hierarchisch mit einem weiteren Dateiobjekt in Beziehung stehen, wenn das frühere Dateiobjekt als „Elternteil" während der Erstellung des neuen Dateiobjektes bezeichnet wird. Dateiobjekte werden üblicherweise bei der Verwaltung sämtlicher I/O-Operationen verwendet, die an einem Stream von Daten arbeiten.
Im Sinne der vorliegenden Erfindung bezeichnet der Begriff „Daten" eine beliebige Information, die von miteinander verbundenen Kernelmodusfiltern verarbeitet wird. Zu derar tigen Daten zählen unter anderem Mediendaten, die Video, Audio, Text, MIDI und dergleichen mehr darstellen; es können jedoch auch Steuerinformationen oder Parameter für andere Anwendungen sein. So kann beispielsweise ein Kernelmodusfiltergraph bei Prozesssteuerungsoperationen verwendet werden, wo die zwischen den verschiedenen Filtern ausgetauschte Steuerinformation zur Entwicklung von Steuersignalen zur Betätigung von Elementen verwendet wird. Obwohl Beispiele für Medienverarbeitungssysteme angegeben sind, können andere Anwendungen auf gleiche Weise von dem System miteinander verbundener Kernelmodusfilter gemäß vorliegender Beschreibung profitieren.
In der vorliegenden Beschreibung erfolgt die Offenbarung der Erfindung im Zusammenhang mit dem von Microsoft^® vertriebenen Betriebssystem Windows NT^TM. Zudem wird davon ausgegangen, dass die I/O-Architektur von Windows NT bekannt ist, damit zu einem Verständnis des bevorzugten Ausführungsbeispieles der vorliegenden Erfindung gelangt werden kann. Ein hervorragendes Lehrbuch betreffend das I/O-System wie auch das NT-Betriebssystem ist das Buch „Inside Windows NT" von Helen Custer, das von Microsoft Press verlegt wird.
Obwohl die Diskussion der Treiber und Systementitäten, so beispielsweise der Dateiobjekte, Vorrichtungsobjekte und Treiberobjekte im Zusammenhang mit der Art ihres Funktionierens anhand des Betriebssystems Windows NT erfolgt, erschließt sich einem Fachmann auf dem einschlägigen Gebiet unmittelbar, dass die vorliegende Erfindung auch bei anderen Betriebssystemen implementiert werden kann, die analoge Komponenten umfassen, und zwar unabhängig davon, ob hierbei die gleiche Terminologie Verwendung findet. Sollte beispielsweise ein anderes Betriebssystem eine Entität umfassen, die als Dateiobjekt arbeitet, so kann diese als Dateiobjekt interpretiert werden, unabhängig davon, wie sie bezeichnet wird.
Die vorliegende Erfindung wird nachstehend beispielhalber unter Bezugnahme auf die begleitende Zeichnung beschrieben, die sich wie folgt zusammensetzt.
1 ist ein Datenflussdiagramm aus dem Stand der Technik, das ein System miteinander verbundener Filter und Treiber unter Leitung eines Steueragenten für die Verbringung von Tondaten von einer Plattendatei, die in irgendeiner Form erfolgende Verarbeitung der Tondaten und die Wandelung der Tondaten zum Zwecke des Abspielens über einen Lautsprecher zeigt.
2 zeigt ein erfindungsgemäßes demselben Zweck wie dasjenige von 1 dienendes System zum Lesen von Tondaten von einem Plattenlaufwerk, zum Bearbeiten dieser Daten und zum Wandeln dieser Dateien derart, dass sie auf einem Lautsprecher angehört werden können, wobei die Verarbeitungsfilter und das Wandeln von miteinander verbundenen Kernelmodussoftwaretreibern erneut unter Leitung eines Steueragenten bewerkstelligt werden.
3 ist ein Vertikalbeziehungsmodell, das die Beziehungen zwischen Treiberobjekten, Vorrichtungsobjekten und Dateiobjekten so, wie sie in einem Betriebssystem erzeugt und verwendet werden, zeigt.
4A, 4B und 4C sind logische Blockdiagramme eines Treiberobjektes, eines Vorrichtungsobjektes beziehungsweise eines Dateiobjektes, wobei deren logische Beziehung mit den Datenstrukturen und dem Programmcode zum Routen von Nachrichten zu geeignetem Prozesshandhabungscode und zur Validierung der Erzeugung neuer Dateiobjekte entsprechend der Erfindung dargestellt sind.
5 ist ein Flussdiagramm, das den Anfangssetup beim Routen und Validieren der Komponenten und der Verarbeitung von I/O-Nachrchten durch die Kernelmodustreiber zeigt.
6 ist ein Flussdiagramm, das die Verarbeitung eines Steueragenten, die Route- und Validierungsmechanismen und spezielle Handlererzeugungsroutinen zur Erzeugung eines neuen Dateiobjektes detaillierter zeigt.
7 ist ein logisches Diagramm, das die Horizontalbeziehung zwischen verbundenen Filtern unter Verwendung der Dateiobjektstrukturen in einem Betriebssystem für die standardisierte Bewerkstelligung einer derartigen Verbindung zeigt.
8 ist ein Flussdiagramm, das von einem Steueragent in einem Anwendermodus getätigte Verarbeitungsschritte zeigt, um die Kernelmodusfilter oder Treiber von 7 zu erzeugen oder zu verbinden, um wiederum eine Verbindung zur Verarbeitung von I/O-Anforderungen, die von dem Steueragent empfangen worden sind, bei weitergehender Verarbeitung zwischen den verschiedenen Treibern (Filtern) zu bewerkstelligen.
9A und 9B sind logische Übersichtsdiagramme der Kernelmodustreiber und Verbindungen, die zur Erstellung einer Kette von Kernelmodusfiltern unter Leitung eines Anwendermodussteueragent verwendet werden, um ein System zum Lesen von Tondaten von einem Plattenlaufwerk, zum Verarbeiten der Daten mit den Kernelmodusfiltern und Umwandeln der Daten derart, dass sie auf einem Lautsprecher angehört werden können, zu implementieren.
10 ist ein Flussdiagramm, das die Verarbeitungsschritte bei der Erzeugung der miteinander verbundenen Kernelmodustreiber für das in 9A und 9B gezeigte System darstellt.
11A und 11B zeigen die Funktion eines Pufferzuweisungsmechanismus. 11A zeigt eine logische Anordnung sowie die Verarbeitung der zugewiesenen Pufferframes, wenn diese von einer Verarbeitungskomponente an eine andere weitergereicht werden. 11B zeigt eine Pufferzuweisungseinrichtung, die als Dateiobjekt dargestellt ist, das wiederum ein „Kind" eines Dateiobjektes ist, das eine Eingabestiftinstanz in einem System miteinander verbundener Kernelmodusfilter darstellt. Sowohl 11A wie auch 11B zeigen dieselbe Filtergraphtopologie.
12 zeigt die Pufferzuweisungseinrichtung bei Übergängen des Systems gemäß Darstellung in 9A und 9B unter Verwendung von Pufferzuweisungseinrichtungen zur Steuerung der Zuweisung der Pufferframes.
13 ist ein Flussdiagramm, das die Verarbeitungsschritte bei der Verbringung von Daten von einem Plattentreiber über eine Kette miteinander verbundener Kernelmodusfilter und beim Wandeln der Daten an einer Tonverarbeitungshardware zeigt, wobei insbesondere der Betrieb der Pufferzuweisungseinrichtungen und die eigentliche Datenübertragung zwischen den Puffern für das in 12 gezeigte System dargestellt sind.
In 1 ist ein Beispielssystem zum Lesen eines Streams von Tondaten von einem Plattenlaufwerk und zum Umwandeln jener Tondaten derart, dass sie an einem Lautsprecher angehört werden können, entsprechend einem Modell aus dem Stand der Technik dargestellt. Eine Datenmenge wird auf einem Festplattenlaufwerk 20 gespeichert, wobei die Daten Ton (sound) in Form digitalisierter Tonabtastungen (samples) darstellen. Alternativ kann die Quelle des Tondatenstreams auch digitalisierte Information sein, die über eine Telefonleitung eintrifft, oder digitalisierte Information aus einem Netzwerk oder andere Kommunikationspakete oder andere im Stand der Technik bekannte Quellen. Der Datenstream setzt sich aus digitalisierten Abtastungen mit einer Zeitintervallinformation zusammen, die damit entweder über das Datenformat oder per Konvention oder über eine explizite Zeitstempelinformation, die an jede Abtastung angefügt ist, zusammenhängt. Ein Kernelmodusplattentreiber 22 steht mit der Plattentreiberhardware 20 in Wechselwirkung und wird von einer Anwendermodusleserprogrammkomponente 24 gesteuert. Ein Steueragent 26 verwaltet die verschiedenen Komponenten, um die Umwandlung der Tondaten zu bewirken, und kann dynamische Grapherstellungsfähigkeiten umfassen, damit die verschiedenen Softwarekomponenten dynamisch zugewiesen werden können, um eine übliche Filterung oder andere Verarbeitungswege gemäß Festlegung durch einem Endanwender bereitzustellen.
Diese Komponente 24 steht mit dem Plattentreiber 22 unter Verwendung einer I/O-Steuerungsstandardschnittstelle des Betriebssystems in Austausch und veranlasst das Lesen der komprimierten Tondaten von dem Plattenlaufwerk 20 in Puffer hinein, die im Anwendermodus als Teil des Anwendermodusprozessadressraumes zugewiesen werden. Anschließend dekomprimiert eine Dekompressorkomponente 28 die komprimierten Daten in ihr dekomprimiertes Format, damit eine Verarbeitung erfolgen kann. Wie gezeigt ist, erfolgt dieser Schritt gänzlich im Anwendermodus mit den zugehörigen Sicherheitsmechanismen von niedriger Priorität und entsprechendem Prozessverhalten.
Der Effektefilter 30 verarbeitet die Daten derart, dass er einen Spezialeffekt bewirkt, und verfügt über einen Begleiteffektefilter 32, der im Kernelmodus arbeitet. Darüber hinaus kann ein Effekteprozessor 34 vorhanden sein, oder es kann der Effektefilter gänzlich als Software ausgebildet sein, die den eigentlichen Hardwareprozessor emuliert. Um auf die Effektefilter 32 zuzugreifen, bedient sich die Effektekomponente 30 des System-I/O-Steuermechanismus zur Übertragung der Daten und zur Steuerung des Effektefilters. Erneut wird die Grenze zwischen Kernelmodus und Anwendermodus überschritten, um diesen Übergang zu vollziehen.
Der Effektefilter 32 steuert den Effekteprozessor 34 und erzeugt beliebige an den Daten notwendige oder gewünschte Spezialeffekte. Dies kann mit dem Kopieren sämtlicher Daten aus der Effektekomponente 30 in den Effektefilter 32 und erneut in den Effekteprozessor 34 in Abhängigkeit von der tatsächlichen Systemkonfiguration einhergehen. Während viele Softwareeffektekomponenten einen damit verbundenen Hardwareprozes sor aufweisen, funktionieren andere gänzlich innerhalb der Systemsoftware, die auf dem Hostprozessor läuft.
Nach Steuerung und Rückübertragung der Daten in den Anwendermodus erfolgt bei Beendigung der Verarbeitung seitens der Effektekomponente 30 anschließend eine Übertragung an die Tonwandlungskomponente 36. Die Tonwandlungskomponente 36 überträgt die Steuerung und Daten an den Tonwandlungstreiber 38, der wiederum die Soundkarte 40 steuert, um die Daten, die verarbeitet und gefiltert sind, in Ton für den Lautsprecher 42 zu wandeln. Es ist ersichtlich, dass eine Mehrzahl von Übertragungen zwischen Anwendermodus und Kernelmodus auftritt, wodurch Ineffizienzen bei der Umwandlung der Tondaten auftreten. Aufgrund der zeitempfindlichen Natur von Multimediadaten, so beispielsweise eines kontinuierlichen Streams von Ton oder Bildern, ist von Vorteil, wenn diese Ineffizienzen und Steuerungsübergänge wie auch das mehrfache Kopieren der Daten zwischen den verschiedenen Puffern verringert werden.
Ein Ausführungsbeispiel der vorliegenden Erfindung, das durchweg verwendet wird, bedient sich eines Dienstes, der von der Architektur des Betriebssystems Windows NT zur Verfügung gestellt wird. Dieser Dienst umfasst verschiedene Softwarekomponenten, auf die ein Anwender des Systems Zugriff hat. Zunächst steht ein Anwendermodus-API zur Verfügung mit einer Routine zur Erzeugung von Anschlussstiftinstanzen und anderen Dateiobjekten, die eine bestimmte Funktionalität darstellen, so beispielsweise einen Taktmechanismus oder einen Pufferzuweisungsmechanismus. Darüber hinaus liegt, was stärker von Bedeutung ist, ein vollständiger Satz von Routinen und Datenstrukturen vor, um den Treiberentwickler bei der Erstellung von Treibern zu unterstützen, die der standardisierten Architektur entsprechen.
Durch Verwendung derartiger dem System entstammender Einrichtungen können verschiedene Treiberentwickler normgerechte Treiber erzeugen, die miteinander entsprechend der spezifizierten Architektur in Wechselwirkung stehen. Anwendermodusagenten stehen mit den normgerechten Treibern über ein Umgebungsuntersystem, das im Anwendermodus läuft, in Verbindung, wobei eine Kommunikation mit den Systemdiensten der NT-Exekutive und dem I/O-Manager erfolgt. Es handelt sich hierbei um denselben Standard-I/O-Mechanismus für sämtliche anderen I/O-Vorgänge, wobei sich die vorliegende Implementierung des bevorzugten Ausführungsbeispiels der bestehenden Systemdienste so weit als möglich bedient.
Die in 1 dargestellte Systemarchitektur, weist, wenn sie sich der vorliegenden Erfindung bedient, das in 2 dargestellte Aussehen auf. Ein Steueragent 44 fragt die bekannten Treiber ab, um anschließend Verbindungen entsprechend dem Datenformat und dem Anschlussformat zu erstellen, damit die Wandlung gänzlich im Kernelmodus erfolgen kann. Darüber hinaus empfängt der Steueragent Benachrichtigungen über wichtige Ereignisse, damit er gegebenenfalls steuernd eingreifen kann. Beispiele für derartige Ereignisse sind unter anderem das Ende der Verarbeitung, eine Datenauslichtungssituation (data starvation situation) und dergleichen mehr.
Bei diesem Aufbau werden die Tondaten von dem Plattenlaufwerk 46 seitens des Plattentreibers 48, genau wie vorher beschrieben, gelesen. Ein Lesertreiber 50 steuert den Plattentreiber 48 und ist „vertikal" mit dem Plattentreiber 48 entsprechend der NT-eigenen geschichteten I/O-Architektur gemäß üblicher Einsatzweise verbunden. Die beiden Begriffe „vertikal" und „horizontal" werden verwendet, um Treiberanschlüsse, die üblicherweise als NT-eigene geschichtete I/O-Architektur (vertikal) auftreten, und Anschlüsse entsprechend den verbundenen Kernelmodustreibern gemäß dynamischer Erstellung seitens eines Fremdsteueragent (horizontal) zu unterscheiden.
Der Lesertreiber 50 ist ebenfalls „horizontal" mit einem Dekompressortreiber 52 entsprechend dem nachstehend erläuterten Anschlussverfahren verbunden und wird von dem Steueragenten 44 verwaltet. Der Dekompressor 42 führt die Dekompression im Kernelmodus aus, bevor die Daten und die Steuerung an den Effektefilter 54 übergeben werden. Der Effektefilter wendet die Spezialeffekte unter Verwendung eines Effekteprozessors 56 je nach Bedarf an, bevor die Daten und die Steuerung an den Tonwandlungstreiber 48 weitergegeben werden, der die Soundkarte steuert und eine Wandlung der Daten in Ton für den Lautsprecher 62 bewirkt. Wie durch ein Studium von 2 einsichtig ist, bringt die Beibehaltung der Verarbeitung im Kernelmodus Effizienzvorteile mit sich, da mehrfache Übergänge zwischen dem Anwendermodus und dem Kernelmodus vermieden werden, und indem die Overheadmenge, die normalerweise bei der Verarbeitung im Anwendermodus anfällt, verringert wird.
3 ist ein logisches Diagramm, das die hierarchische Natur von Systemobjekten in Beziehung zu untereinander verbundenen Softwaretreibern entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung zeigt. Ein Treiberobjekt 64 wird erzeugt, um das in den Speicher geladene ausführbare Softwarecodebild darzustellen. Das Treibercodebild enthält die gesamte Treiberfunktionalität, wobei das Treiberobjekt 64 Informa tionen bezüglich des Bildes, so beispielsweise dessen Lage im System, die Typen unterstützter Vorrichtungen und dergleichen mehr enthält.
Für jeden Typ unabhängig von einem Steueragent ansprechbarer Funktionalität werden Vorrichtungsobjekte 66a bis 66N in der I/O-Verzeichnisstruktur erzeugt, wodurch die verschiedenen Funktionen dargestellt werden, die verfügbar sind und auf die von Anwendermodusclients zugegriffen wird. Diese stellen typischerweise Filter oder andere Teile unabhängig zur Verfügung stehender Funktionalität dar. Das Treiberobjekt 64 und die Vorrichtungsobjekte 66a bis 66N werden bei der Installation von Treibercode erzeugt, wie durch den einschließenden Kasten 68 dargestellt ist.
Historisch betrachtet besteht ein Vorrichtungsobjekt für jedes Element aus physikalischer Hardware. Die Flexibilität in modernen I/O-Systemen lässt jedoch zu, dass ein Vorrichtungsobjekt einen Filter darstellt, der gänzlich als Software implementiert ist. Als solche können Vorrichtungsobjekte ohne Weiteres für jede Instanz eines lediglich als Software implementierten Filters erzeugt werden. Ein Softwarefilter kann daher derart implementiert werden, dass jede Instanz gemäß Darstellung durch ein Vorrichtungsobjekt eine Eins-zu-Eins-Entsprechung zu einem Vorrichtungsobjekt aufweist, oder es kann ein einzelnes Vorrichtungsobjekt dem mehr traditionellen Lösungsansatz folgen und mehrere Dateiobjekte verwalten, wobei jedes Dateiobjekt eine Clientinstanz des Filters darstellt.
Bei einem Vorrichtungsobjekt werden, was für das Vorrichtungsobjekt 66a gezeigt ist, Dateiobjekte erzeugt, die unabhängige Instanzen der von dem Vorrichtungsobjekt dargestellten Funktionalität darstellen. Obwohl ein Vorrichtungsobjekt einen Filter darstellt und verschiedene Instanzen für jenen Filter verwalten kann, stellt ein Dateiobjekt die eigentliche Instanz jenes von einer bestimmten Entität verwendeten Filters dar. Daher ist das Dateiobjekt 70 eine Instanz des Filters gemäß Definition durch das Vorrichtungsobjekt 66a.
Zur Verwendung eines Filters öffnet der Steueragent oder ein anderer Anwendermodusclient eine Datei auf einer in einer I/O-Verzeichnisstruktur zur Verfügung stehenden Vorrichtung. Ein Dateiobjekt mit entsprechender Kontextinformation wird erzeugt, und es wird ein Handle zu jenem Dateiobjekt an den Anwendermodusclient ausgegeben. Obwohl Dateiobjekte hierarchisch verwandt angeordnet werden können, indem ein „Elternteil"-Dateiobjekt während der Erzeugung spezifiziert wird, weisen Dateiobjekte auch eine Geschwisterbeziehung dahingehend auf, dass sie alle Kinder desselben Vorrichtungsobjektes sind.
Kontextinformation innerhalb eines Dateiobjektes enthält Information zur Verwaltung der I/O-Schnittstelle mit Anwendermodusclients, des „Status" der Entität, den das Dateiobjekt darstellt, und dergleichen mehr. Die Kontextinformation umfasst für das System notwendige Information und enthält darüber hinaus anwenderseitig definierbare Bereiche, denen eine spezifische Bedeutung zugewiesen werden kann. Ein Beispiel dafür, wie die anwenderseitig definierbaren Bereiche verwendet werden können, wird nachstehend bei der Diskussion der Implementierung eines Validierungs- und IRP-Routingverfahrens gegeben.
Zur Bereitstellung von Anschlussstiftinstanzen wird das Filterobjekt 70, das eine Filterinstanz darstellt, als Elternteil bei der Erzeugung von Kinderdateiobjekten verwendet, die die Anschlussstiftinstanzen für einen bestimmten Filter darstellen. Obwohl das Dateiobjekt 70 bezüglich der Anschlussstiftherstellungsdefinitionen und der zugehörigen Verfügbarkeit abgefragt werden, werden eigentliche Dateiobjekte für jede Instanz eines derartigen Stifterstellers erzeugt, und zwar unter Verwendung des bestimmten Dateiobjektes als geeigneter Informationskontext, um die Anschlussstiftinstanz gültig und korrekt zu erzeugen. So stellen beispielsweise die Dateiobjekte 72 und 74 Anschlussstiftinstanzen für diejenigen Filter dar, die durch das Dateiobjekt 70 dargestellt werden, und stehen hierarchisch mit dem Dateiobjekt 70 in Beziehung. Die Anschlussstiftinstanzen gemäß Darstellung durch das Dateiobjekt 72 beziehungsweise 74 können einen Datenweg in die Filterinstanzen (Darstellung durch Dateiobjekt 70) hinein und aus diesen heraus darstellen, wobei die Filterinstanz zum Anschluss an andere Anschlussstiftinstanzen bei der Ausbildung einer Reihe verketteter Filter oder einer anderen Treiberfunktionalität verwendet werden kann.
Genau wie eine Stiftinstanz durch ein Dateiobjekt dargestellt wird, das eine hierarchische Beziehung mit einem weiteren Dateiobjekt aufweist, das die Filterinstanz darstellt, um die Kontextinformation für die Stiftinstanz bereitzustellen, können andere Dateiobjekte hierarchisch mit einer Stiftinstanz in Beziehung gesetzt werden, um andere Funktionalitäten darzustellen, damit die richtige Kontextinformation verfügbar wird. Die Kontextinformation ist zur Unterscheidung einer Stiftinstanz von einer anderen Stiftinstanz entsprechend den jeweiligen bei der Erzeugung verwendeten Parametern, so beispielsweise dem Stiftdatenformat, dem Kommunikationstyp und dergleichen mehr, erforderlich.
Andere Betriebsentitäten, so beispielsweise ein Pufferzuweisungsmechanismus, ein Zeitgabemechanismus und dergleichen mehr, die entweder einen individuellen Kontext oder eine Anwendermodussteuerung über einen Handler benötigen, können ebenfalls durch Dateiobjekte dargestellt werden. Darüber hinaus können hierarchische Beziehungen zwischen den Dateiobjekten (beispielsweise ein Pufferzuweisungsmechanismus, der mit einer bestimmten Anschlussstiftinstanz verbunden ist) gegebenenfalls dadurch erstellt werden, dass ein Elternteildateiobjekt während der Erzeugung des Kinddateiobjektes spezifiziert wird. Diese Elternteil/Kind-Beziehungen bestehen, um die Beziehungen und die Struktur zwischen den Dateiobjekten zu bestimmen, die die Betriebsentitäten darstellen. Darüber hinaus kann ein bestimmter Typ von „Elternteil"-Dateiobjekt nur bestimmte Arten von „Kinder"-Dateiobjekten erzeugen, wozu die Erzeugungsvalidierungsmechanismen gemäß nachstehender Beschreibung erforderlich sind. Wiederum verfügen derartige Dateiobjekte über entsprechende im Anwendermodus verfügbare Handles, die an einen Client über einen System-API-Aufruf, so beispielsweise über NtCreateFile, ausgegeben werden.
Die Handles bezüglich Dateiobjekten werden von Anwendermodusclients, so beispielsweise einem Steueragent, eingesetzt, um mit den Kernelmodustreibern zu kommunizieren. Die hierarchische Kette von Dateiobjekten, Vorrichtungsobjekten und Treiberobjekten versetzt das I/O-Untersystem in die Lage, das Treiberobjekt durch die hierarchisch in Beziehung stehenden Dateiobjekte und Vorrichtungsobjekte zurückzuverfolgen und zum Eingangspunkt des eigentlichen Treibercodes zu gelangen. Derartige Eingangspunkte sind Bezugnahmen (beispielsweise Zeiger) auf Funktionen im Softwaretreibercode. Darüber hinaus stellt jedes der Objekte in dem Objektwegverlauf zwischen einem bestimmten Dateiobjekt und dem Treiberobjekt mit den Eingangspunkten für den Softwaretreibercode eine wichtige Kontextinformation für das I/O-Untersystem bei der Erzeugung von IRPs wie auch bezüglich Bezugnahmen auf die Datenstrukturen bereit, die zum richtigen IRP-Routing entsprechend den Routing- und Validierungsmechanismen gemäß nachstehender Beschreibung verwendet werden.
Handles bezüglich Dateiobjekten und anderer Systemobjekte sind prozessspezifisch und stellen dasjenige Mittel dar, durch das ein Anwendermodusprozess mit einem zugrundeliegenden Objekt kommuniziert. Interessant ist festzustellen, dass mehrere Handles erzeugt werden können, um auf ein einzelnes zugrundeliegendes Systemobjekt, so beispielsweise ein Dateiobjekt, Bezug zu nehmen. Dies bedeutet, dass mehrere Anwen dungen Information einer Stiftinstanz gemäß Darstellung durch ein Dateiobjekt zuleiten können.
Ein Informationselement, das für die wechselseitige Verbindung verschiedener Treiber von Bedeutung ist, ist der Vorrichtungsobjektstapeltiefeparameter. Dieser gibt die IRP-Stapelstelle eines bestimmten Treiberobjektes an. Auf diese Weise kann ein einzelner IRP verwendet und zwischen wechselseitig verbundenen Treibern unter Verwendung des I/O-Managers weitergeleitet werden, wodurch eine Leistungsverbesserung gegenüber einer separaten Erzeugung und Versendung von IRPs zwischen den verschiedenen wechselseitig verbundenen Treiben gegeben ist. Alternativ kann jeder Treiber mittels geeigneter I/O-Manageraufrufe neue IRPs für jede aufeinanderfolgende Kommunikation erzeugen und die Versendung einer neuen IRP an den nächsten Treiber in der Kette wechselseitig verbundener Treiber veranlassen.
In 4A bis 4C sind Erweiterungen für die Systemtreiberobjekte, Vorrichtungsobjekte und Dateiobjekte gezeigt, die eine Validierung der Dateiobjekterzeugung verschiedener Typen wie auch ein I/O-Anforderungspaketrouting beziehungsweise IRP-Routing an die geeigneten Handler ermöglichen. 4A zeigt ein Treiberobjekt 76, das den ausführbaren Code darstellt, der einen oder mehrere Filter oder eine andere Treiberfunktionalität implementiert. Innerhalb des Treiberobjektes benötigt die Windows-NT-Architektur eine Bezugnahme auf einen Erzeugungshandler, der vom Entwickler des Softwaretreibers zur Verfügung gestellt wird. Entsprechend diesem Ausführungsbeispiel wird auf eine Multiplexierungslenkfunktion 78 (multiplexing dispatch function) von dem Treiberobjekt 76 als Erzeugungshandler Bezug genommen, wobei diese zum Routen von Nachrichten an bestimmte Erzeugungshandler in Abhängigkeit von dem zu erzeugenden Dateiobjekttyp verwendet wird. Der Betrieb der Multiplexierungslenkfunktion 78 wird nachstehend im Zusammenhang mit dem Flussdiagramm von 6 beschrieben.
Auf gleiche Weise zeigen andere Handler von dem Treiberobjekt eine Multiplexierungslenkfunktion an und können je nach Anwendung auch dieselbe Funktion wahrnehmen. Mit anderen Worten verweist, wie nachstehend noch detaillierter beschrieben wird, jede Art von I/O-Handlerbezugnahme (beispielsweise Lesen, Schreiben, Vorrichtungssteuerung und dergleichen mehr) auf eine Multiplexierungslenkfunktion, die sich der Erweiterungsdaten in einem Vorrichtungsobjekt und der Kontextinformation in einem Dateiobjekt bedient, um die Mitteilung an den richtigen Handler zu routen. Die Erweiterungsdaten in dem Vorrichtungsobjekt, die auf eine Validierungstabelle Bezug nehmen, werden ver wendet, wenn kein Elternteildateiobjekt bei einer Erzeugungsoperation spezifiziert wird. Andernfalls gibt die Elternteildateiobjektkontextinformation die richtige Validierungstabelle an.
4B zeigt ein Treiberobjekt 80, das einen bestimmten Vorrichtungserweiterungsbereich 82 aufweist, der je nach Bedarf von dem Treiberentwickler verwendet werden kann und treiberspezifische Information beinhaltet. An einer definierten Stelle innerhalb des Vorrichtungserweiterungsbereiches 82 des Treiberobjektes 80 ist eine Bezugnahme auf eine Datenstruktur vorhanden, die als Dateitypvalidierungstabelle 84 bekannt ist und Stringdarstellungen von Dateiobjekttypen 86 sowie Bezugnahmen auf die damit verbundenen Erzeugungshandler 88 zu jedem dargestellten Dateityp enthält. Die Erzeugungsmultiplexierungslenkfunktion bedient sich der Dateitypvalidierungstabelle 84 zur Validierung des zu erzeugenden Dateiobjekttyps und gibt die Steuerung dann an den jeweiligen Erzeugungshandler ab, was nachstehend in Verbindung mit der Diskussion von 6 noch eingehend beschrieben wird. Der zu validierende String wird in einer IRP-Erzeugungsanforderung vorgefunden und stammt aus dem Dateinamenstring, der mit dem NtCreate-File-Funktionsaufruf im Anwendermodus verwendet wird. Der NtCreatefile-Aufruf wird innerhalb der Anwendermodusfunktionszelle erstellt, um eine Stiftinstanz oder einen anderen Mechanismus zu erzeugen.
4C zeigt ein Dateiobjekt 90 mit einem Dateikontextbereich 92, der von dem Softwaretreiberentwickler frei verwendet werden kann. Es erfolgt eine Bezugnahme aus dem Dateikontextbereich 92 auf die IRP-Anforderungshandlertabelle 94. Die verschiedenen Typen der IRP-Anforderung 96 sind mit Bezugnahmen auf die jeweiligen Handler 98 verknüpft, und die jeweilige Multiplexierungslenkfunktion bedient sich dieser Information, um auf den richtigen Handler zuzugreifen. Für den Fall der Bestimmung des richtigen Erzeugungshandlers wird auf eine Datenstruktur Bezug genommen, die als Dateitypvalidierungstabelle 100 bekannt ist und die Stringdarstellungen von Dateiobjekttypen 102 sowie Bezugnahmen 104 auf die damit verbundenen Erzeugungshandler für jeden dargestellten Dateityp aufweist. Für Kinderdateiobjekte (das heißt für Dateiobjekte, die ein anderes Dateiobjekt und nicht ein Vorrichtungsobjekt als Elternteil haben) wird der Typ von einem String dargestellt, der mit den Strings in den Dateiobjekttypen 102 verglichen wird. Wird ein Treffer vorgefunden, so wird auf den damit verbundenen Erzeugungshandler unter Verwendung einer Bezugnahme aus der Bezugnahme 104, die mit dem als Treffer vorgefundenen Dateiobjekttypstring verbunden ist, zugegriffen. Wird kein Treffer vorgefunden, so ist die Anforderung nicht gültig, und es wird eine Fehlermeldung ausgegeben.
5 zeigt die Installationsprozedur für den Setup der Erzeugungsvalidierung und den Mechanismus. Bei Schritt 106 erfolgt eine Bezugnahme des Installationsprogramms in dem Treiberobjekt auf die geeignete Multiplexierungslenkfunktion. Wie in 4A gezeigt ist, verweist der Erzeugungshandler auf eine generische Multiplexierungslenkfunktion. Auf gleiche Weise verweisen sämtliche anderen Handlerbezugnahmen in dem Treiberobjekt 76 auf andere generische Multiplexierungslenkfunktionen, die den jeweiligen Handler gegebenenfalls betreffen. Alternativ kann jede Handlerbezugnahme auch auf dieselbe Multiplexierungslenkfunktion verweisen, die wiederum die IRP-Anforderung verarbeiten und diese an den richtigen Handler routen kann. Eine derartige alternative Multiplexierungslenkfunktion ist notwendigerweise komplizierter, damit sie verschiedenen Arten von Anforderungen (beispielsweise Erzeugen, Schreiben und dergleichen mehr) gerecht werden kann.
Anschließend wird bei Schritt 108 jedes Vorrichtungsobjekt, das als Teil der softwaretreiberseitig ausführbaren Codeinstallation erzeugt ist, derart eingestellt, dass es auf die Dateitypvalidierungstabelle 84 Bezug nimmt, wie in 4B gezeigt ist. Schließlich beginnt bei Schritt 110 die Verarbeitung der IRP-Anforderungen mit der Multiplexierungslenkfunktion unter Verwendung der Dateitypvalidierungstabelle 84 gemäß Bezugnahme aus dem zugehörigen Vorrichtungsobjekt 80.
Wird ein Dateiobjekt erzeugt, so wird die zugehörige IRP-Lenktabelle 94 gegebenenfalls mit der Indexierdateiobjekttypvalidierungstabelle 100 erzeugt, und es wird darauf Bezug genommen. Die Erzeugung der Dateiobjekttypvalidierungstabelle erfolgt innerhalb der bereitgestellten Erzeugungshandler entsprechend dem Dateiobjekttyp. Die Datenstrukturen werden erzeugt und stellen die IRP-Lenktabelle 94 und die Dateiobjekttypvalidierungstabelle 100 und eine Bezugnahme hierauf dar, die an einer spezifischen Stelle mit der Dateikontextinformation 92 des jeweils erzeugten Dateiobjektes 90 gespeichert ist.
In 6 ist ein Flussdiagramm dargestellt, das den Betrieb der Erzeugungsmultiplexierungslenkfunktion und des zugehörigen Validierungsmechanismus einschließlich der Wechselwirkung mit den Datenstrukturen, auf die von den Systemtreiberobjekten, den Vorrichtungsobjekten und den Dateiobjekten Bezug genommen wird, darstellt. Bei Schritt 112 sendet ein Anwendermodusprozess eine I/O-Anforderung zur Erzeugung eines Dateiobjektes. Diese I/O-Erzeugungsanforderung ergeht unter Verwendung eines Aufrufes an die System-API nach NtCreateFile. Bei Schritt 114 sendet der I/O-Manager die IRP an die Multiplexierungslenkfunktion 78, und zwar auf Basis der Bezugnahme in dem Treiberobjekt 76 (siehe 4A).
Sobald die Multiplexierungslenkfunktion 78 die IRP für die Erzeugungsanforderung vorliegen hat, wird bei Schritt 116 ein Test vorgenommen, um festzustellen, ob ein Elternteildateiobjekt vorhanden ist. Die Information, die zur Vornahme dieser Bestimmung notwendig ist, ist innerhalb der IRP selbst vorhanden und wird ursprünglich von dem Anwendermodusprozess bereitgestellt. Der Anwendermodusprozess stellt einen Handle mit Bezugnahme auf das „Elternteil"-Dateiobjekt als Teil der Erzeugungsanforderung bereit, während das NT-System die IRP mit der korrekten Bezugnahme auf das "Elternteil"-Dateiobjekterzeugt.
Ist kein Elternteildateiobjekt vorhanden, so wird der rechte Ast genommen, und die Multiplexierungslenkfunktion 78 bedient sich der Vorrichtungserweiterung 82 von dem geeigneten Vorrichtungsobjekt 80, um eine Bezugnahme auf die Dateitypvalidierungstabelle 84 (siehe 4B) bei Schritt 118 vorzunehmen. Unter Verwendung der Validierungstabelle 84 validiert die Multiplexierungslenkfunktion 78 den Dateiobjekttyp bei Schritt 120 durch Vergleichen des Strings in der Anforderung mit den Strings der Dateiobjekttypen 86.
Ist ein passender String gemäß Bestimmung bei Schritt 122 vorhanden, so wird auf den zugehörigen Erzeugungshandler bei Schritt 124 zugegriffen. Andernfalls wird die Erzeugungsanforderung bei Schritt 126 zurückgewiesen. Der Erzeugungshandler gemäß Zugriff bei Schritt 124 erzeugt bei Schritt 126 das Dateiobjekt oder veranlasst dessen Erzeugung. Mit dem erzeugten Dateiobjekt erstellt der jeweilige Erzeugungshandler die Dateiobjektbezugnahme in dem Dateikontext 92 auf eine IRP-Lenktabelle 94, die vorher erzeugt worden ist.
Wiederum bei Schritt 116 kann bestimmt werden, dass ein Elternteildateiobjekt vorhanden ist. Ist ein Elternteildateiobjekt vorhanden, so wie es bei Schritt 116 gemäß Auffinden in der IRP in Verbindung mit der Erzeugungsanforderung bestimmt worden ist, so bedient sich die Multiplexierungslenkfunktion 78 des Dateikontextes 92 aus dem Elternteildateiobjekt 90, um eine Bezugnahme auf eine IRP-Lenktabelle 94 (siehe 4C) bei Schritt 130 vorzunehmen. Bei einer Erzeugungsanforderung greift die Multiplexierungslenkfunktion 78 auf eine Dateitypvalidierungstabelle 100 bei Schritt 132 zu. Mit der Dateitypvalidierungstabelle 100 validiert die Multiplexierungslenkfunktion 78 den Datei- Objekttyp bei Schritt 133 durch Vergleichen des Strings in der Anforderung mit den Strings der Dateiobjekttypen 102 auf die bereits beschriebene Weise.
Ist kein passender String durch die Bestimmung bei Schritt 134 festgestellt worden, so wird auf den jeweiligen Erzeugungshandler bei Schritt 138 zugegriffen. Andernfalls wird die Erzeugungsanforderung bei Schritt 136 zurückgewiesen. Mit dem jeweiligen Erzeugungshandler wird das Dateiobjekt bei Schritt 140 erzeugt, und der Erzeugungshandler erstellt eine neue IRP-Lenktabelle 94 für das neuerzeugte Dateiobjekt und nimmt eine Bezugnahme in dem dem neuerzeugten Dateiobjekt 90 zueigenen Dateikontextbereich 42 auf die neuerzeugte IRP-Lenktabelle 94 bei Schritt 142 vor. Man beachte, dass dieselbe Dateiobjektstruktur wie in 4C zur Erläuterung der Wechselwirkung sowohl mit dem Elternteildateiobjekt und dem gültig erzeugten Kinddateiobjekt verwendet wird. Obwohl in beiden Fällen dieselbe Struktur existiert (sobald das neue Dateiobjekt erzeugt worden ist), werden diese Strukturen auf verschiedene Weisen verwendet und enthalten verschiedene Information.
Wann immer eine Anschlussstiftinstanz erzeugt wird, wird eine Anschlussstift-ID weitergeleitet, die den Stiftersteller in dem Filter identifiziert, der die Erzeugung der Stiftinstanz „unterstützt". Einem Fachmann auf dem einschlägigen Gebiet erschließt sich, dass die Anschlussstift-ID auch als String in einer Validierungstabelle auf dieselbe Weise validiert werden kann, wie das Dateiobjekt validiert wird. Einem Fachmann erschließt sich zudem, dass auch andere Implementierungsvarianten existieren.
Um Verbindungen zwischen verschiedenen Treibern herzustellen, muss ein gemeinsamer Mechanismus vorhanden sein, um sicherzustellen, dass ein gegebener Treiber derartige wechselseitige Verbindungen unterstützt. Dieser gemeinsame Mechanismus muss das Ausfindigmachen von Filterfähigkeiten einschließlich der Anschlussstifterstellerfähigkeiten ermöglichen. Darüber hinaus sollte ein derartiger Mechanismus auch derart erweiterbar sein, dass er zusätzliche Flexibilität für die Treiberentwickler bereitstellt.
Ein im Zusammenhang mit dem vorliegenden Ausführungsbeispiel zur Definition geeigneter Treiber verwendeter und das Ausfindigmachen von Fähigkeiten ermöglichender Mechanismus schlägt sich in "Sätzen" verwandter Einheiten nieder. Es handelt sich hierbei um einen bequem zu verwendenden Mechanismus, der zusammen mit bestehenden I/O-Kommunikationsmechanismen verwendet werden kann. Ein Satz ist logisch derart definiert, dass er eine GUID (global eindeutiger Identifizierer) zur Identifizierung des Sat zes als Ganzes und eine RUID (relativer eindeutiger Identifizierer, wobei sich das Wort „relativ" auf den Satz selbst bezieht) für jedes Element der Funktionalität innerhalb des Satzes umfasst. Der Satzidentifizierer und beliebige andere Datenstrukturen, die zum Betreiben der gewählten RUID-Einheit notwendig sind, werden als Teil eines I/O-Steuerungsaufrufes unter Verwendung des Filterhandles als Parameter weitergeleitet. Nur eine kleine Anzahl von IOCTLs muss zugewiesen werden, um ein volles System von Funktionalitäten zu implementieren. Bei der Implementierung werden drei verschiedene Typen von Sätzen erstellt, und zwar in Abhängigkeit von den jeweiligen Funktionen, was eine Gesamtzahl von vier IOCTLs nach sich zieht. Weitere Implementierungen können die Sätze auf andere Weise verwenden. Die jeweilige IOCTL signalisiert dem Handler für die I/O-Steuerung, dass dieser das gewählte Element (unter Verwendung von RUID) auf bestimmte Weise interpretieren oder verwenden soll. Darüber hinaus können Steuerungsflags (Steuerungsmerker) mit der GUID und der RUID weitergeleitet werden, um die Steuerinformationen weiter zu spezifizieren.
Die erste Satztyp ist ein Eigenschaftssatz und wird in Verbindung mit Werten oder Einstellungen verwendet, die innerhalb des Treibers oder einer damit verbundenen Hardware vorgefunden werden. Beispiele für derartige Einstellungen sind die Übertragungsrate, das Lautstärkeniveau und dergleichen mehr. Eine IOCTL ist mit Eigenschaftssätzen mit einem Steuerungsmerker verbunden, der zwischen einem Befehl „Eigenschaft erhalten" und „Eigenschaft einstellen" unterscheidet. Auf diese Weise kann dieselbe Datenstruktur sowohl zum Einstellen wie auch zum Erhalten einer bestimmten Eigenschaft verwendet werden, wobei der Treiber die jeweils erforderliche Handlung in Abhängigkeit von der verwendeten IOCTL bestimmt. Die wichtige Eigenschaft wird durch den Satzidentifizierer identifiziert, der aus einer eindeutigen Kombination aus GUIDs und RUIDs besteht.
Verfahrenssätze stellen einen weiteren verwendeten Satztyp dar und sind ein Satz von Handlungen, die von einem Treiber ausgeführt werden können. Es wird nur eine IOCTL benötigt, um den Verfahrenssatz mit dem korrekten anzusprechenden Verfahren zu identifizieren, das durch die eindeutige Kombination aus GUID und RUID für den Satzidentifizierer identifiziert ist. Verfahren werden verwendet, um den Treiber zu steuern und umfassen Funktionen wie die Initialisierung des Treibers für den Einsatz, das Löschen der Puffer und dergleichen mehr.
Ereignissätze werden zur Verwaltung von Ereignissen verwendet, die mit der Treiberverarbeitung in Verbindung stehen, so beispielsweise die Vorrichtungsänderungsbenachrichtigung, die Datenauslichtungsbenachrichtigung und dergleichen mehr oder eine beliebige andere Benachrichtigung, die durch den Satz definiert ist, der für eine andere Anwendermodusanwendung von Nutzen sein könnte. Es werden zwei IOCTLs verwendet, und zwar eine zur Aktivierung eines spezifischen Ereignisses und eine zur Deaktivierung eines spezifischen Ereignisses, wohingegen beliebige Datenstrukturen, die für ein durch eine RUID identifiziertes gegebenes Ereignis notwendig sind, dahingehend gemeinsam verwendet werden können, dass sie das Ereignis entweder aktivieren oder deaktivieren.
Zur Verwendung eines Satzes wird eine I/O-Steueroperation unter Verwendung der spezifizierten IOCTL und einer entsprechenden Bezugnahme auf eine Datenstruktur mit den eingestellten Werten für GUID und RUID und andere notwendige Daten (beispielsweise Steuerungsflags, Datenstrukturen und dergleichen mehr) initiiert. So geht beispielsweise mit dem Einstellen einer Lautstärkeeigenschaft auf einen Soundkartentreiber eine I/O-Steueroperation einher, die eine Eigenschaftssatz-IOCTL, einen Steuermerker, der eine eingestellte Eigenschaftsoperation angibt, die richtige GUID für den Eigenschaftssatz mit der Lautstärkeeinstellung, die spezifische RUID innerhalb jenes Satzes mit der Angabe der Lautstärkeeigenschaft und den neuen Lautstärkeeinstellwert verwendet.
Zur Abfrage der unterstützten Sätze nach Typ werden eine IOCTL für einen bestimmten Satztyp (beispielsweise Eigenschafts-IOCTL, Verfahrens-IOCTL oder Ereignisaktivierungs-IOCTL) mit einem Null-GUID und Steuerungsmerker zur Anzeige der unterstützten Satzaufzählung als Teil eines I/O-Befehls ausgegebenen, und es wird eine Liste eingestellter und unterstützter GUIDs ausgegeben. Um die unterstützten Eigenschaften, Verfahren oder Ereignisse innerhalb eines gegebenen Satzes abzufragen, werden die eingestellte GUID, die Satztyp-IOCTL, eine Null-RUID und Steuermerker zur Anzeige der Aufzählung der unterstützten Elemente mit der I/O-Operation verwendet. Eine Liste unterstützter RUIDs wird als Ergebnis der I/O-Operation ausgegeben. Dies versetzt einen Fremdagent in die Lage zu bestimmen, welche optionalen Elemente eines implementierten Satzes gegebenenfalls unterstützt werden.
Die niedergeschriebene Spezifikation eines Satzes, der eindeutig durch eine GUID identifiziert ist, ermöglicht einen dokumentierten Mechanismus, den sowohl die Treiberentwickler wie auch Fremdsteuerungsagenten als Implementierungsführer verwenden kön nen. Der Fremdentwickler besitzt Kenntnisse über die Fähigkeiten eines gegebenen Treibers in Abhängigkeit von der Reaktion auf Abfragen sowie eine vorprogrammierte Kenntnis auf Basis der abstrakten Satzdefinition. Auf gleiche Weise kann ein Treiberentwickler die abstrakte Satzdefinition als Führung zur Implementierung eines Satzes oder einer Gruppe von Sätzen verwenden, die eine bekannte Funktionalität für einen Fremdagent bereitstellen.
Zur Bereitstellung der Anschlussfähigkeiten gemäß vorliegender Beschreibung muss ein geeigneter Treiber bestimmte Sätze unterstützen. Die nachfolgenden Tabellen illustrieren bestimmte Arten von Information, die im Eigenschaftssatzformat unterstützt und die bei der Implementierung der vorliegenden Erfindung Verwendung finden können. Die erste Tabelle betrifft Eigenschaften betreffend einen Anschlussstiftersteller, der durch einen Filter implementiert wird, wohingegen die zweite Tabelle Eigenschaften betreffend eine tatsächliche Anschlussstiftinstanz betrifft, die durch Verwendung eines bestimmten Anschlussstifterstellers als Muster erzeugt wird.
Tabelle 1
Tabelle 2
Die vorstehenden Tabellen sind lediglich als Beispiele angegeben. Einem Fachmann auf dem einschlägigen Gebiet erschließt sich, dass viele verschiedene Eigenschaften und Schemen implementiert werden können, um die Anschlüsse zwischen verschiedenen Treibern zu implementieren. Ein wichtiges Element ist der Standardisierungsfaktor, durch den die verschiedenen Treiberhersteller oder Entwicklergruppen Treiber entwickeln können, die untereinander verbunden sind, damit sie in der Lage sind, dieselben Eigenschaftssätze zu implementieren.
Ein weiterer nützlicher Eigenschaftssatz gibt Topologieinformation für die inneren Beziehungen für die Eingabe- und Ausgabeanschlussstiftersteller an einem gegebenen Filter an. Diese Information stellt die Beziehung von Eingabestifterstellern und den entsprechenden Ausgabestifterstellern an einem gegebenen Filter wie auch die Tatsache fest, welcher Typ von Verarbeitung zwischen den Eingabe- und Ausgabestifterstellern vorliegt. Beispiele für ein Auftreten der Verarbeitung sind beispielsweise verschiedene Datentransformationen, die Datendekompression, die Echounterdrückung und dergleichen mehr. Derartige Information ist für einen automatischen Filtergraphersteller von Nutzen, der einen hypothetischen Anschlussweg unter Verwendung mehrerer Filter verfolgt, be vor tatsächliche Anschlussstiftinstanzen und Anschlüsse erstellt werden. Im Wesentlichen erläutert die Topologieinformation die innere Struktur des Filters und stellt diese über einen Eigenschaftssatzmechanismus für Abfragen durch Fremdagenten bereit.
Aus diesem Grund ist ein einschlägiger Treiber einfach derjenige, der den bezeichneten Eigenschaftssatz implementiert. Dies versetzt einen Fremdsteuerungsagent in die Lage, Abfragen zu tätigen und Einstellungen an dem jeweiligen Filter vorzunehmen, sobald bestimmt worden ist, dass ein bestimmter Eigenschaftssatz unterstützt wird. Das Gesamtziel besteht darin, ausreichend Information dahingehend zu erwerben, wie die verschiedenen Filter miteinander zu verbinden sind, um einen Filtergraph darzustellen.
Durch Verwendung des generischen Satzmechanismus kann eine minimale Funktionalität implementiert werden, um einen jeweiligen Treiber zu unterstützen, um jedoch auch eine unbeschränkte Erweiterbarkeit zu ermöglichen. Ein Satz kann in einer niedergeschriebenen Spezifikation definiert werden, die unabhängig von einer Mehrzahl verschiedener Treiberentwickler kodiert werden kann, um ein System untereinander betreibbarer und verbindbarer Treiber zu erstellen, solange nur die bestimmten Sätze implementiert sind. Darüber hinaus kann die Spezifizierung verpflichtende Eigenschaften, Verfahren und Ereignisse, die unterstützt werden müssen, wie auch optionale Eigenschaften, Verfahren und Ereignisse, die implementiert sein können, definieren, was von den Treiberfunktionen und fortgeschrittenen Fähigkeiten abhängt. Neben der erforderlichen grundlegenden minimalen Kommunalität können die Treiberentwickler auch zusätzliche Funktionalitäten aufnehmen, indem sie ihre eigenen Sätze definieren und ihnen eine GUID zuweisen.
In 7 und 8 ist eine Darstellung des Prozesses zum Anschließen zweier Kernelmodusfilter dargestellt. 7 zeigt eine logische Blockdarstellung, in der jede Filterinstanz und Anschlussstiftinstanz von Dateiobjekten dargestellt ist. 8 ist ein Flussdiagramm, das die Schritte zur Erzeugung der Dateiobjekte und der zugehörigen Anschlüsse darstellt.
Beginnend bei Schritt 144 werden eine Instanz eines Filters A 146 und eine Instanz eines Filters B 148 von einem Anwendermodusagent erzeugt. Diese werden unter Verwendung einer Standarddateisystem-API zur Erzeugung von Dateien mit einer bestimmten Vorrichtung erzeugt. Der Filter A 146 und der Filter B 148 sind einschlägige Filter oder Treiber, da sie die jeweiligen Eigenschafts-, Verfahrens- und Ereignissätze implementieren, um die Erzeugung der Anschlussstiftinstanzen und das Abfragen der jeweiligen Filtereigenschaften im Zusammenhang mit den unterstützten Sätzen und der Anschlussstiftersteller gemäß Definition für jenen Filter unterstützen.
Der Fremdsteuerungsagent nimmt anschließend eine Abfrage des Filters A 146 beziehungsweise des Filters B 148 bei Schritt 150 vor, um die Anschlussstiftersteller zu bestimmen, die verfügbar sind, sowie die Eigenschaften für die Anschlussstiftinstanzen, die daraus erzeugt werden können. Zu diesen Eigenschaften zählen, wie bereits dargelegt wurde, das Anschlussformat und das Datenformat für jeden einzelnen Typ von Stiftinstanz bei jedem entsprechenden Filter 146 und 148. Das Abfragen erfolgt unter Zuhilfenahme der satzbasierten Abfragemechanismen gemäß vorstehender detaillierter Beschreibung.
Nach dem Abfragen dieser Information bestimmt der Fremdsteuerungsagent das optimale Anschlussformat auf Basis der Bereiche der Datenformate und Anschlussformate, die vorher abgefragt worden sind. Die Bestimmung erfolgt bei Schritt 152 und vermittelt dem Fremdagent die Fähigkeit, dieselben Filter auf unterschiedliche Arten entsprechend den Bedürfnissen eines ausgewählten Anschlussweges zu verwenden. Der Fremdsteuerungsagent verwendet die Datenschnittstelleneigenschaft, die Topologieinformation und die Anschlussstiftersteller an beiden Filtern, um zu bestimmen, wie das Datenformat und die Anschlussanordnungen in Abhängigkeit von dem tatsächlich erstellten Filtergraph am besten auszuwählen sind.
Die Eingabefilterstiftinstanz 144 wird bei Schritt 156 von dem Fremdagent unter Verwendung der bei Schritt 152 bestimmten optimalen Erfassungsbildung erzeugt. Da die Eingabestiftinstanz 154 ein Dateiobjekt ist, wird ein Handle vom Erzeugungsprozess ausgegeben, der verwendet werden kann, um I/O-Anfragen an die Eingabeinstanz 154 zu leiten. Darüber hinaus ist die Erzeugung der Eingabestiftinstanz 154 validiert und bedient sich der Routing- und Validierungsmechanismen, die vorab bei der Diskussion der 4A bis 4C sowie 5 und 6 gezeigt worden sind.
Um den Anschluss zu vollenden, wird bei Schritt 160 eine Ausgabestiftinstanz 158 erzeugt, bei der als ein Parameter bei dem NtCreateFile-Aufruf der Einbau der vorher erzeugten Eingabestiftinstanz 154 erfolgt. Die Wirkung dieser Erzeugung der Ausgabestiftinstanz 158 besteht darin, die Systemdateiverwaltung und die I/O-Verwaltungseigenschaften zu nutzen, um eine interne IRP-Stapelstruktur zu erzeugen, die einen ursprüng lichen Schreibbefehl in die Lage versetzt, konsekutiv von den verschiedenen angeschlossenen Anschlussstiftinstanzen und Filtern in der richtigen Reihenfolge derart bearbeitet zu werden, dass der direkte Datenfluss zwischen den verschiedenen Filtern erleichtert wird. Dies erfordert, dass die Eingabestiftinstanz vor der zugehörigen Ausgabestiftinstanz erzeugt wird, die die Eingabestiftinstanz bedient.
Der Stapeltiefeparameter eines Vorrichtungsobjektes steuert, wie viele Stapelorte für ein IRP, das an diesen Treiber gesendet wird, erzeugt werden. Es sei angenommen, dass der Stapeltiefeparameter dann vorliegt, wenn ein Vorrichtungsobjekt anfangs erzeugt wird, und anschließend modifiziert werden kann, was wiederum davon abhängt, ob mehrere Treiber miteinander verkettet sind. Bei dem vorliegenden System tritt gegebenenfalls eine Modifikation auf, wenn eine Ausgabestiftinstanz von einem ursprünglichen „Stopp"-Zustand in einen „Erwerbs"-Zustand oder einen anderen Zustand wechselt. Der Anschlussstiftinstanzzustandswechsel ist derjenige Mechanismus, der die richtige Stapeltiefeparameterinformation für die IRP-Erzeugung und Bearbeitung bestimmt.
Um eine interne IRP-Stapelstruktur korrekt für einen verketteten Satz von Anschlussstiftinstanzen zuzuweisen, ist notwendig, die Anschlussstiftinstanzen aus dem Stoppzustand heraus in einer bestimmten Reihenfolge zu wechseln, und zwar beginnend mit der Letzten Eingabestiftinstanz (in diesem Fall der Eingabestiftinstanz 154) und anschließend konsekutiv rückwärts zu einer zugehörigen (das heißt angeschlossenen) Ausgabestiftinstanz (in diesem Fall der Ausgabestiftinstanz 158) zurückzulaufen. Sind viele Filter miteinander verkettet, so ist die tiefste Filter- oder Brückeneingabestiftinstanz zwangsläufig der Anfangspunkt des Wechsels und sukzessiven Rückwärtslaufens, bis die Anfangsausgabestiftinstanz an einer Brücke oder einem Filter eingestellt ist. Mit anderen Worten, der Wechsel heraus aus dem Stoppzustand muss rückwärts entlang der Kette erfolgen, sodass jede Anschlussstiftinstanz diejenige Stapelgröße erhält, die nach der vorhergehenden Stapelstiftinstanz erforderlich ist. Üblicherweise, jedoch nicht notwendigerweise, wechselt eine Anschlussstiftinstanz vom Stoppzustand in den Erwerbszustand, wobei zu Zwecken der nachstehenden Erläuterung der Wechsel in den Erwerbszustand demselben Zweck mit Blick auf die Stapeltiefeparametereinstellung wie der Wechsel aus dem Stoppzustand heraus dient.
Sobald sämtliche Stiftinstanzen im Erwerbszustand befindlich sind, können Streamlese- und Schreibvorgänge an den Filtergraph ausgegeben werden. Es ist interessant festzustellen, dass das hier vorgestellte System einen Anschluss zugehöriger Eingabe- und Ausgabestiftinstanzen in beliebiger Reihenfolge zulässt; lediglich der Wechsel aus dem Stoppzustand heraus muss von unten nach oben beziehungsweise mit der tiefsten Größe beginnend erfolgen. Darüber hinaus ist der Filtergraph rekonfigurierbar, um die Vornahme von Änderungen nach der anfänglichen Erzeugung zu ermöglichen. Werden Änderungen vorgenommen, so müssen Zustandswechsel nur an denjenigen Anschlussstiftinstanzen vorgenommen werden, die im Stoppzustand befindlich sind, um eine korrekte Stapeltiefeparameterinformation sicherzustellen.
Anschlussstiftersteller, die an Filtern vorgefunden werden, stellen Orte dar, an denen Filter Daten verbrauchen und/oder erzeugen können, und zwar in einem bestimmten Format. So kann beispielsweise ein bestimmter Anschlussstiftersteller eine Anzahl verschiedener Datenformate unterstützen, so beispielsweise PCM-Audio mit 16 Bit und 44 kHz oder PCM-Audio mit 8 Bit und 22 kHz. Wie vorstehend erläutert, können die Anschlussstiftersteller und ihre verschiedenen Fähigkeiten, so beispielsweise das Datenformat, von dem Filter unter Verwendung eines geeigneten Eigenschaftssatzmechanismus und der System-I/O-Einrichtungen abgefragt werden. Tatsächliche Anschlussstiftinstanzen werden auf Basis der von den Stifterstellern bereitgestellten Information erzeugt.
In einer Streamingumgebung, in der eine einzelne Streamschreib- oder Streamleseoperation von einem Anwendermodusagent eine sukzessive Verarbeitung der Daten entlang der angeschlossenen Filter veranlasst, können zwei Hauptverfahren zur IRP-Steuerung als Teil der ursprünglichen Einrichtungen des NT-Betriebssystems verwendet werden. Zunächst kann eine separate IRP von jedem Filter erzeugt und an den nächsten Filter zum Zwecke der Verarbeitung gesendet werden, der wiederum eine neue IRP für eine weitere Verarbeitung in der Kette weiter abwärts erzeugt. Das andere Verfahren betrifft die Verwendung einer einzelnen IRP und leitet diese zwischen den sukzessiven Filtern unter Verwendung von Standardprozeduren weiter, die für eine Wechselwirkung mit dem I/O-Manager bereitstehen. Wird das erste Verfahren zur Erzeugung neuer IRPs für jeden sukzessiven Filter in der Kette verwendet, so ist die Reihenfolge der wechselseitigen Verbindung unter den Filtern nicht von Relevanz, da die Filter nur den Bestimmungsort der IRP kennen müssen, um den I/O-Manager aufzurufen und die IRP an den bezeichneten Filter zu senden. Wird eine IRP nochmals verwendet, so ist wichtig, dass die Anschlussstiftinstanzwechsel aus dem Stoppzustand heraus beginnend mit dem letzten Filter zum Empfangen der neuverwendeten IRP zur Verarbeitung rückwärts bis zum ersten Filter zum Empfangen der neuverwendeten IRP oder zu demjenigen Filter, der die IRP zur Verarbeitung erzeugt hat, erfolgt.
Das hier vorgestellte Ausführungsbeispiel und die Implementierung der wechselseitig verbundenen Kernelmodusfilter bedient sich vorteilhafterweise der gemeinsamen IRP-Verwendung, um die Kompliziertheit bei der Treiberentwicklung zu vereinfachen, die Erzeugung stabiler Treiber zu ermöglichen und eine effektivere Verarbeitung zuzulassen. Der „von unten nach oben" erfolgende Stiftinstanzstatuswechselweg stellt sicher, dass die richtige Stapelreihenfolge in der IRP erzeugt wird, die von den sukzessiven Treibern verarbeitet wird, und dass jedes Treiberobjekt den richtigen Stapeltiefeparametersatz aufweist. Darüber hinaus wird der aktuelle Zustand der empfangenen Eingabestiftinstanz überprüft, um sicherzustellen, dass die Zustandswechselsequenz ordnungsgemäß befolgt wird. Aus diesem Grund bestimmt die Verbindungseigenschaft eines bestimmten Anschlussstifterstellers die mögliche Flussrichtung und Unterstützung bei der richtigen Verteilung der Statuswechsel der Anschlussstiftinstanzen.
Bei der Erzeugung einer Anschlussstiftinstanz (oder IRP-Quelle) wird eine Bezugnahme bezüglich eines Dateiobjektes, das eine Eingabestiftinstanz (oder IRP-Senke) auf einen anderen Filter darstellt, als Teil des NtCreateFile-Aufrufes weitergeleitet. Der entsprechende Erzeugungshandler wird gemäß vorstehender Beschreibung unter Verwendung der Multiplexierungslenkfunktion und der Vorrichtungsobjekt-/Dateiobjekthierarchien ausgeführt. Der Erzeugungshandler hat Zugriff auf das Vorrichtungsobjekt des Filters mit der Eingabestiftinstanz (beispielsweise Filter B 148 in 7) mittels des Eingabeanschlussstiftinstanzdateiobjektes (beispielsweise Eingabestiftinstanz 154). Aus dem Vorrichtungsobjekt kann der vorhergehende Stapeltiefeparameter abgelesen werden, und es kann der Stapeltiefeparameter des Vorrichtungsobjektes für den Filter mit der Ausgabestiftinstanz inkrementiert werden. So weist beispielsweise das Vorrichtungsobjekt in Verbindung mit dem Filter A 146 einen Stapeltiefeparameter auf, der von demjenigen des Vorrichtungsobjektes in Verbindung mit dem Filter B 148 für die in 7 dargestellte Verbindung inkrementiert wird. Dies erfolgt normalerweise bei einem Wechsel aus dem Stoppzustand heraus, wobei die IRPs nicht weitergeleitet werden, während eine Anschlussstiftinstanz im Stoppzustand befindlich ist.
Verarbeitet ein Filter eine IRP, so ist ihm bekannt, auf welchen Stapelframe oder Ort innerhalb des IRP-Stapels zuzugreifen ist, der dann die Information enthält, die für jenen bestimmten Filter durch Bezugnahme den auf Stapeltiefeparamter und Verwendung desselben des zugehörigen Vorrichtungsobjektes bestimmt ist. Darüber hinaus bereitet der jeweilige Filter die IRP für den nächsten Filter in der Verarbeitungskette vor, indem der Vorrichtungsobjektstapeltiefeparameter dekrementiert wird, um den nächsten Filter-IRP-Stapelort örtlich anzugeben.
Der Filtercode ist für die Vorbereitung des nächsten Ortes in dem IRP-Stapel und zum Aufruf des I/O-Managers verantwortlich, damit die IRP an den nächsten Filter gemäß Bezeichnung weitergegeben werden kann. Auf diese Weise kann der Filter bezeichnen, welches Dateiobjekt, das eine bestimmte Anschlussstiftinstanz darstellt, die IRP empfangen soll sowie die zugehörigen Daten zur Verarbeitung. Daher werden Standard-I/O-Manager Aufrufe, so beispielsweise IoAttachDevice, zur Stapelung der jeweiligen Vorrichtungsobjekte zum Zwecke eines sequenziellen IRP-Verarbeitung nicht verwendet.
Es muss erwähnt werden, dass die Erzeugung einer Verbindung zwischen Anschlussstiftinstanzen nicht die Erzeugung neuer Vorrichtungsobjekte zur Darstellung der Verbindung impliziert. Ein einfaches zugrundeliegendes Vorrichtungsobjekt wird verwendet, um eine Instanz eines Filters und sämtliche Anschlussstiftinstanzen an jenem Filter zu unterstützen. Spezifische Information, die für eine geeignete Datenverarbeitung notwendig ist, wird innerhalb des Kontextbereiches des Dateiobjektes gehalten, was eine Erhaltung der Kontextinformation ermöglicht, während die Verwendung von Nichtseitenspeichern (non-page memory) minimal gehalten wird. Es muss darüber hinaus erwähnt werden, dass ungeachtet der Tatsache, dass ein IRP-basiertes Medium dargestellt ist, andere Medien zur Kommunikation zwischen den untereinander verbundenen Filtern verwendet werden können, so beispielsweise Direktfunktionsaufrufe bei Nichthost-Hardware-zu-Hardware-Kommunikation.
In 9A und 9B sowie 10 sind die richtige Erzeugungs-, Verbindungs- und Zustandswechselreihenfolge der Softwaretreiber gemäß 1 (Stand der Technik) und gemäß 2 (logisches Diagramm höherer Ebene der untereinander verbundenen Kernelmodustreiber) dargestellt. 9A zeigt die logische Struktur, die von einem Kasten 162 umrahmt ist, und die darin enthaltenen Verarbeitungsschritte. 9B zeigt die Erzeugung der Anschlussstiftinstanzen zur Vollendung der gegenseitigen Verbindung der Kernelmodusfilter und enthält die Verarbeitungsschritte, die in einem Kasten 164 in dem in 10 gezeigten Flussdiagramm enthalten sind.
In dem Zustand von 9B ist, nachdem sämtliche wechselseitigen Verbindungen erstellt worden sind, das Kernelmodusfiltersystem für Lese- und Schreibvorgänge bereit, um die Verarbeitung zu bewerkstelligen. Das I/O-System verwendet die IRP-Stapelin formation, die geeignet von dem korrekten Statuswechselprozess eingestellt ist, um die Streamlese- und Schreibvorgänge auf den unterschiedlichen Filterelementen mittels ihrer jeweiligen Anschlussstiftinstanzen weiterzuleiten. Man beachte, dass irgendeine externe Software, die über den verwendeten Agent hinausgeht, zur Erzeugung des Graphen, darunter eine Brücke oder ein Filter selbst, wie auch von Hardware Daten für die Streamlese- und Schreibvorgänge bereitstellt.
Nach dem Beginn in Schritt 168 erzeugt der Steuerungsagent 170 Instanzen des Leserfilters 172, des Dekompressorfilters 174, des Effektefilters 176 und des Tonwandlungsfilters 178 in Schritt 180. Darüber hinaus wird ein Anhang (attachment) zwischen dem Leserfilter 172 und einem Plattentreiber 182 getätigt, um Daten von dem Plattenlaufwerk auslesen zu können. Die Erzeugung jeder Filterinstanz wird von dem Anwendermodussteuerungsagent 170 durch Verwendung von Standard-I/O-Aufrufen zum Öffnen einer Datei auf der jeweiligen Vorrichtung so, wie sie in der Vorrichtungs-I/O-Verzeichnishierarchie vorgefunden werden, bewerkstelligt. Ein derartiger Aufruf gibt einen Handle an ein Dateiobjekt aus, das die Instanz jedes Filters darstellt.
Bei Schritt 184 fragt der Fremdagent den Effektefilter 172, den Dekompressorfilter 174, den Effektefilter 176 und den Tonwandlungsfilter 178 ab, um die Anschlussstifterstellerfähigkeiten abzufragen. Diese Fähigkeiten beinhalten, welche Arten von Eingabe- und Ausgabestiftinstanzen erzeugt werden können, wie viele Instanzen jedes Anschlussstifterstellers der bestimmte Filter unterstützt, das bei jedem Anschlussstiftersteller unterstützte Datenformat, das Medium oder den Typ des Kommunikationsweges und dergleichen mehr. Die Fähigkeiten werden „abgefragt", indem der vorstehend detailliert erläuterte Eigenschaftseinstellmechanismus verwendet wird, wobei davon ausgegangen wird, dass die Kernelmodusfilter mit der Architektur verträglich sind, da sie die jeweiligen "Sätze" (so beispielsweise den Eigenschaftssatz) unterstützen.
Die gesamte Abfrageinformation wird bei Schritt 184 verwendet, um zu bestimmen, ob ein verketteter Verbindungsweg zwischen den jeweiligen Filtern möglich ist, indem die jeweiligen Anschlussstiftinstanzen erzeugt und angeschlossen werden. Der Fremdagent bestimmt die Arten von Stiftinstanzen, die zur wechselseitigen Verbindung benötigt werden, um einen Filtergraph zu erstellen, der dann einem bestimmten Zweck dient.
Die Bestimmung des Anschlussformates auf Basis der unterstützten Datenformate erfolgt bei Schritt 186. Unter Verwendung der Topologieinformation, des Datenformates und der Datenschnittmengeneigenschaften an dem Filter kann ein hypothetischer Filtergraph erzeugt werden. Da die Anschlussreihenfolge nicht von Bedeutung ist, muss dies nicht zwangsweise erfolgen, kann jedoch Zeit sparen, wenn versucht wird, einen Filtergraph zu erstellen. Sollte der hypothetische Filtergraph fehlerfrei erzeugt werden, so kann der Fremdagent sicher sein, dass die Erstellung untereinander verbundener Anschlussstiftinstanzen verlässlich erfolgen kann. Da einige Abfragen zu Fehlermeldungen führen, wenn nicht eine tatsächliche Stiftinstanz erzeugt wird, kann es notwendig sein, derartige Anschlussstiftinstanzen zu erzeugen, bevor ein hypothetischer Filtergraph erzeugt wird, der eine verlässliche Angabe betreffend die Lebensdauer macht. Erneut kann der hypothetische Filtergraph getestet werden, bevor die wechselseitigen Verbindungen erstellt werden.
Sobald die richtige Anschlussinformation bekannt ist, so wie sie bei Schritt 186 bestimmt worden ist, können die Eingabestiftinstanzen erzeugt und wechselseitig verbunden werden, was durch die umrandeten Verarbeitungsschritte, die in dem Kasten 164 von 10 enthalten sind, dargestellt ist. Diese Umrandung enthält die Verarbeitungsschritte, die an derjenigen Eingabestiftinstanz beginnen, die am weitesten von der Quelle des Datenstreams entfernt ist. Die letzte Eingabestiftinstanz bezeichnet man als „tiefste" Stiftinstanz und kann als erste erzeugt werden, gefolgt von der damit verbundenen Ausgabestiftinstanz. Eine Verbindung ist daher die Erzeugung einer Ausgabestiftinstanz unter Verwendung des Handles einer vorher erzeugten Eingabestiftinstanz.
Das Muster geht weiter, wobei jede Eingabestiftinstanz anschließend sukzessive vor der Verbindung mit der zugehörigen Ausgabestiftinstanz erzeugt wird. Ein derartiges Verbindungsszenario ist lediglich als Beispiel angegeben und unterliegt keinerlei Beschränkungen bezüglich der anderen Arten der Verbindungen der jeweiligen Eingabe- und Ausgabestiftinstanzen zum Zwecke der Bildung einer erfindungsgemäßen Verbindung zwischen Kernelmodusfiltern. Die Filter können in einer beliebigen Reihenfolge entsprechend der Implementierung verbunden werden, solange nur der Handle von der Eingabestiftinstanz während der Erzeugung der verbundenen Ausgabestiftinstanz an einem anderen Filter verwendet wird. Darüber hinaus können, was vorstehend bereits erläutert worden ist, Veränderungen an dem Filtergraph nach der erstmaligen Erzeugung (und sogar Verwendung) vorgenommen werden.
Bei der ersten Iteration der Umrandung wird eine Eingabestiftinstanz 188 bei Schritt 190 erzeugt. Nach dem Empfangen des Handles von der Erzeugungsfunktion verwendet der Fremdsteuerungsagent 170 jenen Handle als Parameter in einem NtCreateFile-Aufruf, um eine Ausgabestiftinstanz 192 bei Schritt 194 zu erzeugen. Indem dies während der ersten Iteration erfolgt, wird der Tonwandlungsfilter 178 effektiv mit den Effektefiltern 176 über die entsprechenden Anschlussstiftinstanzen 188 beziehungsweise 192 verbunden. Bei der gegenwärtigen Implementierung wird der NtCreateFile-Aufruf als Teil eines Funktionsaufrufes in einem API "eingewickelt", der den Anwendermodusclients zur Verfügung gestellt wird. Dies entlastet den Anwendermodusentwickler der Fremdagenten davon, Detailkenntnisse zu erlangen, und ermöglicht darüber hinaus, dass alte relevanten Funktionalitäten in einem einzelnen Anwendermodus-API konzentriert sind.
Bei Schritt 196 bestimmt der Agent, ob andere bestehende Eingabestiftinstanzen erzeugt werden sollen. Ist dem so, so müssen die Eingabestiftinstanzen erzeugt werden, gefolgt von der entsprechenden Ausgabestiftinstanz an einem anderen Filter. Eventuell werden sämtliche Verbindungen erstellt, und der Fremdsteuerungsagent 170 bereitet den Filtergraph zur Verarbeitung von Streamingdaten vor.
Auf diese Weise wird die Eingabestiftinstanz 202 bei der zweiten Iteration der in dem Kasten 164 eingeschlossenen Umrandung bei Schritt 190 erzeugt, wobei die Ausgabestiftinstanz 204 den Handle der Eingabestiftinstanz 202 als Teil der zugehörigen Erzeugung bei Schritt 194 verwendet. Schließlich wird bei der dritten und letzten Iteration dieses bestimmten Beispieles eine Eingabestiftinstanz 206 erzeugt, gefolgt von einer Ausgabestiftinstanz 208, wodurch das Verbinden vollendet wird.
Bei Schritt 197 wechselt der Fremdsteuerungsagent 170 jede Anschlussstiftinstanz vom Stoppzustand in den Erwerbszustand, um die Verarbeitung von Streamingdaten durch den Filtergraph vorzubereiten. Um den Stapeltiefeparameter in jedem der Vorrichtungsobjekte für die jeweiligen Filter korrekt einzustellen, ist notwendig, den Stapelwechsel beginnend mit der „tiefsten" oder letzten Anschlussstiftinstanz (beispielsweise der letzten Eingabestiftinstanz zur Aufnahme der Daten zur Verarbeitung) zu erstellen und sich sequenziell entlang der Kette wechselseitig verbundener Kernelmodusfilter „nach oben" zu bewegen, bis man bei der ersten Anschlussstiftinstanz (beispielsweise der ersten Ausgabestiftinstanz, die die Daten für den Graph zur Verfügung stellt) anlangt. Der erste Filter beziehungsweise die erste Brücke erzeugt die IRP mit ausreichend zugewiesenen Stapelorten, sodass die IRP auf effiziente Weise sukzessive durch jeden Kernelmodusfilter in dem Graph geleitet werden kann.
Schließlich gibt der Fremdsteuerungsagent 170 die Streamlese- und Schreibvorgänge aus, um die Daten bei Schritt 198 zu verarbeiten, bevor das Ganze bei Schritt 200 endet.
Wie vorstehend erläutert worden ist, erfordert jede Erzeugung einer Ausgabestiftinstanz den Handle eines Dateiobjektes, das die Eingabestiftinstanz, die damit verbunden werden soll, darstellt. Diese Dateiobjektbezugnahme versetzt den Erzeugungshandle für die Ausgabestiftinstanz in die Lage, eine Bezugnahme bezüglich des Vorrichtungsobjektes entsprechend der Eingabestiftinstanz für einen gegenwärtigen oder einen zukünftigen Zugriff einzusparen.
Insbesondere versetzt dies den Stapeltiefeparameter des Vorrichtungsobjektes in die Lage, die Eingabestiftinstanz, auf die von dem Treiber der Ausgabestiftinstanz zugegriffen werden soll, während des Zustandswechsels vom Stoppzustand in den Erwerbszustand oder einen anderen Zustand zu verwalten. Der Wert des Stapeltiefeparameters in Verbindung mit der Eingabestiftinstanz wird abgefragt, inkrementiert und im Stapeltiefeparameter für das Vorrichtungsobjekt entsprechend der Ausgabestiftinstanz gespeichert.
Der Stapeltiefeparameter wird verwendet, um zu bestimmen, wo in der gemeinsam benutzten IRP-Stapelstruktur die Stapelframeinformation für einen bestimmten Filter angeordnet ist, und ist für jeden Filter verschieden. Durch die auf diese Weise erfolgende wechselseitige Verbindung der Filter und Erstellung der Zustandswechsel in der richtigen Reihenfolge, kann eine einzelne IRP entlang der Kette der wechselseitig verbundenen Filter im Kernelmodus geleitet werden, ohne dass zwangsweise eine Kommunikation in den Anwendermodus erfolgen müsste.
Man beachte, dass es möglich ist, mehrere Instanzen auf Basis des gleichen Anschlussstifterstellers zu erhalten. So kann beispielsweise ein Audiomischfilter mehrere Eingabestiftinstanzen zu einer einzigen Ausgabestiftinstanz zum Zwecke der Verarbeitung mischen. Alle Eingabeinstanzen sind vom gleichen Typ, und der Filter kann lediglich eine Art von Eingabestift unterstützen. Eine derartige Anordnung ist auch ein Beispiel dafür, mehrere Eingaben für eine einzelne Ausgabe zu verwenden.
Es gilt auch das Umgekehrte, wobei ein Splitterfilter (Auftrennfilter) eine einzelne Eingabeanschlussstiftinstanz besitzen kann, während mehrere Ausgabestiftinstanzen bereitgestellt werden, durch die die Datenstreams vervielfältigt werden. Einem Fachmann auf dem einschlägigen Gebiet erschließt sich, dass vielerlei Abwandlungen und nützliche Kombinationen an dem Verbindungsmechanismus gemäß vorliegender Beschreibung entsprechend der aktuellen Implementierung und den Erfordernissen vorgenommen werden können.
Die Gleichmäßigkeit und Standardisierung, die dadurch erreicht wird, dass von allen zugehörigen Filtern verlangt wird, dass sie einen gemeinsamen Mechanismus (beispielsweise Eigenschaftssätze, Verfahrenssätze und Ereignissätze) unterstützen, die unabhängig von den Treiberentwicklern implementiert werden können, versetzt einen Steuerungsagent in die Lage, zugehörige Filter bequem zu verbinden, die von verschiedenen Softwareherstellern bereitgestellt werden. Darüber hinaus können viele Einrichtungen im Zusammenhang mit Anschlussstifterstellern, die unter bestimmten Umständen von Nöten sind, unteren anderen Umständen nicht von Nöten sein. Die Bestimmung der notwendigen Anschlussstiftinstanzen wird anfänglich von dem Fremdsteuerungsagent vorgenommen, der die tatsächlichen wechselseitigen Verbindungen zwischen den verschiedenen Filtern erstellt.
In 11A ist der Betrieb eines Pufferzuweisungsmechanismus gezeigt, wie er zwischen mehreren Verarbeitungskomponenten verwendet wird. Darüber hinaus ist der Datenfluss (das heißt die tatsächliche Datenübertragung zwischen den Pufferframes) zwischen den Puffern gezeigt, die mit den jeweiligen Verarbeitungskomponenten verbunden sind. Während die Steuerung jede Verarbeitungskomponente ansteuert, werden Daten nur bei Notwendigkeit an bestimmte Verarbeitungskomponenten übertragen, die ihre Datenmanipulationen vornehmen und die Daten an den bestehenden Pufferframe ausgeben. Mit anderen Worten, die Daten können an derselben Stelle verarbeitet werden, ohne dass sie in einen neuen Puffer übertragen werden müssen, was man als "vor Ort" erfolgende Verarbeitung bezeichnet.
Eine Senkenverarbeitungskomponente 210 weist einen Pufferzuweisungsmechanismus 212 (durch ein Quadrat dargestellt) als Teil ihrer Funktionalität auf. Ein Pufferzuweisungsmechanismus ist nur dann in Verarbeitungskomponenten vorhanden, wenn es notwendig ist sicherzustellen, eine bestimmte Anordnung der Daten in dem jeweiligen Speicher zu gewährleisten, so beispielsweise als On-board-Speicher auf einer Ton- oder Videoverarbeitungskarte oder dort, wo der vorherige Puffer unannehmbare Eigenschaften aufweist, so beispielsweise betreffend die Byteausrichtung, die Framegröße und dergleichen mehr. Zudem werden Bezugnahmen bezüglich des Pufferzuweisungsmechanismus, der zum Zuweisen von Frames des Pufferspeichers verwendet werden soll, durch einen Kreis angedeutet, wobei sämtliche Verarbeitungskomponenten derartige Bezugnahmen aufweisen. Man beachte, dass die Quellenverarbeitungskomponente 214 eine Pufferzuweisungsbezugnahme 216 aufweist, die eine Bezugnahme auf die Senkenpufferzuweisungseinrichtung 212, siehe Pfeil 218, darstellt. Darüber hinaus weist die Übertragungsverarbeitungskomponente 220 eine Nullpufferzuweisungseinrichtungsbezugnahme 222 auf, wobei die Senkenverarbeitungskomponente 210 ebenfalls eine Nullpufferzuweisungseinrichtungsbezugnahme, siehe den leeren Kreis 233, aufweist.
Bei diesem einfachen Verarbeitungsbeispiel weist die Quellenverarbeitungskomponente 214 einen Pufferframe 224a durch Verwendung der Senkenpufferzuweisungseinrichtung 212 auf, wobei unter Verwendung der Pufferzuweisungseinrichtungsbezugnahme 216 zugegriffen wird. Der zugewiesene Frame 224a wird von der Quellenverarbeitungskomponente 224, siehe Pfeil 226, mit Daten gefüllt. Man beachte, dass die Quellenverarbeitungskomponente eine bestimmte Datenmanipulation oder Transformation ausführen kann, bevor die Daten in den neuzugewiesenen Frame 224a geschrieben werden.
An diesem Punkt hat die Quellenverarbeitungskomponente 214 die Verarbeitung beendet und lenkt die Steuerung der Verarbeitung auf die Transformationsverarbeitungskomponente 220, siehe Pfeil 228. Die Transformationsverarbeitungskomponente 220 nimmt keine Pufferzuweisung oder Übertragung der Daten von einem Puffer in einen anderen Puffer vor, da kein Pufferzuweisungsmechanismus angezeigt ist, da die Pufferzuweisungseinrichtungsbezugnahme den Nullwert enthält. Daher nimmt die Transformationsverarbeitungskomponente 220 „vor Ort" eine Datentransformation in dem zugewiesenen Pufferframe 224b, siehe Pfeil 230, vor.
Da die Daten nicht in einen neuen Pufferframe übertragen wurden, sind der Pufferframe 224a, der Frame 224b und der Frame 224c die gleichen und werden einfach in Aufeinanderfolge an die verschiedenen Verarbeitungskomponenten gereicht. Der Pfeil 231 stellt das Weiterreichen des zugewiesenen Frames zwischen der Quellenverarbeitungskomponente 214 und der Transformationsverarbeitungskomponente 220 dar.
Schließlich überträgt die Transformationsverarbeitungskomponente die Steuerung der Verarbeitung an die Senkenverarbeitungskomponente 210, wie durch den Pfeil 232 dargestellt ist. Man beachte, dass zusammen mit der Verarbeitungssteuerung derselbe Frame zur Verarbeitung, siehe Pfeil 234, zwischen den Frames 224b und 224c weitergereicht wird. Erneut sind, wie dargestellt ist, der Frame 224a, der Frame 224b und der Frame 224c derselbe Frame, der ursprünglich von der Quellenverarbeitungskomponente 214 zugewiesen wurde, was aus darstellerischen Gründen separat dargestellt ist.
Die Senkenverarbeitungskomponente 210 beendet die Verarbeitung der Daten und gibt den zugewiesenen Frame 224c innerhalb eines Puffers, siehe Pfeil 236, frei. Da die Senkenkomponente 210 den Puffer nicht mehr verwendet, zeigt der Pfeil 236 nach innen auf die Senkenverarbeitungskomponente 210, weshalb der Frame nunmehr neuverwendet oder von der ursprünglichen Zuweisung entbunden werden kann.
11B zeigt, wie ein Pufferzuweisungsmechanismus logisch in dem Schema wechselseitig verbundener Kernelmoduspuffer gemäß vorstehender Beschreibung implementiert werden kann. 11A und 11B zeigen beide die gleiche Filtergraphtopologie und werden verwendet, um den Betrieb des Pufferzuweisungsmechanismus besser verständlich zu machen. Die relevanten Treiber und Teile hiervon weisen jeweils Zugangspunkte auf, die Anwendermodusclients in die Lage versetzen, die Treiber zu steuern, und sind als Dateiobjekte dargestellt. Die wechselseitige Verbindung erfolgt unter Verwendung von IRPs (die von den Kernelmodustreibern oder durch die NT-Exekutive in Reaktion auf Anwendermodus-I/O-Vorgänge erzeugt werden).
Eine Instanz der Quellenverarbeitungskomponente 238 (als Dateiobjekt dargestellt) weist eine damit verbundene Ausgabestiftinstanz 240 (ebenfalls als Dateiobjekt dargestellt) auf, die eine Quelle der Verbindung mit einer anderen Filterinstanz bildet. Eine Eingabestiftinstanz 242, die ein „Kind" eines Transformationsfilters 244 darstellt, wurde mit einer Bezugnahme bezüglich der Ausgabestiftinstanz 240 auf die vorstehend detailliert beschriebene Weise erzeugt. Auf gleiche Weise wird ein Senkenfilter 246 mit einer Eingabestiftinstanz 248 mit einer Ausgabestiftinstanz 250 verbunden, die mit der Transformationsverarbeitungskomponente 244 in Beziehung steht.
Bei dem System wechselseitig verbundener Kernelmodussoftwaretreiber steht ein Pufferzuweisungsmechanismus mit Eingabestiftinstanzen in Beziehung; er ist, so sagt man, an der Eingabestiftinstanz erzeugt oder ausgebildet. Darüber hinaus weisen Ausgabestiftinstanzen logischerweise Bezugnahmen bezüglich eines Pufferzuweisungsmechanismus, so dies notwendig ist, auf, und der Filter mit der Ausgabestiftinstanz nutzt jene Bezugnahme zur Erstellung beliebiger Pufferframezuweisungen und zur Datenübertragung in neue Frames, bevor die Steuerung auf eine andere Verarbeitungskomponente übergeht. Wie bereits erläutert worden ist, gibt eine Nullbezugnahme an, dass keine Da tenübertragung in einen neuen Frame notwendig ist und dass die Verarbeitung in dem bestehenden Frame erfolgen kann (das heißt nach der Verarbeitung werden die Daten an denselben Pufferframe ausgegeben). Ob eine Pufferzuweisungseinrichtungsbezugnahme vorhanden ist, wird von der anfänglichen Analyse des Fremdsteuerungsagenten bestimmt, der den Filtergraph erzeugt hat.
Der Pufferzuweisungsmechanismus, der an einer Eingabestiftinstanz 248 ausgebildet ist, ist durch ein Dateiobjekt dargestellt, während die Strichellinie 254 zeigt, dass die Ausgabestiftinstanz 240 eine Bezugnahme (beispielsweise einen Zeiger oder einen Handle) bezüglich desjenigen Dateiobjektes aufweist, das die Pufferzuweisungseinrichtung 252 darstellt. In dem in 11B gezeigten Beispiel werden Speicherframes aus dem Systemspeicher 256 zugewiesen.
Da die Filter auf zahlreiche verschiedene Weisen wechselseitig verbunden werden können, kann eine Pufferzuweisungseinrichtung notwendig sein, muss jedoch nicht. Ein Dateiobjekt, das eine Instanz einer Pufferzuweisungseinrichtung darstellt, wird nur dann erzeugt, wenn der die Filter wechselseitig verbindende Fremdsteuerungsagent bestimmt, dass dies notwendig ist. Auf diese Weise können die Filter flexibler in vielerlei Konfigurationen verbunden werden und behalten dennoch ihre optimalen Datenübertragungseigenschaften bei. Darüber hinaus können Standardsystempufferzuweisungseinrichtungen verwendet werden, was den Entwicklungsaufwand für Treiberentwickler weiter verringert.
Ein Fremdsteuerungsagent fragt zudem Pufferanforderungen der Anschlussstifte als Teil der Erzeugung eines hypothetischen Modells vor der Erstellung der tatsächlichen Filterverbindungen ab. Während einige Implementierungen Abfragen vor der Stiftinstanzierung zulassen, ist bei dem vorliegenden Ausführungsbeispiel erforderlich, dass die tatsächliche Anschlussstiftinstanz erzeugt wird, bevor die Pufferungsanforderungen sichergestellt werden können. Darüber hinaus erfolgt bei dem als Beispiel angegebenen offenbarten Ausführungsbeispiel die Abfrage durch Verwendung der eingestellten Mechanismen gemäß vorstehender Beschreibung.
Vollendet ein Fremdclient oder Steuerungsagent die wechselseitigen Verbindungen der Kernelmodusfilter zur Erstellung eines Filtergraphen, so wird anschließend eine Analyse der Zuweisungseinrichtungsanforderungen unter Verwendung der Handles der Eingabestiftinstanzen (oder Senkenstiftinstanzen) vorgenommen. Per Konvention definieren die Eingabestiftinstanzen Pufferzuweisungsanforderungen und stellen einen Pufferzuwei sungsmechanismus bereit, während die Ausgabestiftinstanzen eine Bezugnahme bezüglich beliebiger geeigneter Pufferzuweisungsmechanismen besitzen, die mit den Eingabestiftinstanzen verbunden sind. Einem Fachmann auf dem einschlägigen Gebiet erschließt sich, dass andere Konventionen zum Einsatz kommen können, um dieselben Ergebnisse auf effektive Weise zu erreichen, darunter die Umkehrung der Pufferzuweisungszuständigkeiten bezüglich der Eingabe- und Ausgabestiftinstanzen.
Die Pufferzuweisungsanforderungen werden durch Verwendung eines bestimmten Eigenschaftssatzmechanismus sichergestellt, der von allen einschlägigen Filtern unterstützt wird. Man beachte, dass der der „Pufferzuweisungseinrichtung^„ zueigene Eigenschaftssatz auf mehrere verschiedene Weisen, wie dies bei jedem beliebigen anderen Satz ebenfalls möglich ist, organisiert werden kann. So kann beispielsweise der Eigenschaftssatz eine einzelne Eigenschaft aufweisen, wobei die Eigenschaft eine Datenstruktur mit segmentierter Information aufweist, oder der Eigenschaftssatz kann verschiedene Eigenschaften aufweisen, und zwar eine für jedes separate Framinganforderungselement. Eine einzelne Eigenschaft, die sich aus einer Datenstruktur zusammensetzt, ist unter gewissen Umständen effizienter, da weniger Eigenschaftssatzabfragen seitens des Fremdsteuerungsagent notwendig sind, um sämtliche Framinganforderungsinformation abzufragen. Darüber hinaus kann eine einzelne Datenstruktur nicht nur zur Abfrage der Anforderungsinformation, sondern auch zur Spezifizierung von Parametern, wenn ein tatsächliche Pufferzuweisungseinrichtung erzeugt wird, verwendet werden.
Die nachstehende Tabelle zeigt eine nicht abschließende Liste von Framinganforderungselementen, die in einer Datenstruktur oder einzelnen Eigenschaften enthalten sein kann. Zudem sind Erläuterungen angegeben, wie ein derartiges Element bei dem als Beispiel angegebenen Ausführungsbeispiel zum Einsatz kommen kann.
Tabelle 3
Fachleuten auf dem einschlägigen Gebiet erschließt sich, dass andere relevante Framingeigenschaften vorhanden sind, die mitaufgenommen werden können. Darüber hinaus arbeitet der hier beschriebene Pufferzuweisungsmechanismus im Wesentlichen auf dieselbe Weise, unabhängig davon, ob mehr Pufferframeelemente als in Tabelle 3 spezifiziert miteinbezogen sind, oder ob ein Untersatz des Spezifizierten implementiert ist.
Sind die Filtergraphanforderungen von dem Fremdsteueragenten bestimmt, so können die zugehörigen Kernelmoduspufferzuweisungseinrichtungen an den zugehörigen Eingabeanschlussstiftinstanzen erzeugt werden. Der Client erzeugt eine Pufferzuweisungseinrichtungsinstanz unter Verwendung des Handles der zugehörigen Anschlussstiftinstanz und durch Spezifizieren der zugehörgen Erzeugungsparameter für die Pufferzuweisungseinrichtung. Auf diese Weise ist das sich ergebende Dateiobjekt, das eine Pufferzuweisungseinrichtung darstellt, ein Kind der Anschlussstiftinstanz und verwendet die Kontextinformation aus diesem Dateiobjekt und das Dateiobjekt, das die Instanz des Filters selbst darstellt, für seine eigene Erzeugung.
Mit anderen Worten, es wird derselbe Mechanismus, der oben zur Validierung der Erzeugung einer Anschlussstiftinstanz und zum Routen von Nachrichten an die jeweiligen Handles für eine gegebene Anschlussstiftinstanz beschrieben worden ist, auf gleiche Weise auf die Erzeugung einer Instanz einer Pufferzuweisungseinrichtung angewandt. Erneut wird der NtCreateFile-Aufruf in einen einer höheren Ebene zugehörigen Funktionsaufruf als Teil einer API eingewickelt, worauf dann von Seiten eines Fremdsteueragent zugegriffen werden kann.
Wenn überhaupt, so werden in dem vorliegenden Ausführungsbeispiel die Pufferzuweisungseinrichtungsinstanzen nur an Eingabestiftinstanzen erzeugt. Wird ein Pufferzuweisungseinrichtungsinstanzhandle nicht bezüglich eines Ausgabeanschlussstiftinstanzhandles über einen geeigneten API-Aufruf erzeugt, so kann der Filter davon ausgehen, dass das über die Stream-I/O-Steuerungen vorgelegte Streamsegment die Filteranforderungen erfüllt, und kann die Daten vor Ort nach Belieben modifizieren.
Eine systemeigene Standardzuweisungseinrichtung kann von Filterentwicklern verwendet werden, um die Aufgabe der Bereitstellung von Pufferzuweisungsfähigkeiten für Eingabeanschlussstiftinstanzen zu vereinfachen. Die Standardzuweisungseinrichtung stellt für einen Systemspeicher Pufferframezuweisungen für diejenigen Vorrichtungstreiber bereit, die in der Lage sind, Daten aus dem Systemspeicher zu übertragen, die jedoch spezifische Speicherzuweisungseigenschaften erfordern. Durch Verwendung der Standardpufferzuweisungseinrichtung wird ein Filterentwickler von der Aufgabe entlastet, Code zur Bewerkstelligung der Pufferzuweisung in der Praxis zu entwickeln. Der Filter wird dennoch geschrieben, um die Anfrage betreffend die Pufferzuweisungsanforderungen durch eine Unterstützung des geeigneten Eigenschaftssatzes zu unterstützen.
Zur Verwendung der Standardzuweisungseinrichtung stellt der Filterentwickler (1) Code bereit, um auf die Anfrage betreffend die Pufferzuweisungseinrichtung zu reagieren und (2) platziert eine Standardzuweisungseinrichtungserzeugungshandlerbezugnahme in der Validierungstabelle der jeweiligen Anschlussstiftinstanz, zu der die Standardzuweisungseinrichtung gehört. Mit anderen Worten, wenn eine Erzeugungsanfrage für einen Zuweisungseinrichtungstypmechanismus von einem Filter vorgelegt wird, wird ein spezifischer GUID-String in der Validierungstabelle gematcht, der wiederum den Zugriff auf den Standardzuweisungseinrichtungserzeugungshandler ermöglicht.
Die Standardpufferzuweisungseinrichtung bedient sich des Systemspeichers und arbeitet entsprechend den Pufferzuweisungseinrichtungsstreamingeigenschaften, die als Teile der Erzeugungsanfrage vorgelegt worden sind. Es ist wahrscheinlich, dass eine derartige Standardzuweisungseinrichtung von verschiedenen Transformationsfiltern verwendet wird, und zwar in Abhängigkeit von deren jeweiliger Funktion und Reihenfolge.
Filter, die Pufferzuweisungseinrichtungen für einen On-board-Speicher oder andere vorrichtungsabhängige Speicherverfahren benötigen, können eine spezifische Pufferzuweisungseinrichtung durch Unterstützung eines Pufferzuweisungseinrichtungseigenschaftssatzes und eines Verfahrenssatzes bereitstellen. Für eine filterspezifische Zuweisungseinrichtung ist der Filter für die Bereitstellung von Programmcodes zur Implementierung der kompletten Funktionalität zuständig. Der Betrieb der Pufferzuweisungseinrichtungen ist jedoch für jede Pufferzuweisungseinrichtung gleich, sei sie nun standardmäßig oder filterspezifisch, sodass Fremdagenten die Filter und Pufferzuweisungseinrichtungen korrekt wechselseitig verbinden können.
Das Dateiobjekt, das die Pufferzuweisungseinrichtung darstellt, enthielt bei erfolgreicher Erzeugung im Dateikontextbereich einen Zeiger auf eine Datenstruktur. Diese Datenstruktur enthält eine Lenktabelle zum Leiten von IRPs zu den bezeichneten Handlern auf Basis der verschiedenen IRP-Codes (das heißt Erzeugen, I/O-Steuerungen und dergleichen mehr) wie auch andere Datenbereiche und Strukturen zum Erhalten des Zustandes der Pufferzuweisungseinrichtung. Bestimmte implementierungsabhängige Information, die verfolgt werden kann, umfasst eine Bezugnahme auf das Dateiobjekt der Anschlussstiftinstanz, zu der die Pufferzuweisungseinrichtung gehört, eine Bezugnahme auf Zuweisungsframinganforderungsdatenstrukturen, eine Ereignisschlange derjenigen Clients, die auf Ereignisse warten, eine Schlange derjenigen Zuweisungsanfragen (die beispielsweise von IRP empfangen worden sind), die bereitstehen (outstanding), und dergleichen mehr.
Es gibt zwei Schnittstellen oder Arten der Kommunikation, die für den Pufferzuweisungsmechanismus gemäß Offenbarung im Zusammenhang mit dem vorliegenden Ausführungsbeispiel zur Verfügung stehen. Zunächst müssen sämtliche Zuweisungseinrichtungen die IRP-basierte Schnittstelle bereitstellen, um mit den Anwendermodusclients geeignet zu kommunizieren. Optional kann für den Fall, dass der Zuweisungspooltyp auf der Lenkebene (eine höhere Prioritätsebene, auf der ein begrenzter Untersatz von Diensten zur Verfügung steht, aber auf dem Aufgaben niedrigerer Priorität an jenem Prozessor gesperrt werden) des Betriebssystems bedient werden kann, eine Funktionstabellenschnittstelle unterstützt werden, die wechselseitig verbundene Filter in die Lage versetzt, Direktfunktionsaufrufe (während der DPC-Verarbeitung) zu verwenden, um zu einer höheren Leistung zu gelangen. Dies ermöglicht die Mitteilung von Ereignisbenachrichtigungen zwischen den miteinander verbundenen Filtern ohne einen zusätzlichen Oberhead beim IRP-Durchleiten durch den I/O-Manager oder beim Planen eines Ausführungsthreads und beim Warten auf eine Kontextschaltung.
Die IRP-basierte Schnittstelle verarbeitet sukzessive IRPs auf nachfolgende Weise. Liegt eine Zuweisungsanfrage vor, so vollendet die Pufferzuweisungseinrichtung die Anfrage und gibt einen Zeiger bezüglich eines zugewiesenen Pufferframes aus, oder, wenn sämtliche Frames zugewiesen worden sind, markiert die Zuweisungseinrichtung die noch anhängige IRP und fügt die IRP der Zuweisungsanfrageschlange zum Zwecke der weiteren Verarbeitung in einer annähernden FIFO-Reihenfolge hinzu. Zum Schluss gibt die Pufferzuweisungseinrichtung den Status „anhängig" an den Aufrufer aus.
Ist ein Pufferframe für die Zuweisungseinrichtung verfügbar, so versucht die Zuweisungseinrichtung, die erste Anfrage in der Anfrageschlange für die IRP-basierte Schnittstelle abzuarbeiten. Jene IRPs, die vorher nicht bedient werden konnten, verbleiben in der Anfrageschlange und warten auf den nächsten freigegebenen Frame zum Zwecke der Verarbeitung. Andernfalls wird für den Fall, dass kein Auftrag in der Anfrageschlange verblieben ist, der Frame an die Freigabeliste übergegeben.
Die Lenkebenenschnittstelle arbeitet unter Verwendung der Direktfunktionsaufruftabelle auf folgende Weise. Wird eine Zuweisungsanfrage durch Tätigen eines Funktionsaufrufes (was während einer DPC erfolgen kann) vorgelegt, so gibt die Zuweisungseinrichtung einen Zeiger an den Frame aus, wenn einer verfügbar ist, oder sie gibt unmittelbar „0" aus. Der Kernelmodusanfrager kann dann auf eine freie Ereignisbenachrichtigung warten, wodurch er in Kenntnis gesetzt wird, dass ein freier Frame verfügbar ist. Bei Empfang dieser Benachrichtigung versucht der Kernelmodusanfrager die Zuweisungsanfrage erneut.
Man beachte, dass es sowohl für die Lenkebenenschnittstelle wie auch für die IRP-basierte Schnittstelle möglich ist, um einen verfügbaren freien Frame in Wettbewerb zu treten. Sind zudem Zuweisungsanfrage-IRPs vorhanden, die auf ihre Abarbeitung in der Anfrageschlange warten, so muss die Zuweisungseinrichtung ebenfalls einen Arbeitsein satz planen, wenn die aktuelle IRQL nicht auf der passiven Ebene ist, wenn der Aufrufer ein Framing freigibt, da die Verwendung der Direktaufrufschnittstelle die Möglichkeit impliziert, sich auf der DPC-Ebene zu befinden. Im Wesentlichen besitzt die IRP-Warteschlange keine Kenntnis über den freien Frame, bis der Arbeitseinsatz zum Laufen kommt.
Darüber hinaus ist der Pufferzuweisungsmechanismus gemäß vorliegender Erläuterung auch für einen Einsatz mit MDLs (memory descriptor lists) anwendbar, um Übertragungen zwischen den Puffern weiter zu verringern. Eine derartige Implementierung erlaubt eine weitergehende nahtlose Wechselwirkung zwischen den Systemspeichereinrichtungen des NT-Betriebssystems.
12 zeigt das System wechselseitig verbundener Filter gemäß 9A und 9B, wobei der hier offenbarte Pufferzuweisungsmechanismus zum Einsatz kommt. Sobald der Steuerungsagent 170 die wechselseitigen Verbindungen zwischen den Filtern erstellt hat, nimmt er eine Abfrage bei jeder Eingabestiftinstanz nach deren Pufferanforderungen vor. Wie gezeigt, benötigt der Tonwandlungsfilter 178 die Zuweisung der Pufferframes aus dem Soundkartenspeicher 258, während der Dekompressorfilter 174 Speicher aus dem Systemspeicher 260 zuweist, der die Daten direkt aus dem Plattenlaufwerk 262 erhält.
Der Steuerungsagent 170 erzeugt eine Pufferzuweisungseinrichtung 264, die von einem Dateiobjekt dargestellt und an der Eingabestiftinstanz 188 ausgebildet wird. Die Pufferzuweisungseinrichtung 264 weist Pufferframes aus dem Soundkartenspeicher 258 zu, und es wird eine Bezugnahme bezüglich der Pufferzuweisungseinrichtung 264 in der Ausgabestiftinstanz 204, wie durch die gestrichelte Linie 266 dargestellt ist, versendet. Diese Bezugnahme ist der Handle zu dem Dateiobjekt, das die Pufferzuweisungseinrichtung 264 darstellt, und wird durch den Dekompressorfilter 274 zum Zwecke der Zuweisung von Pufferzuweisungseinrichtungen je nach Bedarf vor einer Übertragung der Daten in den neuen Puffer verwendet.
Auf gleiche Weise wird die Pufferzuweisungseinrichtung 268 ebenfalls durch ein Dateiobjekt dargestellt und an einer Eingabestiftinstanz 206 erzeugt oder ausgebildet. Diese Pufferzuweisungseinrichtung 268 verwaltet die Zuweisung des Systemspeichers 260. Der Steuerungsagent 170 speichert nach der Erstellung der Pufferzuweisungseinrichtung 268 eine Bezugnahme hiervon in der Ausgabestiftinstanz 208, wie durch die gestri chelte Linie 270 dargestellt ist. Erneut ist die Pufferzuweisungseinrichtung 268 für die Zuweisung von Pufferframes in dem Systemspeicher 260 zuständig, damit Daten dort hinein von der Platte 262 aus übertragen werden können.
Der Steuerungsagent setzt ebenfalls einen Nullwert für die Pufferzuweisungseinrichtungsbezugnahme der Ausgabestiftinstanz 192, um hierdurch anzugeben, dass eine vor Ort erfolgende Transformation vorgenommen wird, wobei die Effektefilter 146 die Daten aus dem bestehenden Puffer in den Soundkartenspeicher 258 lesen und die Daten zurück in den Soundkartenspeicher 258 verbringen, nachdem eine beliebige Transformationen oder ein sonstiger Effekt daran vollzogen worden sind. Alternativ wird für den Fall, dass der Steuerungsagent die Pufferzuweisungseinrichtungsbezugnahme nicht setzt, davon ausgegangen, dass ein Nullwert vorliegt und eine vor Ort erfolgende Transformation erfolgt.
In dem Flussdiagramm von 13 und dem logischen Diagramm von 12 ist der Betrieb der Pufferzuweisungseinrichtungen dargestellt. Dieser Prozess tritt nach der Erstellung der wechselseitigen Verbindungen auf, wobei die Streamlese- und Schreibvorgänge von dem Steuerungsagent 170 an den Leserfilter 172 gegeben werden.
Anfänglich weist der Leserfilter 172 einen Frame in dem Systemspeicher unter Verwendung der dem Dekompressorfilter 174 zueigenen Pufferzuweisungseinrichtung 268 bei Schritt 272 zu. Die Ausgabestiftinstanz 208 des Leserfilters 172 weist einen Handle bezüglich desjenigen Dateiobjektes auf, das die Pufferzuweisungseinrichtung 268 darstellt, was durch die Linie 270 dargestellt ist, und hat daher direkten Zugriff auf die Steuerung der Pufferzuweisungseinrichtung 268.
Sobald der Dateileserfilter 172 Zugriff auf ein tatsächliches Pufferframe in dem Systemspeicher 260 hat, erfolgt eine Füllung des Frames mit Daten von der Platte 262 aus, was durch den Pfeil 274 bei Schritt 276 dargestellt ist. Man beachte, dass der Leserfilter 172 eine Transformation oder eine andere Manipulation an den Daten vornehmen kann, wenn er diese in den Systemspeicher 260 verbringt.
Der Dateileserfilter 172 initiiert anschließend einen Streamschreibvorgang für den Dekompressorfilter 174 bei Schritt 278. Dieser Streamschreibvorgang wird mittels IRP durch den I/O-Manager weitergeleitet. Bei Schritt 280 weist der Dekompressorfilter 174 einen Frame des Soundkartenspeichers 258 unter Verwendung der Pufferzuweisungs einrichtung 264 zu. Der Dekompressorfilter 174 hat Kenntnis von der Pufferzuweisungseinrichtung 264, da ein Handle hierfür bezüglich der Ausgabestiftinstanz 204 gespeichert worden ist.
Der Dekompressorfilter 174 dekomprimiert die Daten und überträgt die Daten in den Frame, der vorher in dem Soundkartenspeicher 278 zugewiesen worden ist, was durch den Pfeil 284 dargestellt ist. Man beachte, dass bei der Dekomprimierung der Daten mehr Frames aus dem Soundkartenspeicher zugewiesen werden können, als tatsächlich in dem Systemspeicher vorhanden sind. Dieses zusätzliche Verhältnis von Puffertrames ist notwendig, um dem Dekompressionseffekt an den Daten gerecht zu werden.
Es ist wichtig, sich der Tatsache gewahr zu werden, dass bei der Übertragung von Daten aus einem Puffer in einen anderen Puffer mit Blick auf die Menge der übertragenen Daten keine Eins-zu-Eins-Entsprechung gegeben sein muss. Mit anderen Worten, der empfangende Puffer kann mehr oder weniger Raum (oder Frames) erfordern, was von der Natur der Filterung oder der Transformation abhängt, die während der Pufferübertragung vorgenommen wird.
Sobald der Dekompressorfilter 174 die Dekompression eines bestimmten Frames beendet hat, leitet er den Streamschreibvorgang an den Effektefilter 276 unter Verwendung der Einrichtungen des NT-I/O-Managers weiter. Der Effektefilter 176 empfängt den Streamschreib-IRP bei Schritt 288 und verarbeitet die Daten vor Ort in dem bestehenden Soundkartenspeicher 258. Eine derartige Effekteverarbeitung entspricht üblicherweise einer Eins-zu-Eins-Ersetzung der Daten, sodass sich weder ein größerer noch ein kleinerer Bedarf an Pufferspeicher ergibt.
Sobald die Effektefilter 176 die Verarbeitung der Daten beendet haben, wird ein Streamschreib-IRP an den Tonwandlungsfilter bei Schritt 290 übergeben. Erneut ist der Mechanismus, der die Übertragung des Streamschreib-IRP an den Tonwandlungsfilter 178 veranlasst, die NT-I/O-Managereinrichtung, die von dem Effektefilter 176 aufgerufen wird.
Schließlich empfängt der Tonwandlungsfilter 178 den Streamschreib-IRP bei Schritt 282 und steuert die Soundkartenhardware, um die tatsächliche Wandlung der Tondaten, die in dem Soundkartenspeicher 268 vorhanden sind, vorzunehmen. An diesem Punkt können die Soundkartenpufferframes, die vorher zugewiesen worden sind, neuverwendet werden, um Schreibanfragen zu bedienen, oder sie können freigegeben werden, wenn keine bereitstehenden Anfragen vorliegen. Die Verfügbarkeit eines Pufferframes wird dem Dekompressorfilter 174 mitgeteilt, sodass beliebige wartende Streamschreibvorgänge verwendet werden können, um Daten zu verarbeiten und in den frei zugewiesenen Puffertrames zu platzieren. Auf gleiche Weise werden die Puffertrames des Systemspeichers 260 entweder neuverwendet oder freigegeben.
Einem Fachmann auf dem einschlägigen Gebiet erschließt sich, dass die Verfahren der vorliegenden Erfindung als Computeranweisungen verkörpert sein können, die in einem Computerprogrammcodemittel auf einem computerlesbaren Medium, so beispielsweise einer magnetischen Platte, einer CD-ROM oder einem anderen im Stand der Technik gängigen oder noch zu entwickelnden Medium, abgelegt werden können. Darüber hinaus können wichtige Datenstrukturen, die in einem Computerhardwarespeicher vorgefunden werden, aufgrund des Betriebs derartiger Computerprogrammcodemittel erstellt werden.

Claims

Verfahren zum Übertragen von Daten von einem vorhandenen ersten Puffer (260), der mit einer ersten Verarbeitungskomponente (174) verbunden ist, zu einem zweiten Puffer (258), der mit einer zweiten Verarbeitungskomponente (178) verbunden ist, um Verarbeitung der Daten zu ermöglichen, wobei die Daten sequenziell durch die erste Verarbeitungskomponente, gefolgt von einer dritten Verarbeitungskomponente (176) und dann der zweiten Verarbeitungskomponente verarbeitet werden, sich die Puffer-Anforderungen der ersten Verarbeitungskomponente von denen der zweiten und der dritten Verarbeitungskomponente unterscheiden, die die gleichen Puffer-Anforderungen haben, in der zweiten Verarbeitungskomponente eine Puffer-Zuweisungseinrichtung (264) vorhanden ist, um Datenpuffer entsprechend den Anforderungen der zweiten Verarbeitungskomponente zu erzeugen und zu verwalten, und das Verfahren die folgenden Schritte umfasst: Zuweisen des zweiten Puffers unter Verwendung der Puffer-Zuweisungseinrichtung, die in der zweiten Verarbeitungskomponente vorhanden ist, Verarbeiten der Daten in dem vorhandenen Puffer und dann Übertragen der verarbeiteten Daten zu dem zweiten Puffer durch die erste Verarbeitungskomponente; Verarbeiten der Daten in dem zweiten Puffer durch die dritte Verarbeitungskomponente; und Verarbeiten der Daten in dem zweiten Puffer durch die zweite Verarbeitungskomponente.
Verfahren nach Anspruch 1, wobei die zweite Verarbeitungskomponente (178) auf Abfragen ihrer Puffer-Anforderungen reagiert.
Verfahren nach Anspruch 1, wobei die Puffer-Zuweisungseinrichtung (264), die in der zweiten Verarbeitungskomponente (178) vorhanden ist, Verwaltung von Puf fern durch Implementieren eines eindeutig identifizierten Satzes von Verfahren zulässt.
Verfahren nach Anspruch 1, wobei die Puffer-Zuweisungseinrichtung (264), die in der zweiten Verarbeitungskomponente (178) vorhanden ist, relevante Benachrichtigung über den Puffer-Status bereitstellt.
Verfahren nach Anspruch 1, wobei die Puffer-Zuweisungseinrichtung (264), die in der zweiten Verarbeitungskomponente (178) vorhanden ist, Status und Steuerung von Puffern bereitstellt.
Verfahren nach Anspruch 1, wobei die Puffer-Zuweisungseinrichtung (264), die in der zweiten Verarbeitungskomponente (178) vorhanden ist, Status und Steuerung von Puffern durch Implementieren eines eindeutig identifizierten Satzes von Eigenschaften bereitstellt.
Verfahren nach Anspruch 1, wobei die erste (174), die zweite (178) und die dritte (176) Verarbeitungskomponente separate Kernelmodus-Softwaretreiber sind.
Verfahren nach Anspruch 7, wobei jeder Treiber (174, 178, 176) eine oder mehrere Anschlussstift-Instanzen (188, 192, 202, 204) zum Anschließen der Treiber hat und jede Anschlussstift-Instanz eines Treibers ein Kind-Objekt eines der Treiber ist und zur Datenübertragung zwischen den Treibern dient.
Verfahren nach Anspruch 8, wobei die Puffer-Zuweisungseinrichtung (264) der zweiten Verarbeitungskomponente (178) ein Kind-Objekt der Anschlussstift-Instanz (188) der zweiten Verarbeitungskomponente ist und zum Zuweisen von Puffern dient.
Verfahren nach den Ansprüchen 8 und 9, wobei jede Anschlussstift-Instanz (188, 192, 202, 204) durch ein Datei-Objekt (174) dargestellt wird und die Kind-Beziehung durch Spezifizieren des zugehörigen Treibers (174, 178, 176) erzeugt wird, auf den Treiber als ein Datei-Objekt (70) einer I/O-Vorrichtung, die in dem System verfügbar ist, während Erzeugung des Datei-Objektes der Anschlussstift-Instanz Bezug genommen wird und jede Puffer-Zuweisungseinrichtung durch ein Datei-Objekt dargestellt wird und die Kind-Beziehung zu einer Anschlussstift-Instanz erzeugt wird, indem das zugehörige Datei-Objekt der Anschlussstift-Instanz während der Erzeugung des Datei-Objektes der Puffer-Zuweisungseinrichtung als ein Eltern-Objekt spezifiziert wird.
Verfahren nach den Ansprüchen 8 und 9, wobei wenigstens eine der einen oder mehreren Anschlussstift-Instanzen (188, 192, 202, 204) an den Treibern (174, 178, 176) wenigstens einen vordefinierten Satz von Eigenschaften, einen Satz von Verfahren und einen Satz von Ereignissen unterstützt, um einer Fremd-Komponente (170) die Puffer-Anforderungen der wenigstens einen Anschlussstift-Instanz anzuzeigen und zuzulassen, dass die Fremd-Komponente die Puffer-Zuweisungseinrichtung (264) an jeweiligen Anschlussstift-Instanzen bildet, und die jeweiligen Puffer-Zuweisungseinrichtungen wenigstens einen vordefinierten Satz von Eigenschaften, einen Satz von Verfahren und einen Satz von Ereignissen unterstützen, um die jeweiligen Puffer-Zuweisungseinrichtungen zu steuern und so Daten-Puffer je nach Erfordernis, wie durch die Fremd-Komponente bestimmt, zuzuweisen und zu verwalten.
Datenverarbeitungssystem, das umfasst: eine Datenverarbeitungsvorrichtung; und eine Speichervorrichtung, die mit der Datenverarbeitungsvorrichtung kommuniziert und Computerprogrammcode speichert, der so eingerichtet ist, dass er das Verfahren nach einem der Ansprüche 1 bis 11 bereitstellt.
Computerprogrammcode, der durch einen Computer ausgeführt werden kann, um das Verfahren nach einem der Ansprüche 1 bis 11 bereitzustellen oder eine Datenverarbeitungsvorrichtung nach Anspruch 12 bereitzustellen.
Computerprogrammerzeugnis, das ein computerlesbares Medium umfasst, wobei das computerlesbare Medium Computerprogrammcode nach Anspruch 13 enthält.