Thema: Interprozesskommunikation (mit CDI) aufbauen

[TheThing]

Hi,
nach langer Zeit hab ich mich mal wieder um meinen Kernel gekümmert. Dem fehlt jetzt noch ein wichtiger Bestandteil: Interprozesskommunikation. Ist ja wichtig für einen Mikrokernel 

Mein Problem ist, das ich noch keine Ahnung hab wie ich so etwas sinnvoll realisiere. Ich hab mich mal ein wenig umgesehen und bin dabei im Wiki über CDI gestolpert, da es unabhängig vom Betriebssystem ist, dachte ich, das ich das verwende.

Könnt ihr mir erklären, wie ich eine Interprozesskommunikation (speziell mit CDI) aufbaue bzw. wie sie funktioniert?

Und ganz nebenbei: Wie krieg ich das hin das meine Tasks im Usermode laufen?

Grüße, TheThing

[kevin]

nach langer Zeit hab ich mich mal wieder um meinen Kernel gekümmert. Dem fehlt jetzt noch ein wichtiger Bestandteil: Interprozesskommunikation. Ist ja wichtig für einen Mikrokernel 

Wäre ganz geschickt, sonst kommst du nicht richtig weit.

Es gibt da viele im Detail verschiedene Möglichkeiten, aber letztendlich geht es immer darum, dass ein Prozess einem anderen Daten schicken kann. Unterschiedliche Lösungen kommen raus, je nachdem ob die Datenpakete eine feste oder eine dynamische Größe haben, ob der Empfängerprozess sie sofort abarbeiten muss oder nicht, ob der Absender auf eine Antwort wartet oder direkt weitermacht und evtl. einen Callback bekommt, sobald eine Antwort da ist, usw.

Ich würde mal grob zwei wirklich unterschiedliche Möglichkeiten nennen: Zum einen sind das Nachrichtenwarteschlangen. Ein Prozess ruft eine Kernelfunktion, die an die Warteschlange eines anderen Prozesses eine Nachricht anhängt. Der andere Prozess fragt regelmäßig die Nachrichten in seiner Warteschlange ab und verarbeitet sie dann. Die andere Möglichkeit geht in die Richtung der Unix-Signale: Wenn eine Nachricht (oder ein Signal) kommt, wird der Prozess vom Kernel unterbrochen und in einen Handler gesprungen, wo er die Nachricht sofort verarbeiten muss (das ist deswegen problematisch, weil der Prozess an jeder beliebigen Stelle unterbrochen werden könnte ohne das zu wissen).

Mein Problem ist, das ich noch keine Ahnung hab wie ich so etwas sinnvoll realisiere. Ich hab mich mal ein wenig umgesehen und bin dabei im Wiki über CDI gestolpert, da es unabhängig vom Betriebssystem ist, dachte ich, das ich das verwende.

Könnt ihr mir erklären, wie ich eine Interprozesskommunikation (speziell mit CDI) aufbaue bzw. wie sie funktioniert?

CDI ist eine Treiberschnittstelle und hat mit IPC nichts zu tun. Du wirst natürlich bei einem Mikrokernel auch für CDI IPC brauchen, aber die wird hinter den Kulissen ablaufen und ist komplett dir überlassen.

Und ganz nebenbei: Wie krieg ich das hin das meine Tasks im Usermode laufen?

http://lowlevel.brainsware.org/wiki/index.php/Teil_6_-_Multitasking#Userspace

[TheThing]

Hm, ok, mal angenommen ich hab eine Nachrichtenwarteschlange. Wie genau kann denn dann der Kernel dem Prozess Daten geben?
Welches Prinzip nutzt denn tyndur?

Der Link ist schon mal hilfreich. Mir wird aber nicht ganz klar, was genau denn den Task dazu bringt in Ring 3 zu laufen.

