Anbindung des Network-File-Systems an den Virtual-File-System-Layer der SB-PRAM

Anbindung des Network-File-Systems an den Virtual-File-System-Layer der SB-PRAM

Fort­geschrit­te­nen­prak­tikum von
ALEXANDER LEIDINGER
Alexander@Leidinger.net

Herun­ter­laden dieser Ausar­beitung als kom­prim­ierte Post­script Datei.

Inhalt

  • Inhalt
  • 1. Ein­leitung
  • 2. PRAMOS – Hostrechner-Kommunikation 
    • 2.1 Grund­la­gen
    • 2.2 Modul-Struktur
    • 2.3 Mehrere MTRP-Queues
    • 2.4 Über­ar­beitung der Module
  • 3. Das NFS-Modul 
    • 3.1 Grund­la­gen
    • 3.2 Struk­tur
    • 3.3 Über­sicht über die Funk­tion­sweise des NFS-Moduls
    • 3.4 Abar­beitung ein­er NFS-Anfrage der SB-PRAM anhand eines Beispiels
    • 3.5 VFS-Funktionen ohne direk­tes NFS-Äquivalent
  • 4. Aus­blick
  • A. Neue MTRP-Queue Funktionen 
    • A.1 Gemein­sam genutzte Daten­struk­tur6
    • A.2 SB-PRAM-Seite9
    • A.3 Host­seite12
  • B. NFS-Modul
    • B.1 Star­tup­pro­tokoll zwis­chen NFS-Modul und Hostprogramm
    • B.2 MTRP-Requests für das NFS-Modul
  • C. Uni­versell ein­set­zbare Datenstrukturen 
    • C.1 PRAMOS15
    • C.2 Host18
  • D. Glos­sar
    • D.1 Dateisystem-spezifisch
    • D.2 SB-PRAM-spezifisch
  • Abbil­dungsverze­ich­nis
  • Lit­er­atur

1. Ein­leitung

Die SB-PRAM ist ein exper­i­menteller shared-memory Par­al­lel­rech­n­er [1], der das PRAM-Modell (par­al­lel ran­dom access machine) der the­o­retis­chen Infor­matik [2, 3] real­isiert. Die SB-PRAM unter­schei­det sich von anderen shared-memory Rech­n­ern dadurch, daß mehrere Pro­gramme par­al­lel in kon­stan­ter Zeit auf den Inhalt der­sel­ben Spe­icherzelle zugreifen kön­nen. Die Hardware

Abbil­dung 1: Die SB-PRAM.
PRAM

der SB-PRAM (Abbil­dung 1) beste­ht aus dem eigentlichen PRAM Par­al­lel­rech­n­er und einem Hostrech­n­er. Die PRAM ist hier­bei über das Hostin­ter­face an den Hostrech­n­er angeschlossen, der im laufend­en Betrieb der SB-PRAM als IO-Schnittstelle (ähn­lich einem Mon­i­tor, ein­er Tas­tatur und ein­er Net­zw­erkkarte bei einem nor­malen Rech­n­er) dient. Der Hostrech­n­er ist ein PC mit einem han­del­süblichen UNIX-Betriebssystem, der an ein IP-Netzwerk angeschlossen ist.

Das Betrieb­ssys­tem der SB-PRAM ist eine Eige­nen­twick­lung die aus zwei Teilen beste­ht, dem Host­pro­gramm [4] und dem PRAMOS [5]. Die Funk­tion­al­ität des Host­pro­gramms wird durch Mod­ule erweit­ert, die wie das Host­pro­gramm als eigen­ständi­ge Pro­gramme auf dem Hostrech­n­er ablaufen. Das Host­pro­gramm ist für das Ini­tial­isieren der PRAM zuständig, erledigt das Laden und Starten von Pro­gram­men auf der SB-PRAM und startet bei Bedarf von der PRAM ges­teuert Mod­ule auf dem Hostrechner.

Das PRAMOS läuft direkt auf der PRAM und stellt den Anwen­dung­spro­gram­mier­ern eine UNIX-ähnliche Pro­gram­mierumge­bung zur Ver­fü­gung. Sobald ein Pro­gramm vom Host­pro­gramm ges­tartet wird, übern­immt das PRAMOS das Kom­man­do über die SB-PRAM und das Host­pro­gramm hat nur noch IO-Operationen durchzuführen.

Als logis­che Datenüber­tra­gungschicht zwis­chen bei­den Teilen des SB-PRAM Betrieb­ssys­temes (PRAMOS, Host­pro­gramm) dient ein Kom­mu­nika­tion­spro­tokoll; das Mem­o­ry Trans­fer Request Pro­tokoll (MTRP) [4, Kapi­tel 3]. Ges­teuert und ini­ti­iert wird das MTRP vom PRAMOS.

Da ein Anwen­dungs­ge­bi­et für die SB-PRAM die Nutzung als Daten­bankserv­er ist und eine Daten­bank ihre Dat­en über­wiegend auf Fest­spe­ich­ern lagert, wurde auch der Zugriff auf Dateisys­teme im PRAMOS vorge­se­hen. Ein Dateisys­tem stellt für den Zugriff üblicher­weise eine Pro­gram­mier­schnittstelle zur Ver­fü­gung (z.B. die UNIX Dateisystem-Zugriffsfunktionen), die das Öff­nen, Schließen, Lesen, Schreiben und Löschen von Dateien und Verze­ich­nis­sen ermöglicht.

Die ursprüngliche Imple­men­tierung des Dateisys­temzu­griffes ermöglichte den Zugriff auf das SB-PRAM eigene Dateisys­tem (SB-PRAM FS) und auf das Dateisys­tem des Hostrech­n­ers (Host-FS). Ein Nachteil dieser Imple­men­tierung waren die unter­schiedlichen Pro­gram­mier­schnittstellen für die jew­eili­gen Dateisys­teme. Ein Applikations-Programmierer hat­te deshalb für jede Art von Dateisys­tem spezielle Zugriffs­funk­tio­nen zu ver­wen­den. Ein weit­er­er Nachteil war, daß z.B. /foo/bar und /example/../foo/bar physikalisch dieselbe Datei auf dem Spe­icher­medi­um beze­ich­nen, bei­des jedoch für das PRAMOS logisch zwei ver­schiedene Dateien darstell­ten. Es kon­nte dadurch geschehen, daß das Betrieb­ssys­tem /example/../foo/bar nicht als gelöscht ansah, wenn /foo/bar gelöscht wurde. Ein Zugriff mußte deshalb durch absolute Ref­eren­zierung von Dateien erfol­gen, eine Ref­eren­zierung rel­a­tiv zum aktuellen Verze­ich­nis war nicht möglich.

Um die oben ange­sproch­enen Nachteile zu beseit­i­gen, wurde par­al­lel zu diesem Fort­geschrit­te­nen­prak­tikum das Vir­tu­al File Sys­tem (VFS) [8] als Pro­gram­mier­schnittstelle imple­men­tiert. Es abstrahiert

Abbil­dung 2: VFS Schnittstelle
PRAMOS_VFS

von der Imple­men­tierung und stellt dateisys­temüber­greifende Funk­tio­nen zur Ver­fü­gung (UNIX-Dateisystem-Zugriffsfunktionen). Der Applikations-Programmierer hat durch diese Abstrahierung nur die UNIX-Dateisystem-Zugriffsfunktionen zu beacht­en. Das VFS übern­immt die Auf­gabe, die für das jew­eilige Dateisys­tem richti­gen Zugriffs­funk­tio­nen aufzu­rufen (Abbil­dung 2).

Ziel dieses Fort­geschrit­te­nen­prak­tikums war es, eine Anbindung des Hostrechner-Dateisystems an die VFS-Schicht des PRAMOS zu real­isieren. Da eine Änderung des Host-FS wäre ähn­lich aufwendig gewe­sen, wie eine kom­plette Neupro­gramierung, wurde nach ein­er alter­na­tiv­en Imple­men­tierungsmöglichkeit gesucht, die eine größere Funk­tion­al­ität zur Ver­fü­gung stellt. Es wurde das Net­work File Sys­tem (NFS) [7] für eine Imple­men­tierung gewählt.

