Nachrichten

121

OS-Design / Re: Flexibles und einfaches Prozess erzeugen

« am: 19. October 2011, 20:43 »

Also wenn man für synchrones IPC (also alles was eine zugehörige Antwort hat) bereits einen eigenen Port benötigt um auch nur als Client funktionieren zu können ist das IMHO schon eine Einschränkung, die meisten (einfachen) Funktionen aus der libc sind synchron (und blockierend).

Ich habe doch geschrieben, dass man auf Senderseite keinen Port benötigt und bei asynch kann man dann keine Antwort bekommen, aber bei synch blockiert ja der Sender (und wartet auf Daten) und somit kann ihm auch die Nachricht zugestellt werden.

Der Grund warum das so "komisch" ist, weil entweder ich lasse das IPC per Thread machen (jeder Thread hat eine Messagebox) oder ich erstelle Ports dafür. Das mit jeder Thread hat ne Msgbox gefällt mir irgendwie nicht und deswegen halt die Ports.

Kann man so machen aber ist natürlich zusätzlicher Overhead. Wenn man schon beim Callee einen neuen Thread erzeugt ist es IMHO Unsinn auch noch beim Caller einen neuen Thread zu erzeugen der eigentlich nur dazu dient untätig zu blockieren bis der Callee fertig ist.

Hast du ja recht, aber würde halt die Sache mit dem Callback (ohne das man das zusätzlich über den Kernel implementieren müsste) einfacher machen.

Würde das eigentlich auch für Signale so funktionieren oder muss das zwingend an einen bestimmten Thread und nicht nur Task gehen? Ich überlege immernoch ob man Signale über IPC (was dann einen Port pro Anwendung die Signale nutzen möchte) oder über nen Art Callback macht.
Wobei mit obigen Callback hätte die IPC Variante weniger Overhead.

Davon bin ich nicht unbedingt überzeugt, aber ich schätze zumindest für Dinge wie stdin/stdout/stderr dürfte das zutreffen.

Dann sag mir doch mal ein paar Sachen die immer/meistens über 4kb liegen, aber nicht gleich mehrere MBs sind, so dass Mapping sich auf jeden Fall lohnt.

Tolle Idee, aber dann mach doch gleich richtiges Memory-Mapped-File-I/O.

Ich hatte das immer so verstanden, dass da einfach ein, gewünschter, Teil der Datei in den User-Prozess gemappt wird!? Und damit man den User-Prozess nicht zuspamt dachte ich halt an ein oder zwei Pages. Denn Dateien die größer sind als der Adressraum, können sowieso nicht vollständig eingeblendet werden.

Das mit dem Datei einblenden ist auch eine Sache die dafür Spricht fork() nicht anzubieten. Denn so spare ich mir das ich auf jeden Fall FD´s haben muss, die gesharet werden können.

122

OS-Design / Re: Flexibles und einfaches Prozess erzeugen

« am: 19. October 2011, 17:02 »

Immer? Auch wenn es sich nur um eine unidirektionale Kommunikation handelt? Falls ja empfände ich das als etwas übertrieben.

Praktisch bisher ja, theoretisch muss aber auf jeden Fall auf Empfängerseite immer ein Port vorhanden sein, nicht aber auf Senderseite, aber dann kann man auch nicht auf eine Nachricht antworten.

Asynchrones File-I/O (was auch Character-Devices und Stream-Sockets usw. mit einschließt) funktioniert in etwas so das der aio_read()/aio_write()-Aufruft nicht so lange bis alles erledigt ist intern blockiert sondern das der Caller (fast) sofort aus der aio_read()/aio_write()-Funktion zurückkommt und weiterarbeiten kann, intern (im VFS) wird dann dieser Job eigenständig abgearbeitet (und, zumindest bei einem Monolithen, auch direkt mit dem bei aio_read()/aio_write() übergebenen User-Buffer gearbeitet) so das dann am Ende oder bei einem Fehler der zum Abbruch führt (z.B. EOF) dann ein Call-Back o.ä. an die Applikation durchgeführt werden kann der das Ergebnis signalisiert (ab hier kann die Applikation auch die Buffer die bei aio_read()/aio_write() mitgegeben wurden wieder normal nutzen, eventuelles Memory-Sharing muss hier also beendet werden).

Hmm, spontan würde ich sagen, einfach durch aio_read()/aio_write() nen neuen Thread erstellen, der dann normales RPC macht, aber der Caller (der den Thread erstellt hat) kann sofort danach (Threaderstellung) weitermachen.

Nur das mit dem Callback verstehe ich noch nicht ganz bzw. leuchtet mir noch nicht ein, was der genau bewirkt. Ich meine am Bsp. aio_read() (das ich nicht wüsste was eine Anwendung weiter machen sollte, wenn sie noch keine Daten hat, ist erstmal egal), was ändert dieser Callback, dass die Anwendung miteinmal die Daten, die jetzt vorhanden sind, nutzt? Wird der Code der die Daten verarbeitet direkt in dem Callback ausgeführt? Wird für den Callback der laufende Thread unterbrochen (wenn ja, welcher Thread, bei Multithreading) oder wird dafür ein neuer erstellt?

wenn die nicht wären würde sich Mapping (fast) immer lohnen (außer wenn die Daten so wenig sind das nicht mal eine einzige Page voll wird).

Also wahrscheinlich für verdammt viele Sachen in einem Mikrokernel!? Selbst viele (die meisten?) read()´s und write()´s dürften darunter fallen. Womit wir dabei wären, kopieren ist meistens schneller als Mappen. Denn ich gehe davon aus, dass das meiste was per IPC kommuniziert wird unter 4kb liegt.

