Thema: Interprozesskommunikation (mit CDI) aufbauen

[erik.vikinger]

Hallo,

.... warum denkst du, sie würden bei uns nicht zu 70% funktionieren?

Ich habe langsam den Eindruck Du willst mich missverstehen. Ich habe nirgends Euren Code bewertet! Das einzigste von tyndur was ich jetzt ein klein wenig kennen gelernt habe ist der IPC-Mechanismus und das auch nur aufgrund Deiner Beschreibungen. Und eben diese Beschreibungen lassen in mir die subjektive Bewertung "ungenügend" aufkeimen. Aber wirklich beurteilen kann ich gar nichts von tyndur und genau deshalb mach ich das auch nicht.

Was sind die elementarsten Module bei dir

Im Kernel :
 - Speicher-Management (Live-Defragmentierung, Paging u.ä. sind aber keine zwingenden Basics und kommen später)
 - Process/Thread-Management (aber SMP ist für diese frühe Phase wirklich noch nicht erforderlich)
 - einen primitiven Round-Robin-Scheduler (was besseres kann später immer noch kommen)
 - IPC (zumindest Messages sync/async und unnamed-Stream-Pipes, die Blockierungsmechanismen müssen noch nicht perfekt sein und unnamed-Packet-Pipes kommen später)
 - möglicherweise IRQs
User-Space-Personality :
 - init das die anderen Prozesse erzeugt
 - einen Prozess der eine Serielle-Schnittstelle als simple Konsole zur Verfügung stellt (PCI-Treiber und alles was drauf aufsetzt währe der nächste Schritt aber als erstes reicht es wenn dieses Programm den UART mit hardcodierten Speicher-Adressen in Betrieb nimmt)
 - das eigentliche "Hello World"-Programm das die Konsole, inklusive den 3 Stream-Pipes für stdin/stdout/stderr, öffnet und den String rausschickt
Wenn ich soweit bin ist IMHO damit schon ein Großteil der elementaren Basics abgehackt.
Ab dann gehts an die PCI-Enumeration/Konfiguration, die Device-Treiber (welche dann vom PCI-Treiber eingebunden werden) und natürlich eine libc (ich würde gerne die glibc protieren aber das sieht nach sehr viel Arbeit aus dafür würde ich wahrscheinlich aber gleich ne Menge Programme geschenkt bekommen also easy portieren können, ob die newlib taugt weis ich noch nicht so genau da liest man auch negatives drüber). Danach (oder besser während dessen) kann ich sicher auch schon mal das ein oder andere Programm portieren. Das währenddessen hängt sehr von den Anforderungen des betreffenden Programms an die libc ab.

Zum einen: Der meiste Quellcode ist einfach kaputt ....

Okay, das ist natürlich ein ernstes Problem. Fixt Ihr dann die Programme? Trifft das auch die coreutils?

Zum anderen - ja, .... Allerdings würde dieser Compilerlauf frühstens in drei Jahren statt jetzt stattfinden.

Und so lange möchte natürlich niemand warten, würde ich auch nicht.

und POSIX komplett kann (tyndur ist übrigens kein *nix, was diese Sache nicht erleichtert)

Mein OS soll auch kein *nix werden. Deshalb möchte ich auf ne ordentliche libc, am liebsten die "richtige", setzen.

Und in der Zwischenzeit, um die Lib zu testen, müsste ich irgendwelche anderen (nutzlosen) Programme schreiben,

Die müssen ja nicht unbedingt nutzlos sein, sicher kann man sich ab diesem Punkt auch mal die Mühe machen ein kleines Programm mit etwas mehr Anpassungsaufwand zu portieren.

.... denn selbst du wirst nicht eine komplette libc schreiben und erst hinterher das erste Hello-World-Programm ausprobieren, oder?

Nein, natürlich nicht. Alles muss ordentlich getestet werden und dazu bieten sich fertige Programme, deren Verhalten man gut kennt, geradezu an. Es muss nur im Rahmen bleiben.

.... da müsste man irgendwann mal das volle Programm mit fork/exec und Vererbung von Dateideskriptoren implementieren.

