Beiträge anzeigen

Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.


Themen - FlashBurn

Seiten: 1 [2]
21
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)?
22
Lowlevel-Coding / Treiber "Management"
« am: 19. September 2010, 18:05 »
Ich mache mir gerade Gedanken darüber wie man Treiber performant "managen" kann.

Damit meine ich, das z.B. nicht jeder Treiber geladen und ausgeführt wird und dann guckt ob ein Gerät, das er unterstützt, vorhanden ist, sondern das ein Treiber auch immer nur dann ausgeführt wird, wenn ein Gerät für ihn vorhanden ist.

Ich hatte mir da folgendes überlegt. Ich könnte als Anforderung für einen Treiber sagen, dass dieser eine bestimmte ELF-Sektion haben muss, wo in einer genau definierten Datenstruktur die Geräte drin stehen, die er unterstützt.
Problem wäre hier, das ich das ganze dann für jedes Bussystem (ISA, PCI, USB, ...) extra machen müsste.
Vorgestellt habe ich mir das so, dass der Device-Server das Verzeichnis wo die ganzen Treiber drin sind "beobachtet" (also benachrichtigt wird, wenn eine Änderung aufgetreten ist) und dann alle Dateien in dem Verzeichnis "parst" (also den ELF-Header laden und die spezielle Sektion, wo die Daten drin sind) und sich eine Liste anlegt.

Soweit so gut. Wie könnte man es machen, das die Liste nicht bei jeder Änderung neu erstellt wird? Ich dachte, das man vielleicht neben dem Dateinamen, noch die Zeit der letzten Änderung speichert. Damit kann ein Treiber gegebenenfalls neugeladen werden, wenn eine neuere Version in das Verzeichnis kopiert wurde.

Was haltet ihr davon, was würdet ihr anders/besser machen?
23
Lowlevel-Coding / Shared Memory
« am: 19. September 2010, 17:48 »
Ich bin gerade über einen Bug in meinem Shared Memory Code gestolpert und bin mir bei einer Sache nicht ganz sicher wie man es am besten macht.

Mein Shared Memory funktioniert so, das ein Prozess einen Bereich als SharedMemory erstellen kann (sprich der Speicher dafür muss schon im Prozess vorhanden sein). Will er (der Prozess) anderen Prozessen den Zugriff auf den Speicher geben, muss er einen "SharedAllow"-Syscall aufrufen, dem er die Adresse des Shared Memory und des Ziel-Prozesses übergibt.
Der Zielprozess ruft dann einen "SharedMap"-Syscall auf mit der ID des SharedMemory, hat er seine Arbeit erledigt ruft er den "SharedUnmap"-Syscall auf.

Mit dem letztgenannten Syscall (SharedUnmap) hab ich dann so meine Probleme. Im Moment habe ich nen Counter wie oft ein Shared Memory Bereich irgendwo gemappt ist und nur wenn dieser Counter "0" wird, wird die ganze Strukur (die die Daten zur Beschreibung des Shared Memory beinhaltet) wieder freigegeben/gelöscht.
Nur kann es jetzt die Situation geben, das ein anderer Prozess noch gar nicht an der Reihe war (zwecks Scheduling-Strategie) und den Speicher noch nicht mappen konnte. Dadurch würde diese Shared Memory nicht mehr existieren und der Empfänger würde nen Fehler zurückbekommen.
Das ist natürlich unschön. Wenn ich sage das ein Shared Memory solange exisitiert bis alle Prozesse, die in der "Allow"-Liste stehen, diesen auch einmal gemappt und dann wieder geunmappt haben, mache ich mir sorgen um die Sicherheit bzw. würde ich das dann fast schon als Speicherleck sehen.

Was meint ihr wie man das lösen sollte?
24
Lowlevel-Coding / Treiber bei einem Mikrokernel
« am: 06. September 2010, 13:34 »
Beim Thema IPC Methoden wurde es mal ganz kurz angerissen, das Thema Treiber. Bei einem Mikrokernel ist das Thema nicht so einfach.

Um was es mir aber genau geht, ein Treiber braucht oft (??) die physikalische Adresse einer virtuellen (da DMA kein Paging kennt) und das erste Problem wäre die Sicherheit, ich möchte eigentlich nicht jedem Prozess erlauben rauszubekommen welche physikalische Adresse hinter einer virtuellen steckt.

Aber was wäre das Problem wenn dem so wäre, sprich was könnte ein Prozess damit anfangen?

Ich überlege einfach die Pagingtabellen für Treiber "freizugeben", sprich die können lesend darauf zugreifen (natürlich nur auf den UserSpace-Teil). Was haltet ihr davon? Der Vorteil wäre die Performance, da dadurch Syscalls entfallen würden.

Nächstes Problem wäre, wie bekommt man den Speicher eines Geräts, z.B. den Framebuffer einer Graka, in den Adressraum des Treibers?