Soweit Theorie. Ein Bsp. fällt mir ein wo mapping schneller wäre, anstatt die Daten die man per read() anfordert ständig in einzelne Msgs zu kopieren, könnte man immer eine oder zwei Pages der Datei per Mapping in den Prozess gemappt haben und die read()´s lesen direkt daraus. Das verzögerte Dateipointer aktualisieren dürfte doch kein Problem sein (wenn man mal davon ausgeht, das nicht der gleiche Dateipointer von mehreren Prozessen zum Lesen verwendet wird, wofür ich kein vernünftiges Bsp kenne).
Selbst für (zumindest exklusives) das Schreiben kann man so vorgehen. Es wird immer direkt in die Memory gemappte Datei geschrieben und nur bei der Anforderung eines neuen Bereiches der Datei oder dem expliziten fseek() muss auch der Dateipointer im VFS aktualisiert werden. Das ganze würde natürlich nicht für das Schreiben von Daten von verschiedenen Prozessen aus in die gleiche Datei funktionieren.

123

OS-Design / Re: Flexibles und einfaches Prozess erzeugen

« am: 19. October 2011, 09:14 »

Wenn eine Antwort was anderes ist, wie funktionieren denn bei dir asynchrone Antworten?

Man muss bei mir zw. RPC (wozu auf der Sender-Seite kein Port notwendig ist) und asynchronem IPC unterscheiden (hier ist auf der Sender und Empfänger-Seite ein Port notwendig).

Aber ihr habt mir mit dem Callback schon neue Ideen geliefert. Ich überlege, ob man darüber nicht Signale (in Form eines Signal-Servers) anbieten könnte. Allerdings hieße das, das man dann immer "Nachrichten" an diesem Callback bekommen könnte, sprich da wäre kein Anfrage-Antwort-Prinzip.

Könnte denn mal jemand ein Bsp. aus der Praxis bringen, wo asynchrones IPC genutzt wird, weil mir fällt so nur asynch-I/O ein, aber da wartet man doch auch nicht auf eine Antwort (das habe ich sowieso nicht ganz verstanden wie das genau funktioniert)?

Das Arbeitsäquivalent für die Zeit in der eine CPU X Bytes kopiert dürfte sich in den letzten 20 Jahren nur wenig verändert haben, genau weiß ich das aber nicht, so das man davon ausgehen kann das Kopieren in Software immer etwa gleich teuer ist (relativ unabhängig von der absoluten Performance der CPU).

Das ist halt Situationsabhängig. Der Flaschenhals bleibt im Endeffekt der Speicherbus. Desto schneller die CPUs werden, desto mehr Takte müssen sie auch warten bis der Speicher dann "verfügbar" ist. Das kann negativ für das Kopieren sein, aber auch fürs Mappen.

Natürlich ist auch das Erstellen eines Mappings nicht kostenlos, bei meinen Segmenten könnte eventuell das Erstellen eines neuen Segments sogar ein bisschen mehr kosten als zwei oder drei Pages bei Flat-Memory, so das man auf jeden Fall mal ausmessen sollte wie viele Bytes man in der selben Zeit kopieren könnte um zu wissen aber welcher Menge an Nutzdaten sich das Mapping überhaupt lohnt.

Man könnte davon ausgehen, das die Daten schon im Cache sind und von daher, sollte das Kopieren von 2 oder 3 Pages wirklich kein Problem darstellen (vorallem nicht bei den heutigen Caches).
Zumal ich nicht von mehreren MBs rede, sondern von wenigen KBs, das sollte sich wirklich vernachlässigen lassen.

124

OS-Design / Re: Flexibles und einfaches Prozess erzeugen

« am: 18. October 2011, 19:53 »

Also da kann ich mir so einiges vorstellen: z.B. ein Programm könnte den SHM erstellen und dann weitere Kind-Prozesse starten und diesen die nötigen Zugriffsinformationen gleich als Command-Line-Parameter o.ä. mitgeben.

Das stimmt wohl, irgendwie vergesse ich immer die Command-Line-Parameter (auch bei meinen Überlegungen zwecks Prozesserstellung und sowas). Hast du dafür mal nen richtiges (in Form einer Anwendung, real existent) Bsp?
Michwürde halt interessieren, ob das eher selten ist oder ob sogar ein Service mit reinspielt und ob es sich lohnt das ganze noch anders umzusetzen.

Der Nutzwert von Zero-Copy ist IMHO unabhängig vom Alter des Systems, Kopieren kostet immer unnütz CPU-Zeit.

Ist erstmal richtig, aber wenn man sich dann die Zeit anguckt, die gespart werden kann, kann man den ganzen Spaß auch vernachläßigen (vorallem wenn man daran denkt, das die meisten Rechner die meiste Zeit eh nix tun).

Zumal man auch den Overhead durchs Mappen nicht vergessen darf, ich denke mal bis zu einer gewissen Menge an Speicher ist kopieren sogar schneller als Mappen. Allerding bleibt es auch so, das die Zeit die absolut dafür gebraucht wird, bei vielen Sachen inzwischen zu gering ist als das sie auffallen würde.

125

OS-Design / Re: Flexibles und einfaches Prozess erzeugen

« am: 18. October 2011, 18:03 »

und FlashBurn wohl auch, falls ich Euch da missverstanden habe so Bitte ich um konkrete Aufklärung

Bei mir gibt es SHM nur in Verbindung mit IPC. Ich mache es daher mehr oder weniger so wie du. Du kannst beim Senden einer Nachricht angeben, dass du nen gewussen Speicherbereich mitsenden willst (was dann halt SHM wird). Ich möchte den Syscall sogar so allgemein machen, dass du nur durch ein Flag auch den Speicher versenden (Speicher wird auf Senderseite ungemappt) kannst.