Das NFS ermöglicht den Zugriff auf beliebige Dateis­erv­er in einem IP-Netzwerk. Ins­beson­dere kann auch auf den Hostrech­n­er zuge­grif­f­en wer­den. Durch die Wahl des NFS kann, ohne nen­nenswerten Mehraufwand bei der Imple­men­tierung, eine weitaus größere Funk­tion­al­ität zur Ver­fü­gung gestellt wer­den, da nicht nur auf das Dateisys­tem des Hostrech­n­ers zuge­grif­f­en wer­den kann.

Imple­men­tiert wurde der Zugriff auf das NFS in einem Mod­ul des Host­pro­grammes. Dabei wurde die Struk­tur der Mod­ule grundle­gend über­ar­beit­et. In der ursprünglichen Imple­men­tierung der Mod­ule mußte für jedes neu pro­gram­mierte Mod­ul das Host­pro­gramm in großen Teilen über­ar­beit­et wer­den. Desweit­eren kon­nte das PRAMOS nicht mit einzel­nen Instanzen eines Mod­ules direkt kom­mu­nizieren, son­dern mußte das Host­pro­gramm als Ver­mit­tler benutzen. Um diese Nachteile zu beheben, entsch­ieden wir uns dazu, die Imple­men­tierung der Mod­ule dahinge­hend zu über­ar­beit­en, daß das Host­pro­gramm keine Ken­nt­nis über die Funk­tion­al­ität der Mod­ule haben, und auch nicht als Ver­mit­tler zwis­chen PRAMOS und einem Mod­ul agieren mußte.

Die vor­liegende Arbeit ist wie fol­gt gegliedert: In Kapi­tel 2 wird erläutert, wie die Funk­tion­al­ität der PRAMOS – Hostrech­n­er Kom­mu­nika­tion (MTRP/Module) erweit­ert wurde. In Kapi­tel 3 wird die Anbindung des NFS an die SB-PRAM erläutert. In Kapi­tel 4 wird ein Aus­blick über die Aus­baumöglichkeit­en der NFS-Anbindung gegeben. Im nach­fol­gen­den Anhang find­et sich eine Ref­erenz der neuen bzw. geän­derten Funk­tio­nen im PRAMOS inklu­sive ein­er Kurzbeschrei­bung der jew­eili­gen Funk­tion­al­ität, Über­gabepa­ra­me­ter und Rückgabewerte.

2. PRAMOS – Hostrechner-Kommunikation

2.1 Grund­la­gen

Die Grund­lage der PRAMOS – Hostrechner-Kommunikation ist das Mem­o­ry Trans­fer Request Pro­tokoll (MTRP) [4, Kapi­tel 3]. Es ermöglicht dem PRAMOS das Aus­führen von Funk­tio­nen auf dem Hostrech­n­er (Remote Pro­ce­dure Calls, RPC). Dazu wer­den Funk­tion­saufrufe und Para­me­ter (MTRP-Requests) vom PRAMOS an die Host­seite des SB-PRAM-Betriebssystems (Hostprogramm/Module) geschickt. Die MTRP-Requests wer­den vom PRAMOS über eine MTRP-Queue an den Host übergeben. Die MTRP-Queue ist als FIFO-Schlange real­isiert, in der Zeiger auf den eigentlichen MTRP-Request-Block abgelegt wer­den (siehe Abbil­dung 3).

Abbil­dung 3: Struk­tur des MTRP
MTRP

Der MTRP-Request wird von dem Host­pro­gramm oder einem Mod­ul mit­tles direk­tem Spe­icherzu­griff (DSZ) aus­ge­le­sen. Nach Abar­beitung solch eines Funk­tion­saufrufes vom Host­pro­gramm oder einem Mod­ul wird der Rück­gabe­w­ert der Funk­tion in eine vorgegebene Adresse inner­halb des MTRP-Requests im PRAMOS geschrieben, wiederum mit­tels DSZ. Für den Betriebssystem-Programmierer ste­hen MTRP-Zugriffsfunktionen zur Ver­fü­gung, die sich um die Ver­wal­tung der MTRP-Queue kümmern.

2.2 Modul-Struktur

Die ursprüngliche Imple­men­tierung des MTRP sah nur eine einzige MTRP-Queue [4, Kapi­tel 3] für die Kom­mu­nika­tion zwis­chen dem PRAMOS und dem Hostrech­n­er vor (siehe Abbil­dung 4). Falls ein MTRP-Request des PRAMOS für ein Mod­ul bes­timmt war, schick­te das PRAMOS einen MTRP-Request zum Host­pro­gramm, das mit­tels Inter­prozesskom­mu­nika­tion (IPC) die entsprechende Funk­tion in dem dafür zuständi­gen Mod­ul aus­führte. Das Mod­ul schrieb dann nach Abar­beitung des MTRP-Requestes den funk­tion­sspez­i­fis­chen Rück­gabe­w­ert durch direk­ten Spe­icherzu­griff in den Spe­ich­er der SB-PRAM.

Durch diese Art der Kom­mu­nika­tion kon­nte das PRAMOS nur über den Umweg über das Host­pro­gramm mit einem Mod­ul kom­mu­nizieren. Außer­dem wur­den durch diesen Kom­mu­nika­tion­sweg unab­hängige MTRP-Requests des PRAMOS serialisiert.

Um die oben genan­nten Beschränkun­gen aufzuheben, wurde eine neue Imple­men­tierung für Mod­ule geschrieben, so daß das PRAMOS direkt mit einem Mod­ul kom­mu­nizieren kann und unab­hängige MTRP-Requests par­al­lel abgear­beit­et wer­den kön­nen. Jedes Mod­ul hat in der neuen Imple­men­tierung eine eigene MTRP-Queue, damit das PRAMOS mit dem jew­eili­gen Mod­ul direkt kom­mu­nizieren kann. Diese Imple­men­tierung impliziert, daß nun das Host­pro­gramm nur ein Mod­ul unter vie­len ist, allerd­ings mit der Möglichkeit andere Mod­ule zu starten.

Abbil­dung 4: Ursprüngliche Imple­men­tierung der SB-PRAM – Host­pro­gramm Kommunikation
MTRP_vorher
Abbil­dung 5: Neue Imple­men­tierung der SB-PRAM – Host­pro­gramm Kommunikation
MTRP_nachher

Solange die bere­its vorhan­de­nen Mod­ule noch nicht auf die neue Imple­men­tierung umgestellt sind (nicht im Rah­men dieser Arbeit), wer­den bei­de Imple­men­tierun­gen par­al­lel benutzt.

2.3 Mehrere MTRP-Queues

Die ursprüngliche Imple­men­tierung der MTRP-Queue war eine einzige Struk­tur mit ein­er zur Compile-Zeit des Betrieb­ssys­tems fest vorgegebe­nen Anzahl an Ein­trä­gen, deren Adresse im Adress­raum des Spe­ich­ers der SB-PRAM zum Zeit­punkt des Kom­pilierens des Betrieb­ssys­tems fest­gelegt wird. Um das MTRP sin­nvoll für die Mod­ule nutzen zu kön­nen, wurde diese Imple­men­tierung der­art erweit­ert, daß Spe­ich­er für eine MTRP-Queue dynamisch zur Laufzeit des SB-PRAM-Betriebssystems alloziert wer­den kann und die Anfangsadresse dieser Struk­tur dem Host­pro­gramm oder einem Mod­ul bekan­nt gemacht wird. Durch diese über­ar­beit­ete Imple­men­tierung des MTRP ist eine Begren­zung der Anzahl der Kom­mu­nika­tion­spart­ner nur noch durch die zur Ver­fü­gung ste­hen­den Resourcen gegeben (siehe Abbil­dung 5).

2.3.1 PRAMOS-Seite