Das Problem was ich habe, ist das die ganzen Geräte nicht im Kernel sondern in einem Device-Server verwaltet werden und es so schwieriger wird solchen Speicher zu mappen, weil auch da wieder die Frage ist, wie bekomme ich diesen Speicher in den Device-Server?
25
Lowlevel-Coding / IPC Methoden
« am: 27. August 2010, 15:25 »
Ich starte dann mal eine Diskussion zum Thema der verschiedenen IPC Methoden und wie diese implementiert werden können.

Mir fallen als grobe Methoden erstmal synchrones und asynchrones Message-Handling, Pipes, Signal-Handler und Shared-Memory ein.

Fangen wir mit dem synchronen Message-Handling an.

Darunter ist zu verstehen, das der Sender solange blockiert bis der Empfänger bereit ist die Nachricht entgegen zu nehmen.

Vorteil ist, das man als Programmierer daran gewöhnt ist und es die meisten Aufgaben erleichtert. Auch könnte man so einige schöne Optimierungen (siehe z.B. L4-Mikrokernel) reinpacken.
Als weiterer Vorteil wird oft genannt das man die Nachrichten nicht hin und her kopieren muss, das stimmt so aber nicht. Denn man muss die Daten ja aus einem Thread in den nächsten kopieren.
Was aber wirklich als Vorteil genannt werden kann, ist dass die Nachrichten nicht extra im Kernel zwischen gespeichert werden müssen.

Als Nachteil sehe ich das damit nicht alles praktikabel gelöst werden kann. Man stelle sich z.B. einen Server vor der nur eine Statusnachricht an viele Empfänger verschicken möchte. Dort wäre es aus performance Gründen blöd, wenn jedes Mal gewartet wird bis der Empfänger bereit ist die Nachricht abzuholen auch kann das ein interaktives System vereiteln.

Als nächstes also das asynchrone Message-Handling.

Vorteil ist halt das man eine Nachricht senden kann und gleich weiter arbeiten kann, was halt (wie oben geschrieben) vorallem aus Server sicht und für Statusnachrichten gut ist.

Als Nachteil wird oft genannt das die Nachrichten im Kernel zwischengespeichert werden.

Ein Thema was für beide (synchron/asynchron) zutrifft, ist ob man sich für feste oder dynamisch Lange Nachrichten entscheidet.

Nimmt man Nachrichten mit einer fixen Länge, erleichtert es natürlich die Arbeit des Kernelprogrammierers. Allerdings muss man dann bei langen Nachrichten entweder eine andere Art der Übertragung nutzen oder mehrere Nachrichten (komplizierter) senden.

Bei Nachrichten mit dynamischer Länge sehe ich das Problem das man sich als Kernelprogrammierer ganz schön verrenken muss oder sich das Problem der Fragmentierung in den Kernel holt damit das klappt.

Zu Signal-Handlern kann ich gar nichts sagen, da ich sowas noch nie verwendet habe und was ich davon weiß auch nicht sonderlich begeistert bin ;)

Pipe´s kann man gut als Mittel verwendet wenn es darum geht Daten dynamischer Länger zu übermitteln, man das aber nicht über Nachrichten machen kann/will.
Wie man die Pipe´s implemenitert ob im Kernel- oder zum großteil im UserSpace ist eine Performance- und Sicherheitsfrage.

SharedMem ist sicherlich die schnellste Möglichkeit Daten aus einem Prozess in einen anderen zu bekommen. Hier ist halt das Problem das man sich das Kommunikationsmodell selbst einfallen lassen muss (als App-Programmieren) und nur hoffen kann das der andere sich daran hält.

Ich denke am einfachsten wäre es, wenn jemand einfach mal ein "Problem" in den Raum stellt. Daran kann man dann am besten diskutieren welche Variante die beste ist.
26
Softwareentwicklung / Cygwin unter Win7
« am: 23. April 2010, 14:23 »
Ich bekomme morgen oder Montag ne Festplatte und wollte dann eigentlich Win7 auf meinem Laptop installieren (momentan noch XP).

Da ich aber eigentlich nur am Laptop programmieren, muss Cygwin funktionieren. Ich habe auf meinem Desktop Rechner Win7 x64 und da läuft Cygwin nicht wirklich, d.h. es läuft, aber arsch langsam. Ich meine ich brauche dort (mit nem Q9550 auf 3.4GHz) alleine für das Configure-Script von den binutils so lange wie auf meinem Laptop (mit nem T7200-Merom) für das Kompilieren von binutils+gcc!

Von daher wäre es nicht schlecht zu wissen ob jemand Cygwin auf Win7 erfolgreich betreibt!?
27
Lowlevel-Coding / Schedulingstrategien
« am: 16. April 2010, 18:51 »
So nun mal zu einem interessanten Thema :D

Richtig interessant sind die ja erst auf Multi-CPU Systemen.

Ich nutze im Moment noch eine Queue wo sich alle CPUs bedienen. Ich weiß das es durchaus zu Engpäßen kommen kann, aber ich habe halt noch keine bessere Strategie gefunden mit der ich leben kann (und welche ich verstehe, das ist Voraussetzung).

Ich würde also gerne mal hören was ihr so für Strategien auf 1-CPU oder Multi-CPU System nutzen würdet/nutzt.
Seiten: 1 [2]

Einloggen