Thema: IPC - Implementierungsansätze

[sebi2020]

Hallo erstmal
Ich bin jetzt an dem Punkt, wo ich Paging implementiere und werde damit auch zwangsläufig dazu kommen müssen irgend eine Art von IPC zu implementieren.

In dem Wiki-Artikel find ich es sehr abstrakt. Es ist klar wie das Model aussieht, aber wie man das Softwäretechnisch implementiert, hab ich keine Ahnung, wie das gehn soll. Als Beispiel nenn ich jetzt mal die Message Queue die ich gern für mein System hätte.
Was ich mich nun Frage ist, wie ich es Umsetzte, dass ein Programm Daten emfpängt und ein anderes sendet, ohne den Programmfluss zu stören, aber trotztdem auf die Ereignisse reagieren zu können... Aber das halt so, das es zu keinen Seiteneffekten kommt. Ich versteh noch nicht ganz, wie das überhaupt gehen soll, wenn die Programme Speichermäßig und auch vom CPU Zustand völlig abgekoppelt sind.
So ein paar Zeilen Pseudo-Code würden mir vielleicht auf die Sprünge helfen.

Lieben Gruß,
Sebi2020

[kevin]

Was ich mich nun Frage ist, wie ich es Umsetzte, dass ein Programm Daten emfpängt und ein anderes sendet, ohne den Programmfluss zu stören, aber trotztdem auf die Ereignisse reagieren zu können...

Dafür gibt es unterschiedliche Ansätze.

Man kann zum Beispiel eine Nachrichtenwarteschlange basteln, aus der das Programm aktiv Nachrichten abholen muss und damit an passender Stelle behandeln kann. Wenn es nicht abholt, bleibt die Nachricht halt liegen.

Dann gibt es die Möglichkeit, das Programm einfach zu unterbrechen und zu einem Handler zu springen. Man muss dabei natürlich alle Register speichern und hinterher wiederherstellen. Problematisch ist das ganze trotzdem, wenn der Handler globale Variablen verändert, weil der unterbrochene Code damit in der Regel nicht rechnet. Vergleichbar ist das Modell mit Unix-Signalen.

Ein paarmal diskutiert wurde hier schon die Möglichkeit, einfach einen Popup-Thread neu anzulegen (bzw. einen Threadpool zu benutzen) und den Handler parallel zum normalen Programmablauf zu machen. Offensichtliches Problem ist, dass jedes Programm, das Nachrichten empfangen will, threadsicher sein muss.

Aber das halt so, das es zu keinen Seiteneffekten kommt. Ich versteh noch nicht ganz, wie das überhaupt gehen soll, wenn die Programme Speichermäßig und auch vom CPU Zustand völlig abgekoppelt sind.

Die Prozesse sind natürlich voneinander komplett abgeschottet. Deswegen muss der Kernel dafür sorgen, dass mit einem speziellen Syscall IPC gemacht werden kann. Der Kernel hat ja Zugriff auf beide Prozesse.

So ein paar Zeilen Pseudo-Code würden mir vielleicht auf die Sprünge helfen.

Code hilft bei Konzepten selten weiter.

[sebi2020]