Die neu imple­men­tierte MTRP-Funktion new_mtrp_queue() legt eine neue MTRP-Queue an. Als Argu­ment übergibt man ihr die max­i­male Länge der Queue; d.h. die Anzahl der MTRP-Requests [4, S. 19ff] die später gle­ichzeit­ig in der MTRP-Queue auf Bear­beitung warten kön­nen. Alle bere­its vorhan­de­nen MTRP-Funktionen wur­den der­art über­ar­beit­et, daß sie als zusät­zlich­es Argu­ment eine MTRP-Queue erwarten, über die sie mit dem Host kom­mu­nizieren sollen.

2.3.2 Host­seite

Um eine FIFO-Abarbeitung der Anfra­gen inner­halb ein­er MTRP-Queue garantieren zu kön­nen, wird auf der Host­seite durch die neue Funk­tion get_mtrp_queue() eine Zugriff­sstruk­tur angelegt (im fol­gen­den Hostqueue genan­nt), in der unter anderem jew­eils ein Zeiger auf das nächste/letzte zu bear­bei­t­ende Kom­man­do gespe­ichert ist. Dazu übergibt man der Funk­tion die Anfangsadresse der MTRP-Queue im Adress­raum der SB-PRAM.

Die neue Funk­tion mtrp_read_request(), der man eine Hostqueue als Para­me­ter übergibt, hat als Rück­gabe­w­ert einen Zeiger auf einen MTRP-Request, der aus der MTRP-Queue aus­ge­le­sen wird. Dies kann entwed­er block­ierend oder nicht block­ierend geschehen. Bei einem block­ieren­den Zugriff wartet die Funk­tion solange, bis sich min­destens ein MTRP-Request in der MTRP-Queue befind­et und gibt diesen zurück. Bei einem nicht block­ieren­den Zugriff liefert die Funk­tion einen NULL-Zeiger zurück, falls zur Zeit des Funk­tion­saufrufs kein MTRP-Request auf Abar­beitung wartet.

Nach Abar­beitung eines MTRP-Requests teilt man dem PRAMOS den erfol­gre­ichen oder mißlun­genen Abschluß des MTRP-Requests durch den Aufruf der Funk­tion mtrp_confirm_job() mit (siehe auch Abschnitt D.2 und [4, Kapi­tel 3]).

Es ist nicht möglich, dieselbe MTRP-Queue von mehr als einem Mod­ul ausle­sen zu lassen, da die für eine MTRP-Queue zuständi­ge Zugriff­sstruk­tur (Hostqueue) lediglich in einem Mod­ul lokal zur Ver­fü­gung steht.

2.4 Über­ar­beitung der Module

Da die ursprüngliche Imple­men­tierung der Mod­ule wed­er eine direk­te Kom­mu­nika­tion des PRAMOS mit einem Mod­ul erlaubte (siehe Abbil­dung 4), noch die Kon­fig­u­ra­tion und Ein­bindung einzel­ner Mod­ule von dem PRAMOS ges­teuert wer­den kon­nte, wurde die Imple­men­tierung der Mod­ule angepasst. Dazu wurde ein neuer MTRP-Request definiert, der das Host­pro­gramm dazu ver­an­laßt ein Mod­ul zu starten. Der neue MTRP-Request sieht fol­gen­der­maßen aus:

Name:MTRP_MAIN_CREATEMODULE
Para­me­ter:par[0]: Mod­ul­typ,
par[1]: Adresse der MTRP-Queue im Adress­raum der SB-PRAM,
par[2]: Länge des Argu­mentstrings oder 0,
par[3]: Anfangsadresse des Argu­mentstrings im Adress­raum der SB-PRAM.

Das Host­pro­gramm erwartet als ersten Para­me­ter des Requests den Mod­ul­typ1 (im Falle des NFS-Moduls ist dies MODULE_PRAM_NFSD), der die Art des zu star­tenden Moduls angibt. Außer­dem wird für jedes Mod­ul eine eigene MTRP-Queue benötigt, deren Anfangsadresse im Adress­raum der SB-PRAM als zweit­er Para­me­ter übergeben wird. Erlaubt das Mod­ul die Über­gabe von Kom­man­dozeile­nar­gu­menten, so ist die Länge der Zeichen­kette, welche die Kom­man­dozeile­nar­gu­mente spez­i­fiziert, als drit­ter Para­me­ter und die Anfangsadresse im Adress­raum der SB-PRAM dieser Zeichen­kette als viert­er Para­me­ter zu übergeben. Erlaubt das Mod­ul keine Kom­man­dozeile­nar­gu­mente, oder sollen keine übergeben wer­den, so ist der dritte Para­me­ter auf 0 zu set­zen. Der vierte Para­me­ter wird in diesem Fall ignoriert.

Erhält das Host­pro­gramm solch einen Request, so ver­sucht es, das spez­i­fizierte Mod­ul mit eventuell übergebe­nen Kom­man­dozeile­nar­gu­menten zu starten. Der Pfad­name des Moduls im Dateisys­tem des Hostrech­n­ers ist dabei im Host­pro­gramm einkom­piliert. Die vom Mod­ul benötigte Adresse der MTRP-Queue im Spe­icher­bere­ich der SB-PRAM wird mit­tels eines Star­tup­pro­tokolles übergeben (siehe Abbil­dung 6).

Abbil­dung 6: Kom­mu­nika­tion­skanäle eines Moduls
Modul-Startup

3. Das NFS-Modul

3.1 Grund­la­gen

Das Net­work File Sys­tem (NFS) [7] ist ein Pro­tokoll, das von einem lokalen Rech­n­er über ein Net­zw­erk den Zugriff auf Dateien ander­er Rech­n­er ermöglicht, sofern die jew­eili­gen Rech­n­er für diese Dateien den Zugriff erlauben. Dabei wer­den geöffnete Datei/ein geöffnetes Verze­ich­nis durch ein NFS-Filehandle ein­deutig iden­ti­fiziert. Der Spe­icherver­brauch für diese Daten­struk­tur ist deut­lich klein­er (32 Byte), als der Spe­icherver­brauch bei ein­er Iden­ti­fizierung durch den absoluten Pfad ein­er Datei/eines Verze­ich­niss­es (allein die Spe­icherung ein­er Kom­po­nente eines Pfad­na­mens kann 255 Zeichen beanspruchen, wobei auf der SB-PRAM ein Zeichen 4 Byte an Spe­icher­platzt ein­nimmt). Auf der SB-PRAM wird das NFS als Sub­sys­tem des Vir­tu­al File Sys­tems (VFS) [8] real­isiert.

3.2 Struk­tur

Ruft ein Benutzer­pro­gramm auf der SB-PRAM eine Betrieb­ssys­tem­funk­tion (syscall) auf, die auf ein Dateisys­tem zugreift, benutzt die Betrieb­ssys­tem­funk­tion dazu eine Funk­tion des VFS-Layers, der die betr­e­f­fende dateisys­tem­spez­i­fis­che Funk­tion aufruft. Im Falle des NFS schickt diese dateisys­tem­spez­i­fis­che Funk­tion einen MTRP-Request an das NFS-Modul auf dem Hostrech­n­er. Das NFS-Modul greift dann mit­tels des NFS-Protokolls über ein Net­zw­erk auf ein Dateisys­tem eines Net­zw­erkrech­n­ers zu. Nach Abar­beitung eines Zugriffs wird das Ergeb­nis auf dem umgekehrten Weg zurück­geliefert (Abbil­dung 7).

Abbil­dung 7: Struk­tur eins NFS Zugriffs
NFS-Struktur

3.3 Über­sicht über die Funk­tion­sweise des NFS-Moduls

Alle Dateisys­te­man­fra­gen des VFS-Layers der SB-PRAM, für die das NFS-Protokoll Funk­tio­nen bere­it­stellt (z.B. mkdir), wer­den vom NFS-Modul auf dem Hostrech­n­er bear­beit­et. Alle anderen VFS-Funktionen (z.B. sync)werden auf der SB-PRAM direkt bear­beit­et (siehe dazu auch Abschnitt 3.5).

3.3.1 Host­seite (Start­up des NFS-Moduls)