Einen Nachteil den ich darin sehe ist, dass man für SHM also immer nen Port braucht (der die Nachricht/den SHM bekommt), aber das ist nicht wirklich schlimm. Denn wie bekommt man die SHM-ID in einen anderen Prozess, wenn nicht über IPC, sprich der Port muss eh vorhanden sein.

Naja, damit kommen wir direkt wieder zur Diskussion von Popup-Threads. Ich halte es nach wie vor übertrieben, von allen Programmen zu verlangen, dass sie threadsafe sind.

Das trifft nur Programme die Nachrichten auch empfangen können (und eine Antwort ist bei mir nicht eine Nachricht zu empfangen) und bei denen sehe ich nicht so das Problem.

Was für Programme und Probleme schweben dir denn dort genau vor?

Was die Puffer angeht, führt bei einem x86-OS mit flachem Speichermodell nichts dran vorbei, das ist keine IPC-Designentscheidung.

Das stimmt so nicht. Es wäre möglich, indem einfach alle Puffer an 4kb ausgerichtet wären oder man es mit der Sicherheit nicht so genau nimmt, nicht schön, aber möglich.

Vorallem sollte man auch immer das Verhältnis betrachten, von was für Puffern sprechen wir hier? Alles was größer als 4kb ist, kann man doch auch ruhig an 4kb ausrichten und alles andere müsste halt kopiert werden, aber da ja niemand hier mit solch "alter" Hardware wie ich plant, sollte das auch kein Problem darstellen.

126

OS-Design / Re: Flexibles und einfaches Prozess erzeugen

« am: 17. October 2011, 10:58 »

Aha, da ist dann aber doppelte Indirektion weil der Code im Programm ja nicht direkt das Plug-In aufruft sondern dies immer über einen Vermittlungsmechanismus tut, sehe ich das richtig?

Ich weiß nicht was du mit doppelter Indirektion meinst, aber es ist nix anderes als Irgendwo Funktionspointer zu haben, zumal die Performance in dem Fall keine Rolle spielt.

Und der Loader findet diese Funktion anhand eines fest definierten Label-Namens?

Jap, du suchst z.B. per dlsym("initFS") nach einem Symbol und kannst die Funktion dann aufrufen. Im Endeffekt implementiert jedes Modul mind. die nötigen API Symbole (init, deinit usw).

Interessant aber erklärt auch nicht wie dieses dynamische Linken hinter den Kulissen genau funktioniert.

Wo genau hapert es bei dir? Ich meine du lädst halt das Modul, was nen shared-object ist und löst alles externen Symbole auf. Dazu brauchst du entweder weitere Libs, aber auf jeden Fall brauchst du die Symbole von dem Programm was das Modul geladen hat.
Die Symbole die du aus deinem Programm heraus dann im Modul nutzen willst, holst du dir halt über dlsym().

Das einzigste Problem das ich sehe ist das die Zugangsdaten zum Device-Treiber ja noch immer in dem Programm vorhanden sein können und demzuvollge auch benutzt werden können, von daher wäre es nicht schlecht wenn das VFS bei jedem open auf ein Device dem Treiber ein weiteres Set an Zugangsdaten mitteilt die dann auch das Programm bekommt und diese Zugangsdaten beim close vom VFS beim Device-Treiber wieder gelöscht werden. Sicher is Sicher.

Das will ich direkt mit Hilfe des IPCs lösen. Bei meinen Ports kannst du die Lese- und Schreibrechte grob angeben, heißt lesen global, ein Thread oder ein Task und schreiben auch global, ein Thread oder ein Task.
Für die Treiber bräuchte man dann 2 Ports, einen für das VFS (wo auch niemand anders reinschreiben darf) und einen für den Nutzer. Wenn der Nutzer eine Gerätedatei öffnet, sagt das VFS dem Treiber wer das war und der Treiber ändert entsprechend die Schreibrechte für den anderen Port. Genauso wenn der Nutzer die Gerätedatei wieder schließt, dann bekommt der Treiber ne Nachricht und ändert die Rechte entsprechend.

Der Benchritigungs-Mechanismus gehört auch meiner Meinung nach ganz klar ins VFS, dort müssen alle wirksamen/sichtbaren Änderungen durch.

D.h. aber das wirklich alle Sachen auch durchs VFS müssen und dass man z.B. die libc nicht direkt mit dem Treiber/Dateisystem kommunizieren lassen kann.

127

OS-Design / Re: Flexibles und einfaches Prozess erzeugen

« am: 16. October 2011, 13:38 »

FlashBurn, eine Frage, die sich mir bei deinem ursprünglichen Modell stellt, ist, ob man in deinem OS auf Sachen wie Block und Character Devices mit den normalen Dateisystemoperationen zugreifen können soll. Habe ich also irgendwie sowas wie ein /dev/hda? Wenn ja, dann hast du schon Treiber vorgesehen, die außerhalb des VFS liegen und an die Requests einfach durchgereicht werden müssen. Warum nicht also konsistent das gleiche mit Dateisystemen machen?

Ansich würde ich schon sowas wie /dev/ haben wollen, nur habe ich noch keine Vorstellung wie das Interface dann aussehen soll und wie das ganze dann läuft. Ich dachte da irgendwie daran, das man Devices öffnen, schließen und lesen kann. In der "Datei" wären dann genau 4bytes gespeichert und das wäre der IPC-Port des Treibers.
Problem ist halt, ich habe sowas noch nie programmiert (Hardwarezugriff über solchen "Dateien").