Braucht man dazu wirklich fork? Ich schätze das kann ich prinzipbedingt nicht vernünftig in mein OS implementieren. Ich wollte eigentlich auf fork verzichten und statt dessen lieber ordentliche Threads anbieten (zusammen mit der pthread-lib). Vererbung von Dateideskriptoren ist bei einem Microkernel-OS doch keine Angelegenheit für den Kernel sondern für den "Virtual File System"-Service.

Du kannst uns dann ja sagen, was deine Erfahrungen damit sind.

Ich werd dran denken.
Du wolltest noch einen Forums-Thread zum Thema IPC-Varianten raussuchen.

Ist schon in Ordnung, es gehört ja zum gleichen Thema, und es gibt ein paar nützliche Infos her

Dann hast Du bestimmt nichts dagegen wenn wir noch etwas weiter vom Thema abkommen.

Für git brauchst Du stdin/stdout/stderr-Umleitung? Hast Du da schon eine Idee? Mir ist eine eingefallen die komplett am Kernel vorbei geht. Interesse?

Du kannst die Idee ja einfach mal vorstellen.

Ich habe mir gedacht das man einen User-Space-Prozess hat der die Funktionalität hinter exec liefert, könnte z.B. der init-Prozess sein.
Man ruft ihn, per RPC, auf und sagt welches Programm mit welchen Parametern gestartet werden soll. Auch die Umgebungsvariablen, das aktuelle Verzeichnis und z.B. die IDs der Stream-Pipes von stdin/stdout/stderr muss man dazu mitteilen. Aus all diesen Informationen schnürt der exec-Prozess einen Datensatz und gibt diesen dem neuen Prozess als "Parameter-Block" mit. Dieser Parameter-Block wird beim Prozess-Start von der crt zerlegt und die Infos passend in die libc verteilt bzw. die Kommandozeilen-Parameter an main weitergereicht. Das hat den Vorteil das nur die crt und der exec-Prozess zueinander kompatibel sein müssen und der Kernel davon überhaupt nichts mitbekommt, auch Änderungen am Parameter-Block kümmern den Kernel nicht, der Kernel muss nur seine Länge wissen und nicht in den Inhalt schauen. Außerdem könnte der exec-Prozess auch das dynamische linken mit Bibliotheken übernehmen, der Kernel bekommt nur noch ein fertiges Monsterbinary (eventuell sogar in einem extra simplen Format) und muss fast nichts damit machen. So bleibt der Kernel simpel. Selbst ein anderes Executable-Format könnte man dann im exec-Prozess implementieren solange das fertig gelinkte Ergebnis im richtigen Simple-Format für den Kernel passt.
Für die stdin/stdout/stderr-Umleitung bedeutet dass das man entweder die vorhandenen Pipes weiterreicht oder neue erstellt und diese selber verarbeitet. Solange der neue Prozess drei funktionierende Pipe-IDs bekommt ist alles in Ordnung. Der Eltern-Prozess muss das nur dem exec-Prozess passend mitteilen und schon ist jede denkbare Variante möglich.


Grüße
Erik

[ChristianF]

Ich habe da mal eine ganz kurze Frage zum RPC-Kram von Tyndur, da ich mir darüber ja auch schon Gedanken gemacht habe, auch wenn ich momentan meilenweit davon entfernt bin, so etwas umzusetzen... 
 
Beispiel:

• Prozess B registriert einen RPC-Handler
• Der Kernel legt irgendwo, z.B. einer Liste, diesen Handler ab, damit er weiß, dass dieser registriert wurde
• Nun kommt Prozess A und möchte, diese RPC-Funktion aufrufen

Was passiert dann? Man muss den Handler heraussuchen, und je nach dem, z.B. eine Nachricht an diesen Handler schicken, damit diese Funktion, nennen wir sie mal "foo" ausgeführt wird.
Woher weiß Prozess A, dass Prozess B überhaupt ausgeführt wird? Können gleiche, bzw. ähnliche, Handler vorkommen, sodass der falsche ausgeführt wird?
Wird ein RPC über die ID des Prozesses B ausgeführt?
 
Gruß Christian

[kevin]

Ich habe langsam den Eindruck Du willst mich missverstehen. Ich habe nirgends Euren Code bewertet! [...] Aber wirklich beurteilen kann ich gar nichts von tyndur und genau deshalb mach ich das auch nicht.