Das Startup-Protokoll des NFS-Moduls benutzt die nor­malen Ein-/Ausgabekanäle (stdin, std­out) des Hostrechner-Betriebssystems, die mit­tels ein­er Pipe in das Host­pro­gramm umgeleit­et wer­den und so während des Startens des Mod­ules eine Inter-Prozess-Kommunikation (IPC) ermöglichen. Sobald das Mod­ul betrieb­s­bere­it ist, wer­den die Kom­mu­nika­tion­skanäle geschlossen und das Mod­ul kann nur noch mit dem PRAMOS kom­mu­nizieren. Eine genaue Beschrei­bung des Startup-Protokolles für das NFS-Modul befind­et sich in Anhang B.1.

3.3.2 Host­seite (Betrieb)

Damit ein Benutzer auf ein Dateisys­tem zugreifen kann, muß es erst dem Betrieb­ssys­tem bekan­nt gemacht wer­den. Diese Oper­a­tion heißt „ein Dateisys­tem moun­ten”. Die Umkehrung hierzu heißt „ein Dateisys­tem unmoun­ten”, wobei der VFS-Layer dafür zuständig ist, daß ein bei ein­er Unmount-Operation keine Datei mehr geöffnet ist.

Das NFS-Modul ver­wal­tet auf dem Hostrech­n­er eine Liste gemoun­teter Dateisys­teme. Die Länge der Liste kann dynamisch wach­sen und ist somit nur vom zur Ver­fü­gung ste­hen­den Spe­ich­er beschränkt. Wird ein Dateisys­tem gemoun­tet (Abschnitt D.1), wird der SB-PRAM eine ID-Nummer (die Posi­tion in der Liste der gemoun­teten Dateisys­teme) mit­geteilt, welche dieses Dateisys­tem ein­deutig bes­timmt. Ein Lis­tenele­ment in der Liste der gemoun­teten Dateisys­teme enthält nicht nur Infor­ma­tio­nen für welch­es Dateisys­tem es zuständig ist, son­dern auch Authen­tifizierungsin­for­ma­tio­nen, die den Zugriff auf dieses Dateisys­tem erst ermöglichen.

Ein Unmount auf dieses Dateisys­tem (Abschnitt D.1) löscht zwar alle NFS spez­i­fis­chen Dat­en aus der Liste, nicht jedoch das Lis­tenele­ment, das diese Dat­en enthielt

Abbil­dung 8: Unmount von Dateisys­tem Num­mer 3
Unmount

(Abbil­dung 8). Da NFS-Anfragen von der SB-PRAM die IDs benutzen (welche die Posi­tion in der Liste der gemoun­teten Dateisys­teme darstellen), um das Dateisys­tem anzugeben auf das ger­ade zuge­grif­f­en wird, wird so sichergestellt, daß eine NFS-Operation auf das richtige Dateisys­tem angewen­det wird. Würde auch das Lis­tenele­ment aus der Liste ent­fer­nt, müßten im PRAMOS alle geöffneten Dateien/Verzeichnisse über­prüft wer­den, ob diese noch eine kor­rek­te ID-Nummer enthal­ten. Enthiel­ten sie keine kor­rek­te ID-Nummer mehr, müßte diese dann kor­rigiert (dekre­men­tiert) werden.

Strenggenom­men stellt die imple­men­tierte Art des Unmoun­tens eines Dateisys­temes ein Spe­icher­leck dar. Da jedoch das PRAMOS für jedes Pro­gramm neu ini­tial­isiert wird, und damit auch das Host­pro­gramm und die Mod­ule, wird aus Geschwindigkeits­grün­den auf eine „saubere” Imple­men­tierung dieser Ver­wal­tung verzichtet. Sollte das PRAMOS jedoch um Mehrbenutzer-Funktionalität erweit­ert und nicht mehr für jedes Pro­gramm neu ini­tial­isiert wer­den, so muß diese Dateisys­temver­wal­tung über­ar­beit­et wer­den, da sich son­st im Laufe der Zeit (mounten/unmounten) eine größere Anzahl an „toten” Lis­tenele­menten ansam­meln könnte.

3.3.3 PRAMOS-Seite

Die NFS-Komponente des VFS-Layers im PRAMOS ver­wal­tet eine Liste aktiv­er vnodes [8]. Ein aktiv­er vnode ist hier­bei ein vnode, der vom VFS-Layer des PRAMOS noch benutzt wird um eine Datei ein­deutig iden­ti­fizieren zu kön­nen und somit nicht freigegeben wer­den kann. Inner­halb eines aktiv­en vnode wer­den hier­bei pri­vate Dat­en des NFS, wie z.B. das zuge­hörige NFS-Filehandle (Abschnitt D.1) oder die ID-Nummer des zuge­höri­gen Dateisys­tems (Abschnitt 3.3.2), gespe­ichert.

Wird auf der SB-PRAM eine Datei oder ein Verze­ich­nis geöffnet, so wird über­prüft ob dafür bere­its ein vnode existiert. Dies geschieht durch ver­gle­ichen des NFS-Filehandles des Verze­ich­niss­es oder der Datei mit den bere­its in der Liste der aktiv­en vnodes gespe­icherten NFS-Filehandles. Existiert bere­its ein vnode mit diesem NFS-Filehandle, so wird dieser existierende vnode zurück­gegeben, anson­sten wird ein neuer vnode erzeugt. Dies ist nötig, da der VFS-Layer ver­langt, daß lediglich ein vnode pro Verze­ich­nis bzw. Datei existiert.

Da auf der SB-PRAM Auf­gaben par­al­lel abgear­beit­et wer­den, muß sichergestellt wer­den, daß nicht zwei oder mehr Prozes­soren gle­ichzeit­ig die Liste verän­dern, damit z.B. nicht zwei vnodes angelegt wer­den, die dieselbe Datei ref­eren­zieren. Dies wird durch Lock­ing sichergestellt. Die dazu benötigten Funk­tio­nen standen dazu bere­its zur Ver­fü­gung und sind inte­graler Bestandteil des PRAMOS [6, Kapi­tel 4]. Hier­bei kann durch Zuhil­fe­nahme von Locks garantiert wer­den, daß nur ein Prozes­sor die Liste bearbeitet.

3.4 Abar­beitung ein­er NFS-Anfrage der SB-PRAM anhand eines Beispiels

Anhand eines Aufrufs von mkdir, der ein neues Verze­ich­nis im Dateisys­tem erzeugt, wird im fol­gen­den die Abar­beitung ein­er NFS-Anfrage verdeut­licht. Zur Vere­in­fachung wird jedoch nicht im Detail auf die vorhan­dene Fehler­be­hand­lung einge­gan­gen. Der VFS-Layer des PRAMOS ruft die Funk­tion nfs_mkdir() mit den Übergabeparametern

  • struct vnode *vp (Verze­ich­nis, in dem das neue Verze­ich­nis erzeugt wer­den soll)
  • char *nm (Name des zu erzeu­gen­den Verzeichnisses)
  • mode_t mode (Zugriff­s­rechte auf das zu erzeu­gende Verzeichnis)
  • struct vnode **vpp (Adresse im Spe­ich­er der SB-PRAM, an die der vnode des zu erzeu­gen­den Verze­ich­niss­es geschrieben wer­den soll)

auf [8, Funk­tion vfs_makedir]. Diese Funk­tion alloziert nun Spe­ich­er für den vnode des zu erzeu­gen­den Verze­ich­niss­es. Danach erzeugt sie einen MTRP-Request an das NFS-Modul vom Typ MTRP_NFS_MKDIR, dem als Para­me­ter die Anfangsadresse der pri­vat­en Dat­en des vnodes vp im Adress­raum des Spe­ich­ers der SB-PRAM, die Länge des Namens des zu erzeu­gen­den Verze­ich­niss­es, die Anfangsadresse des Namens im Adress­raum des Spe­ich­ers der SB-PRAM, die Zugriff­s­rechte des zu erzeu­gen­den Verze­ich­niss­es und die Anfangsadresse der pri­vat­en Dat­en des neu erzeugten vnodes vppim Adress­raum des Spe­ich­ers der SB-PRAM übergeben werden.