Ansonsten hast du mir doch jetzt einen sehr guten Grund geliefert die Dateisysteme doch als eigenständige Prozesse zu implementieren.

Nur wie setzt man dann sowas (besser wo) um wie gleichzeitiger (unabhängiger) Lese-Zugriff und ein anderes Programm schreibt in diese Datei. Ich möchte etwas implementieren so dass ich bei Änderungen eine Benachrichtigung bekomme. Nur wird das im VFS oder im Dateisystem implementiert?

Die Metadaten in eine Pipe und die Nutzdaten eventuell über einen anderen Mechanismus wie Shared Memory klingt für mich eigentlich sehr sinnvoll (und deswegen ist das ja auch die Richtung, in die wir mit LIOv2 gehen).

Klingt ähnlich wie mein IPC System, meine Nachrichten bestehen aus 32byte "Metadaten" und Shared Memory als Nutzdaten. Allerdings kopiert man dadurch natürlich viel wenn nicht direkt das IPC, sondern z.B. die libc genutzt wird.

So wir werden schonwieder ganz schön OT, für eine Diskussion zwecks VFS oder IPC sollte man vllt nen neuen Thread aufmachen

128

OS-Design / Re: Flexibles und einfaches Prozess erzeugen

« am: 16. October 2011, 12:14 »

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.

Das wäre alles kein Problem, da man sowas ja beim Mappen mit angeben kann. Auch ASLR kann wunderschön im Loader implementiert werden ohne das der Kernel geändert werden muss oder etwas darüber wissen muss.

Was Plug-Ins betrifft, ist kein Plug-In geladen ist auch kein Element in der Liste. Die Listeneinträge werden erst erstellt wenn ein Plug-In geladen ist und sehen z.B. so aus:

Code: [Auswählen]

struct PlugInAPI {
 uint32 (*open)(const char* name);
 uint32 (*close)(uint32 handle);
};
Und jedes Plug-In muss mindestens die Symbole haben, die man für diese Struktur benötigt oder am besten noch, die Struktur selbst ist im Plug-In gespeichert und kann durch einen Funktionsaufruf geholt werden.

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.

Ich kann dir gerade nicht ganz folgen was du genau meinst, aber ich habe ne art PageStruc Tabelle, wo für jede physisches Page gespeichert ist, wie oft sie gemappt ist und noch zusätzlich ein 4byte Wert gespeichert werden kann (wird im Mom nur vom SlabAllocator genutzt um auf die Slab-Struktur zu kommen).

Ansonsten hätte ich gesagt, kann man beim Speicheranfordern/Mappen sagen, ob der Speicher geswappt werden darf oder nicht.

Edit::

Was dynamisches Laden zur Laufzeit betrifft: http://en.wikipedia.org/wiki/Dynamic_loading

129

OS-Design / Re: Flexibles und einfaches Prozess erzeugen

« am: 15. October 2011, 22:07 »

Ich dachte Dein Loader ist dann in jedem Prozess mit enthalten damit er später eben AddOns nachladen kann usw., aber wenn der extern bleiben soll is auch gut, wobei das dann einige Dinge wohl ziemlich umständlich machen würde.

Das meintest du, ja dann hast du recht, aber bei Linux ist es doch genauso (dort ist es irgendeine ld.so oder so). Der Runtime-Loader liegt als ein fertiges Programm vor, dass nur noch gemappt werden muss (und damit in jedem Prozess die selben Pages nutzt).
Benutzt der Prozess keine Plug-Ins oder ähnliches zur Laufzeit, kann man diesen ja wieder unmappen bzw. würde es wahrscheinlich besser sein, einfach nach bestimmten Symbolen zu gucken (das wäre z.B. dlopen() und solche Sachen) und ihn dann nicht zu unmappen, ansonsten aber schon.

Trotzdem wüste ich gerne wie das überhaupt funktionieren soll. Werden dann Reste in der Executable nachträglich reloziert?

Plug-Ins zur Laufzeit funktionieren so, dass du dir ne Liste von denen merkst und die ein ganz bestimmtes 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.

Das hängt doch nur davon ab ob Du ein IPC mit geringem Overhead (wie z.B. Zero-Copy) hinbekommst.

Wohl eher nicht bzw. hängt davon ab wie detailiert du es betrachtest. Das Senden und Empfangen von Daten sollte mehr oder weniger per Zero-Copy gehen, die eigentliche Kommunikation (welche Operation und sowas) wird durch kopieren passieren und 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).

Welche denn? Solange Du das API zwischen VFS und den Dateisystemen klar strukturierst sollte es völlig egal sein ob da IPC dazwischen ist oder nicht.

Wo würden dann die FD´s sein? Im VFS oder im Dateisystem-Programm?

Für jedes Dateisystem einen eigenen Prozess zu benutzen ist nicht unbedingt langsam. Die meisten Dateisysteme arbeiten ohnehin mit realen Devices, deren Latenz wesentlich größer sein dürfte als der Overhead eines Kontextswitches (allein schon, weil es durch das PCI-Subsystem muss - und damit durch mindestens zwei weitere Kontextwechsel).

Overhead ist da, aber er wäre so geringer.

Ich versuche mir das gerade vorzustellen. Das VFS müsste auf jeden Fall immer alle Pfade bis zu einem Mount-Point zwischenspeichern. Auch wäre es bestimmt nicht schlecht wenn Directories irgendwie gecacht werden.

