| Zeile 19: | Zeile 19: | ||
== IPC == | == IPC == | ||
| − | Zur IPC werden Popupthreads verwendet, die entweder asynchron oder synchron (über waitpid) abgesetzt werden können. Jeder Popupthread erhält als Parameter einen Integer (eine Funktionsnummer) und ggf. eine SHM-ID. Zusätzlich kann der Aufrufer eine Nachricht übergeben, die vom Kernel zwischengespeichert wird und vom Popupthread über einen Syscall abgerufen werden kann. | + | Zur IPC werden Popupthreads verwendet, die entweder asynchron oder synchron (über waitpid) abgesetzt werden können. Jeder Popupthread erhält als Parameter einen Integer (eine Funktionsnummer) und ggf. eine SHM-ID. Zusätzlich kann der Aufrufer eine Nachricht übergeben, die vom Kernel zwischengespeichert wird und vom Popupthread über einen Syscall abgerufen werden kann; ebenso kann der Popupthread eine Antwortnachricht angeben, die der Aufrufer dann abrufen kann. |
== VFS == | == VFS == | ||
| Zeile 46: | Zeile 46: | ||
Die Symlinkimplementierung ist vielleicht nicht die schönste ihrer Art, aber zumindest funktioniert sie soweit. | Die Symlinkimplementierung ist vielleicht nicht die schönste ihrer Art, aber zumindest funktioniert sie soweit. | ||
| − | All diese VFS-Funktionen laufen transparent über die IPC-Funktionen ab. Der Aufrufer erzeugt für alle VFS-Funktionen kurze Nachrichtenblöcke, die über Message Passing an Popupthreads im Aufrufer weitergegeben werden, sowie für einige (read/write bzw. stream_recv/stream_send) auch SHM-Bereiche, über die größere Datenmengen ausgetauscht werden können. Auf Empfängerseite lesen Bibliotheksfunktionen die Informationen aus den Nachrichtenblöcken wieder aus und geben sie an vom Service bereitgestellte Funktionen wie „service_create_pipe“ weiter, deren Interface beinahe exakt denen der Aufruferfunktionen (wie „create_pipe“) entspricht. Zur VFS-Benutzung ist die Benutzung der IPC-Funktionen also prinzipiell nicht nötig. | + | All diese VFS-Funktionen laufen transparent über die IPC-Funktionen ab. Der Aufrufer erzeugt für alle VFS-Funktionen kurze Nachrichtenblöcke, die über Message Passing an Popupthreads im Aufrufer weitergegeben werden, sowie für einige (read/write bzw. stream_recv/stream_send) auch SHM-Bereiche, über die größere Datenmengen ausgetauscht werden können (kleinere werden auch hier per Message Passing übergeben). Auf Empfängerseite lesen Bibliotheksfunktionen die Informationen aus den Nachrichtenblöcken wieder aus und geben sie an vom Service bereitgestellte Funktionen wie „service_create_pipe“ weiter, deren Interface beinahe exakt denen der Aufruferfunktionen (wie „create_pipe“) entspricht. Zur VFS-Benutzung ist die Benutzung der IPC-Funktionen also prinzipiell nicht nötig. |
Die praktisch absolute Dezentralität hat den Vorteil einer funktionierenden fork-Implementierung (wobei jeder Prozess die von ihm gehaltenen Pipe-IDs im Userspace selbst duplizieren muss (dafür existiert eine „duplicate_pipe“-Funktion)). | Die praktisch absolute Dezentralität hat den Vorteil einer funktionierenden fork-Implementierung (wobei jeder Prozess die von ihm gehaltenen Pipe-IDs im Userspace selbst duplizieren muss (dafür existiert eine „duplicate_pipe“-Funktion)). | ||
| Zeile 53: | Zeile 53: | ||
* o. g. IPC und VFS | * o. g. IPC und VFS | ||
| − | |||
* [[Common Driver Interface|CDI]] | * [[Common Driver Interface|CDI]] | ||
* Netzwerkstack: [[Ethernet]], [[Internet Protocol|IPv4]], UDP, DHCP, TCP | * Netzwerkstack: [[Ethernet]], [[Internet Protocol|IPv4]], UDP, DHCP, TCP | ||