Naja, du hast was davon gesagt, dass git bei einem vernünftigen Unterbau eine Sache von einmal durchkompilieren wäre - und weil es das bei uns nicht ist, und du das auch weißt, hast du damit implizit auch gesagt, dass diese elementarsten Sachen bei uns eben nicht zu diesen 70% vollständig ist.

Was sind die elementarsten Module bei dir

[...]
Wenn ich soweit bin ist IMHO damit schon ein Großteil der elementaren Basics abgehackt.

Abgehakt, nicht abgehackt, hoffe ich.

Ja, was du hier aufzählst, klingt sehr elementar und ist eigentlich relativ zügig machbar (okay, bei dir kommt noch die ungewöhnliche Plattform dazu). Ich bin mir allerdings nicht sicher, ob du eine realistische Vorstellung davon hast, was mit dieser Basis möglich ist. Das ist nämlich nicht wesentlich mehr als ein Hello World.

(ich würde gerne die glibc protieren aber das sieht nach sehr viel Arbeit aus dafür würde ich wahrscheinlich aber gleich ne Menge Programme geschenkt bekommen also easy portieren können, ob die newlib taugt weis ich noch nicht so genau da liest man auch negatives drüber).

Die glibc gilt im allgemeinen als unportierbar. newlib wird öfter verwendet. Aber je mehr du im Userspace machst, um so mehr wirst du natürlich auch von der libc selbst schreiben müssen (eben alles das an Infrastruktur, was bei einem Monolithen im Kernel landen würde).

Zum einen: Der meiste Quellcode ist einfach kaputt ....

Okay, das ist natürlich ein ernstes Problem. Fixt Ihr dann die Programme? Trifft das auch die coreutils?

Im Normalfall patchen wir dann die Programme, ja. So wie wir sie auch patchen, wenn unsere libc noch nicht ganz mitkommt und es gerade zu aufwendig erscheint, die libc zu ergänzen. Du kannst ja unsere Patches für die coreutils überfliegen, wenn du willst. Dazu muss aber noch gesagt werden, dass der Port der coreutils nicht vollständig und vor allem nicht gut getestet ist.

und POSIX komplett kann (tyndur ist übrigens kein *nix, was diese Sache nicht erleichtert)

Mein OS soll auch kein *nix werden. Deshalb möchte ich auf ne ordentliche libc, am liebsten die "richtige", setzen.

Hm, was hat das miteinander zu tun?

Braucht man dazu wirklich fork? Ich schätze das kann ich prinzipbedingt nicht vernünftig in mein OS implementieren.

Genau dieses Problem haben wir eben auch. Aber dieser ganze fork-Mechanismus ist eben ein zentraler Teil von POSIX und ohne den darfst du mindestens 90% aller Nicht-Hello-World-Programme auf einen genehmeren Mechanismus patchen.

git einfach nur durchkompilieren kriegst du ohne fork jedenfalls nicht hin.

Ich wollte eigentlich auf fork verzichten und statt dessen lieber ordentliche Threads anbieten (zusammen mit der pthread-lib). Vererbung von Dateideskriptoren ist bei einem Microkernel-OS doch keine Angelegenheit für den Kernel sondern für den "Virtual File System"-Service.

Das ändert nichts an der Tatsache, dass existierende Programme fork benutzen und eine bestimmte Semantik erwarten. Da hilft einfach nichts drum herum. Außerdem sind Threads kein Ersatz für fork, wie willst du denn sonst neue Prozesse starten? Oder gibt es bei dir nur Threads eines einzigen Prozesses?

Du kannst uns dann ja sagen, was deine Erfahrungen damit sind.

Ich werd dran denken.
Du wolltest noch einen Forums-Thread zum Thema IPC-Varianten raussuchen.

Ich glaube ich habe mich getäuscht und der Thread existiert nicht so, wie ich das in Erinnerung hatte. Das beste, was ich gefunden habe, ist der hier.

Ich habe mir gedacht das man einen User-Space-Prozess hat der die Funktionalität hinter exec liefert, könnte z.B. der init-Prozess sein.

Ja, so läuft das momentan in tyndur. Die Übergabe der Umgebungsvariablen ist noch etwas kaputt, aber dein Parameterblock klingt eigentlich ganz vernünftig und wäre ohne weiteres ohne Wissen des Kernels möglich.

