Lowlevel
Lowlevel => OS-Design => Thema gestartet von: TheThing am 24. October 2009, 21:18
-
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
-
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
-
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" ?
-
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.
-
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" :P
Jetzt weiß ich wenigstens mal wie ich rangehen muss :)
-
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" :P
Sagen wir so: Ich kenne die Nachteile der tyndur-Methode mittlerweile ganz gut. Vielleicht sind andere Methoden genauso doof, das weiß ich nicht.
-
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
-
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.
-
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. :oops:
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
-
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.
-
Hallo,
Richtig.
:-o
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. :wink:
Warum alles Mist?
Ich denke fast alles was einem da so einfällt ist besser als das was jetzt in Tyndur drin ist. :wink:
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
-
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. :wink:
Warum alles Mist?
Ich denke fast alles was einem da so einfällt ist besser als das was jetzt in Tyndur drin ist. :wink:
Es gibt verschiedene Ebenen von Mist. :-D
Und wenn du den Drang verspüren solltest, tyndur mit was besserem zu beglücken, akzeptieren wir übrigens gern Patches. ;)
-
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. :-D
Das mag sein, das was zur Zeit als IPC-Mechanismus in tyndur realisiert ist stellt aber schon eine ungewöhnliche Ebene Mist dar. :-D
Und wenn du den Drang verspüren solltest, tyndur mit was besserem zu beglücken, ....
Da kann ich mich grad so beherrschen. :wink: 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
-
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. :-D
Wir machen eben nicht nur normale Sachen, sondern was ganz besonderes. :)
-
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 ;)
-
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? :wink:
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. :wink: Mein Projekt, eine Plattform mit Segmentierung, ist auch nichts gewöhnliches.
Also, wenn mein OS mehr als 50% Marktanteil hat melde ich mich wieder :wink:
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
-
Ja, dieses Problem ist mir wohl bekannt. Aber sollte nicht eine gute Lösung eine ausreichende Motivation sein? :wink:
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).
-
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. :wink:
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
-
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 :)
-
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. ;)
-
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. :wink:
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. :wink:
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. :wink:
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
-
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... :roll:
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
-
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 (http://git.tyndur.org/?p=lbuilds.git;a=tree;f=lbuilds/coreutils/7.4/patches;h=3d0df99b6c8da9b39838808813b48f15e65e0d2f;hb=HEAD) ü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. :wink:
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 (http://lowlevel.brainsware.org/forum/index.php?topic=1787.0).
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.
-
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.
-
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...
-
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 formuliertdass 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 (http://lowlevel.brainsware.org/forum/index.php?topic=1787.0).
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
-
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?
-
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. :wink:
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. :cry: 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
-
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. :wink:
Grüße
Erik
-
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. :wink:
Nur zu. Versuch macht kluch. ;)
-
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. ;)
:-D
Grüße
Erik
-
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.
-
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
-
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