Ja klar hat er Zugriff, aber wo sollen die Nachrichten den genau dann hin?`Also das mit dem mappen der adressen in zweier Prozesse find ich nachvollziehbar. Aber der Kernel weis doch nicht genau, wo er Nachrichten hinschreiben kann. Man könnte per Konvention ne Adresse festlegen, wo die Nachrichten dann liegen. Das würde mir z.B. einfallen. Ich meine mit dem virtuellen Adressraum ist das leichter zu bewerkstelligen, weil jeder Prozess dann z.B. seine Nachrichten bei 1 MB liegen haben könnte, oder so ähnlich. Die muss er sich dann aktiv rausfischen. So nach dem FIFO Prinzip hatte ich mir das gedacht.

[erik.vikinger]

Hallo,


IPC-Konzepte sind immer ziemlich abstrakt da es eben recht viele Varianten gibt. Die 3 Grundkonzepte, die taljeth alle genannt hat, lassen sich noch mit Dingen wie synchrone Frage-Antwort-Spiele (RPC) vs. simple asynchrone Messages (wo jeder Prozess eine eigene Queue braucht, selbst ein simples "Hello World"-Programm) oder auch über die Art der Nutzdatenübermittlung also Kopieren vs. Memory-Sharing noch weiter untergliedern.
Der Zeitpunkt um über das IPC-Konzept nachzudenken ist während des Implementierens von Paging aber IMHO schon ein wenig spät. IPC ist bei einem Micro-Kernel-OS das Basis-Konzept überhaupt, demzufolge sollte dieses Konzept meiner persönlichen Meinung nach schon gut durchdacht sein bevor überhaupt eine Zeile Code geschrieben wird.

Um sich für ein IPC-Konzept zu entscheiden musst Du als erstes die Designziele Deines OS festlegen. Ist Dir eher die Performance des fertigen OS wichtig oder soll lieber alles möglichst einfach implementierbar sein?

Das die Queue im virtuellen Adressraum des Prozess liegt empfinde ich als eher ungeschickt, das dürfte nur sehr schwer zu synchronisieren sein und wenn ein Prozess mehrere Services anbieten will wird das Problem noch größer. Außerdem machst Du damit Zero-Copy komplett unmöglich was die Performance stark limitiert.


Lass Dich nicht vom Multithreading abschrecken, das taljeth in threadsicheren Programmen ein Problem sieht liegt wohl daran das tyndur und die zugehörige libc in der Vergangenheit nicht threadsicher war und das nun geändert werden muss, so das jetzt eben das Problem einer nachträglichen Konzeptänderung entsteht. Wäre tyndur von Anfang an threadsicher gebaut worden wäre der Gesamtaufwand sicher ein klein wenig geringer ausgefallen.


Grüße
Erik

[kevin]

Ja klar hat er Zugriff, aber wo sollen die Nachrichten den genau dann hin?`Also das mit dem mappen der adressen in zweier Prozesse find ich nachvollziehbar. Aber der Kernel weis doch nicht genau, wo er Nachrichten hinschreiben kann. Man könnte per Konvention ne Adresse festlegen, wo die Nachrichten dann liegen

Ich würde das so machen, dass das Programm Speicher alloziert und dann dem Kernel sagt, wo dieser Speicher ist. Du kannst es auch andersrum machen und den Kernel automatisch einen Puffer anlegen lassen und das Programm benutzt dann eben einen Syscall, um herauszufinden, wo es die Daten auslesen muss.

Der Zeitpunkt um über das IPC-Konzept nachzudenken ist während des Implementierens von Paging aber IMHO schon ein wenig spät. IPC ist bei einem Micro-Kernel-OS das Basis-Konzept überhaupt, demzufolge sollte dieses Konzept meiner persönlichen Meinung nach schon gut durchdacht sein bevor überhaupt eine Zeile Code geschrieben wird.

Paging ist meines Erachtens so grundlegend, dass du bis dahin noch nichtmal den Unterschied zwischen einem Monolithen und einem Microkernel merkst. Es stehen also noch alle Wege offen.

Lass Dich nicht vom Multithreading abschrecken, das taljeth in threadsicheren Programmen ein Problem sieht liegt wohl daran das tyndur und die zugehörige libc in der Vergangenheit nicht threadsicher war und das nun geändert werden muss, so das jetzt eben das Problem einer nachträglichen Konzeptänderung entsteht. Wäre tyndur von Anfang an threadsicher gebaut worden wäre der Gesamtaufwand sicher ein klein wenig geringer ausgefallen.

Öhm, nein, weder habe ich im Moment vor, tyndur auf dieses Modell zu ändern, noch hat meine Aussage irgendwas mit tyndur zu tun.

Gethreadeder Code ist schwerer korrekt zu implementieren als strikt sequenzieller. Das ist einfach so, völlig unabhängig von Programmiersprache, OS, CPU-Architektur mit oder ohne Segmentierung und ähnlichen Dingen.

[sebi2020]

Lass Dich nicht vom Multithreading abschrecken, das taljeth in threadsicheren Programmen ein Problem sieht liegt wohl daran das tyndur und die zugehörige libc in der Vergangenheit nicht threadsicher war und das nun geändert werden muss, so das jetzt eben das Problem einer nachträglichen Konzeptänderung entsteht. Wäre tyndur von Anfang an threadsicher gebaut worden wäre der Gesamtaufwand sicher ein klein wenig geringer ausgefallen.