Der Kernel hat bei uns zwar einen ELF-Loader, aber den benutzt er nur für das Laden von init. Mit den Binaries hat er später nichts zu tun. Wenn man in tyndur ein Programm startet, läuft das ungefähr so ab:

• Elternprozess sendet einen RPC mit dem Dateinamen als Parameter an init
• init erstellt einen neuen "leeren" Prozess (das ist ein Syscall)
• init lädt die Datei in neue Pages und "schenkt" diese Pages dem neu erstellten Prozess (zweiter involvierter Syscall)
• init startet den Prozess (dritter Syscall) und verliert damit gleichzeitig die Kontrolle über ihn, kann also keine weiteren Pages mehr in seinen Adressraum mappen.

[kevin]

Woher weiß Prozess A, dass Prozess B überhaupt ausgeführt wird?

Prozess A braucht die PID von Prozess B, damit er überhaupt einen RPC durchführen kann. Die weiß er entweder, weil sich B vorher bei ihm registriert hat, oder er kann sie bei init nachschlagen (als RPC der Form "Sag mal, welche PID hat eigentlich der Service ext2?"). init hat immer die PID 1, ist daher immer auf die gleiche Weise kontaktierbar.

Können gleiche, bzw. ähnliche, Handler vorkommen, sodass der falsche ausgeführt wird?

Was Prozess B mit der Anfrage macht, ist ihm eigentlich selbst überlassen. Es wird ein zentraler Handler angesprungen, und der muss dann anhand der übergebenen Daten entscheiden, was er damit machen will. Im allgemeinen fangen die Daten mit einem Funktionsnamen an.

[ChristianF]

Gut, das heißt also, dass Prozess A beim Init-Prozess per RPC anfragt, ob z.B. ein USB-Treiber (Prozess B) gestartet wurde, läuft und einen RPC-Handler registriert hat.
Gibt es noch andere Ansätze so etwas zu lösen? Mir fällt da gerade leider kein vernünftiger ein...

[erik.vikinger]

Hallo,

Naja, du hast was davon gesagt, dass git bei einem vernünftigen Unterbau eine Sache von einmal durchkompilieren wäre -

Und wenn ich nun behaupten würde (ohne es beweisen zu können) ....

Das habe ich absichtlich in der Möglichkeitsform formuliert

dass diese elementarsten Sachen bei uns eben nicht zu diesen 70% vollständig ist.

Wenn man mit meinem OS auch nur halbwegs was anstellen können soll, und da denke ich noch lange nicht an git o.ä., dazu muss der Kernel und die elementarsten Module (Personality im User-Space) schon zu mindestens 70% fehlerfrei funktionieren.

Dieser Satz bezieht sich eindeutig auf mein eigenes Projekt.

Offensichtlich habe ich diese 2 Aussagen nicht deutlich genug von einander getrennt.
Falls Du noch mal was von mir ließt das man möglicherweise negativ auslegen könnte dann Bitte Bitte ließ das noch mal oder frage mich direkt. Ich habe wirklich nicht vor irgendetwas unangemessen zu kritisieren. Thema erledigt? Bitte.

.... Ich bin mir allerdings nicht sicher, ob du eine realistische Vorstellung davon hast, was mit dieser Basis möglich ist. Das ist nämlich nicht wesentlich mehr als ein Hello World.

Es ist genau der Punkt ab dem ein eigenständiges "Hello World"-Programm zum ersten mal möglich ist. Nicht mehr aber auch nicht weniger. Alles andere (PCI, VFS usw.) kommt danach.

Die glibc gilt im allgemeinen als unportierbar. newlib wird öfter verwendet. Aber je mehr du im Userspace machst, um so mehr wirst du natürlich auch von der libc selbst schreiben müssen (eben alles das an Infrastruktur, was bei einem Monolithen im Kernel landen würde).

Diese Erkenntnis hat mich nun so langsam auch erreicht, Danke für Deinen Hinweis.

Mein OS soll auch kein *nix werden. Deshalb möchte ich auf ne ordentliche libc, am liebsten die "richtige", setzen.

Hm, was hat das miteinander zu tun?

