Nachrichten

601

Lowlevel-Coding / Re:Neuen Prozess laden/starten (Mikrokernel)

« am: 10. October 2010, 11:12 »

Ich habe mal ein wenig im INet gesucht und so wie ich das mit fork() und dem Vererben von z.B. Sockets bei nem Webserver verstanden habe funktioniert das so, dass der Parent sein Socket nach dem fork() schließt und dann nur noch das Kind alleine den Socket nutzt.

Wenn das bei annähernd 100% aller Fälle so ist (was ich nicht glaube) dann ist das Problem doch praktisch nicht vorhanden?!

Ich will darauf hinaus, das selbst bei anderen Sachen (wie z.B. Sockets) nie der Fall eintritt, dass mehrere Prozesse gleichzeitig (mit ein und dem selben Dateidiskriptor/-pointer) lesend zugreifen.

Wenn ich mich nicht irre, dann sind ja C-Library und POSIX zwei unterschiedliche Sachen oder?

Edit::

Nachdem was ich zu fork() und dup() gefunden habe, ist fork() der einzige Fall wo wirklich der Dateipointer auch geshared wird (und es wird auch gesagt, das gleichzeitiger Zugriff nicht sequentiell ist) und bei dup() wird zwar die Position übernommen, aber es ist ein eigenständiger Dateidiskriptor, sprich es ist ein "fork" (eine Momentaufnahme) des Dateidiskriptors.

602

Lowlevel-Coding / Re:Neuen Prozess laden/starten (Mikrokernel)

« am: 09. October 2010, 18:37 »

stdio.h ist grundsätzlich gepuffert. Lies dir am besten mal die Doku zu setvbuf durch.

Die Frage ist dann ja, wann wird der Buffer geflusht? Wird es zu oft gemacht, ist es nicht gut für die Performance, wird es zu wenig gemacht, kommen eventuell Meldungen auf der Konsole "zu spät" an.

Da sehe ich dann die ersten Nachteile, wenn man alles auf Dateien abbildet. Denn ich würde sagen, wenn man in Dateien schreibt, kann der Buffer ruhig etwas größer sein und sollte so wenig wie möglich geflusht werden, aber was Meldungen auf der Konsole betreffen, möchte ich die so schnell wie möglich sehen, werden die aber in eine Datei umgeleitet ist wieder ein großer Buffer besser.

603

Lowlevel-Coding / Re:Neuen Prozess laden/starten (Mikrokernel)

« am: 09. October 2010, 17:42 »

Weil Sockets was anderes als Dateien sind und insbesondere nicht vom "VFS-Dienst" verwaltet werden?

Auch

Aber wenn ich dein Bsp. richtig verstehe (wenn nicht gibt es die selben Probleme wie bei der gleichzeitigen Nutzung von einer Datei) dann wird der Socket ja "nur" weitergegeben, sprich der "Erstbesitzer" greift nicht mehr darauf zu? Dann gibt es auch keine Probleme.

Wir reden aber davon, das mehrere Threads/Prozesse durch ein und den selben Diskriptor auf eine Datei zugreifen und das glaube ich kaum das es wirklich verwendet wird.

Edit::

@erik

Ich glaube so langsam, das "unser" VFS-Service doch einige Sachen übernehmen muss, außer reines Dateihandling. Denn wie hast du es dir vorgestellt das Umleiten von Stdin/Stdout zu bewerkstelligen, wenn du es nicht auf Dateien abbildest?

@all

Etwas Offtopic, aber passt irgendwie doch hierher.

Wie funktioniert euer printf. Genauer bin ich daran interessiert ob ihr die Daten erst in einen "kleinen" (die Größe wäre auch interessant) Buffer schreibt und am Ende von printf einen flush() macht oder ob ihr jedes Zeichen einzeln sendet (was ich eher nicht glaube).

Ich frage das, weil ich auch schon von Problemen gehört habe, das unter Umständen die Ausgabe eines Programms erst sichtbar wird, wenn dieses beendet wird, weil erst dann ein flush() durchgeführt wird, aber jedes Zeichen einzeln zu senden ist ja auch quatsch.

604

Lowlevel-Coding / Re:Neuen Prozess laden/starten (Mikrokernel)

« am: 08. October 2010, 22:24 »

Also ich stimme erik zu, solange wie kein "vernünftiges" Bsp. genannt wird sehe ich auch keinen Sinn darin einen Diskriptor zu vererben, halt wegen der genannten Probleme.

605

Lowlevel-Coding / Re:Neuen Prozess laden/starten (Mikrokernel)