Auf dem Hostrech­n­er wird dadurch im NFS-Modul die mkdir Funk­tion aktiviert. Diese Funk­tion liest die pri­vat­en vnode Dat­en des Verze­ich­niss­es (aus dem Spe­ich­er der SB-PRAM), in dem das neue Verze­ich­nis erzeugt wer­den soll. In diesen Dat­en ste­ht die ID-Nummer des zuge­höri­gen Verze­ich­nis­baumes, so daß die zuge­höri­gen NFS-Daten (z.B. Authen­tifizierung) aus der Liste der gemoun­teten Dateisys­teme des NFS-Moduls aus­ge­le­sen wer­den kön­nen. Danach wird der Name des zu erzeu­gen­den Verze­ich­niss­es aus­ge­le­sen, vom SB-PRAM-Zeichenkettenformat [5] ins Host-Zeichenkettenformat (ASCII) umge­wan­delt und zusam­men mit den Zugriff­s­recht­en in eine NFS-Anfragestruktur geschrieben.

Nach dem erfol­gre­ichen Abschluß der daraufhin fol­gen­den NFS-Anfrage schreibt das Mod­ul das NFS-Filehandle des erzeugten Verze­ich­niss­es in die pri­vat­en Dat­en des auf der SB-PRAM neu erzeugten vnodes.

Auf der SB-PRAM wird nun der vnode des neuen Verze­ich­niss­es, nach­dem NFS-spezifische Teile des vnodes vorher ini­tial­isiert wur­den, in die Liste der aktiv­en vnodes einge­fügt.

3.5 VFS-Funktionen ohne direk­tes NFS-Äquivalent

Für alle VFS Funk­tio­nen ohne Äquiv­a­lent im NFS wur­den im PRAMOS Funk­tio­nen imple­men­tiert, die die geforderte Funk­tion­al­ität, soweit möglich bzw. sin­nvoll, durch Benutzung vorhan­den­er Funk­tio­nen emulieren:

  • root() liefert den vnode des Wurzelverze­ich­niss­es des Dateisys­tems zurück.
  • sync() schreibt noch nicht gespe­icherte Dat­en (Cache) eines gesamten Dateisys­tems. Da auf der SB-PRAM kein Cache für das NFS existiert, ist diese Funk­tion immer erfolgreich.
  • access() über­prüft die Zugriff­ser­laub­nis mit­tels der Zugriff­sat­tribute der Datei bzw. des Verzeichnisses.
  • fsync() schreibt noch nicht gespe­icherte Dat­en (Cache) ein­er Datei. Da auf der SB-PRAM kein Cache für das NFS existiert, ist diese Funk­tion immer erfolgreich.
  • inac­tive() markiert eine Datei bzw. ein Verze­ich­nis als unbe­nutzt, damit Ressourcen freigegeben wer­den kön­nen. Die Imple­men­tierung dieser Funk­tion ent­fer­nt den vnode aus der Liste der aktiv­en vnodes.

4. Aus­blick

Im fol­gen­den wer­den ein paar Verbesserungsmöglichkeit­en für die vorhan­dene Imple­men­tierung der NFS-Anbindung vorgestellt.

  • Mehrere Instanzen des NFS-Moduls

    Die derzeit­ige Imple­men­tierung des SB-PRAM-NFS benutzt nur ein NFS-Modul und führt somit keine unab­hängi­gen Dateizu­griffe par­al­lel durch. Bei ein­er Erweiterung des SB-PRAM-NFS um die Fähigkeit mehrere NFS-Module auf Dateisys­teme arbeit­en zu lassen, ist jedoch darauf zu acht­en, daß in allen NFS-Modulen diesel­ben Dateisys­teme in der gle­ichen Rei­hen­folge gemoun­tet und unge­moun­tet wer­den. Damit wird sichergestellt, daß ein beliebiger (aber fes­ter) NFS-Request an ein NFS-Modul, der das Ziel-Dateisystem mit­tels ein­er ID-Nummer ref­eren­ziert, auch genau das­selbe Dateisys­tem erre­icht wie von ein­er anderen NFS-Modul aus.

  • Caching

    Die Liste der aktiv­en vnode im PRAMOS kann verbessert wer­den zu einem vnode Cache, so daß das Öff­nen von Dateien bzw. Verze­ich­nis­sen beschle­u­nigt wird. Dies kann dadurch erre­icht wer­den, daß bei einem Aufruf von inac­tive() ein aktiv­er vnode als inak­tiv markiert, jedoch nicht aus der Liste ent­fer­nt wird.

    Bei einem lookup() sollte dabei zusät­zlich der zu einem vnode zuge­hörige Pfad in den pri­vat­en Dat­en des vnodes gespe­ichert wer­den. Ein lookup() sucht dann zuerst nach dem Pfad im vnode Cache und ruft nur dann die lookup() Funk­tion im NFS-Modul auf, falls der Pfad nicht im vnode Cache gefun­den wird. Andern­falls braucht nur ein eventuell inak­tiv markiert­er vnode als aktiv markiert zu wer­den. Hier­bei muß jedoch beachtet wer­den, daß bei einem Aufruf von remove() bzw. rmdir() der jew­eilige vnode aus dem Cache ent­fer­nt wird, da es son­st zu Cacheinkon­sis­ten­zen kommt.

    Bei dieser Erweiterung kann auch ein Geschwindigkeits­gewinn im nor­malen Betrieb erwartet wer­den (wenn z.B. ein bere­its geöffnetes Verze­ich­nis wieder geöffnet wird), da die Erken­nung bere­its existieren­der vnodes anhand des Pfades real­isiert wer­den würde, und nicht anhand des NFS-Filehandles, welch­es die lookup() Funk­tion im PRAMOS durch den Aufruf der lookup() Funk­tion des NFS-Moduls erhält.

    Desweit­eren kann die neuere Ver­sion 3 des NFS-Protokolls2 ver­wen­det wer­den um Dat­en zu cachen, da diese Ver­sion im Gegen­satz zu der von uns benutzten Ver­sion 2 des NFS-Protokolls3 die für einen Daten­cache benötigten Rou­ti­nen zur Wahrung der Cachekon­sis­tenz bereitstellt.

  • Time­out­be­hand­lung

    Eine weit­ere sin­nvolle Erweiterung wäre eine Time­out­be­hand­lung auf der PRAMOS-Seite. Wird das NFS-Modul auf dem Hostrech­n­er durch irgendwelche äußeren Umstände an der Arbeit gehin­dert oder ter­miniert, soll das aufrufende Pro­gramm auf der SB-PRAM nicht “end­los” auf das Zurück­kehren der Funk­tion warten.

  • Geän­derte Ver­wal­tung gemoun­teter Dateisysteme

    Sobald das PRAMOS nicht mehr für jedes auszuführende Pro­gramm neu ini­tial­isiert wird, muß die Ver­wal­tung gemoun­teter Dateisys­teme über­ar­beit­et wer­den (siehe auch Abschnitt 3.3.2).

    Bei einem Unmount müssen in der Liste der aktiv­en vnodes die ID-Nummern der Dateisys­teme entsprechend angepaßt wer­den. Falls die Benutzung mehrerer Instanzen des NFS-Modules imple­men­tiert wurde und auch mehrere Instanzen benutzt wer­den, so muß diese Anpas­sung in jed­er Instanz vorgenom­men wer­den. Danach kann das kom­plette Lis­tenele­ment aus der Liste der gemoun­teten Dateisys­teme ent­fer­nt werden.

A. Neue MTRP-Queue Funktionen

A.1 Gemein­sam genutzte Daten­struk­tur6

typedef struct pram_mtrp_queue
{
 /* must be a power of 2 */
 int queue_len;

 /* num­ber of free slots;
    accessed on pram via tdr/mpadd */
 int free_slots;

 /* point­er to next free slot;
    accessed on pram via mpadd on host via load */
 int write_pointer; 

 pram_req_t *volatile *queue;
} pram_mtrp_queue;

A.2 SB-PRAM-Seite9

Name:new_mtrp_queue()
Para­me­ter:int
Rück­gabe:pram_mtrp_queue *
Beschrei­bung:

Diese Funk­tion legt eine neue MTRP-Queue an. Sie erwartet als Argu­ment eine Zahl die angibt, wieviele MTRP-Requests gle­ichzeit­ig in der neu anzule­gen­den Queue auf Bear­beitung warten kön­nen. Sie liefert einen Zeiger auf die neu erzeugte Queue zurück, falls kein Fehler auf­trat, NULL sonst.

A.3 Host­seite12

A.3.1 Daten­struk­turen

typedef struct host_mtrp_queue
{
 /* must be a power of 2 */
 int queue_len;

 /* only accessed on host;
    free_slots is not needed */
 int next_read;

 int write_pointer;
 pram_req_t *volatile *queue;
} host_mtrp_queue;

type­def enum {BLOCKING, NON_BLOCKING} mtrp_read_mode;

A.3.2 Funk­tio­nen

Name:get_mtrp_queue()
Para­me­ter:pram_mtrp_queue *
Rück­gabe:host_mtrp_queue *
Beschrei­bung:

Diese Funk­tion erwartet die Adresse ein­er MTRP-Queue auf der SB-PRAM, um eine Struk­tur anzule­gen, die Infor­ma­tio­nen über die übergebene MTRP-Queue enthält. Mit­tels dieser Struk­tur kön­nen die nach­fol­gen­den Funk­tio­nen auf die Queue auf der SB-PRAM zugreifen. Zurück­gegeben wird ein Zeiger auf diese Zugriff­sstruk­tur falls kein Fehler auf­trat, NULL sonst.

Name:mtrp_read_request()
Para­me­ter:host_mtrp_queue *, con­st mtrp_read_mode
Rück­gabe:pram_req_t *
Beschrei­bung:

Diese Funk­tion erwartet einen Zeiger auf eine Zugriff­sstruk­tur für eine MTRP-Queue und einen Zugriff­s­modus (BLOCKING, NON_BLOCKING). Wird als Zugriff­s­modus BLOCKING ver­wen­det, kehrt diese Funk­tion erst wieder zurück, wenn sich min­destens ein MTRP-Request in der MTRP-Queue befind­et. Zurück­gegeben wird in diesem Fall die Adresse eines Requests auf der SB-PRAM. Wird als Zugriff­s­modus NON_BLOCKING benutzt, kehrt diese Funk­tion auch dann zurück, wenn kein Request auf Bear­beitung wartet. In diesem Fall wird NULL zurückgegeben.

Name:mtrp_confirm_job()
Para­me­ter:pram_req_t *, int
Rück­gabe:keine
Beschrei­bung:

Diese Funk­tion erwartet die Adresse eines Requests auf der SB-PRAM und einen Rück­gabe­w­ert für diesen Request, der an die SB-PRAM weit­ergeleit­et wird.

B. NFS-Modul

B.1 Star­tup­pro­tokoll zwis­chen NFS-Modul und Hostprogramm

Die Kom­mu­nika­tion zwis­chen einem Mod­ul, das in einem Kind-Prozess des Host­pro­grammes ges­tartet wird, und dem Host­pro­gramm wird über eine Pipe zwis­chen bei­den Prozessen abgewickelt.

NFS-ModulHost­pro­gramm

Das NFS-Modul sendet den String PRAM-MTRP-Queue? an das Hostprogramm.

 
 

Das Host­pro­gramm antwortet daraufhin mit der SB-PRAM-Adresse der MTRP-Queue für dieses Mod­ul. Die Adresse wird als String übergeben.

Die Adresse der MTRP-Queue im Adress­raum der SB-PRAM wird über stdin als String eingelesen.

 

Tritt hier­bei kein Fehler auf, so gibt es den String PNFSD up and run­ning. aus.

 
 

Daraufhin sig­nal­isiert das Host­pro­gramm dem PRAMOS den erfol­gre­ichen Abschluß des MTRP_MAIN_CREATEMODULE Requests, baut die IPC-Verbindung ab und das PRAMOS kom­mu­niziert unab­hängig vom Host­pro­gramm mit dem Mod­ul (siehe auch Abbil­dung 6).

Tritt jedoch ein Fehler auf, so gibt das Mod­ul stattdessen PNFSD failed. aus.

 
 

Dies ver­an­laßt das Host­pro­gramm dem PRAMOS eine Fehler­mel­dung zu übergeben.

B.2 MTRP-Requests für das NFS-Modul

Vorbe­merkung zu den MTRP-Requests:

  • die Para­me­ter der MTRP-Requests sind angelehnt an die Über­gabepa­ra­me­ter des VFS-Layers (struct vnode, struct moun­ta, struct statvfs, struct vat­tr, struct uio), die in [8] detail­liert beschrieben sind,
  • pri­vate vfs Dat­en sind Dat­en des NFS, die in der Struk­tur struct vfs des VFS-Layers abgelegt sind,
  • pri­vate vnode Dat­en sind Dat­en des NFS, die in der Struk­tur struct vnode des VFS-Layers abgelegt sind,
  • eine ID-Nummer als Argu­ment wird vor dem Request aus den pri­vat­en vfs Dat­en extrahiert,
  • Adresse­nangaben beziehen sich auf den Adress­raum auf der SB-PRAM.
Name:MTRP_NFS_MOUNT
Para­me­ter:par[0]: Länge + 1 des Namens des Dateisystem-Hosts,
par[1]: Anfangsadresse des Namens des Dateisystem-Hosts,
par[2]: Länge + 1 das Namens des Verzeichnisses,
par[3]: Anfangsadresse des Namens des Verzeichnisses,
par[4]: Adresse der pri­vat­en vfs Dat­en (Ergeb­nis).		 
Speziell:Die struct vnode des VFS-Layers wird nicht benötigt, Namen wer­den aus der struct moun­ta extrahiert.
Name:MTRP_NFS_UNMOUNT
Para­me­ter:par[0]: ID-Nummer des gemoun­teten Dateisystems.
Name:MTRP_NFS_STATFS
Para­me­ter:par[0]: ID-Nummer des gemoun­teten Dateisystems,
par[1]: Adresse ein­er Struk­tur statvfs (Ergeb­nis).
Name:MTRP_NFS_LOOKUP
Para­me­ter:par[0]: Adresse der pri­vat­en vnode Daten,
par[1]: Länge des Namens + 1,
par[2]: Anfangsadresse des Namens,
par[3]: Adresse der pri­vat­en vnode Dat­en (Ergeb­nis).
Name:MTRP_NFS_GETATTR
Para­me­ter:par[0]: Adresse der pri­vat­en vnode Daten,
par[1]: Adresse ein­er Struk­tur vat­tr (Ergeb­nis).
Name:MTRP_NFS_SETATTR
Para­me­ter:par[0]: Adresse der pri­vat­en vnode Daten,
par[1]: Adresse ein­er Struk­tur vat­tr.
Name:MTRP_NFS_CREATE
Para­me­ter:par[0]: Adresse der pri­vat­en vnode Daten,
par[1]: Länge des Namens + 1,
par[2]: Anfangsadresse des Namens,
par[3]: Zugriff­s­rechte für die Datei,
par[4]: Adresse der pri­vat­en vnode Dat­en (Ergeb­nis).
Name:MTRP_NFS_REMOVE
Para­me­ter:par[0]: Adresse der pri­vat­en vnode Daten,
par[1]: Länge das Namens + 1,
par[2]: Anfangsadresse des Namens.
Name:MTRP_NFS_RENAME
Para­me­ter:par[0]: Adresse der pri­vat­en vnode Dat­en (Quelle),
par[1]: Kodierung der Län­gen der bei­den Namen (je + 1),
par[2]: Anfangsadresse des Namens (Quelle),
par[3]: Adresse der pri­vat­en vnode Dat­en (Ziel),
par[4]: Anfangsadresse des Namens (Ziel).
Kodierung:((strlen(Quellname)+1)<<16)|(strlen(Zielname)+1)
Name:MTRP_NFS_MKDIR
Para­me­ter:par[0]: Adresse der pri­vat­en vnode Daten,
par[1]: Länge des Namens + 1,
par[2]: Anfangsadresse des Namens,
par[3]: Verzeichnisattribute,
par[4]: Adresse der pri­vat­en vnode Dat­en (Ergeb­nis).
Name:MTRP_NFS_RMDIR
Para­me­ter:par[0]: Adresse der pri­vat­en vnode Daten,
par[1]: Länge des Namens + 1,
par[2]: Anfangsadresse des Namens.
Name:MTRP_NFS_READDIR
Para­me­ter:par[0]: Adresse der pri­vat­en vnode Daten,
par[1]: Adresse ein­er Struk­tur uio (Ergeb­nis),
par[2]: Adresse eines Daten­typs int (EOF).
Bedin­gung:uio_resid >= 64 (NFS Beschränkung).
Name:MTRP_NFS_LINK
Para­me­ter:par[0]: Adresse der pri­vat­en vnode Dat­en (Quelle),
par[1]: Adresse der pri­vat­en vnode Dat­en (Ziel),
par[2]: Länge des Namens + 1,
par[3]: Anfangsadresse des Namens.
Name:MTRP_NFS_READ
Para­me­ter:par[0]: Adresse der pri­vat­en vnode Daten,
par[1]: Adresse ein­er Struk­tur uio (Ergeb­nis).
Name:MTRP_NFS_WRITE
Para­me­ter:par[0]: Adresse der pri­vat­en vnode Daten,
par[1]: Adresse ein­er Struk­tur uio.