Ich hatte gehofft das mir eine ordentliche libc einige Probleme erspart, war wohl etwas zu optimistisch gedacht.

Braucht man dazu wirklich fork? Ich schätze das kann ich prinzipbedingt nicht vernünftig in mein OS implementieren.

Genau dieses Problem haben wir eben auch. Aber dieser ganze fork-Mechanismus ist eben ein zentraler Teil von POSIX und ohne den darfst du mindestens 90% aller Nicht-Hello-World-Programme auf einen genehmeren Mechanismus patchen.

git einfach nur durchkompilieren kriegst du ohne fork jedenfalls nicht hin.

Schade. Das bedeutet Arbeit.

Ich wollte eigentlich auf fork verzichten und statt dessen lieber ordentliche Threads anbieten (zusammen mit der pthread-lib). Vererbung von Dateideskriptoren ist bei einem Microkernel-OS doch keine Angelegenheit für den Kernel sondern für den "Virtual File System"-Service.

Das ändert nichts an der Tatsache, dass existierende Programme fork benutzen und eine bestimmte Semantik erwarten. Da hilft einfach nichts drum herum. Außerdem sind Threads kein Ersatz für fork, wie willst du denn sonst neue Prozesse starten? Oder gibt es bei dir nur Threads eines einzigen Prozesses?

Nein, es gibt (hoffentlich viele) Prozesse und jeder Prozess kann einen oder mehrere Threads haben, so wie das z.B. in Windows ist.
Neue Prozesse starten möchte ich möglichst einfach haben :

• Elternprozess sendet einen RPC mit dem Dateinamen u.v.m. als Parameter an init/exec
• init/exec baut ein simples Monsterbinary (dabei werden eventuell auch Libs dazugelinkt) und den Parameterblock im eigenen RAM zusammen
• init/exec gibt beide Speicherbereiche dem Kernel und dieser baut daraus einen neuen Prozess, alles wird in neue Segmente kopiert/zusammengebaut, erstellt den ersten Thread, ordnet diesen Thread beim Scheduller ein und gibt als letztes die neue Prozess-ID zurück (einzigster spezifischer SYSCALL, nicht deterministisch)
• init/exec dealloziert die beiden Speicherbereiche aus dem eigenen Speicher und beantwortet den RPC vom Elternprozess und gibt dabei die neue Prozess-ID zurück

Die Vorgehensweise von fork/execv kann ich nicht nachvollziehen, da wird ein ganzer Prozess kopiert (Okay wirklich kopiert wird nicht viel aber an den Verwaltungsstrukturen wird bestimmt einiges gedreht) und anschließend sein Innenleben komplett ausgetauscht. Ich finde ein sauberer Neuanfang ist da deutlich sinnvoller, bei der Austauschaktion könnten Dinge übersehen werden die dann im neuen Programm landen.

Ich glaube ich habe mich getäuscht und der Thread existiert nicht so, wie ich das in Erinnerung hatte. Das beste, was ich gefunden habe, ist der hier.

Danke für Deine Mühe.
Ich bin der Meinung das wenn jeder Prozess einen Haufen Threads startet um auf RPCs zu warten dann kostet das ne Menge Ressourcen ohne das es unter hoher punktueller Last wirklich was nützt. Wenn das OS die Threads selber erstellt (oder ne gewisse Menge auf Vorrat hält und diese dann bei Bedarf zuordnet und aktiviert) kann man IMHO die vorhandenen Ressourcen, Speicher und vor allem CPUs, deutlich besser nutzen.

Ja, so läuft das momentan in tyndur. Die Übergabe der Umgebungsvariablen ist noch etwas kaputt, aber dein Parameterblock klingt eigentlich ganz vernünftig und wäre ohne weiteres ohne Wissen des Kernels möglich.

Als kleines Extra könnte in der crt ein Wert auf Publick gesetzt werden, den init/exec dann einfach findet. Dieser Wert könnte signalisieren was in dem Parameterblock alles drin sein muss. Ein reines GUI-Programm könnte z.B. auf stdin/stdout/stderr ganz verzichten. Auf diese Weise könnte init/exec den Parameter-Block möglichst kompatibel zur crt gestalten so das man dort nicht unbedingt exakt zueinander gehörende Versionen, von init/exec und crt, benötigt.