Ansonsten wären das halt anstatt Funktionsaufrufen IPC-Requests. Möglich wäre es, nur die Frage wofür man optimiert? Wenn ich da an SSDs denke, könnte sich der Overhead bemerkbar machen oder? Bei normalen HDDs nicht.
Aber was wäre durch den Overhead gewonnen? Zumal es halt wesentlich mehr Speicher verschlingen würde und den Systemstart nicht einfacher macht. Ich wüsste jetzt auch nicht wie komplex solche "Programme" dann wären, sprich was sie an Libs benötigen würden.
Da muss ich nochmal ne Nacht drüber schlafen, aber ihr könnt ja versuchen es mir schmackhaft zu machen

130

OS-Design / Re: Flexibles und einfaches Prozess erzeugen

« am: 15. October 2011, 21:08 »

und der hohe und redundante Speicherverbrauch wurde auch schon erwähnt.

Hier stehe ich irgendwie aufm Schlauch, welcher hohe und redundante Speicherverbrauch?

Warum nicht den Executable-Loader in den Kernel packen? Wenn Du unbedingt AddOns haben willst dann lass die als Vorverarbeitung im User-Space laufen und erst das fertige Executable (das dann im simplen Format für den Kernel vorliegt) an den Kernel weitergeben.

Naja, keine halben Sachen, sprich entweder ganz oder gar nicht. Soll heißen, mit dem einfachen Format wäre es ja nicht getan, um zur Laufzeit Libs nachladen zu können, müsste der Kernel entweder die Formate kennen oder ich brauche was im UserSpace. Dann sagst du, dass das halt der UserSpace-Teil machen soll, aber wo sind dann die Symboltabellen?
Deswegen soll der Kernel gar nix davon wissen und der entsprechende Runtime-Loader ist immer und dauerhaft im Prozess gemappt (obwohl man da optmieren könnte und jeder Prozess könnte festlegen ob das wirklich sein muss). Damit ginge zwar auch "nur" das Libs nur im selben Format nachgeladen werden, wie das Hauptprogramm, aber ich denke mit der Einschränkung kann ich leben

Vor allem wüste ich gerne mal was Du mit Modulen meinst.

Ich habe alle meine Beiträge nochmal gelesen und da tauchen keine Module, aber sehr wohl Add-Ons auf. Das sollen ne Art Plug-Ins sein, die erst zur Laufzeit hinzugefügt werden.

Bei fork() muss übrigens auch der Stack komplett mit kopiert werden, und auch alle anderen Speicherbereiche (auch solche die erst zur Laufzeit angelegt wurden) ich glaube sogar Shared-Memory (bin mir da aber nicht sicher). Es sollte auf jeden Fall noch jeder Pointer funktionieren.

Das macht die Sache doch einfacher, darum ging es mir eigentlich nur.

Die Dateisysteme mit in den VFS-Prozess zu integrieren empfinde ich auch als etwas zu monolithisch, da hätte man ja wieder einen fetten Single-Point-of-Failure.

Das muss ich bei der konkreten Implementierung sehen. Im Moment gefällt mir das irgendwie nicht, dass jedes Dateisystem seinen eigenen Prozess bekommt. Das kostet wahrscheinlich richtig Performance und verursacht bestimmt auch neue Probleme.

Wenn ich natürlich sehe, dass die Dateisysteme nur an wenigen Bestimmten Stellen so aufgerufen werden, dass ich sie auch auslagern könnte, kann ich darüber ja nochmal nachdenken.

Ich wollte nur rasch hierzu was sagen: Und zwar ist ja IPC eine zentrale Aufgabe des Mikrokernels. Somit finde ich das VFS im Kernel bei einem OS, das das VFS als primäre IPC-Methode benutzt nicht soo verkehrt.

Wie soll ich mir das vorstellen, das VFS als primäre IPC-Methode? Pipes und Dateien?

131

OS-Design / Re: Flexibles und einfaches Prozess erzeugen

« am: 15. October 2011, 15:38 »

Wenn dein VFS-Server sämtliche Dateisysteme beinhaltet (und sei es dynamisch nachladbar als Plugin), dann ist das schon monolithisch.

Naja, dass sehe ich z.B. als KISS an. Wie gesagt, die Dateisysteme auch noch in eigene Prozesse auszulagern würde zu noch mehr Problemen führen.

Da ich das VFS zu den grundlegendsten Funktionalitäten zähle (neben Speicher- und Prozessverwaltung), darf es auch in einem Mikrokernel im Kernel selbst implementiert sein.

Wow, dann wäre der Haiku-Kernel ja für dich auch noch nen MikroKernel (ich möchte meinen die haben "nur" das VFS im Kernel, bin mir aber nicht sicher). So ist das halt mit den Auslegungen

Warum nicht?

Zu unflexibel (in meinen Augen) und verwendet Konzepte die ich absolut nicht nachvollziehen kann (ich meine damit, dass ich sie verstehe, aber nicht verstehe warum sie genutzt werden). Mal ganz davon abgesehen das ich ihn inzwischen auch für bloated halte und wie man den nicht konfigurieren kann, damit er ja auch auf allen Architekturen läuft. Dann lieber vieles physisch voneinander trennen und den Kernel so klein wie möglich halten (da würde ich dann sogar nix gegen ein VFS im Kernel haben, ist ja wie du sagtest ein muss für das OS).

132

OS-Design / Re: Flexibles und einfaches Prozess erzeugen

« am: 15. October 2011, 15:11 »

Definiere "richtiger Mikrokernel". Nur, weil PMM und VMM im Kernel liegen, ist das noch lange kein Monolith.

Das sehe ich ja genauso, nur je nach dem wen du fragst ist das dann schonmal kein MikroKernel mehr.