btw: Im Wiki (beim Teil 7) wird ein Stückchen C-Code verwendet, dass ich nicht verstehe: "x &= ~FLAG". Was genau macht das denn? Bedeutet das "&" soviel wie "AND" in BASIC und "~" soviel wie "NOT" ?

[kevin]

Hm, ok, mal angenommen ich hab eine Nachrichtenwarteschlange. Wie genau kann denn dann der Kernel dem Prozess Daten geben?

Indem er einfach in die Nachrichtenwarteschlange was reinschreibt. Das wird ja irgendein Userspace-Speicherbereich sein, der regelmäßig abgefragt wird.

Welches Prinzip nutzt denn tyndur?

Das falsche. Das RPC von tyndur sind so ungefähr Unixsignale, die auf dem Stack Daten mitbekommen können.

Der Link ist schon mal hilfreich. Mir wird aber nicht ganz klar, was genau denn den Task dazu bringt in Ring 3 zu laufen.

cs zeigt jetzt auf ein Ring-3-Codesegment (das 0x03, das dazugeodert wird)

btw: Im Wiki (beim Teil 7) wird ein Stückchen C-Code verwendet, dass ich nicht verstehe: "x &= ~FLAG". Was genau macht das denn? Bedeutet das "&" soviel wie "AND" in BASIC und "~" soviel wie "NOT" ?

Ja, & ist bitweises Und, | ist bitweises Oder, ~ ist bitweises Nicht.

[TheThing]

Danke für die schnelle Antwort.

Ich muss also "einfach" darauf achten, das ich die Nachrichten in einen Speicherbereich des Prozesses reinschreibe?

tyndur nutzt das falsche? Ich denke es gäbe kein "falsch"

Jetzt weiß ich wenigstens mal wie ich rangehen muss

[kevin]

Ich muss also "einfach" darauf achten, das ich die Nachrichten in einen Speicherbereich des Prozesses reinschreibe?

Der Prozess sollte natürlich auch noch wissen, welcher Bereich das ist, damit er auch merkt, dass jemand was von ihm will.

Ansonsten ja. Es geht ja nur darum, dass der eine Prozess sich dem anderen irgendwie mitteilen kann.

tyndur nutzt das falsche? Ich denke es gäbe kein "falsch"

Sagen wir so: Ich kenne die Nachteile der tyndur-Methode mittlerweile ganz gut. Vielleicht sind andere Methoden genauso doof, das weiß ich nicht.

[erik.vikinger]

Hallo,


Entschuldigt bitte wenn ich störe.

Sagen wir so: Ich kenne die Nachteile der tyndur-Methode mittlerweile ganz gut.

Könntest Du diese Nachteile bitte etwas näher erläutern.


Grüße
Erik

[kevin]

Das wesentliche Problem besteht darin, dass ein Prozess, der einen RPC empfängt, an Ort und Stelle unterbrochen wird, um den Handler auszuführen. Und wenn der RPC-Handler auf irgendeinen globalen Zustand zugreift, gibt es natürlich Stellen, an denen es weniger geschickt ist, unterbrochen zu werden und nachher mit veränderten Werten weiterzuarbeiten. Deswegen kann man in tyndur RPCs blockieren, aber man kann das nicht selektiv machen, sondern es kommt dann halt gar kein RPC mehr durch (und der Absender muss warten, bis er seine Nachricht senden darf).

Eine mögliche Lösung wäre es eben eine Nachrichtenwarteschlange einzurichten und die Nachrichten erst abzuarbeiten, wann der Empfänger es für passend hält, oder aber man könnte für jeden RPC einen neuen Thread erstellen, der einfach nur den Handler abarbeitet. Dann könnte man gezielt mit Locking arbeiten.

[erik.vikinger]

Hallo,

Das wesentliche Problem besteht darin, dass ein Prozess, der einen RPC empfängt,