Der Kernel hat bei uns zwar einen ELF-Loader, aber den benutzt er nur für das Laden von init. ....

Der Loader in meinen Kernel soll auch später verwendet werden.


Grüße
Erik

[kevin]

Offensichtlich habe ich diese 2 Aussagen nicht deutlich genug von einander getrennt.
Falls Du noch mal was von mir ließt das man möglicherweise negativ auslegen könnte dann Bitte Bitte ließ das noch mal oder frage mich direkt. Ich habe wirklich nicht vor irgendetwas unangemessen zu kritisieren. Thema erledigt? Bitte.

Es ging mir nicht darum, dass du irgendwas kritisierst, das kann ich aushalten. Die Tatsache, auf die ich rauswollte, ist, dass man auch mit einem recht ordentlichen Unterbau Probleme damit haben kann, Fremdprogramme zu portieren - es sei denn, du hättest eine komplette POSIX-Implementierung als Bestandteil eines ordentlichen Unterbaus definiert - aber das hast du ja nicht.

Ich hatte gehofft das mir eine ordentliche libc einige Probleme erspart, war wohl etwas zu optimistisch gedacht.

Ach, die peinlichsten (und zeitraubendsten) Fehler macht man in den einfachsten Funktionen - Stringfunktionen und so. Dafür was fertiges herzunehmen ist gar nicht so blöd.

Aber eine libc ist halt groß genug, dass wenn einem einige Probleme erspart bleiben, trotzdem noch wesentlich mehr andere bestehen bleiben.

Nein, es gibt (hoffentlich viele) Prozesse und jeder Prozess kann einen oder mehrere Threads haben [...] Die Vorgehensweise von fork/execv kann ich nicht nachvollziehen, da wird ein ganzer Prozess kopiert (Okay wirklich kopiert wird nicht viel aber an den Verwaltungsstrukturen wird bestimmt einiges gedreht) und anschließend sein Innenleben komplett ausgetauscht. Ich finde ein sauberer Neuanfang ist da deutlich sinnvoller, bei der Austauschaktion könnten Dinge übersehen werden die dann im neuen Programm landen.

Das sehe ich ziemlich ähnlich wie du. Aber es hilft nichts, die Programme da draußen erwarten alle, dass es ein fork und getrennt davon ein exec gibt und dass man dazwischen drin noch lustige Sachen machen kann oder auch eins von beidem ohne das andere aufzurufen.

Dieser Wert könnte signalisieren was in dem Parameterblock alles drin sein muss. Ein reines GUI-Programm könnte z.B. auf stdin/stdout/stderr ganz verzichten.

Ich würde an dieser Stelle Einheitlichkeit bevorzugen.

Der Kernel hat bei uns zwar einen ELF-Loader, aber den benutzt er nur für das Laden von init. ....

Der Loader in meinen Kernel soll auch später verwendet werden.

Das klingt für mich nicht sehr mikrokernelig. Dann müsste ja jedes unterstützte Dateiformat im Kernel landen?

[erik.vikinger]

Hallo,

Die Tatsache, auf die ich rauswollte, ist, dass man auch mit einem recht ordentlichen Unterbau Probleme damit haben kann, Fremdprogramme zu portieren

Okay, da hast Du definitiv recht.
Gut das wir uns ausgesprochen haben.

es sei denn, du hättest eine komplette POSIX-Implementierung als Bestandteil eines ordentlichen Unterbaus definiert - aber das hast du ja nicht.

Selbst das ist kein Garant für Problemfreies portieren. Aber weitestgehende POSIX-Konformität wollen wir ja beide nicht, wenn ich Dich richtig verstanden hab.

Aber es hilft nichts, die Programme da draußen erwarten alle, dass es ein fork und getrennt davon ein exec gibt und dass man dazwischen drin noch lustige Sachen machen kann oder auch eins von beidem ohne das andere aufzurufen.

Das deprimiert mich. Hat sich den die NPTL noch so wenig durchgesetzt? Die will ich zu (nahe) 100% kompatibel unterstützen.

<EDIT>Okay 100% sind selbst bei pthread sicher etwas utopisch aber soweit wie die http://sourceware.org/pthreads-win32/ möchte ich schon kommen.</EDIT>

