Die Idee ein User-Level-Filesystem zu implementieren entsteht aus dem Ansatz heraus möglichst viel Funktionalität aus dem Systemkern zu nehmen und diese einfach und flexibel den jeweiligen Bedürfnissen anpassen zu können.2. Aufbau und Arbeitsweise
Üblicherweise finden alle Operationen eines Filesystems in der Kernumgebung statt. Will man die Funktionen abändern, weil sich z.B. ein Standard geändert hat, kommt man dann an einer Änderung der Betriebssystemsourcen nicht herum.
Beim User-Level-Filesystem werden die Operationen im Kern auf die wesentlichen beschränkt und die konkrete systemabhängige Funktionalität als Requests an einen im User Mode laufenden Daemon weitergeleitet, der die entsprechenden Antworten dann zurückgeschickt.
So lässt sich ohne Änderungen am Filesystem im Kern das vorherige FTP-Filesystem z.B. in ein Loopback-Filesystem verwandeln.
Der wesentliche Punkt bei der Implemenitierung eines User-Level-Filesystems, ist die Kommunikation zwischen den Filesystemoperationen im Kern und dem User-Level-Daemon.
Dies stellt einen gewissen Aufwand dar, da die Nachrichten vom Kernadressraum in den Benutzeradressraum und zurück gelangen müssen.
Die übliche Vorgehensweise sind dabei Remote Procedure Calls (RPC) oder die direkte Programmierung der Transport Level Interface (TLI), das zentrale Kommunikationsorgan im Kern.
Wir haben einen anderen Weg gewählt: Die Verwendung von Message Queues, einem sonst selten eingesetzten UNIX-Systemdienst. Message Queues sind eigentlich zur Interprozesskommunikation von User-Level-Prozessen gedacht. Spricht man sie im Kern jedoch direkt an, ohne auf die eingebauten Systemcalls zurückzugreifen, so lassen sie sich auch zur Kommunikation zwischen Kern- und Benutzerumgebung verwenden.
Bevor das User-Level-Filesystem benutzt werden kann, muss das akbp_fs-Filesystem-Modul den Kernfunktionen hinzugefügt werden. Dies setzt auf dem virtuellen Filesystem von Sun auf, das verschiedene Filesysteme in einem Betriebssystem zulässt.
Mit dem Mounten des Dateisystems wird der Daemon gestartet, der sich vom Mount-Prozess des Benutzers "forked".
Greift der Benutzer in einem Prozess (linker Kasten) auf das Dateisystem mit einem der üblichen Datei-Operationen (lookup(), readdir(), open(), ...) zu, so hängt das akbp_fs - Modul eine entsprechende Nachricht in die Request-Queue und wartet auf die Antwort.
Der Daemon hat sich nach seinem Start mit dem System-Call msgrcv(2) schlafen gelegt, um auf eintreffende Requests zu warten und sie gleich entgegenzunehmen. Die Antworten werden mittels msgsnd(2) zurückgeschickt. Hierbei wird wohlgemerkt das Message-Modul des Kerns zurückgegriffen.