Verstehe ich das richtig das der Prozess nicht extra eine (oder mehrere) Message-Sink/Queue explizit erstellt (um diese dann, eventuell aus mehreren Threads parallel, gezielt, eventuell blockierend, abzufragen) sondern eben so wie bei klassischen Signalen das es pro Prozess einen Signal-Handler gibt der für alles zuständig ist und einen beliebigen Thread im Prozess an beliebiger Stelle unterbricht?
Das würde ich persönlich als schlimm empfinden.

Und wenn der RPC-Handler auf irgendeinen globalen Zustand zugreift, ...

dann wird es eklig. Ja das kann ich als Nachteil sehr gut verstehen.

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?

oder aber man könnte für jeden RPC einen neuen Thread erstellen, der einfach nur den Handler abarbeitet

Meinst Du damit dass das OS einfach einen neuen Thread für den betreffenden Prozess erstellt und dieser Thread als main-Funktion den Message-Handler und die Message als dessen Parameter (und der Return-Wert die Antwort ist) bekommt? Das währe natürlich mal ne interessante Idee. Das löst das Problem das ein Prozess auf mehrere unabhängige Message-Queues mit einem SYSCALL warten muss oder gar für jede Message-Queue einen extra Thread erstellen muss anstatt alle Queues reihum aktiv abzufragen.
Natürlich muss dann beim erstellen der Message-Queue festgelegt werden wie viele Threads das OS maximal gleichzeitig erstellen darf und das OS muss alles was mehr kommt dann wirklich in die Queue legen und kann dafür die existierenden Threads dann, wenn diese ihre Antwort zurückgeben, gleich recyceln für die nächste Message in der Queue. Eine echt interessante Idee, muss ich mal ein paar Nächte drüber schlafen.
In der WIN32-API gibt es für das warten auf mehrere Events (das Event welches zuerst kommt weckt dann den wartenden Thread) extra Funktionen.


Grüße
Erik

[kevin]

Verstehe ich das richtig das der Prozess nicht extra eine (oder mehrere) Message-Sink/Queue explizit erstellt (um diese dann, eventuell aus mehreren Threads parallel, gezielt, eventuell blockierend, abzufragen) sondern eben so wie bei klassischen Signalen das es pro Prozess einen Signal-Handler gibt der für alles zuständig ist und einen beliebigen Thread im Prozess an beliebiger Stelle unterbricht?

Richtig. 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).

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.

Meinst Du damit dass das OS einfach einen neuen Thread für den betreffenden Prozess erstellt und dieser Thread als main-Funktion den Message-Handler und die Message als dessen Parameter (und der Return-Wert die Antwort ist) bekommt? Das währe natürlich mal ne interessante Idee.

Ja, ungefähr so. Ich glaube, wir hatten auch schonmal einen Thread zu den ganzen unterschiedlichen Möglichkeiten und sind am Ende zum Ergebnis gekommen, dass alles Mist ist. Den müsste ich mal bei Gelegenheit wieder raussuchen.

Natürlich muss dann beim erstellen der Message-Queue festgelegt werden wie viele Threads das OS maximal gleichzeitig erstellen darf und das OS muss alles was mehr kommt dann wirklich in die Queue legen und kann dafür die existierenden Threads dann, wenn diese ihre Antwort zurückgeben, gleich recyceln für die nächste Message in der Queue.

Die Frage ist nur, ob es sich lohnt, das alles in den Kernel zu packen, wenn man am Ende dann doch wieder eine Queue anlegen muss. Dann könnte der Userspace sich auch selbst ein paar Threads erstellen, die die Queues abarbeiten.

[erik.vikinger]

Hallo,

Richtig.

Es gibt keine Queue (außer man möchte den Stack des Prozesses als solche ansehen).

Soll das heißen das ein neues Signal auch einen bereits laufenden Signal-Handler unterbrechen kann? Das sich das nach großem Scheiß anhört muss ich Dir bestimmt nicht erklären.

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.

