Hallo,
zu Deinem Loader fällt mir noch ein das Du es lösen musst den Speicher mit den richtigen Rechten (für den neuen Prozess) zu injizieren. Also z.B. Code sollte als Executable-Only gemappt sein und ASLR solltest Du auch (zumindest konzeptionell) vorsehen.
Plug-Ins zur Laufzeit funktionieren so, dass du dir ne Liste von denen merkst und die ein ganz bestimmtes API implementieren.
Hä? Soll die Liste ein API implementieren?
Im Endeffekt ruft das eigentliche Programm die Funktionen nur über eine Struktur mit Funktionspointern (siehe VFS bei Linux und bestimmt auch allen anderen OS´s) auf, aber im Plug-In werden Symbole reloziert, nicht aber im eigentlichen Programm.
Diese Strucktur-Member dann später (zur Laufzeit) auf den richtigen Code zeigen zu lassen ist auch relozieren. Auf was zeigen diese Funktions-Pointer vorher? Nebst dessen das solche Strukturen besser in
rodata liegen damit das eigentliche Programm da nicht aus versehen was doofes reinschreibt, damit sollte Dein Loader umgehen können.
Das Senden und Empfangen von Daten sollte mehr oder weniger per Zero-Copy gehen
Das meinte ich auch, die Metadaten sind doch nur ein paar Bytes so das dort Kopieren immer billiger als Mappen sein sollte.
die Implementierung in der libc wird definitiv nur über kopieren zu lösen sein (geht auch gar nicht anders ohne Segmente, irgendwo muss immer kopiert werden).
Hm, ich wollte eher im VFS kopieren, dort muss man das doch eh tun wenn man anständigen Cache haben will. In der libc würde ich nur dann cachen wenn z.B. eine Datei per readln eingelesen wird aber wenn dort read(file,buffer,1000000) steht dann soll das VFS lieber direkt von seinem Cache in den eigentlich User-Buffer kopieren. Es ist IMHO auch unwahrscheinlich das ein Programm die selben Bytes aus einer Datei mehrfach hintereinander einließt so das es eher darum geht dass das VFS nicht für zu arg kleine Häppchen in Anspruch genommen wird was also eher für ein dezentes Read-Ahead und Write-Combining in der libc spricht (und für richtiges Datei-Caching ist die libc auf jeden Fall der falsche Ort).
Wo würden dann die FD´s sein? Im VFS oder im Dateisystem-Programm?
Auf jeden Fall nicht im Datei-System-Treiber, ich würde dort nicht mal irgendeine Art von Datei-Handle o.ä. haben wollen, eher würde ich dem VFS immer 2 oder 3 uint64_t Werte vom Datei-System-Treiber mitgeben die dann vom VFS wieder an den Datei-System-Treiber übergeben werden müssen damit diese z.B. zum schnelleren Finden der Datei benutzt werden können (bei FAT wäre das z.B. der Start-Cluster des Verzeichnisses und das Offset mit dem Verzeichniseintrag innerhalb des Verzeichnisses wenn es um die Metadaten geht und der Start-Clusster der eigentlichen Datei wenn es um die Datei selber geht, bei ext wohl eher eine INode-Nummer). Es ist auf jeden Fall Speicher-Effizienter wenn das Cache-Management nur einmal gemacht wird und da bietet sich das VFS geradezu an.
Wenn ich da an SSDs denke, könnte sich der Overhead bemerkbar machen oder?
Dann denk mal an eine PCIe-RAM-Disk (also ein HDD-Controller auf einer PCIe-Karte an dem direkt 4 oder mehr GB normaler DRAM hängen), damit kann man selbst bei zufälligem Lesen und Schreiben (es muss ja kein Wear-Leveling durchgeführt werden) von einzelnen Sektoren Commit-Zeiten von unter 1 µs erreichen. Da ist die SW-Schichtung im OS immer der Bremsklotz. Aber sowas ist eben auch für keinen von uns der normale Einsatzzweck, ich denke das 3 SW-Schichten im OS (VFS / Datei-System-Treiber / Block-Device-Treiber) ganz okay sind, bei normalen HDDs dürfte das nichtmal messbar sein.
Ich wüsste jetzt auch nicht wie komplex solche "Programme" dann wären, sprich was sie an Libs benötigen würden.
Ich vermute mal das so ein Datei-System-Treiber als eigenständiger Prozess fast gar nichts an libs braucht, außer malloc/free, nen printf für Fehlermeldungen und etwas Code zum umrechnen von Zeitwerten (Datei-System-Format <> UTC) fällt mir nicht viel ein.
noch etwas OT (ich finde jetzt auf die Schnelle nicht mehr den richtigen Thread):
Du hast doch mal gefragt ob man von einer virtuellen Adresse auf das zugehörige Objekt schließen können muss also ob man im VMM im Kernel auch die belegten Blöcke verwalten sollte: ich denke ja, weil spätestens wenn Du doch mal swappen willst must Du in der Lage sein zu wissen was Du gerade auslagerst wenn Dir die Page-Ersetzungsstrategie eine Page vorschlägt.
Grüße
Erik