C. Uni­versell ein­set­zbare Datenstrukturen

C.1 PRAMOS15

Die vor­liegende Imple­men­tierung der NFS Anbindung benutzt eine Liste um bere­its geöffnete Dateien und Verze­ich­nisse erken­nen zu kön­nen. Diese Liste wurde als dop­pelt ver­ket­tete Liste imple­men­tiert und erlaubt die all­ge­meine Anwen­dung durch aus­tauschbare Vergleichsroutinen.

Name:List_Init()
Para­me­ter:struct List **
Rück­gabe:int
Beschrei­bung:

Diese Funk­tion legt eine neue Liste an. Ein Zeiger auf diese Liste wird an die Adresse geschrieben, die übergeben wird. Bei Erfolg wird 1 zurück­gegeben, 0 sonst.

Name:List_SetCompare()
Para­me­ter:struct List *, int (*)(unsigned long *, unsigned long *)
Rück­gabe:void
Beschrei­bung:

Diese Funk­tion weist der Liste eine neue Ver­gle­ichs­funk­tion zu.

Name:STD_List_Compare()
Para­me­ter:unsigned long *, unsigned long *
Rück­gabe:int
Beschrei­bung:

Stan­dard Ver­gle­ichs­funk­tion, falls nicht mit­tels List_SetCompare() eine neue Ver­gle­ichs­funk­tion zugewiesen wird.

Bemerkung:

Diese Funk­tion ist nur der Funk­tion List_Init() bekan­nt, da STD_List_Compare() als sta­t­ic deklar­i­ert ist.

Quell­text:if (first == second) return 0;
if (first < second) return -1;

return 1;

Name:List_Add()
Para­me­ter:struct List *, unsigned long *
Rück­gabe:struct List_Node *
Beschrei­bung:

Diese Funk­tion fügt einen Zeiger auf beliebige Dat­en in die übergebene Liste ein. Zurück­gegeben wird NULL im Fehler­fall, ein Zeiger auf ein Lis­tenele­ment, das den Zeiger auf das Datum enthält, sonst.

Name:List_Head()
Para­me­ter:struct List *
Rück­gabe:struct List_Node *
Beschrei­bung:

Diese Funk­tion gibt einen Zeiger auf das Kopfele­ment der Liste zurück, falls die Liste nicht leer ist, NULL sonst.

Name:List_Tail()
Para­me­ter:struct List *
Rück­gabe:struct List_Node *
Beschrei­bung:

Diese Funk­tion gibt einen Zeiger auf das Endele­ment der Liste zurück, falls die Liste nicht leer ist, NULL sonst.

Name:List_Next()
Para­me­ter:struct List *, struct List_Node *
Rück­gabe:struct List_Node *
Beschrei­bung:

Diese Funk­tion gibt einen Zeiger auf das Nach­fol­gerele­ment des übergebe­nen Ele­mentes zurück., falls ein Nach­fol­gerele­ment existiert, NULL sonst.

Name:List_Previous()
Para­me­ter:struct List *, struct List_Node *
Rück­gabe:struct List_Node *
Beschrei­bung:

Diese Funk­tion gibt einen Zeiger auf das Vorgän­gerele­ment des übergebe­nen Ele­mentes zurück, falls ein Vorgän­gerele­ment existiert, NULL sonst.

Name:List_Search()
Para­me­ter:struct List *, unsigned long *
Rück­gabe:struct List_Node *
Beschrei­bung:

Diese Funk­tion sucht, unter Zuhil­fe­nahme ein­er vorher spez­i­fizierten Ver­gle­ichs­funk­tion (List_SetCompare()), nach einem Datum in der Liste, das zu dem übergebe­nen Datum äquiv­a­lent ist (“äquiv­a­lent” deshalb, da dies von der speziellen Such­funk­tion abhängt, siehe STD_List_Compare()). Zurück­gegeben wird das Lis­tenele­ment, welch­es das gesuchte Datum enthält, oder NULL, falls das gesuchte Datum nicht in der Liste ist.

Name:List_Data()
Para­me­ter:struct List *, struct List_Node *
Rück­gabe:unsigned long *
Beschrei­bung:

Diese Funk­tion gibt das in einem Lis­tenele­ment enthal­tene Datum zurück.

Name:List_SetData()
Para­me­ter:struct List *, struct List_Node *, unsigned long *
Rück­gabe:unsigned long *
Beschrei­bung:

Diese Funk­tion erset­zt das Datum eines Lis­tenele­mentes, zurück­gegeben wird das alte Datum.

Name:List_Size()
Para­me­ter:struct List *
Rück­gabe:unsigned int
Beschrei­bung:

Diese Funk­tion gibt die Anzahl der in der Liste enthal­te­nen Ele­mente zurück.

Name:List_Delete()
Para­me­ter:struct List *, struct List_Node *
Rück­gabe:unsigned long *
Beschrei­bung:

Diese Funk­tion ent­fer­nt ein Lis­tenele­ment aus der Liste, zurück­gegeben wird das in dem ent­fer­n­ten Lis­tenele­ment enthal­tene Datum.

C.2 Host18

Das NFS-Modul auf dem Hostrech­n­er benutzt eine Liste um bere­its gemoun­tete Dateisys­teme ver­wal­ten zu kön­nen. Diese Liste ist ana­log zu der Liste im PRAMOS real­isiert, wobei eine erweit­erte Funk­tion­al­ität wie fol­gt imple­men­tiert ist:

Name:List_SetConstruct()
Para­me­ter:struct List *, int (*)(unsigned long **)
Rück­gabe:void
Beschrei­bung:

Diese Funk­tion weist der Liste einen neuen Kon­struk­tor zu, der auf jedes neu hinzuge­fügte Datum angewen­det wird.

Name:STD_List_Construct()
Para­me­ter:unsigned long **
Rück­gabe:int
Beschrei­bung:

Stan­dard Kon­struk­tor, falls nicht mit­tels List_SetConstruct() ein neuer Kon­struk­tor zugewiesen wird. Zurück­gegeben wird 0 bei Erfolg.

Bemerkung:

Diese Funk­tion ist nur der Funk­tion List_Init() bekan­nt, da STD_List_Construct() als sta­t­ic deklar­i­ert ist.

Quell­text:return 0;
Name:List_SetDestruct()
Para­me­ter:struct List *, unsigned long *(*)(unsigned long *)
Rück­gabe:void
Beschrei­bung:

Diese Funk­tion weist der Liste einen neuen Destruk­tor zu, der auf jedes zu ent­fer­nende Datum angewen­det wird.

Name:STD_List_Destruct()
Para­me­ter:unsigned long *ele­ment
Rück­gabe:unsigned long *
Beschrei­bung:

Stan­dard Destruk­tor, falls nicht mit­tels List_SetDestruct() ein neuer Destruk­tor zugewiesen wird. Zurück­gegeben wird 0 bei Erfolg.