Plugin-Technologien sind dagegen ein dynamischer, monolithischer Ansatz. Ein einzelner, riesiger, monolithischer Userspace-Prozess auf einem Mikrokernel führt das Mikrokernelkonzept ohnehin ad absurdum.

Naja, was würdest du denn als einzelener monolithischen Userspace-Prozess bezeichnen?

Die Treiber werden wahrscheinlich alle in ihrem eigenem Prozess laufen und die Services sind auch getrennt. Nur sehe ich halt nen Dateisystem nicht als Treiber an.

Und ein Betriebssystem mit einem Mediaplayer zu vergleichen finde ich etwas abwegig.

Da ging es mir auch nur darum, dass die ganzen unterstützten Media- und Dateiformate dynamisch nachgeladen werden können, aber nicht in einem eigenen Prozess laufen (was ja wohl auch Overkill wäre, aber bestimmt einfacher umzusetzen als die Sache mit den Dateisystemen).

Warum baust du dann eigentlich keinen monolithischen Kernel? Da kannst du die Performance eh am feinsten steuern.

Was die Performance betrifft hast du da mMn recht. Allerdings mag ich das vieles physisch getrennt von anderen Sachen läuft (z.B. Treiber und die Services). Man kann halt auf nem MikroKernel viele Sachen einfacher dynamisch machen und vorallem leichter austauschen.

Nen schön modularen Monolithen gab es mit BeOS und gibt es wieder mit Haiku. Nur mit dem Linux-Kernel kann ich mich absolut nicht anfreunden (Windows kann ich nix zu sagen, da ich darüber zu wenig weiß).

Auf CDs würde ich gerne die Variante von BeOS nutzen. Da hat man mehrere Tracks auf der CD, der erste Track ist nen normales ISO9660 und die weiteren sind BeFS Images (einmal ein x86 und einmal ein PPC Image).

133

OS-Design / Re: Flexibles und einfaches Prozess erzeugen

« am: 15. October 2011, 14:39 »

Du baust alle Dateisystemtreiber in den VFS-Server ein? Das ist aber kein sehr mikrokerneliger Ansatz.

Hmm, darüber lässt sich jetzt streiten

Aus sicht einiger Vertreter habe ich sowieso keinen richtigen MikroKernel da ich ja den Speichermanager im Kernel habe. Allerdings wieso ist dem nicht so? Es läuft nicht im Kernel und so richtig als Treiber würde ich es nicht sehen. Ich habe einen Service (der VFS-Server) und den kann ich per Add-Ons erweitern (so wie Video- und Containerformate bei Mediaplayern).

Wenn ich die Sachen auch noch jeweils in einen extra Prozess lege, dann geht die Performance ja richtig in den Keller, es wird mehr Speicher verbraucht und macht die Sache ja noch komplexer (weil dadurch wieder neue Probleme auftauchen würden).

inux hatte mal UMSDOS, das irgendwie zusätzliche Metadaten auf einem FAT-Dateisystem angelegt hat. War aber wohl immer relativ kaputt und ist soweit ich weiß mittlerweile auch rausgeflogen.

Hmm, ich weiß das Linux von nem FAT32 USB-Stick starten kann (obwohl es sein kann das da dann nen Image drauf ist, aber da waren so viel Dateien drauf) und von CD.

134

OS-Design / Re: Flexibles und einfaches Prozess erzeugen

« am: 15. October 2011, 12:47 »

Das heißt, dass du den Dateizeiger im VFS-Server hast und die Programme alle Requests nicht direkt an den Treiber schicken, sondern an den VFS-Server, der die Requests dann entsprechend weiterleitet? Was bedeutet das für die Performance?

Am liebsten wäre es mir wenn die Dateizeiger in der libc wären, aber das wäre ja noch umständlicher mit dem sharen. Das Thema hatten wir ja schon, wie das so ist mit den gemeinsamen Dateizeigern, ob da wirklich gleichzeitig geschrieben und/oder gelesen wird.

Gerade zwecks Performance sehe ich es als besser an das ganze Dateimanagement an einem Ort zu machen. Ich cache sozusagen die Dateien im VFS-Server (immer in vielfachem der Page-Größe bzw. "Cluster"-größe, je nach dem was größer ist).
Vorallem von welchem Treiber redest du? Der Medium-Treiber kennt keine Dateisystemstrukturen, die sind als Add-On im VFS-Server und der holt sich die Daten von den Treibern (wie genau ich das mit den Treibern und Bus-Treibern mache, muss ich mal sehen).

Vielleicht so: Ein Prozess hat ein Flag, das sagt, ob der VFS-Server im Adressraum rumpfuschen darf. Das erste, was der Prozess in _start macht, ist dieses Flag zu löschen und während exec setzt er das Flag halt wieder.

Das ist eigentlich ne richtig gute Idee. So kann jeder Prozess selbst entscheiden ob er das zulässt bzw. halt nur exec().

Warum willst du für die Systempartition etwas benutzen, das keine Rechte kann?

Ich bin Windows-User und der Einfachheit halber. Ich wollte mich aber eigentlich mal mit extfs2 auseinander setzen und das in meinem Bootloader implementieren (bisher habe ich nur FAT und ISO9660). Linux scheint das doch auch irgendwie hinzubekommen, mit nem Overlay oder so.

135

OS-Design / Re: Flexibles und einfaches Prozess erzeugen

« am: 15. October 2011, 11:01 »

Das große Problem beim fork() ist nicht das Kopieren des Adressraums, sondern dass die beiden Prozesse hinterher gemeinsame Dateideskriptoren haben müssen.