Das bedeutet das ein Prozess der gleichzeitig mit verschiedenen Services (File-System, TCP/IP , UI usw.) kommunizieren möchte (also quasi alles was über "Hello World" hinaus geht) intern einen Verteilungsmechanismus implementieren muss damit die Antworten auch den entsprechenden Part/Thread im Prozess erreichen. Das stelle ich mir sehr umständlich vor und vor allem Redundant da das ja in jedem Prozess drin sein muss.

Ja, ungefähr so.

Mir gefällt diese Idee irgendwie.

Ich glaube, wir hatten auch schonmal einen Thread zu den ganzen unterschiedlichen Möglichkeiten ...... Den müsste ich mal bei Gelegenheit wieder raussuchen.

Ja Bitte.

und sind am Ende zum Ergebnis gekommen, dass alles Mist ist.

Warum alles Mist?
Ich denke fast alles was einem da so einfällt ist besser als das was jetzt in Tyndur drin ist.

Dann könnte der Userspace sich auch selbst ein paar Threads erstellen, die die Queues abarbeiten.

Sicher, aber wie viele? Legt man für jede Queue einen eigenen Thread an gibts am Ende vielleicht ne Menge wartende Threads die nur Speicher (Stack) kosten und trotzdem braucht man die Queue da pro Message-Target ja möglicherweise zeitgleich von verschiedenen anderen Prozessen Anfragen rein kommen können. Damit währe eine zügige Abarbeitung auch nicht gegeben weil die Anfragen nach einander abgearbeitet werden obwohl noch 2 CPUs sich langweilen und ein ganzer Sack mit Threads schläft. Wenn man nur einen Thread erstellt der auf mehrere Message-Queues wartet leidet erst recht die Performance.
Die Idee dass das OS die Threads nach tatsächlichen Bedarf erstellt/verteilt finde ich recht verlockend. Außerdem lässt sich so ein modernes Multi-Core-System recht gut ausnutzen.


Grüße
Erik

[kevin]

Soll das heißen das ein neues Signal auch einen bereits laufenden Signal-Handler unterbrechen kann? Das sich das nach großem Scheiß anhört muss ich Dir bestimmt nicht erklären.

Hm, ich sag's mal so... Das reißt's auch nicht mehr raus. Wenn man den Rest unter Kontrolle hat, sind unterbrechbar RPC-Handler echt nicht mehr das Problem.

Aber eigentlich erstaunlich, dass ich erst jetzt gerade zum ersten Mal im Forum den (verdienten) Prügel einstecken muss. Im IRC hatten wir das Thema aber schon öfters.

Das bedeutet das ein Prozess der gleichzeitig mit verschiedenen Services (File-System, TCP/IP , UI usw.) kommunizieren möchte (also quasi alles was über "Hello World" hinaus geht)

Dann haben wir im Moment nur Hello-World-Programme. Die meisten davon sind ja Ports von *nix und benutzen ein synchrones read/write, warten also sowieso, bis die Antwort da ist...

intern einen Verteilungsmechanismus implementieren muss damit die Antworten auch den entsprechenden Part/Thread im Prozess erreichen. Das stelle ich mir sehr umständlich vor und vor allem Redundant da das ja in jedem Prozess drin sein muss.

Naja, für redundante Sachen hat man Libs erfunden.Aber irgendwie verwalten müsste man das schon alles, um richtige asynchrone IO-Funktionen bereitstellen zu können. Darin sehe ich jetzt aber nicht unbedingt das große Problem.

und sind am Ende zum Ergebnis gekommen, dass alles Mist ist.

Warum alles Mist?
Ich denke fast alles was einem da so einfällt ist besser als das was jetzt in Tyndur drin ist.

Es gibt verschiedene Ebenen von Mist.

Und wenn du den Drang verspüren solltest, tyndur mit was besserem zu beglücken, akzeptieren wir übrigens gern Patches.

[erik.vikinger]

Hallo,

Wenn man den Rest unter Kontrolle hat, sind unterbrechbar RPC-Handler echt nicht mehr das Problem.