« am: 08. October 2010, 12:11 »

Ich habe mir mal den MINIX-Source und Windows-Aufrufe angeguckt und es läuft darauf hinaus, das der VFS-Service einen neuen Prozess startet.

Man richtet also die Anfrage, einen neuen Prozess zu starten, an den VFS-Service. Dieser kann dann (wenn nötig/gewollt) irgendwelche Handles an den Kindprozess weitervererben.

Soweit ich das bei Windows verstanden habe, würde eine Shell ein Konsolenfenster öffnen. Wenn die Shell dann ein Programm ausführt, erstellt es Pipes für Stdin/Stderr/Stdout und "vererbt" diese an den Kindprozess. Sprich wenn der Kindprozess wieder einen Prozess startet würde er auch wieder Pipes erstellen und diese "weitervererben". So entsteht unter Umständen ne tierisch lange Kette und es muss verdammt viel kopiert werden.
Was mir daran ein wenig komisch vorkommt, ist dass das auch bedeutet das jeder Prozess läuft und aus der vererbten Pipe liest und die Daten an seine Stdout Pipe weiterreicht. Das finde ich dann doch ein wenig umständlich/kompliziert.

Ich bin mir immernoch nicht sicher wie ich es denn nun umsetze. Allerdings scheinen wirklich alle OSs nur einen Handle für das Dateihandling zu nutzen und der Rest (Filepointer usw.) liegt beim VFS-Service.

Das heißt also das meine Idee so nicht klappen wird. Ich wollte es eigentlich so machen, das Dateien immer in 4K Blöcken in den Prozess gemappt werden und fread dann z.B. daraus in den Client-Buffer schreiben würde. Auch würde dann der VFS-Service sich nie um den Filepointer und solche Geschichten kümmern müssen und er hätte einfach immer nur irgendwelche Pages durch die Gegend geschoben.

Nur ist es bei dieser Idee schwierig das mit dem Vererben umzusetzen. Denn der Filepointer wäre ja beim Clienten.

Da stellt sich mir halt wieder die Frage, wo (außer bei Stdout/Stdin/Stderr) wird das Vererben angewendet? Denn wenn das wirklich nicht häufig und nur für spezielle Sachen verwendet wird, dann könnte man das auch anders lösen.

606

Lowlevel-Coding / Re:Neuen Prozess laden/starten (Mikrokernel)

« am: 06. October 2010, 17:14 »

Waren Stdout/Stderr/Stdin nicht die ersten 3 Filehandles eines Prozesses?

Ich habe mir das dann so vorgestellt, das man einfach so als wenn man in die Datei schreiben würde den write-Aufruf macht und das VFS dann die Daten an meinen App-Server per Pipe weitersendet. So wird zwar unnötig kopiert aber das sollte mir einige Probleme vom Hals halten.
So kann ich auch ganz einfach das Vererben lösen.

Ich muss allerdings erik zustimmen, dass das eigentlich nicht die Aufgabe des VFS ist.

607

Lowlevel-Coding / Re:Neuen Prozess laden/starten (Mikrokernel)

« am: 05. October 2010, 21:16 »

Was leider immer noch keiner erklärt hat ist ob es tatsächlich Anwendungsfälle gibt in denen 2 Prozesse auf die selbe Datei über den selben File-Descriptor zugreifen. Das stelle ich mir immer ziemlich tricky vor.

Wäre ich auch dran interessiert.

Das geht binär genau so gut und ist leichter zu parsen/interpretieren.

Aber, binär legst du auch die Reihenfolge fest und wie willst du es machen einen neuen Parameter hinzuzufügen ohne das es Probleme mit alten Programmen gibt. Auch wäre es so kein Problem wenn sich irgendwelche IDs ändern würden (z.B. bei Syscalls) weil man ja den direkten Namen nimmt.

608

Lowlevel-Coding / Re:Neuen Prozess laden/starten (Mikrokernel)

« am: 05. October 2010, 20:50 »

Für solche Fälle kann man auch select() oder poll() oder epoll() oder kqueue nutzen. Du kannst ja nicht nur auf zu schreibende, sondern auch auf zu lesende Daten warten. Ursprünglich funktionierte das nur mit Sockets, inzwischen kannst du diese libc-Funktionen auch auf Dateihandles anwenden. Es sei denn, ich irre mich gerade gewaltig.

Gut, das klingt so als wenn das nicht immer so war? Mir geht es darum, das diese "Dateien" im Kernel also speziell behandelt werden, das aber hinter einer Datei versteckt wird.