Naja, für mich ist eher das Kopieren des Adressraums ein Problem und nicht die Dateidiskriptoren. Wegen den FD´s (und aus einem anderen Grund) wird das ganze ja auch über den VFS-Server gemacht.

Ob es so clever ist, jedes Programm eine zusätzliche Lib für den VFS-Server installieren zu lassen, weiß ich nicht.

Jap, ist mir auch schon aufgefallen, zumal es wahrscheinlich daran scheitern würde, dass es nicht reicht das Programm einfach zu "injezieren", weil fast alle Programme noch Libs hätten und dafür bräuchte man wieder den Runtime-Loader.
Sprich die ganze Sache mit dem in einen leeren Adressraum injezieren, bleibt den Runtime-Loadern vorbehalten.

Und warum ist ausgerechnet der VFS-Server für das Starten von Prozessen zuständig?

Will man das Unix-Konzept "alles ist eine Datei" nutzen, ist das nun man die Stelle schlechthin dafür (ob ich das nutze, weiß ich noch nicht, wird wohl aber darauf hinauslaufen). Dann kommt noch hinzu, dass der Kernel nix von den Runtime-Loadern weiß, sondern nur der VFS-Server und auch nur diesem ist es erlaubt die leeren Prozesse mit Leben zu füllen.

Ein Problem wäre nur, wenn ich dann schon fork() habe, dann muss ich natürlich auch noch exec() umsetzen und das bereitet mir ein wenig Sorgen. Denn wenn ich dem VFS-Server auch noch die Möglichkeit gebe, den Adressraum eines vorhandenen Prozesse komplett zu löschen, haben alle Add-Ons ganz schön viel Rechte. Allerdings will ich der Einfachheit halber, dass ganze über Datei-Rechte lösen. Sprich man braucht root-Rechte um überhaupt ein Add-On an seinen Platz zu schaffen (die müssen in einem bestimmten Ordner liegen) und ich gehe einfach davon aus, dass das System wenn es installiert wird, sicher ist.
Selbst wenn ich Dateisystem nicht derartige Rechte unterstützt kann ich einfach bestimmte Ordner festlegen wo man für Schreibrechte (Leserechte sind da nicht so wichtig oder?) root-Rechte braucht. Das ganze lässt sich auch wunderbar im VFS-Server umsetzen.

136

OS-Design / Flexibles und einfaches Prozess erzeugen

« am: 14. October 2011, 21:11 »

Ich wollte keine ewig alten Threads aus der Versenkung holen, deswegen mache ich mal nen neuen auf, auch wenn das Thema (Prozesserstellung) schon ein paar Mal diskutiert wurde.

Da ich bisher immer noch nicht so richtig weiß/wusste wie ich einen Runtime-Loader haben kann, der als Programm vorliegt, ist mir jetzt eine Idee für die Prozesserstellung gekommen, mit der ich vllt sogar fork() anbieten kann, ohne das auf Kernel-Ebene machen zu müssen.

Mein createTask() soll nur einen komplett leeren Task erstellen, nicht mehr und nicht weniger.

Der VFS-Server kann dann über eine private Kernel-API (die soll so geschützt sein, dass nur der VFS-Server sie aufrufen kann) Speicher in einen Prozess "injezieren" (im Endeffekt mappen) können und zwar an Adressen wo er das gerne hätte (soweit es da keine Überschneidungen gibt).

Damit ist es möglich einen Runtime-Loader, der als Programm vorliegt, in den leeren Prozess zu injezieren, einen neuen Thread zu erstellen und dieser Thread führt dann den Runtime-Loader aus, welcher sich die Daten (die ausführbare Datei und die nötigen Libs) vom VFS-Server holt und parst.
Ein weiterer Vorteil ist, dass ich dann auch einfach mehrere Runtime-Loader, für verschiedene Dateiformate, haben kann und vorallem bleiben diese im Prozess gemappt und der Prozess kann dann später noch Libs nachladen (Plug-Ins) und die Symbole auflösen lassen.
Der Runtime-Loader würde dann aus 2 Dateien bestehen, einmal aus dem eigentlichen Runtime-Loader (als Programm oder ne Art Programm, da bin ich mir noch nicht sicher) und einmal aus nem Add-On für den VFS-Server. Das Add-On wäre dafür da, dass der VFS-Server weiß welchen Runtime-Loader er für welche Datei nehmen muss (ne einfache Funktion, die nen Pointer auf z.B. die ersten 8kb von der Datei bekommt und den Header überprüft).
Ganz nebenbei könnte man so auch das Starten jeglicher Dateien, wo Programme für installiert sind, lösen. Sprich jedes Programm bringt für jeden Dateityp den sie unterstützt ein Add-On für den VFS-Server mit (z.B. ein Media-Player ein Add-on für jedes Container-Format oder so). Ist das Overkill? Ich meine man muss ja nicht, man könnte aber, die Funktionalität wäre gegeben.

Genauso kann ich es so ermöglichen das ein fork() über den VFS-Server stattfindet. In dem einfach der schon vorhanden Prozess per COW in den neuen Prozess injeziert wird.

Eine Frage zum fork(), wird da wirklich der komplette Adressraum geclont oder werden z.B. die Stacks weggelassen? Weil letzteres wäre dann schon wieder schwieriger umzusetzen (und wahrscheinlich nicht ohne die Hilfe des Kernels).

137

OS-Design / Re: Nicht unterbrechbarer Kernel

« am: 12. October 2011, 16:39 »

FlashBurn ist ein typischer Vertreter des deutschen Over-Engineerings.

Also erstmal danke für das Kompliment

OT:
Sind wir deutschen wirklich dafür bekannt?

138

OS-Design / Re: Nicht unterbrechbarer Kernel