Dieser Wert könnte signalisieren was in dem Parameterblock alles drin sein muss. Ein reines GUI-Programm könnte z.B. auf stdin/stdout/stderr ganz verzichten.

Ich würde an dieser Stelle Einheitlichkeit bevorzugen.

Ich denke da z.B. an ein Handle o.ä. zum Zugriff auf den D-Bus, ein GUI-Programm kann damit bestimmt mehr anfangen als mit stdin/stdout/stderr und der exec-Service könnte dieses Handle per RPC mitbekommen. Ich würde etwas Flexibilität beim Zusammenbau des Parameter-Block bevorzugen um je nach Bedarf unterschiedliche Features realisieren zu können.

Der Loader in meinen Kernel soll auch später verwendet werden.

Das klingt für mich nicht sehr mikrokernelig. Dann müsste ja jedes unterstützte Dateiformat im Kernel landen?

Nein, der exec-Service soll das Executable passend zusammenlinken und dabei auch das richtige und möglichst simple Format für den Kernel erzeugen. Der Kernel soll nicht mit relozieren o.ä. anfangen sondern nur Code/Constanten/Daten/BSS u.ä. auf die passenden Segmente/Sektionen verteilen und danach einen Stack anlegen, den ersten Thread erstellen und damit entry anspringen. Die vom exec-Service unterstützten Formate haben damit nichts zu tun, man könnte exec beliebig komplexe Formate unterstützen lassen ohne am Kernel was ändern zu müssen.


Grüße
Erik

[erik.vikinger]

Hallo,

Wie macht ihr das dann mit RPC? Wie wird die Antwort der entsprechenden Anfrage zugeordnet und wieder zum richtigen Prozess zugestellt? Kommt die Antwort über den selben Weg, als asynchrones Signal, zum Absender der Anfrage?

Ja, falls es eine Antwort gibt, kommt die auf dem gleichen Weg zurück. Die Zuordnung geschieht über eine ID, die der Absender der Anfrage mitschickt.

Was ist wenn jemand eine falsche Absender-ID mitschickt? Ich denke da an Angriffe wie http://de.wikipedia.org/wiki/Domain_Name_System#DNS-Amplification-Angriff. Sollte der Kernel nicht lieber die Absender-ID setzen?

Deswegen habe ich ja gesagt, es sind Signale mit Daten. Es gibt keine Queue (außer man möchte den Stack des Prozesses als solche ansehen).

Mir ist gerade aufgefallen das es sich dabei um einen LIFO handelt, richtig? Bereitet das nicht Probleme wenn mehrere Programme parallel laufen und sich gegenseitig verdrängen?


Zum Thema Kernel-Generierter Popup-Threads :
Ich habe da nicht viel drüber gefunden, nur ein paar theoretische Aussagen die aber kaum negatives enthalten.
Zumindest scheint es noch kein OS zu geben das sowas kann, also ein guter Grund das mal zu implementieren.


Grüße
Erik

[kevin]

Was ist wenn jemand eine falsche Absender-ID mitschickt? Ich denke da an Angriffe wie http://de.wikipedia.org/wiki/Domain_Name_System#DNS-Amplification-Angriff. Sollte der Kernel nicht lieber die Absender-ID setzen?

Ja, natürlich. Der Empfänger bekommt immer die PID vom Absender. Die zusätzlich gesendete ID ist nur zusammen mit der PID eindeutig und ist eben dafür zuständig, dass ein Absender, der mehrere Anfragen geschickt hat, die Zuordnung hinbekommt. Der Empfänger macht damit nichts weiter als sie für den Absender wieder in die Antwort reinzupacken.

Mir ist gerade aufgefallen das es sich dabei um einen LIFO handelt, richtig? Bereitet das nicht Probleme wenn mehrere Programme parallel laufen und sich gegenseitig verdrängen?

In der Theorie könnte sich das vermutlich schon negativ auswirken.

Zum Thema Kernel-Generierter Popup-Threads :
Ich habe da nicht viel drüber gefunden, nur ein paar theoretische Aussagen die aber kaum negatives enthalten.
Zumindest scheint es noch kein OS zu geben das sowas kann, also ein guter Grund das mal zu implementieren.