Davor schrecke ich im Moment zurück, da ich 1. bis jetzt nur Prozesse habe, keine Threads und 2. die Fehlersuche noch aufwändiger wird.
Mein erstes Ziel ist es immer es einfach zu implementieren. Mein zweites ist die Performance. Das beste Beispiel ist mein Task Scheduler, ich hab im Moment einen Round Robin (oder wie heißt der?) im System. Nur das der erste Task der ausgeführt wird derjenige ist, der als letztes in die Liste aufgenommen wurde. Das zweite ist die Speicherverwaltung. Es ist ziemlich "Ressourcenfressend", wenn er jedesmal 32768 * 32 Bits durchgeht um zu schauen, ob irgendwo freier Speicher gibt (okay, dass tut er nicht, weil meistens nach 1,2 MB oder so eine freie beschreibbare Speicherstelle ist), aber ihr wisst schon was ich meine.

Wenn ich ehrlich bin, habe ich mich noch nie mit IPC beschäftigt, was davon herrührt, das ich noch nie wirklich Programme die sowas nutzen geschrieben habe. Zu dem Konzept mit den SIGNALS...
Wenn ich das richtig verstanden habe ist es doch so, dass ein Programm diese Signals mit der Funktion signal() nutzt. Dabei wird doch das Signal festgelegt, an welches reagiert werden soll und eine callback Funktion, oder? Und mit raise() wird ein bestimmtes Signal für den Prozess ausgelöst. Stimmt das soweit?

[erik.vikinger]

Hallo,

Ich würde das so machen, dass das Programm Speicher alloziert und dann dem Kernel sagt, wo dieser Speicher ist. Du kannst es auch andersrum machen und den Kernel automatisch einen Puffer anlegen lassen und das Programm benutzt dann eben einen Syscall, um herauszufinden, wo es die Daten auslesen muss.

Beide Varianten verhindern aber Zero-Copy zuverlässig, wenn das kein Designziel ist ist das natürlich Okay.

Paging ist meines Erachtens so grundlegend, dass du bis dahin noch nichtmal den Unterschied zwischen einem Monolithen und einem Microkernel merkst. Es stehen also noch alle Wege offen.

Das ist zwar grundsätzlich richtig aber falls Shared-Memory für IPC benutzt werden soll dann sollte das schon einigermaßen spezifiziert sein bevor man anfängt Paging zu implementieren.

Gethreadeder Code ist schwerer korrekt zu implementieren als strikt sequenzieller. Das ist einfach so ....

Ohne einen Flame-War anfangen zu wollen aber das ist Quatsch. Code threadsicher zu machen ist nur für diejenigen schwerer die sich damit nicht auskennen.

Davor schrecke ich im Moment zurück ....

Dann wirst Du vieles mehrfach implementieren müssen. Zu sagen "erstmal was einfaches und dann später was besseres" bringt normalerweise kein vernünftiges Ergebnis. Das Bessere wird sicher auch ein anderes Interface haben oder muss anders benutzt werden so das Du dann fast den gesamten Code anfassen musst und wenn Du dann davor zurück schreckst und Dich mit irgendwelchen Krücken (wie Wrappern o.ä.) behilfst kommt erst recht nur Blödsinn bei raus.
Meine Empfehlung lautet ganz klar: Mach ein Konzept wie das Endergebnis aussehen soll und dann implementiere das.
Auch dabei kann es passieren das Dir am Schluss Dinge auffallen die Dich dazu zwingen Dein Konzept zu ändern wobei Du dann wieder die freudige Entscheidung zwischen einer Krückenlösung und einem (totalen) Rewrite treffen darfst.

Wenn ich ehrlich bin, habe ich mich noch nie mit IPC beschäftigt

Dann weißt Du ja was als nächstes gemacht werden muss.

was davon herrührt, das ich noch nie wirklich Programme die sowas nutzen geschrieben habe.

Programme nutzen selten IPC direkt (vor allem portable Programme) sondern tun das mithilfe von Librarys. Für die üblichen IPC-Sachen in einem Micro-Kernel-OS ist das die libc, die musst Du passend zu Deinem OS (bei dem die gesamte User-Mode-Personality, welche ja die Basis-Services anbietet, mit dazu gehört) implementieren.