« am: 12. October 2011, 14:18 »

Du scheinst Simplizität immer als absolute Simplizität anzunehmen und nie in Relation zur Problemstellung zu setzen.

Ah, also subjektiv. Denn wer legt fest was relativ ist?

Dann zur Problemstellung, in meinem Fall heißt das, der Kernel soll MAP_NOW anbieten (es soll nicht irgendwie über den UserSpace gelöst werden) und der Kernel soll eine gewisse maximale Zeitspanne nicht mit Ints aus laufen.

Also entweder man nimmt KISS wörtlich und dann braucht man mMn auch nix besseres als ne Liste (lasse mich gerne eines besseren belehren) oder es ist abhängig von den Anforderungen.

Um mal wieder nen Autovergleich zu bringen. Willst du nen Auto das fährt brauchst du keine hoch-komplexen Motoren, wie wir sie heute haben. Willst du aber nen Auto das auch noch wenig Verbraucht, also effizient ist, brauchst du nen komplexen modernen Motor.
Selbst wenn es vllt einfache Grundprinzipien gibt, ist die Umsetzung dann meistens komplex.

Ich verstehe z.B. nicht wozu Du verschiedene Arten von Threads mit unterschiedlichen Speicheranforderungen haben möchtest.

Anforderung -> max. Zeitspanne mit Int aus => der Code muss im Kernel unterbrechbar gemacht werden, wenn er Gefahr läuft zu lange zu brauchen.

Ich habe in dem Sinne auch nicht verschiedene Arten von Threads. Ich setze da nirgends ein Flag was sagt, du bist jetzt ein Kernel-Thread und du ein User-Thread (gut man könnte argumentieren, dass ich das indirekt mache).

Bei mir werden Threads nur Attribute haben, z.B. Dämon-Thread (die den Prozess-Tod nicht blockieren) oder PopUp-Thread (vom IPC-System), aber diese Attribute spielen nur in einer eng begrenzten Anzahl an Situationen eine Rolle (z.B. ein PopUp-Thread darf sich nicht einfach selbst killen, was sollte in so einer Situation das IPC-System dem Caller als Antwort geben?) und werden ansonsten ignoriert (weder der Scheduler noch die Exceptionhander oder der generische IRQ-Handler interessieren sich für die Thread-Attribute wenn sie einen Thread von der CPU schmeißen u.ä.).

Das finde ich komplex. Wieso kannst du nicht nur eine Art von Thread haben

Hä? Du meinst ne Minifunktion aus der libOS? Also die die das kleine Stück Inline-Assembler enthält.

Jap. Mir fällt auf, das immer nur von Open-Source ausgegangen wird. Wenn das Programm aber nur in binärer Form vorliegt (und man nicht den DAU entscheiden lassen möchte welche Version er braucht, ob Intel oder AMD), dann macht genau solch eine Funktion (wie es in Windows und ich möchte meinen auch in Linux verwendet wird) Sinn.

Auch möchte ich nicht mehrere Einsprungspunkte haben (einmal für Int, Syscall und Sysenter).

Blödsinn. Erstens ist es sowieso immer Aufgabe des Compilers, die passenden Opcodes rauszusuchen. Wenn du die benutzen willst, brauchst du halt einen aktuellen Compiler. Wo ist das Problem?

Wie oben schon beschrieben, die Situation Programm liegt nur in binärer Form vor.

Und du brauchst auf x86 auch im PM keine zwei Varianten.

Einmal Int, einmal Sysenter und einmal Syscall, macht schon 3 Varianten und alle im PM!

Ich hatte FlashBurn so verstanden das er diesen Timer exklusiv für die Zeitscheibe benutzt, wenn er den selben Timer auch für andere Dinge nutzt kann er sowieso nicht einfach blind bei jedem IRQ den Thread wechseln.

Richtig, ich benutze den IRQ nur für die Zeitscheiben. Zumal ich ja nen One-Shot-Timer nutze und keinen monotonen.

Edit::

Ich habe ganz vergessen, es gibt sogar noch eine 4. Methode nen Syscall zu machen, call-gates. Die sollen wohl auch schneller sein als Ints, nur halt mehr Speicher als Opcode verbrauchen.

139

OS-Design / Re: Nicht unterbrechbarer Kernel

« am: 12. October 2011, 09:00 »

Das ist, mit Verlaub, Blödsinn. Weiter sage ich dazu nichts.

Wieso

Für mich ist alles was irgendwie komplex ist nicht mehr KISS, also eigentlich fast alles moderne (vorallem technische). Es würde alles auch einfacher gehen, aber es wäre halt nicht so effizient (dazu sage ich nur Locking und lock-free Algos).

Ja, natürlich, der Compiler erzeugt ja nicht direkt den Syscall-Befehl. Warum eigentlich nicht? Das wäre doch mal ne colle Sache.

Würde gehen, wenn man nicht erst noch bestimmt Dinge machen müsste (was ansich auch kein Problem ist), aber du würdest dich damit auf bestimmte CPUs festlegen (auch erstmal kein Problem), könntest dann eventuelle neue Opodes auf neueren CPUs nicht mehr nutzen und müsstest, zumindest unter 32bit 2 Varianten, einmal für Intel und einmal für AMD zur Verfügung stellen und wozu den Aufwand, wenn man auch ne mini-Funktion vom OS nutzen kann?

140

OS-Design / Re: Nicht unterbrechbarer Kernel

« am: 11. October 2011, 21:30 »

Wobei mir gerade auffällt, das ein Syscall auf neueren (und auch einigen älteren) CPUs wesentlich schneller als ein "int TIMER_IRQ" ist.