Thema: Design für mein OS

[kevin]

Der Vaterprozess kann zum Beispiel eine Datei öffnen und an einen niedriger privilegierten Kindprozess vererben, der sie selbst nicht mehr öffnen könnte. Sowas kommt schon mal vor.

[erik.vikinger]

Hallo,

Der Vaterprozess kann zum Beispiel eine Datei öffnen und an einen niedriger privilegierten Kindprozess vererben, der sie selbst nicht mehr öffnen könnte. Sowas kommt schon mal vor.

Solange der Vaterprozess die Datei unmittelbar nach oder während dem Vererben schließt liegt da auch kein Sharing vor so das ein lokaler Datei-Pointer in der libc kein Problem darstellt. Und genau darum geht es mir doch, ich würde gerne den VFS-Service aus solchen Dingen weitestgehend raus halten und für echte Dateien nur pread/pwrite anbieten wollen (beides aus Gründen der Performance). Klar bedeutet dass das in der libc eine zusätzliche Schicht rein muss aber die dürfte eigentlich nur aus einer vTable bestehen (dafür ist diese Schicht nicht mehr im VFS oder sonstwo erforderlich).


Grüße
Erik

[kevin]

Ich dachte, du willst Vererben grundsätzlich und ohne Ausnahme verbieten? Wie sollte es dann helfen, nach dem Vererben die Datei zu schließen? Die Vererbung ist doch dann schon schiefgegangen.

[erik.vikinger]

Hallo,


Wo hab ich geschrieben das ich Vererbung "grundsätzlich und ohne Ausnahme" verbieten will?
Ich nehme an Du meinst nur Dateien?
Dateien sollen bei mir nicht geshared werden aber gegen Vererben im Sinne von Weitergeben hab ich nichts einzuwenden, die Frage ist eher wie das zu implementieren ist. Ich könnte mir vorstellen dafür ein Flag "FD_CLOFORK" (was sich auf den Elternprozess bezieht) in der libc einzuführen (zumindest in der BAD-POSIX-Version), wenn der Versuch eine Datei ohne dieses Flag zu vererben zu einem Fehler führt kann man den Source-Code des Programms analysieren und einfach fixen. Da viele Programme kein allumfassendes Fehlerhandling haben wäre es hier geschickt wenn die libc interne Fehler mit einem gesondertem Mechanismus loggen kann.

Ich will doch gar keine echte POSIX-Konformität erreichen (ist für mein eigenes Projekt eh unrealistisch), alles was ich will ist das man möglichst viele existierende Programme mit möglichst wenig Aufwand portieren kann (und das am besten ohne das man sich merkwürdige Effekte einhandelt).

Aus Gründen der Performance finde ich es besser wenn z.B. der Datei-Pointer nicht im VFS sondern in der libc ist (deswegen hab ich das Thema ja eigentlich erst hier angesprochen). Damit bekommt man aber eben Probleme beim POSIX-Konformen Vererben von Dateien. Mein Vorschlag ist nichts weiter als eine Variante damit umzugehen und trotzdem möglichst viele existierende Programme möglichst ohne Änderungen lauffähig zu halten. Der Grund warum ich glaube dass das auch funktioniert ist der das es kaum echte Szenarien gibt in denen echte Dateien vererbt werden (die paar Ausnahmen die es sicher gibt werden die Datei auch nicht sharen sondern eher nur weitergeben was natürlich auch mit möglichst wenig Portierungsaufwand machbar sein soll) so das es IMHO reicht wenn man richtiges Vererben nur mit Streams kann.


Grüße
Erik

[LittleFox]

Moin,

ich werd' jetzt einfach pread, pwrite, read write und seek in mein VFS packen. Damit sind alle Fälle einfach abgedeckt.

Nochmal Danke für eure Hilfe

Grüße,
LittleFox

[Svenska]

Das ist übertrieben.
Denn read und write kannst du immer mit pread und pwrite emulieren, das sind dann Dreizeiler in der libc. Die brauchen nicht ins VFS.

Gruß,
Svenska

[erik.vikinger]

Hallo,

Denn read und write kannst du immer mit pread und pwrite emulieren ....

Aber nur wenn auch der Datei-Pointer in der libc bleibt und das ist ja wieder nicht POSIX-Konform. Dieser Dreizeiler wird für ein POSIX-Konformes System wohl ins VFS müssen. Wenn das VFS nur pread/pwrite kennt dann benötigt es auch kein seek,


Grüße
Erik

[Svenska]

Gut, dann kann man eben read, write und seek implementieren und pread/pwrite in der libc verschwinden lassen.

[erik.vikinger]

Hallo,

und pread/pwrite in der libc verschwinden lassen.

Und wie? Doch wohl hoffentlich nicht indem Du seek und dann read/write und dann wieder seek machst? Stell Dir nur mal vor was die anderen POSIX-Konformen Programme dazu sagen wenn Du einfach mal so den Datei-Pointer kurz änderst. Von den 2 unnützen Syscalls/IPC-Calls mal ganz abgesehen, eigentlich sind es ja 3 zusätzliche Syscalls/IPC-Calls weil Du ja vorher noch den alten Datei-Pointer erfragen musst.


Grüße
Erik