Nur zu. Versuch macht kluch.

[erik.vikinger]

Hallo,

Der Empfänger bekommt immer die PID vom Absender. Die zusätzlich gesendete ID ist nur zusammen mit der PID eindeutig und ist eben dafür zuständig, ....

Ah ja, mir ist nur so das Fehlerpotential aufgefallen. Ich selber möchte synchrone Messages (neben asynchronen) anbieten bei denen der fragende Thread solange blockiert wird bis seine Antwort eintrifft. Auch der Popup-Thread muss sich beim abliefern der Antwort nicht darum kümmern wo die hin muss, das soll der Kernel selber machen. Ich weis das dadurch der Kernel etwas komplexer wird aber es geht mir dabei vor allem darum den ganzen Mechanismus möglichst zuverlässig (manipulationssicher) zu machen und ob das in einer Lib oder direkt im Kernel steckt macht es nicht so viel schwieriger.

Mir ist gerade aufgefallen das es sich dabei um einen LIFO handelt, richtig? Bereitet das nicht Probleme wenn mehrere Programme parallel laufen und sich gegenseitig verdrängen?

In der Theorie könnte sich das vermutlich schon negativ auswirken.

Naja, ich befürchte einfach negative Konsequenzen, oder gar Deadlocks, wenn die Anfragen in umgekehrter Reihenfolge abgearbeitet werden. Obwohl das wohl erst zum Problem wird wenn wirklich sehr viele Programme und Services gleichzeitig laufen und fleißig kommunizieren.

Nur zu. Versuch macht kluch.

Grüße
Erik

[kevin]

Naja, ich befürchte einfach negative Konsequenzen, oder gar Deadlocks, wenn die Anfragen in umgekehrter Reihenfolge abgearbeitet werden. Obwohl das wohl erst zum Problem wird wenn wirklich sehr viele Programme und Services gleichzeitig laufen und fleißig kommunizieren.

Naja, die Situation sehe ich jetzt nicht unbedingt als ein Problem mit dem LIFO an. Das Problem kriegst du erst, wenn der Service nicht mehr hinterherkommt, alle Anfragen zu bearbeiten, und dann hast du auch vorwärts einen DoS.

Was richtig ist, ist dass man gelegentlich aufpassen und in Erinnerung behalten muss, was passiert. Ich glaube, wir hatten zum Beispiel am Anfang den Effekt, dass Buchstaben vertauscht wurden, wenn man zu schnell getippt hat.

[erik.vikinger]

Hallo,

Das Problem kriegst du erst, wenn der Service nicht mehr hinterherkommt, alle Anfragen zu bearbeiten, und dann hast du auch vorwärts einen DoS.

Dann ist es bereits zu spät, obwohl dieses Problem ja über die Prioritäten zu lösen sein sollte. Und wenn eine Queue voll ist müssen eben alle warten die was ranhängen möchten sogar bei asynchronen Messages.
Mein Bauchgefühl sagt mir eher das beim LIFO-Prinzip blöde Deadlocks u.ä. lauern können, beweisen kann ichs aber nicht.

Ich glaube, wir hatten zum Beispiel am Anfang den Effekt, dass Buchstaben vertauscht wurden, wenn man zu schnell getippt hat.

Sicher das dieses Problem wirklich weg ist? Und nicht nur keiner so schnell tippen kann?
Nach etwas nachdenken würde ich sagen dieses Problem könnte mit nem LIFO äußerst schwer zu beseitigen sein.


Grüße
Erik

[erik.vikinger]

Hallo,

Das Problem kriegst du erst, wenn der Service nicht mehr hinterherkommt, alle Anfragen zu bearbeiten, und dann hast du auch vorwärts einen DoS.

Nein, mit nem FIFO hast Du nur zähflüssigen Verkehr aber mit nem LIFO kann ein Programm das immer mindestens 2 RPCs aktiv hält ein anderes, das den selben Service benötigt, komplett verhungern lassen. Das würde ich als echten DoS bezeichnen.

Das mit den vertauschten Tastendrücken ist sicher ein lustiges Phänomen, aber es deutet IMHO auf ein sehr ernstes/schwerwiegendes Problem hin.


Grüße
Erik