Also ganz ehrlich, mir stehen die Nackenhaare zu Berge wenn ich das lese.
Im Berufsleben dürfte ich sowas nicht abliefern, selbst ein sehr ökonomisch eingestellter Chef weis das man ein Problem lieber einmal ordentlich löst als sich ewig mit ner Krücke rum zu ärgern. In einem Hobby-Projekt würde ich sowas erst recht nicht haben wollen.

Wie viel Zeit hat Euch dieses Konstrukt bereits gekostet?

den (verdienten) Prügel einstecken muss.

Das ist wirklich nicht meine Absicht. Ich möchte einfach nur nicht den selben Fehler machen und daher habe ich genauer nachgefragt.

Dann haben wir im Moment nur Hello-World-Programme.

Na nun untertreibst Du aber. Nebenan hast Du geschrieben das Du git schon so etwas am laufen hast (und vieles anderes ja wohl auch), das ist ja dann doch etwas mehr als "Hello World".

Es gibt verschiedene Ebenen von Mist.

Das mag sein, das was zur Zeit als IPC-Mechanismus in tyndur realisiert ist stellt aber schon eine ungewöhnliche Ebene Mist dar.

Und wenn du den Drang verspüren solltest, tyndur mit was besserem zu beglücken, ....

Da kann ich mich grad so beherrschen. Obwohl, mal so zum üben, na ich weis nicht. Das währe auf jeden Fall mehr als nur ein Path sondern ein halber Rewrite.
Ich suche eher Ideen für mein eigenen Projekt. Probleme anderer will ich natürlich vermeiden und möchte daher möglichst viel über diese Probleme erfahren.


Grüße
Erik

[kevin]

Im Berufsleben dürfte ich sowas nicht abliefern, selbst ein sehr ökonomisch eingestellter Chef weis das man ein Problem lieber einmal ordentlich löst als sich ewig mit ner Krücke rum zu ärgern. In einem Hobby-Projekt würde ich sowas erst recht nicht haben wollen.

Wie viel Zeit hat Euch dieses Konstrukt bereits gekostet?

Wie sollte ich das messen? Letztendlich hat es aber vermutlich eher Performance gekostet als Arbeitszeit. Das einzige, was man wirklich beachten muss, ist eben, RPCs an kritischen Stellen zu blockieren. Letztendlich ist das auch der Grund, warum es in dieser Form noch lebt: Es ist zwar grundsätzlich ziemlich kaputt, aber funktioniert halt doch zu gut, um wirklich für den Rewrite zu motivieren.

Dann haben wir im Moment nur Hello-World-Programme.

Na nun untertreibst Du aber. Nebenan hast Du geschrieben das Du git schon so etwas am laufen hast (und vieles anderes ja wohl auch), das ist ja dann doch etwas mehr als "Hello World".

Ja, ich konnte den tyndur-Kernelcode aus dem SVN auschecken, kompilieren und booten. Aber alle beteiligten Programme sind nach deiner Definition Hello-World-Programme. Keins davon macht paralleles asynchrones IO mit mehreren Backends.

Das mag sein, das was zur Zeit als IPC-Mechanismus in tyndur realisiert ist stellt aber schon eine ungewöhnliche Ebene Mist dar.

Wir machen eben nicht nur normale Sachen, sondern was ganz besonderes.

[TheThing]

Danke an euch, jetzt hab ich schonmal eine Ahnung wo ich anfangen kann/soll, und wie ich es mache 

Also, wenn mein OS  mehr als 50% Marktanteil hat melde ich mich wieder 

[erik.vikinger]

Hallo,

.... aber funktioniert halt doch zu gut, um wirklich für den Rewrite zu motivieren.

Ja, dieses Problem ist mir wohl bekannt. Aber sollte nicht eine gute Lösung eine ausreichende Motivation sein?

Aber alle beteiligten Programme sind nach deiner Definition Hello-World-Programme.