Bemerkung:

Diese Funk­tion ist nur der Funk­tion List_Init() bekan­nt, da STD_List_Destruct() als sta­t­ic deklar­i­ert ist.

Quell­text:return element;
Name:List_GetItem()
Para­me­ter:struct List *, unsigned long pos
Rück­gabe:struct List_Node *
Beschrei­bung:

Diese Funk­tion gibt das Lis­tenele­ment zurück, das sich an Posi­tion pos befind­et, sofern 1 <= pos <= List_Size() und List_Size() > 0.

Name:List_Remove()
Para­me­ter:struct List **
Rück­gabe:void
Beschrei­bung:

Diese Funk­tion ent­fer­nt die Liste kom­plett aus dem Spe­ich­er, es kann nun nicht mehr mit dieser Liste gear­beit­et werden.

D. Glos­sar

D.1 Dateisystem-spezifisch

Vir­tu­al File Sys­tem (VFS)

Das Vir­tu­al File Sys­tem [8] stellt eine ein­heitliche Schnittstelle zwis­chen Betrieb­ssys­tem und ver­schiede­nen Dateisys­te­men zur Ver­fü­gung, so daß man mit­tels ein­er ein­heitlichen Benutzer­schnittstelle auf die ver­schiede­nen Dateisys­teme zugreifen kann.

Net­work File Sys­tem (NFS)

Das Net­work File Sys­tem [7] ist ein Pro­tokoll, das den Zugriff auf Dateien ander­er Rech­n­er in einem Net­zw­erk ermöglicht, sofern die jew­eili­gen Rech­n­er für diese Dateien den Zugriff erlauben.

NFS-File­han­dle

Ein NFS-Filehandle ist eine Daten­struk­tur, die ein Verze­ich­nis oder eine Datei auf die mit­tels des NFS zuge­grif­f­en wird, ein­deutig bestimmt.

Dateisys­teme moun­ten

Ein Dateisys­tem moun­ten heißt, das Dateisys­tem dem Betrieb­ssys­tem bekan­nt zu machen, damit ein Benutzer darauf zugreifen kann.

Dateisys­teme unmoun­ten

Ein Dateisys­tem unmoun­ten ist die inverse Funk­tion zu Dateisys­teme mounten.

D.2 SB-PRAM-spezifisch

Mem­o­ry Trans­fer Request Pro­tokoll (MTRP)

Das Mem­o­ry Trans­fer Request Pro­tokoll [4, Kapi­tel 3] ermöglicht dem PRAMOS auf dem Hostrech­n­er Funk­tio­nen auszuführen (Remote Pro­ce­dure Calls, RPC).

MTRP-Queue

Die MTRP-Queue [4, Kapi­tel 3] ist eine FIFO-Schlange, in die MTRP-Requests des PRAMOS an die Host­seite des SB-PRAM Betrieb­ssys­tems einge­fügt werden.

MTRP-Request

Ein MTRP-Request ist ein inner­halb ein­er MTRP-Queue gespe­ichert­er Funk­tion­saufruf des PRAMOS an die Host­seite des SB-PRAM Betriebssystems.

MTRP-Funktionen

Die MTRP-Funktionen stellen eine ein­heitliche Schnittstelle zur Ver­fü­gung, um das MTRP zu benutzen. Sie ermöglichen das Erzeu­gen von MTRP-Queues und MTRP-Requests.

Host­pro­gramm

Das Host­pro­gramm [4] regelt die Kom­mu­nika­tion der SB-PRAM mit dem Benutzer und ist für das Starten der Pro­gramme auf der PRAM sowie der Mod­ule auf dem Hostrech­n­er verantwortlich.

Mod­ul

Es gibt zwei Arten von Mod­ulen, die alte und die neue Imple­men­tierung. Diese Beschrei­bung bezieht sich auf die neue Imple­men­tierung. Mod­ule sind vom PRAMOS aufruf­bare Pro­gramme auf dem Hostrech­n­er, die nach dem Starten durch das Host­pro­gramm autonom agieren.

Abbil­dungsverze­ich­nis

  1. Die SB-PRAM.
  2. VFS Schnittstelle
  3. Struk­tur des MTRP
  4. Ursprüngliche Imple­men­tierung der SB-PRAM – Host­pro­gramm Kommunikation
  5. Neue Imple­men­tierung der SB-PRAM – Host­pro­gramm Kommunikation
  6. Kom­mu­nika­tion­skanäle eines Moduls
  7. Struk­tur eins NFS Zugriffs
  8. Unmount von Dateisys­tem Num­mer 3

Lit­er­atur

1
P. Bach, M. Braun, A. Formel­la, J. Friedrich, Th. Grün, C. Licht­e­nau. Build­ing the 4 Proces­sor SB-PRAM Pro­to­type. Hawaii Inter­na­tion­al Con­fer­ence on Sys­tem Sci­ences, Hawaii, USA, 1996.

2Jörg Keller. Zur Real­isier­barkeit des PRAM Mod­ells. Dis­ser­ta­tion, FB 14 Infor­matik, Uni­ver­sität des Saar­lan­des, 1992.

3Abhi­ram G. Ranade, Sandeep N. Bhatt, S. Lennart John­son. The Flu­ent Abstract Machine. In „Pro­ceed­ings of the 5th MIT Con­fer­ence on Advanced Research in VLSI”, pages 71 – 93, Cam­bridge, MA, 1988. MIT Press.

4Ste­fan Franziskus. Entwurf und Imple­men­ta­tion der Host­seite des PRAM-Betriebssystems PRAMOS. Diplo­mar­beit, FB14 Infor­matik, Uni­ver­sität des Saar­lan­des, Mai 1997.

5Andreas Crauser. Entwurf und Imple­men­tierung des SB-PRAM-Betriebssystems PRAMOS: SB-PRAM-Seite. Diplo­mar­beit, FB 14 Infor­matik, Uni­ver­sität des Saar­lan­des, 1996.

4Jochen Röhrig. Imple­men­tierung der P4-Laufzeitbibliothek auf der SB-PRAM. Diplo­mar­beit. FB 14 Infor­matik, Uni­ver­sität des Saar­lan­des, 1996.

7SUN Microsys­tems Inc., Request for com­ment (RFC) 1094, Net­work File Sys­tem V2, 1989.

8Daniel Rock. VFS. Manuskript, Lehrstuhl Prof. Paul, FB14 Infor­matik, Uni­ver­sität des Saar­lan­des, 1998.

Fuss­noten

… Mod­ul­typ1
siehe CVS: PRAM/pramos/common/modules_req.{h,m4}
… NFS-Protokolls2
siehe RFC 1813
… NFS-Protokolls3
RFC 1094
… Daten­struk­tur4
siehe CVS: PRAM/pramos/common/mtrp.h
… Daten­struk­tur5
siehe CVS: PRAM/pramos/common/mtrp.h
… Daten­struk­tur6
siehe CVS: PRAM/pramos/common/mtrp.h
…SB-PRAM-Seite7
siehe CVS: PRAM/pramos/pram/kern/hostcommstack.c
…SB-PRAM-Seite8
siehe CVS: PRAM/pramos/pram/kern/hostcommstack.c
…SB-PRAM-Seite9
siehe CVS: PRAM/pramos/pram/kern/hostcommstack.c
…Host­seite10
siehe CVS: PRAM/pramos/host/mtrp_communication.c
…Host­seite11
siehe CVS: PRAM/pramos/host/mtrp_communication.c
…Host­seite12
siehe CVS: PRAM/pramos/host/mtrp_communication.c
…PRAMOS13
siehe CVS: PRAM/pramos/pram/vfs/list.c
…PRAMOS14
siehe CVS: PRAM/pramos/pram/vfs/list.c
…PRAMOS15
siehe CVS: PRAM/pramos/pram/vfs/list.c
…Host16
siehe CVS: PRAM/pramos/host/nfs/list.c
…Host17
siehe CVS: PRAM/pramos/host/nfs/list.c
…Host18
siehe CVS: PRAM/pramos/host/nfs/list.c

Share/Save