XML ist ein Gerüst der Hölle. So ziemlich jede XML-Implementation ist kaputt, anfällig für buffer overflows usw. Wer auf Anhieb eine XML-Implementation fehlerfrei hinkriegt, der ist entweder ein Genie oder ein Lügner.

Außerdem müsstest du deine XML-Strukturen ohnehin inkompatibel zum Rest der Welt standardisieren, da kannst du ein (wesentlich einfacher zu parsendes) binäres Format nutzen. Das ist zudem noch kleiner. Bleib mir bloß mit XML vom Leibe.

Ok, XML ist schlecht, aber ich meine sowas das man eine Anfrage in der Art macht:

Code: [Auswählen]

OPEN name="foo.bar" flags="rb"
So wäre es z.B. egal in welcher Reihenfolge du Parameter übergibst und damit lassen sich dann bestimmt auch andere schöne Sachen machen.

Du könntest z.B. mehrere verschiedene Versionen dieses "call´s" haben mit verschiedenen Parametern und wenn ein altes Programm nicht alle Parameter übergibt, dann werden in die restlichen Standardwerte reingeschrieben.

609

Lowlevel-Coding / Re:Neuen Prozess laden/starten (Mikrokernel)

« am: 05. October 2010, 18:15 »

Das stelle ich mir sehr langsam vor. Die Prüfung auf Wohlgeformtheit ist bei XML nicht ohne und eine XML-Anfrage ist x-fach größer als ein Binär-Äquivalent.

Das wird auch der Grund sein, warum es noch nicht wirklich versucht wurde, aber wenn man den Overhead mal beiseite lässt wäre ne Text-API nicht schlecht.

610

Lowlevel-Coding / Re:Neuen Prozess laden/starten (Mikrokernel)

« am: 05. October 2010, 16:40 »

Kannst du, oder andersrum. Beispiel wieder DOS: Pipes sind Dateien.

Aber nur wenn du nach der "alles ist eine Datei" Philosophie handelst. Zumal das immernoch nicht meine Frage beantwortet wie das auf der lesenden Seite aussieht.

Was ich halt nicht ganz verstehe ist, man liest bis zum EOF, soweit so gut, aber was passiert wenn man ftell() aufrufen würde und liest man dann das nächste mal einfach wieder bis zum EOF und wie wird man benachrichtig das neue Daten vorhanden sind?

Im Endeffekt ist zwar nach außen alles eine Datei, aber dahinter muss man sich immer was spezielles einfallen lassen, damit es funktioniert. Warum dann nicht den Layer der Datei weglassen?

Der Vorteil ist, dass du die Schnittstelle zwischen Kernel und Treiber komplett ändern kannst und trotzdem irgendwie (read/write) kompatibel zum Userspace bleibst - es ändern sich nur ein paar Dateinamen - was du mit den reinen exportierten APIs nicht kannst. Die APIs kannst du natürlich direkt exportieren (z.B. DOS-basierte Windowse). Die Darstellung als Datei ist nur der nullte Wrapper.

Ich sehe da keinen Vorteil. Entweder es ändert sich die exportierte API und beide Seiten (Kernel und Treiber) müssen geändert werden oder es ändert sich das Protokoll welches hinter read/write kommt, dann muss genauso neugeschrieben werden.

Aber mal zum Punkt fexible API. Ich habe in letzter Zeit oft mit dem Gedanken gespielt das ne Text-API (nach XML Art) ziemlich flexible wäre.?

611

Lowlevel-Coding / Re:Neuen Prozess laden/starten (Mikrokernel)

« am: 05. October 2010, 15:47 »

Das eigentliche Problem ist doch, das diese "alles ist eine Datei" Geschichte vorallem auf monolithische Kernel zugeschnitten ist und man so bei einem Mikrokernel einen IPC Overhead hat den man nicht haben müsste.

Das nächste Problem sehe ich darin wie man z.B. den Stdout implementiert. Ich meine wie soll ich mir das am lesenden Ende vorstellen und wo werden die Daten wie gespeichert?
Würde man das ganze als Pipe implementieren ist das schon wesentlich einfacher.

Eine Sache habe ich aber noch nicht ganz verstanden, File-Handles werden doch pro Prozess und nicht global rausgegeben, oder? Wie stellt man dann sicher das 2 Handles auch ein und die selbe Datei ansprechen?

Weil ansonsten könnte ich die Stout/-err/-in Geschichte einfach per Pipe lösen.

612

Lowlevel-Coding / Re:Neuen Prozess laden/starten (Mikrokernel)

« am: 04. October 2010, 16:58 »