Also das hab ich so nicht geschrieben.
Hier http://lowlevel.brainsware.org/forum/index.php?topic=2174.msg26239#msg26239 sieht es doch schon recht ordentlich aus. Und das Niveau von "Hello World"-Programmen scheinen die meisten der dort aufgeführten Punkte bereits hinter sich gelassen zu haben.

<EDIT>

Das bedeutet das ein Prozess der gleichzeitig mit verschiedenen Services (File-System, TCP/IP , UI usw.) kommunizieren möchte (also quasi alles was über "Hello World" hinaus geht) intern einen Verteilungsmechanismus implementieren muss damit die Antworten auch den entsprechenden Part/Thread im Prozess erreichen. Das stelle ich mir sehr umständlich vor und vor allem Redundant da das ja in jedem Prozess drin sein muss.

Damit habe ich gemeint das ein Prozess der der z.B. Daten aus einer Datei ließt, diese per TCP wegschickt und abschließend über stdout eine Meldung ausgibt die RPC-Antworten der verschiedenen Services in seinem einen generischen Signal-Handler irgendwie wieder zuordnen können muss. Also die Antwort für fread() auch wirklich dort hin zurückgibt damit fread(), welches ja während es wartet vom Signal-Handler mit der RPC-Antwort unterbrochen wird, eben auch mit einem passenden Return-Wert zurückkommen kann. Daran das in einem Single-Thread-Prozess immer nur eine  Funktion, die RPC benötigt, aufgerufen werden kann hatte ich heute Mittag nicht gedacht. Ich meinte damit nicht das all diese Dinge wirklich gleichzeitig/überlappend ablaufen müssen. Ich wollte auf gar keinen Fall die Qualität Eurer Arbeit abwerten.
</EDIT>

Keins davon macht paralleles asynchrones IO mit mehreren Backends.

Das kommt bestimmt noch. Eine Frage: Kann tyndur Multithreading? Spätestens dann kommt asynchrones IO mit mehreren Backends von ganz alleine. Und mit SMP kommt sowas noch viel mehr.

Wir machen eben nicht nur normale Sachen, sondern was ganz besonderes.

Ja, scheint so. Mein Projekt, eine Plattform mit Segmentierung, ist auch nichts gewöhnliches.

Also, wenn mein OS  mehr als 50% Marktanteil hat melde ich mich wieder 

Da Du wohl auf die klassischen Konzepte setzen wirst hast Du sicher eine höhere Chance dieses Ziel zu erreichen als ich. Viel Glück dabei. Und entschuldige Bitte noch mal das ich Deinen Thread entfremdet hab.


Grüße
Erik

[kevin]

Ja, dieses Problem ist mir wohl bekannt. Aber sollte nicht eine gute Lösung eine ausreichende Motivation sein?

Sollte vielleicht. Aber ich bin jemand, der gern Ergebnisse sieht. Wenn ich mich entscheiden kann, ein paar Stunden zu investieren und am Ende kann ich entweder git clone/pull/push haben oder die RPCs sind intern schöner geworden, dann entscheide ich mich mit einer nicht zu geringen Wahrscheinlichkeit für git.

Kann tyndur Multithreading? Spätestens dann kommt asynchrones IO mit mehreren Backends von ganz alleine. Und mit SMP kommt sowas noch viel mehr.

kernel2 kann das theoretisch, ist aber im Userspace noch nicht zugreifbar. Irgendwann in nächster Zeit muss sowieso mal eine große Kerneloffensive kommen (LIOv2, Kernelthreads, SMP, amd64, evtl. noch eine richtig andere Plattform - und vielleicht auch das tatsächliche Verfügbarmachen von Multithreading).

[erik.vikinger]

Hallo,

Aber ich bin jemand, der gern Ergebnisse sieht.