Zu dem Konzept mit den SIGNALS...

So im wesentlichen ist das richtig. Wobei Signale nicht unbedingt geeignet sind größere Mengen an Nutzdaten zu übertragen, für ein write(handle,buffer,100MB) ist das keine so geschickte Lösung.
Und wo wir gerade dabei sind, ein read bekommt einen Pointer wo es die Daten hinlegen soll und liefert nicht einen Pointer wo die Daten liegen. Das ist ein sehr wesentliches Detail. Wenn Du das ohne Kopieren realisieren willst dann sollte es möglich sein das bei der read-Anfrage ein Puffer mitgegeben werden kann der dann vom Service befüllt wird und anschließen nur das Sharing beendet wird. Dazu findest Du auch schon eine Diskussion hier im Forum.


Grüße
Erik

[sebi2020]

Und wo wir gerade dabei sind, ein read bekommt einen Pointer wo es die Daten hinlegen soll und liefert nicht einen Pointer wo die Daten liegen. Das ist ein sehr wesentliches Detail...

Jetzt bin ich aber verwirrt, ein Read liest doch die Daten aus und sollte selber bestimmen können, was mit den ausgelesenen daten gemacht werden (also wo sie hin sollen. vor allem liest es doch und schreibt nicht, jetzt bin ich verwirrt was das mit "Daten irgendwo hinlegen" zu tun hat. Ich dachte eig, dass ein read einen Puffer bekommt, die mittels write dort reingeschrieben wurden...

[kevin]

Ich würde das so machen, dass das Programm Speicher alloziert und dann dem Kernel sagt, wo dieser Speicher ist. Du kannst es auch andersrum machen und den Kernel automatisch einen Puffer anlegen lassen und das Programm benutzt dann eben einen Syscall, um herauszufinden, wo es die Daten auslesen muss.

Beide Varianten verhindern aber Zero-Copy zuverlässig, wenn das kein Designziel ist ist das natürlich Okay.

Du brauchst kein Zero Copy.

Okay, ich sehe ein, das sollte ich so nicht stehen lassen: Du brauchst es jedenfalls nicht für die Metadaten. Nehmen wir zum Beispiel einen Request für die Festplatte. Ignorieren wir der Einfachheit halber mal Dinge wie scatter/gather, dann hast du einen Puffer, eine Sektornummer und eine Länge zu übertragen. Für den Puffer willst du Zero Copy haben. Für Sektornummer, Länge und die Information, dass wir hier einen Write-Request haben, interessiert es dich nicht wirklich. Also sind diese kleinen Informationen direkt in der Nachricht drin, und für den Puffer ein Verweis auf SHM oder ähnliches.

Gethreadeder Code ist schwerer korrekt zu implementieren als strikt sequenzieller. Das ist einfach so ....

Ohne einen Flame-War anfangen zu wollen aber das ist Quatsch. Code threadsicher zu machen ist nur für diejenigen schwerer die sich damit nicht auskennen.

Sorry, aber das überzeugt mich nicht. Früher kannten wir dieses Argument als "Aber ein guter Assemblerprogrammierer ist so viel besser als ein durchschnittlicher C-Programmierer, dass sein Code trotzdem besser ist".

Etwas zu tun ist schwieriger als es nicht zu tun, auch wenn es "nur" darum geht, Code threadsicher zu machen. Aber ich widerspreche dir auch schon bei diesem "nur". Nebenläufigkeit ist nicht einfach und es braucht zumindest einiges an Erfahrung, um es richtig zu machen. Ich behaupte, es ist auch dann noch nicht trivial.

Oder umgekehrt: Zeig mir doch mal ein Beispiel, wo es einfacher ist, threadsicheren Code zu schreiben als die Threadsicherheit zu ignorieren?

Meine Empfehlung lautet ganz klar: Mach ein Konzept wie das Endergebnis aussehen soll und dann implementiere das.

Die meisten bauen ein OS, um zu lernen, wie ein OS funktioniert. Wenn sie es vorher schon wüssten, bräuchten sie keins zu bauen. Auf die Schnauze fliegen gehört zum Lernen dazu.

[sebi2020]

Hm, habt ihr vielleicht eine gute Adresse wo solche Dinge erklärt werden?
Ich hab mir mal z.B. das mit den unamed Pipes angeschaut. Ich verstehe nciht wie das Funktionieren soll...
Ich meine diesen teil hier:

Code: [Auswählen]

int main(void)
{
int fd[2];
int status = pipe(fd);
...
return 0;
}
Wie soll den die pipe Funktion die handles zurückliefern, wenn fd so übergeben wird. Oder verweist fd auf eine Adresse weils nen Array ist, und die pipe funktion kann so die elemente belegen? Ich frag mich halt, weil ich jetzt gewettet hätte, das man einen Pointer übergeben muss. Aber bei diesem Aufruf wird im Grunde ein Pointer übergeben, oder? Weils ein Array ist...

EDIT: Also ich gucke sehr oft auf dieser Seite nach:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/contents.html

[erik.vikinger]

Hallo,

ein Read liest doch die Daten aus

Aus der falschen Richtung betrachtet. Ein read sagt dem System wo es die Daten hinschreiben soll welche aus einer Datei/Pipe/sonstwas kommen.

Ich dachte eig, dass ein read einen Puffer bekommt, die mittels write dort reingeschrieben wurden...

Wieder aus der falschen Richtung betrachtet. Ein write schreibt die Daten wieder nach Extern (egal wo/was das ist) die das read von Extern (das selbe oder ein anderes) geholt hat. Aus Sicht der Applikation ist write ein Lesezugriff (es ließt Die Daten aus Deinem User-Mode-Puffer) und read ein Schreibzugriff (es schreibt die Daten in Deinen User-Mode-Puffer.)

Also sind diese kleinen Informationen direkt in der Nachricht drin, und für den Puffer ein Verweis auf SHM oder ähnliches.

Richtig. Das ist es was ich mit Nutzdaten ausdrücken wollte. Die Metainformationen werden bei einfachen Dingen sicher direkt per Register übergeben und selbst wenn das als simple Message im Speicher liegt kostet das nicht wirklich Performace sowas zu kopieren (dafür haben aktuelle CPUs Cache).

Etwas zu tun ist schwieriger als es nicht zu tun ....

Okay, das ist sicher auch eine Frage wie man überhaupt programmiert. Wenn man über den Code vor/während des Tippens nachdenkt dann fallen Dinge wie Threadsicherheit automatisch mit ab. Das klingt sicher reichlich arrogant aber ich würde behaupten das der meiste von mit getippte Code threadsicher ist. Ich mach mir z.B. bei jeder Variable bzw. Objekt Gedanken wo die hingelegt werden soll (Statisch, auf dem Stack oder auf dem Heap) da ist der Gedanke an die Threadsicherheit einfach mit dabei.

Die meisten bauen ein OS, um zu lernen, wie ein OS funktioniert. Wenn sie es vorher schon wüssten, bräuchten sie keins zu bauen.

NAK
Man muss doch kein Auto bauen um zu wissen wie es funktioniert, egal wie tief dieses Wissen ins Detail gehen soll.

Auf die Schnauze fliegen gehört zum Lernen dazu.

Dem kann ich zu 100% zustimmen. Aber eines was man möglichst früh lernen sollte ist es zu vermeiden auf der Schnauze zu laden. Meine persönliche Erfahrung sagt mir eindeutig das es einfacher ist sich erst mit einer Sache soweit zu beschäftigen das man eine konkrete Vorstellung davon hat und dann dafür zu Programmieren als andersrum.

Aber bei diesem Aufruf wird im Grunde ein Pointer übergeben, oder? Weils ein Array ist...

Ganz genau, in C werden Arrays immer per Referenz übergeben und nie als Kopie. Ist zwar manchmal etwas verwirrend und auch doof das man bei allen Typen (selbst großen Strukturen/Objekten) die Wahl hat und bei Array nicht aber so ist C nunmal.


Grüße
Erik

[kevin]

Also sind diese kleinen Informationen direkt in der Nachricht drin, und für den Puffer ein Verweis auf SHM oder ähnliches.

Richtig. Das ist es was ich mit Nutzdaten ausdrücken wollte. Die Metainformationen werden bei einfachen Dingen sicher direkt per Register übergeben und selbst wenn das als simple Message im Speicher liegt kostet das nicht wirklich Performace sowas zu kopieren (dafür haben aktuelle CPUs Cache).

Wo ist dann der Widerspruch zwischen Zero Copy der Nutzdaten und meiner Nachrichtenwarteschlange? Du hast ja immerhin behauptet, dass das ganz und gar unmöglich vereinbar sei.

Okay, das ist sicher auch eine Frage wie man überhaupt programmiert. Wenn man über den Code vor/während des Tippens nachdenkt dann fallen Dinge wie Threadsicherheit automatisch mit ab. Das klingt sicher reichlich arrogant aber ich würde behaupten das der meiste von mit getippte Code threadsicher ist. Ich mach mir z.B. bei jeder Variable bzw. Objekt Gedanken wo die hingelegt werden soll (Statisch, auf dem Stack oder auf dem Heap) da ist der Gedanke an die Threadsicherheit einfach mit dabei.

Und du meinst, ich würfle das aus, wo die Variable hinkommt?

Sich klarzuwerden, wo man was wie locken muss, ist nicht immer ganz offensichtlich. Es fällt sicher nicht automatisch als Nebenprodukt beim Tippen ab, sondern man muss sich Gedanken drüber machen. Ich traue dir zu, dass du das tatsächlich tust, aber wenn man sich ernsthaft Gedanken über etwas machen muss, dann ist es ganz offensichtlich schwer.

Die meisten bauen ein OS, um zu lernen, wie ein OS funktioniert. Wenn sie es vorher schon wüssten, bräuchten sie keins zu bauen.

NAK
Man muss doch kein Auto bauen um zu wissen wie es funktioniert, egal wie tief dieses Wissen ins Detail gehen soll.

Du hast nicht meiner Aussage, sondern ihrer Umkehrung widersprochen. Nächster Versuch, bitte.

[erik.vikinger]

Hallo,

Wo ist dann der Widerspruch zwischen Zero Copy der Nutzdaten und meiner Nachrichtenwarteschlange?

Bei Deiner Queue hast Du nur von Daten allgemein gesprochen und ich bin da irrtümlich davon Ausgegangen das Du die Message als ganzes, inklusive der Nutzdaten, meinst. Sorry.

Und du meinst, ich würfle das aus, wo die Variable hinkommt?

Da Du ja nun schon mehrmals geschrieben hast das richtiges Nachdenken schwer ist war das tatsächlich mein naheliegenster Gedanke, ja.

Es fällt sicher nicht automatisch als Nebenprodukt beim Tippen ab, sondern man muss sich Gedanken drüber machen.

Richtig, aber das trifft IMHO auf alle Aspekte des Programmierens zu und nicht nur auf Nebenläufigkeit. Oder willst Du ernsthaft behaupten das Du über den von Dir getippten Code gar nicht nachdenkst?

aber wenn man sich ernsthaft Gedanken über etwas machen muss, dann ist es ganz offensichtlich schwer.

Ich hab auch nicht behauptet das es einfach wäre, sonst könnte ja jeder Noob super toll programmieren. Ich behaupte nur das wenn man sich als Programmierer eh ernsthaft Gedanken machen muss dann ist Nebenläufigkeit auch kein nennenswerter Extraaufwand mehr.

Du hast nicht meiner Aussage, sondern ihrer Umkehrung widersprochen. Nächster Versuch, bitte.

Ich denke schon das ich Deiner eigentlichen Aussage widersprochen habe aber wenn Du willst dann jetzt Versuch 2:

Wenn sie es vorher schon wüssten, bräuchten sie keins zu bauen.

Damit sagst Du doch das Vorwissen kontraproduktiv ist, oder wie soll ich das sonst verstehen?
Ich habe mich die letzten 3 bis 4 Jahre ziemlich intensiv mit den Konzepten verschiedener OSe beschäftigt. Ich denke das ich heute ein recht umfangreiches Wissen über den Aufbau von Betriebssystemen im allgemeinen habe, egal ob Monolith oder Micro-Kernel. Ich hoffe doch Du erklärst mir jetzt nicht das ich mein Projekt gleich ganz bleiben lassen kann nur weil für meinen eigenen Kernel bereits ganz genau 0 Zeilen Code existieren.
Ich bin wirklich der Meinung das es besser ist sich erst mit einer Sache so intensiv zu beschäftigen das man wirklich Ahnung davon hat und erst danach anfängt Code zu schreiben. Wenn man das andersrum macht macht man das bloß mehrmals was im Endeffekt deutlich mehr Zeit erfordert. Im Berufsleben kann ich es mir nicht erlauben mehrere Lösungen für ein Problem zu implementieren bis ich mal eine hab die wirklich gut funktioniert, so viel Zeit ist einfach nicht vorhanden, und meine private Freizeit ist ebenfalls nicht unbegrenzt (nicht nur weil ich alleinerziehender Vater bin) so das ich meine Hobby-Projekte genauso angehe.
Bitte versteht mich nicht falsch, ihr könnt wirklich stolz auf Eure Arbeit sein, aber wenn ihr vorher die grundlegenden Konzepte von tyndur ordentlich durchdacht hättet dann wäre Euer heutiges IPC-Design keine solch vortreffliche Performance-Bremse wie es das jetzt ist.

Ist noch ein Versuch 3 erforderlich? Oder war ich für heute genug Ar***loch?


Grüße
Erik

[kevin]

Ich sage nicht, dass Vorwissen kontraproduktiv ist, sondern dass, wenn das persönlich Ziel beim OS-Dev ist, zu lernen, was hinter den Kulissen passiert und man genau weiß, wie man es anstellen muss, dass man dann das Ziel eigentlich schon erreicht hat und den Kernel gar nicht mehr erst schreiben muss. Insofern, wenn das dein Ziel war, brauchst du deine Architektur wohl nicht mehr verwirklichen, ja.

Ich sehe ja ein, dass du eine eher theoretische und sorgfältige Herangehensweise hast. Ich kenne noch mehr von dieser Sorte. Was die machen, hätte absolut Hand und Fuß, wenn es denn mal fertigwerden würde. Ich und viele andere sind ein anderer Typ: Wenn ich eine Idee habe und damit draufloshacken kann, dann macht es Spaß. Wenn ich monatelang planen muss, artet es in Arbeit aus, und das brauche ich ja eigentlich nicht auch noch in meiner Freizeit.

[FlashBurn]

Ich mische mich in die Diskussion mal ein.

Muss taljeth recht geben, wenn man nur theoriesiert (was ein komisches Wort) hat man Wissen, aber das bringt dir oft absolut gar nix. Erst mit dem Machen und der Erfahrung kannst du was wirklich.

Theoretisch Autofahren können und praktisch Autofahren können sind zwei absolut unterschiedliche Dinge

Noch besser ist aber das Bsp. Fahrradfahren. Denn theoretisch ist das verdammt einfach, aber praktisch braucht man da ganz schön Übung (und versuch mal jemanden zu erklären wie man das Gleichgewicht hält )

[Svenska]

Naja, das sind einfach zwei paar Schuhe: Entweder, man entwickelt ein OS, um ein OS zu entwickeln (und dabei zu verstehen, wie es funktioniert) - oder man versteht, wie es funktioniert und entwickelt es nach diesen Vorgaben, um es praktisch umzusetzen. Beides sind valide Ansatzpunkte, nur dass man beim ersten Fall schneller zu (auch suboptimalen) Ergebnissen kommt.

Gruß,
Svenska

[erik.vikinger]

Hallo,

Ich sage nicht, dass Vorwissen kontraproduktiv ist, sondern dass, wenn das persönlich Ziel beim OS-Dev ist, zu lernen, was hinter den Kulissen passiert und man genau weiß, wie man es anstellen muss, dass man dann das Ziel eigentlich schon erreicht hat und den Kernel gar nicht mehr erst schreiben muss.

Ein schwieriger Satz aber so wie ich ihn verstehe möchte ich noch mal wiederholen:

Man muss doch kein Auto bauen um zu wissen wie es funktioniert, egal wie tief dieses Wissen ins Detail gehen soll.

Wenn man eine Sache möglichst gut verstehen möchte ist es nicht immer zuträglich wenn man dieses Wissen sofort in die Praxis umsetzt. Gerade bei der OS-Entwicklung ist es doch so das wenn man anfängt bevor man alles weis das man dann ziemlich schnell vor einem Fehldesign steht und man damit im Endeffekt nur seine Zeit vertrödelt hat die für das theoretische Studium sinnvoller eingesetzt wäre. Solange das eigentliche Ziel eben nur das Erlangen von Wissen ist.

Insofern, wenn das dein Ziel war, brauchst du deine Architektur wohl nicht mehr verwirklichen, ja.

Du kennst mein Ziel. Ich möchte beweisen das sehr hohe Sicherheit und sehr hohe Performance sich nicht gegenseitig ausschließen müssen. Diesen Beweis kann ich aber nur dann sauber erbringen wenn ich es auch tatsächlich umsetze und nicht bloß theoretisch darüber philosophiere. Ich denke das ich gerade wegen meinem IPC-Konzept die Performance-Rückstände eines Micro-Kernel gegenüber einem Monolithen deutlich verringern kann, ohne dafür die Sicherheit des Micro-Kernel-Paradigmas aufweichen zu müssen.

.... wenn es denn mal fertigwerden würde.

Du willst doch damit hoffentlich nicht sagen das Leute wie ich ihre Projekte nicht fertig bekommen? Ich denke das ich gerade wegen meiner Vorgehensweise es so oft schaffe meine Aufgaben rechtzeitig und ordentlich zu Ende zu bringen, das bestätigt mir auch meine über 10 Jahre Berufspraxis.

Ich und viele andere sind ein anderer Typ: Wenn ich eine Idee habe und damit draufloshacken kann, dann macht es Spaß. Wenn ich monatelang planen muss, artet es in Arbeit aus

Natürlich macht das programmieren an sich auch Spaß, das steht völlig außer Frage, aber ein tolles Ergebnis und das gute Gefühl es mit möglichst wenig Aufwand erreicht zu haben können auch sehr befriedigend sein. Mir persönlich macht aber auch gerade das Designen und Konzeptionieren großen Spaß und das eigentliche Umsetzen ist oft nur noch simple Fleißarbeit.

und das brauche ich ja eigentlich nicht auch noch in meiner Freizeit.

ACK 

(und versuch mal jemanden zu erklären wie man das Gleichgewicht hält )

Dann beobachte Dich mal bei der nächsten Fahrradtour ganz bewusst selber (natürlich nicht im Straßenverkehr sondern irgendwo wo Du ganz ungestört bist) und Du wirst sehen das sich die Kunst des Fahrradfahrens in wenigen Punkten zusammenfassen lässt. Fahrradfahren ist ein deterministischer Vorgang und daher auch vollständig erklärbar, dagegen ist OS-Dev schon ein ziemlich komplexes und nur schwer überschaubares Gebiet. Ein weiterer Unterschied zwischen Fahrradfahren und OS-Dev ist das ersteres völlig unbewusst geschehen muss, sonst könnten wir uns ja eben nicht noch nebenher auf den Straßenverkehr o.ä. konzentrieren, so das hierfür einfach viel Übung erforderlich ist damit sich die passenden Verknüpfungen in unserem Gehirn entwickeln können.


Grüße
Erik

[FlashBurn]

@erik

Mir ging es vorallem darum das es auch viele Situationen gibt, wo dir die Theorie gar nichts bringt.

Ein eher praktisches Bsp., mein Vater hat mal in einen Stickstoffwerk gearbeit und das als Facharbeiter. In der Nachtschicht war es dann so, das die Ingenieure eigentlich nur meinen Vater losgeschickt haben um irgendwelche Probleme zu lösen, da sie zwar theoretisch wussten wie die Anlage funktioniert, aber praktisch keine Ahnung hatten welche Ventile wie weit auf oder zu gedreht werden mussten und solche Dinge.

Sowas sehe ich auch oft in der Uni, klar wissen die wie ein AVL-Baum theoretisch funktioniert und können dir das auch erklären, ihn aber richtig zu programmieren und das gleich beim ersten Mal, das schaffen die wenigsten und das sind dann auch immer die die schon Erfahrung mitbringen.

Auch schützt das theoretische Beschäftigen vor dem Programmieren nicht vor Fehlern, die wirst du dann genauso erst beim Programmieren feststellen.