Warum wurde C "erfunden" und woran hat sich der C-Standard orientiert? Unix, richtig

Ich wollte das in eine Pipe schreiben (ist keine Datei) und es dann in einem "Konsolen"-Fenster ausgeben.

Musst du eigentlich irgendwo festlegen, das du willst, das alle Diskriptoren kopiert werden bzw. nicht kopiert werden? Oder musst du dann jedes Mal ne neue Standardausgabe öffnen wenn du nicht die alte nutzen willst?

613

Lowlevel-Coding / Re:Neuen Prozess laden/starten (Mikrokernel)

« am: 04. October 2010, 16:48 »

Aber jetzt denk mal weiter und leite die Standardausgabe in eine Datei um. Du willst, dass auch die Ausgabe der Kindprogramme mitgeloggt wird, und du willst nicht, dass sich die Ausgaben der verschiedenen Prozesse gegenseitig überschreiben, weil ihr Dateizeiger unabhängig ist.

Wo wir wieder bei so einer Unix-Sache wären, ich hatte nämlich nicht vor die Standardausgabe als Datei anzulegen, sondern das muss ich emulieren. Na mal sehen wie ich das alles hinbekomme.

Die Kinderprozesse würden bei mir ihr eigenes "Fenster" bekommen.

614

Lowlevel-Coding / Re:Neuen Prozess laden/starten (Mikrokernel)

« am: 04. October 2010, 16:37 »

Das war nicht wirklich hilfreich

Nee, aber mal ehrlich, in welcher Situation braucht man sowas? Ich meine das bedeutet ja auch, das wenn ein Prozess die Datei liest und der Pointer verändert wird, das dann der andere Prozess an der neuen Stelle liest oder?

Das klingt so als wenn man sich das hat einfallen lassen um Multithreading per Multitasking zu simulieren. Klingt also nach Unix

615

Lowlevel-Coding / Re:Neuen Prozess laden/starten (Mikrokernel)

« am: 04. October 2010, 16:27 »

Sowas müsste man dann in einer "libposix" verstecken und die müssten beide miteinander kommunizieren.

Wozu braucht man sowas bzw. wo wird es angewendet?

616

Lowlevel-Coding / Re:Neuen Prozess laden/starten (Mikrokernel)

« am: 04. October 2010, 14:10 »

Also ein Dateideskriptor ist eigentlich schon das, was du wohl mit einem Handle meinst. Einfach ein Integer, den du z.B. von open() zurückkriegst.

Was mich verwirrt hat, war das du davon gesprochen hast das ein solcher Diskriptor die Position in der Datei speichert.

So wie ich mir das vorgestellt habe, wird das alles in der libc gemacht, sprich du sagst dem VFS-Service immer welchen 4kb Block du gerade brauchst und den Rest macht der libc Code.

Der VFS-Service soll bei mir eigentlich wirklich nur minimale Sachen machen und der Rest wird von den Libraries gemacht.

617

Lowlevel-Coding / Re:Neuen Prozess laden/starten (Mikrokernel)

« am: 04. October 2010, 13:38 »

Es sind also zwei Deskriptoren, die sich aber beispielsweise einen gemeinsamen Zeiger für die Position in der Datei teilen.

Du solltest mir eventuell erläutern was ein Dateidiskriptor ist, ich glaube ich habe das mit dem Dateihandle (einfach ne ID) verwechselt. Denn der Diksriptor ist doch der Client-Teil des Handles oder?

618

Lowlevel-Coding / Re:Neuen Prozess laden/starten (Mikrokernel)

« am: 04. October 2010, 13:09 »

Wenn du was POSIX-artiges machst, musst du übrigens noch viel mehr an den neuen Prozess weitergeben als nur Parameter. Beispielsweise Umgebungsvariablen oder Dateideskriptoren (wie auch immer die bei dir intern funktionieren).

Das wäre meine nächste Frage gewesen. Wie man z.B. das mit den Dateidiskriptoren lösen könnte.

Ich dachte daran, dass das der erzeugende Prozess selber machen sollte, so würde kein Sicherheitsproblem entstehen.
Er (der Prozess der einen neuen gestartet hat) schickt dem VFS-Service eine Nachricht das alle seine Dateidiskriptoren an einen bestimmten Prozess kopiert werden (oder was genau muss mit den Dateidiskriptoren gemacht werden, bei POSIX?).

Die Umgebungsvariablen würde ich im App-Server verwalten, aber auch da habe ich noch gar keine Vorstellung was das genau bedeutet, wozu die verwendet werden usw.