Die sieht sicher jeder gerne, aber ich persönlich mag keine Ergebnisse die auf dem Prinzip "außen hui, innen pfui" aufbauen.
Mir ist sehr wohl bewusst das ich bei meinem eigenen Projekt ne menge Arbeit investieren muss bevor ich auch nur das erste "Hello World" sehe. 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. Der Weg ist sicher hart aber ich möchte meine Zeit auch nicht mit unsinnig aufwendigen Zwischenlösungen vergeuden. Natürlich will ich mich auch nicht erst dann an "Hello World" machen wenn SMP läuft aber eine gute Basis will ich schon haben.

.... dann entscheide ich mich mit einer nicht zu geringen Wahrscheinlichkeit für git.

Und wenn ich nun behaupten würde (ohne es beweisen zu können) das wenn Du vorher eine ordentliche Basis geschaffen hättest könnte die Portierung auf einen einfachen Compiler-Lauf hinauslaufen ohne das Du etliche Stunden lang basteln müsstest? Okay, das währe unverschämt von mir, aber ein gewisser Grad an Wahrheit steckt da schon drin.

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?

Noch mal zum eigentlichen Thema IPC : Deine Idee mit den OS-generierten Handler-Threads gefällt mir immer noch sehr (maximale Performance bei minimaler Ressource-Verschwendung, ich denke das ich es schaffen könnte das vom SYSCALL-Befehl bis zum ersten Befehl im Handler-Thread weniger als 300 CPU-Takte vergehen, inklusive Kontext-Wechsel). Danke für Deine Idee! Ich überlege mir heute mal die passenden SYSCALLs dafür.


Grüße
Erik

[TheThing]

Und entschuldige Bitte noch mal das ich Deinen Thread entfremdet hab.

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

[kevin]

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.

Was sind die elementarsten Module bei dir und warum denkst du, sie würden bei uns nicht zu 70% funktionieren?

Und wenn ich nun behaupten würde (ohne es beweisen zu können) das wenn Du vorher eine ordentliche Basis geschaffen hättest könnte die Portierung auf einen einfachen Compiler-Lauf hinauslaufen ohne das Du etliche Stunden lang basteln müsstest? Okay, das währe unverschämt von mir, aber ein gewisser Grad an Wahrheit steckt da schon drin.

Zum einen: Der meiste Quellcode ist einfach kaputt und funktionieren selbst dann nicht, wenn du alle Spezifikationen einhältst aber an manchen Stellen eben undefinierte Dinge anders machst als andere Systeme. Von der Kaputtheit der Buildsysteme will ich gar nicht anfangen zu reden...

Zum anderen - ja, wenn das System vollständig ist und POSIX komplett kann (tyndur ist übrigens kein *nix, was diese Sache nicht erleichtert), dann wäre man womöglich mit ein bisschen Buildsystem anpassen und durchkompilieren getan. Allerdings würde dieser Compilerlauf frühstens in drei Jahren statt jetzt stattfinden.

Und in der Zwischenzeit, um die Lib zu testen, müsste ich irgendwelche anderen (nutzlosen) Programme schreiben, denn selbst du wirst nicht eine komplette libc schreiben und erst hinterher das erste Hello-World-Programm ausprobieren, oder?

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.

Ideen, wie das zu machen geht, habe ich schon. Eigentlich ist es nichtmal besonders aufwendig und für native tyndur-Programme völlig ausreichend. Für POSIX-Programme wäre es aber ein Hack - da müsste man irgendwann mal das volle Programm mit fork/exec und Vererbung von Dateideskriptoren implementieren.

Noch mal zum eigentlichen Thema IPC : Deine Idee mit den OS-generierten Handler-Threads gefällt mir immer noch sehr (maximale Performance bei minimaler Ressource-Verschwendung, ich denke das ich es schaffen könnte das vom SYSCALL-Befehl bis zum ersten Befehl im Handler-Thread weniger als 300 CPU-Takte vergehen, inklusive Kontext-Wechsel).

Ja, die Methode ist für mich auch eine Option für "den nächsten Versuch". Falls der irgendwann kommen sollte. Du kannst uns dann ja sagen, was deine Erfahrungen damit sind.