619

Lowlevel-Coding / Re:Neuen Prozess laden/starten (Mikrokernel)

« am: 03. October 2010, 19:40 »

Der VFS selber gehört bei mir zum Boot-Image, ist also schon im RAM wenn der Kernel zum Leben erwacht. Die ganzen Dateisystemtreiber usw. kommen ebenfalls aus ner ROM-Disk die zusammen mit dem Kernel und den ersten Prozessen in den RAM kommt, auf einem PC würde ich das als Module die von GRUB geladen werden implementieren.

Also wird dein VFS-Service auch alle Libraries die er benötigt schon statisch gelinkt haben.?

Mich hätte halt interessiert ob jemand eine Idee hat wie man das Lösen könnte ohne das man sich alzu sehr verrenken müsste?

also ich habe vor dafür einen User-Mode-Prozess zu nehmen so das CreateProzess() erstmal auf IPC basiert. Dieser exec-Prozess lädt dann die Datei in den Speicher und macht daraus eine simple Fat-Binary (fürs erste ist sie das bereits), also wenn ich mal Librarys unterstützen sollte dann wird das alles noch vor dem Kernel gemacht. Der Kernel bietet dann einen speziellen Syscall dem die fertig gelinkte Executable in einem simplen Format bereits im Speicher übergeben werden muss.

Das hätte natürlich den Vorteil das man sich nicht auf ein Dateiformat festlegen muss und es wäre die perfekte Anwendung für fork().

Also wenn ich es richtig verstanden habe, willst du per IPC nen Art runtimeloader aufrufen. Dieser läd die Datei erstellt nen Prozess-Image und könnte nen Fork machen. So umgeht man den Kernel fast ganz und macht das meiste im UserSpace.

Ist ne Variante, aber da müsste man dann sehen, wie man es macht das man warten kann bis der Prozess zu Ende ist und sowas.

Ich würde halt das Laden und das Parsen im Kernel machen, in einem neuen Prozess und KernelThread.

Edit::

Was ich noch vergessen habe, wie bekommt ihr die Parameter die dem Programm übergeben werden in das Programm?

620

Lowlevel-Coding / Neuen Prozess laden/starten (Mikrokernel)

« am: 03. October 2010, 16:46 »

Wie im Titel schon zu sehen, geht es mir darum mal darüber zu diskutieren wie man (am besten) einen neuen Prozess lädt und startet. Das ganze sollte aus Sicht eines Mikrokernel betrachtet werden, wo auch der VFS-Service nicht im Kernel ist.

Im besonderen geht es mir darum, wie man es am besten löst, das ja im Normalfall auch verschiedenste Libraries geladen werden müssen.

Ich habe mir über diesen Libraries-Kram noch gar keine richtigen Gedanken gemacht, aber im Moment kann bei mir nur ein neuer Prozess geladen werden, in dem man eine Funktion/Syscall CreateProcess() aufruft, der man nen Pointer zu der startenden Datei mitgibt, sprich die Datei muss schon im UserSpace geladen sein.

Das ist natürlich beim Booten ganz vorteilhaft, weil ich da alle als Module geladenen Dateien im Kernel eingeblendet habe und so bloß diese Funktion aufrufen muss.
Aber normalerweise übergibt man doch solch einer Funktion einen Dateinamen, oder?

Bei mir sieht es dann auch so aus, das ich einen neuen Prozess erstelle und dort einen neuen Kernelthread, welcher dann die ganze Arbeit übernimmt. Er (der KernelThread) mappt also die Datei rein und parst sie und erstellt dann nen UserModeThread mit der Main-Funktion.

Wie macht ihr das oder wie wird das im Normalfall gemacht?

Ich dachte daran, diese CreateProcess()-Funktion beizubehalten, aber ne Verbindung zum VFS-Service aufzubauen und dann die entsprechende Datei in den neu erstellten Prozess zu laden (vom Kernel aus) und dann erst zu parsen. Wie klingt das?

Wenn ich das so machen würde, dann könnte ich auch einfach über diese Verbindung (zum VFS-Service) die nötigen Libraries laden und einbinden.

So meine letzte Frage bezieht sich dann auf das Henne-Ei-Problem, das ja auch der VFS-Service erstmal gestartet werden muss. Wie macht man das ohne das Dateien geladen werden können (was jetzt nicht so schwierig sein sollte)? Selbst wenn man das geschafft hat, wie würde man dann erreichen das der VFS-Service selbst auch Libraries nutzen kann (im Moment linke ich die einfach mit zu der Executeable dazu)?