Nachrichten

41

OS-Design / Re: IPC - Popup-Threads

« am: 23. November 2011, 20:27 »

@erik

Das ist mir auch alles klar und sieht auch so ähnlich bei mir aus. Ich habe nur noch eine Schicht zw. SlabAllocator und PMM, nämlich den VMM.

Auch dein Bsp. sagt mir nicht woher der SlabAllocator weiß welche virtuellen Adressen frei und welche belegt sind. Das muss du doch irgendwie verwalten und dafür brauchst du Speicher.

Der SlabAllocator funktioniert doch so, das er guckt ob er einen komplett freien ObjectCache oder einen ObjectCache mit mind. einem freien Objekt hat. Ist das nicht der Fall fragt er den VMM nach sovielen Pages wie man pro ObjectCache für den entsprechenden Objekttypen braucht.
Der VMM benutzt nun praktisch den SlabAllocator für die Objekte die er zur Verwaltung des virtuellen Speichers braucht. Da haben wir dann wieder diese Abhängigkeit die sich nicht so einfach auflösen lässt. Dafür brauchst du einen Allocator der keinen dynamischen Speicher braucht bzw. diesen irgendwo herbekommt ohne einen anderen Speichermanager aufzurufen.

Um es kurz zu machen, woher weiß, in deinem Bsp., der SlabAllocator wo noch freie Bereiche im Adressraum des Kernels sind? Das steht in einer Datenstruktur und wo kommt der Speicher (der ja auch dynamisch verwaltet werden soll) für diesen Speicher her?

Ich möchte meinen aus diesem Grund nutzt man unter Linux nen BuddyAllocator und hat das Prinzip des HighMem. Man nutzt also im Kernel ein 1:1 Mapping der physischen und virtuellen Adressen. Das ist aber mMn totaler Müll, ist zwar einfach aber du bekommst dadurch Probleme wo ich ehrlich gesagt nur drüber lachen kann Aber du kannst dir den VMM für den Kernel sparen.

42

OS-Design / Re: IPC - Popup-Threads

« am: 23. November 2011, 18:00 »

was genau versuchst Du mit Deiner komplizierten VMM-Architektur eigentlich zu erreichen?

Ich habe doch das Problem beschrieben das der Kernel-VMM auch Speicher für seine eigenen Objekte braucht und normalerweise malloc() dafür aufrufen würde. Malloc() wiederrum ruft dann den Kernel-VMM zwecks neuem Speicher auf. Das kann nicht funktionieren und man muss also nen "einfachen" Speichermanager zumindest für die Objekte des VMM haben.

Ich nutze halt den selben Code für den Kernel- und die User-VMMs.

Ich könnte, wie oben schon geschrieben, auch einfach nur den Kernel-VMM diesen "einfachen" Speichermanager nutzen lassen und die User-VMMs nutzen dann ganz normal Kernel-Speicher. Das wiederrum hätte aber einen Nachteil was den eventuellen Speicheroverhead betrifft, wäre aber performanter.

Nur bin ich mir halt nicht sicher, ob der Performanceunterschied wirklich relevant ist. Denn die einzige Situation (die mir im Moment einfällt), wo ich auf den VMM eines anderen Prozesses zugreifen muss, ist IPC.
Wenn ich jetzt davon ausgehe, dass nur beim RPC auch auf den VMM eines anderen Prozesses zugegriffen werden muss (und das nur beim Senden, für die Antwort ja nicht) und ich dann auch gleich in dem anderen Prozess bleibe, habe ich eigentlichen keinen Performance-Vor- oder -Nachteil.

Ausnahme wäre da jetzt nur asynchrones-IPC, aber da fallen mir im Moment auch nur Notify-Nachrichten ein und dafür würden meine fixed-size-Nachrichten eigentlich ausreichen und da würde dann also auch nicht auf den VMM eines anderen Prozesses zugegriffen.

Meine Frage wäre dann, wie löst ihr das, dass der Kernel-VMM ja auch irgendwo Speicher herbekommen muss?

43

OS-Design / Re: IPC - Popup-Threads

« am: 23. November 2011, 17:31 »

Ich dachte, im eigenen Prozess (und vor allem im Kernelspeicher, der ja in allen Prozessen der gleiche ist) kann der VMM allozieren und das Problem ist nur mit anderen Prozessen?

Jap, es geht darum, das ich aus einem Prozess heraus nicht auf den VMM eines anderes Prozesses zugreifen kann. Der Kernel hat aber auch nen VMM der irgendwo her seinen Speicher bekommen muss und der ist auch in alle Prozesse gemappt.

Achso jetzt verstehe ich. Es geht eigentlich gar nicht um das Page Directory, sondern darum, dass du auf den virtuellen Adressraum des anderen Prozesses zugreifen willst.

Auch darum geht es nicht ganz Ich müsste auf den VMM eines anderen Prozesses zugreifen und der VMM für jeden Prozess holt sich den Speicher für seine Objekte immer aus dem selben virtuellen Bereich.

Du könntest ausnutzen, dass dein VMM für jeden Prozess in einem begrenzten Bereich liegt. Dann kannst du einfach die dazugehörigen Einträge im PD des Sender mit den Werten aus dem PD des Empfängers überschreiben, den Speicher normal reservieren, und anschließend die alten Werte wiederherstellen. Mit etwas Glück gibt es nicht mal unnötige TLB-Misses, falls das die einzigen Zugriffe auf den VMM sind.

Ansich gar keine schlechte Idee, aber ...

Was machst du bei Multithreading? Thread A mappt also den VMM raus und den von einem anderen Prozess rein und Thread B will jetzt, auf einer anderen CPU, gleichzeitig Speicher anfordern!

Also mein VMM besteht aus 2 AVL-Bäumen, dort werden Nodes gespeichert (erster Objekttyp) und dann gibt es die Bereiche (zweiter Objekttyp). Für diese beiden Objekttypen muss ich ja irgendwo her Speicher bekommen.
Wenn der VMM also nen neuen freien Bereich eintragen will, muss er eventuell zwei neue Nodes und einen neuen Bereich allozieren. Wenn er dabei ganz normal ein malloc() aufrufen würde, würde das malloc() feststellen das es neuen Speicher braucht und den VMM aufrufen ...

Ich hoffe das Problem ist klar.

Ich habe das ganze so gelöst das ich einen festen virtuellen Bereich habe wo ein "einfacher" Allocator Speicher für diese beiden Objekttypen herholt (er braucht keinen dynamischen Speicher dafür, weil die Größe und Position des Bereichs ja statisch schon zur Compilezeit bekannt ist). Das ganze habe ich einmal für den Kernel-VMM (und dieser Bereich ist in jedem Adressraum der gleiche) und einmal für den User-VMM (dieser Bereich ist in jedem Adressraum mit anderen Daten/Pages gemappt).

Ich kann also für einen Prozess der gerade die CPU hat, ganz einfach Speicher über den VMM allozieren, aber wenn ich aus einem Prozess A heraus Speicher in einem Prozess B allozieren will, muss ich auf dessen VMM zugreifen. Das bringt Probleme, weil der VMM von Prozess B Objekte benutzt die an der selben Adresse liegen wie Objekte vom Prozess A. Dadurch kann ich den VMM des Prozesses B auch nicht einfach in Prozess A mappen (zumal das eh Probleme bei vielen CPUs gibt, da irgendwann auch der virtuelle Speicher ausgeht).

44

OS-Design / Re: IPC - Popup-Threads

« am: 23. November 2011, 16:59 »

Warum kann sich der VMM nicht einfach den Speicher nehmen, den er selber braucht? Wie man physischen Speicher holt, dürfte er wissen, und wie man ihn mappt auch.

Und wo soll er den hinmappen? Ich hatte es vor langer Zeit auch mal so, dass der VMM ganz normal seine Objekte alloziert hat, aber das führt zu so vielen Problemen und Code der manchmal funktioniert und manchmal nicht.

Es geht doch bei einem VMM darum, das er weiß welche Bereiche im virtuellem Speicher frei sind und welche nicht und dafür braucht er Speicher. Mein VMM besteht im wesentlichen aus 2 AVL-Bäumen, einen der die Bereiche nach der Größe sortiert und einer der die Bereiche nach der Start-Adresse sortiert.

Allerdings kommt mir gerade eine Idee (wo ich mich wieder frage wieso ich die nicht schon eher hatte) und zwar reicht es ja, wenn der Kernel-VMM so gebaut ist. Der User-VMM kann dann die allgemeinen Speicherfunktionen nutzen.
Das würde sogar sehr einfach umzusetzen sein, würde aber zu einem anderen Problem führen (was nicht unbedingt auftreten muss, aber kann). Jetzt ist es so, dass wenn ein Prozess beendet wird, wird auch der gesamte Speicher, den der VMM gebraucht hat, freigegeben. Bei der obigen Variante kann es (und wird es bestimmt auch) aber passieren, das die Objekte so dämlich über viele Objekt-Caches (SlabAllocator) verteilt sind, das man nacher eine Aufteilung, das jeder Objekt-Cache im worst-case genau ein Objekt hat, welches noch in Benutzung ist und es deswegen zu einer tierischen Speicherverschwendung kommt (pro Objekt in dem Fall etwas über 4000bytes, macht bei einem Prozess mit 1024 freien Bereichen schonmal 4MB verschwendet).

Ist halt die Frage, was ist wichtiger Speicherverbrauch oder Performanceeinbußen wegen dem Wechseln des PDs.

Ich würde den Stack erst erstellen, wenn der Scheduler zum Thread wechselt. Zum Beispiel durch einen Stub, der vor dem Sprung in den User-Space ausgeführt wird.

Finde ich ne ganz schlechte Idee, weil erst dann festgestellt werden kann ob genügend Speicher für den Stack vorhanden ist oder nicht und Fehler, vorallem solche, will ich im Scheduler gar nicht haben.

45

OS-Design / IPC - Popup-Threads

« am: 23. November 2011, 16:29 »

Ich will ja die Idee von erik benutzen, wo der IPC-Handler in einem eigenen Thread läuft. Dieser Thread wird auch wirklich erst erstellt wenn eine Nachricht vorhanden ist/empfangen wird.

Dabei ist halt ein Problem bei meinem Kernel-Design aufgetreten. Dort ist es nicht möglich auf den VMM eines anderen Prozesses zu zugreifen, was ja nötig wäre um einen Stack für den Thread erstellen zu können.

Der Grund warum das nicht möglich ist, ist folgender. Auch der VMM braucht ja Speicher um die freien Bereiche verwalten zu können. Allerdings kann er ja schlecht die normalen malloc()/free() Funktionen nutzen, weil die wiederrum auf den VMM aufbauen.
Deswegen habe ich im KernelSpace einen Prozess-lokalen Bereich (der ist immer an der gleichen virtuellen Adresse) wo nur ein "kleiner" Speicher-Manager läuft und auch genau auf den VMM zugeschnitten ist.
Es ist halt einfacher wenn ich nur einen festen Bereich verwalten muss, als wenn ich das ganze von der Größe her dynamisch machen müsste.

Ich habe auch schon eine Idee für eine Lösung.

Wenn ein Client eine RPC-Anfrage macht, muss er in den Kernel. Dort wird dann der fixed-size Anteil der Message in einen Kernel-Buffer kopiert (sind im Mom 32bytes, die man als Metadaten nutzen könnte).
Es wird dann geguckt ob ein neuer Thread beim Empfänger erstellt werden darf (man kann bei der Erstellung der Ports festlegen wieviele Threads max gestartet werden dürfen), ist das der Fall so wird einfach in das PD des Empfängers gewechselt, ein neuer Thread erstellt und dieser wird gleich gestartet ohne das der Scheduler davon wissen muss.

Ist der Handler fertig (die Funktion macht also nen "ret" was wiederrum bewirkt das zurück in den Kernel gesprungen wird) wird überprüft ob eine weitere Nachricht vorliegt oder ob der Thread beendet werden kann.
Liegt eine weitere Nachricht vor, wird diese bearbeitet und der Sender-Thread wird in die Ready-Queue des Schedulers gepackt. Kann der Thread beendet werden, wird danach gleich in das PD des Senders gewechselt und der Sender Thread wird laufen gelassen.

Wird nur eine Nachricht versendet ohne das gewartet werden soll (oder es keine Antwort gibt), so muss trotzdem in das PD des Empfängers gewechselt werden und es wird ein neuer Thread erstellt. Dieser wird dann in die Ready-Queue des Schedulers gepackt und es wird wieder zurück in das PD des Senders gewechselt.

Falls jemand eine gute Idee hat, wie ich das Wechseln der PDs vermeiden kann, also im Endeffekt wie ich den Speicher für den VMM verwalten kann, dann immer her damit.

Fallen euch daran irgendwelche groben Fehler auf oder habt ihr eine bessere Idee (die Popup-Threads bleiben )?

46

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 10. November 2011, 17:10 »

Das geht sogar ganz wunderbar, wenn du dich auf eine Plattform beschränkst. Du sagst "x86", meinst aber "ibmpc".

Jap, da hast du natürlich recht.

Sagen wir einfach außerhalb von "ibmpc" gibt es einfach zu viele Plattformen, die zwar eigentlich alle die gleiche Architektur verwenden, aber das wars dann auch schon. Ist aus Hobby-OS-Dever Sicht nicht so das Wahre.

47

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 10. November 2011, 15:16 »

Du könntest einen Funktionsprototypen als typedef deklarieren und in Deinem Code eine Konstante (die das Sprungziel darstellt) in einen Funktions-Pointer mit diesem Typ casten und das dann direkt aufrufen, wenn Du das in ein passendes Makro verpackst dürfte das sogar recht hübsch aussehen.

Hätte ich damit nicht wieder eine Indirektion (durch den Funktionspointer)? Diese Variante hätte natürlich den Vorteil, dass sie keinen Linker erfordert.

Wenn Du Deinen Loader Multiboot-kompatibel machst sollte das meiste schon mal funktionieren und wenn Dein Loader dann noch so aussieht wie ein Linux-Kernel dürftest Du mit (fast) jedem Open-Source-Boot-Loader auf (fast) allen Plattformen klar kommen.

Naja, aber selbst Multiboot-kompatibel ist ja nur die halbe Miete (für den normalen OS-Dever). Wenn man das richtig macht dann sollte das klappen, aber auch das ist schon verdammt aufwendig. Man muss immer vom schlimmsten ausgehen und aufs beste hoffen

Ein anderes Problem lässt sich leider weder durch einen eigenen Bootloader noch durch eine eigenen 3.-Stage lösen. Denn selbst wenn dein Loader aussieht wie ein Linux-Kernel (ich wüsste nichtmal was das heißt), gibt es noch die ganzen Architekturen außerhalb von x86
Ich kenne es nur vom Toshiba AC100 (ARM Cortex-A9 und von nVidia), aber da müssen sogar ein paar Werte im Kernel (ich vermute mal repräsentiert durch ein Symbol) ganz genau so sein wie es (in dem Fall) fastboot haben möchte. Und diese Werte können sich schon durch ein Update ändern (das war mal nen Problem bzw. ist es für einige immernoch).

Lange Rede kurzer Sinn, außerhalb von x86 hat man sowieso ganz schön Arbeit und kann nicht mal eben eine Datei (was teilweise schon geht) oder eine bestimmte Datei laden lassen.

48

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 09. November 2011, 20:45 »

Was Du da beschreibst hast Du in diesem Thread auch noch gar nicht erwähnt und leider kann ich mir nicht zu jedem hier diskutiertem OS alle intimen Details merken.

Habe ich nicht? Mir war so

Wobei dieser Weg immer zwei zusätzliche Indirektionen hat, im Gegensatz dazu wenn der richtige Syscall-Befehl direkt in den User-Code geinlined wird (was mit LTO bei kleinen libc-Funktionen ja problemlos möglich wäre). Irgendwie verstehe ich Dich wirklich nicht, da nimmst Du einen riesigen Aufwand mit einem zur Boot-Zeit zusammengelinkten Kernel in kauf nur um eine einzige Indirektion zu sparen und dann baust Du gleich zwei davon in den User-Mode ein. Was soll ich den jetzt noch über Dich denken?

Das Inlinen geht ja nicht, dadurch dass es verschiedene Methoden gibt. Als Bsp. was machst du wenn der Code die syscall/sysret Variante nimmt (AMD) und auf einer Intel CPU läuft?
Wieso eigentlich 2 Indirektionen (steh da gerade aufm Schlauch)? Wegen einmal "call" und einmal "jmp"?

Mir wäre es am liebsten wenn man dem Compiler irgendwie sagen könnte, dass er diese bestimmte Adresse callen soll und die Parameter auf den Stack pusht. Also wenn jemandem sowas bekannt ist, immer her damit.

Aber wo ich da gerade so drüber nachdenke, kann man nicht einfach ne Funktion "bool sendMsg(buffer,receiver,flags);" definieren und dann beim Laden des Programms das Symbol auflösen? Damit würde ich mir ja eine Indirektion sparen (wieso bin ich da nicht früher draufgekommen).

Zumal auch das mit dem Inlinen aus einem anderen Grund doof ist, "syscall"/"sysenter" sind nicht so einfach wie ein "int", da muss man erst Register sichern und bestimmte Sachen in diese Register laden oder das passiert automatisch (ich mag die beiden Varianten nicht so, aber sie sind halt schneller als "int"). Deswegen habe ich auch nen Stub dafür (und mache leider noch keine Überprüfungen ob die Rücksprungadresse wirklich ok ist).

Fällt dir denn ne bessere Variante ein? Deswegen habe ich das bisher so gemacht, mir ist keine bessere (kompliziertere ) eingefallen.

Die x86-Plattform ist auch die einzigste bei der das so ein komplexes Thema ist, alle anderen Plattformen haben einen spezifischen Syscall-Befehl, der von der CPU möglichst performant unterstützt wird, und gut.

Warum ist das eigentlich bei x86 so kompliziert? Ist das nicht auch wegen den Segmenten so?

Nö nö, keine Sorge, ich bin bloß der Meinung das gerade das Thema Linken gerade für OS-Dev-Anfänger eher nicht so geeignet ist und daher viele diesen Punkt auf eine spätere Version vertagen.

Also object-files in ein executeable-file zu linken ist gar nicht so schwer. Viel schwieriger sind dann schon die shared-libraries, aber auch das sollte (wenn man das vorherige kann) nicht so schwierig sein.

Obwohl ich als Ausweg lieber eine Art Init-RAM-Disk nehmen würde in der der eigentliche Kernel mit allen potentiellen Komponenten und auch alle wichtigen Services, die ein Micro-Kernel-OS ja benötigt damit weitere User-Mode-Programme von HDD geladen werden können, drin sind und dazu ein Programm (welches für den Boot-Loader als Kernel behandelt wird) das daraus dann ein lauffähiges System zusammenbaut. Problem dabei wäre natürlich das Du dann von der Vorbereitung des virtuellen Speichers durch den Boot-Loader abhängig bist aber ich denke auch das lässt sich lösen.

Du musst dann deinen Loader auch an jeden Bootloader anpassen oder im Falle von U-Boot vllt sogar nen Linux-Kernel emitieren (keine Ahnung ob das wirklich nötig oder schwer ist).
Da du dann ja eigentlich auch Dinge machst, die der erste Bootloader schon kann, kannst du den auch gleich selber schreiben. Mit einer Ausnahme, wenn der erste Bootloader die Firmware darstellt. Da macht es dann wenig Sinn dieses neu zu schreiben.

Ich habe da mit nem eigenen Bootloader auf x86 eventuell weniger Arbeit, weil entweder du musst deinen Loader an mehrere Bootloader anpassen oder der User müsste deinen Bootloader nutzen (was bei mir der Fall ist, aber das ist das gleiche als ob du Windows damit laden würdest).

Da gefällt mir der Bootloader vom Raspberry Pi sogar besser als U-Boot oder so. Da wird einfach ne bestimmte Datei an eine festgelegt Adresse geladen und einfach dahin gesprungen. Damit kann ich arbeiten

49

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 09. November 2011, 16:57 »

Aber sobald diese Library ins Executable eingelinkt wurde ist das Executable fest. Wenn Du dort die Library-Version einbaust die INT für Syscalls benutzt aber das Executable dann auf einem PC laufen soll der SYSENTER will geht Dein Executable nicht mehr. Das ist irgendwie doof, oder? Vor allem weil man ja durchaus auch mal wegen der Performance statisch linken möchte (damit selbst die libc von LTO profitiert).

Manchmal denke ich ihr wollt mich nicht verstehen

Hast du dich schonmal mit den Syscall-Methoden unter Linux und Windows beschäftigt?

Also mal ganz genau beschrieben, der Caller packt seine Parameter auf den Stack (ja die werden nicht über die Register weitergereicht, da die dann eh auf den Kernel-Stack gepackt werden müssen und kopieren muss man auch wenn es zu viele sind) und callt die von mir zur Verfügung gestellt Funktion. Diese Funktion macht nix anderes, als die Funktionsnr (vom Kernel-API) in EAX zu packen und einen "jmp" zu einer festen Adresse zu machen und das ist jetzt der Punkt wo es transparent für die Anwendung ist. Denn an dieser festen Adresse steht der Code für nen kleinen Stub der in den Kernel springt und genau hier wird dann die jeweils beste zur Verfügung stehende Methode genutzt.
Dazu braucht man weder dynamische Libraries noch wird in das Programm irgendetwas reingelinkt was mit der eigentlich verwendeten Methode zu tun hat.

Diese Page (bisher ist es nur eine) ist am oberen Ende eines jeden Adressraumes gemappt. Da können dann auch noch mehr Sachen rein (Haiku stellt so z.B. optimierte memcpy und Konsorten zur Verfügung und ich wollte das eigentlich auch noch so machen) und diese Adressen ändern sich nicht. Man muss halt sehen wie viel da rein soll, sprich ob es Sinn macht in der oberesten Page nur Adressen auf Funktionen zu speichern oder (so wie ich bisher) da schon direkt Code reinzuschreiben.

Wenn Du das sauber hinkriegst ist das natürlich toll.

Wenn du das so schreibst klingt das als wenn du schon eine Idee hast was da schief gehen könnte bzw. wo es Probleme geben wird?

Nochmal zum IO-APIC, soweit ich es verstanden habe, sind dem die Prioritäten auch eigentlich egal. Die Lokalen-APICs interessiert das dann erst.

Ich habe mir heute nochmal (versucht) GRUB und auch U-Boot näher anzuschauen und nein, definitiv nicht als einziger Bootloader. Alleine schon durch die Tatsache das ich einige Annahmen mache wo meine Module liegen, macht es die Sache einfacher. Soweit ich es verstanden habe, werden die Module bei GRUB1 direkt hinter den Kernel geladen (ich gehe davon aus, dass das mit 4kb alignt passiert, habe dazu aber nix gefunden) und bei GRUB2 irgendwo in den höheren Speicher. Ich denke fast mal mit GRUB2 werden wohl einige Hobby-OS´s Probleme genau deswegen bekommen.
In der U-Boot Doku habe ich gar nix gefunden wie man andere Systeme oder Kernel allgemein lädt, da ist alles auf Linux bezogen, von Multiboot auch keine Spur. D.h. also wenn man auf eine andere Architektur will und dann nicht mehr GRUB nutzen kann, muss man sich sowieso was einfallen lassen.

Wenn jemand mal nen Link zu einer halbwegs guten Doku (oder wenigstens irgendwelche interessanten Infos) zu fastboot (Android) hat, wäre ich sehr dankbar dafür.

Ich bin immernoch überzeugter eigener-Bootloader-Nutzer

50

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 09. November 2011, 12:45 »

Das Problem was ich sehe ist das Du mit Deinem Weg statisches Linken (zumindest der libc) grundsätzlich ausschließt und das gefällt mir persönlich gar nicht, damit wird auch LTO eingeschränkt.

Wieso, ich stelle diese Funktionen auch als statische Libraries zur Verfügung.

Ich denke die meisten Hobby-OSe benutzen nur statisch gelinkte Executables, einfach weil man sich damit das fertig-linken im Executable-Loader sparen kann (ist ja doch kein so ganz einfaches Thema und für den ersten Anlauf kann man eigentlich auch gut drauf verzichten).

Also das will ich nicht. Dynamische Libraries sollen bei mir eigentlich Standard sein (vom RT-Linker, VFS-Server und Device-Server mal abgesehen).

Ich will Dir ja nicht widersprechen aber es fällt mir wirklich extrem schwer zu glauben das bei den 24 IRQs die so ein I/O-APIC unterstützt nicht auch jeder IRQ ein individuelles Prioritätsregister hat, ließ da Bitte noch mal in der APIC-Spec genau nach. Ich kann mir einfach nicht vorstellen das die Intel-Ingeniöre solch kapitale Fehler gemacht haben.

Unlike IRQ pins of the 8259A, the notion of interrupt priority is completely unrelated to the position of the
physical interrupt input signal on the APIC. Instead, software determines the vector (and therefore the priority)
for each corresponding interrupt input signal.

Sollte doch als "Beweis" reichen oder

51

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 08. November 2011, 20:37 »

Ich denke FlashBurn's Fehler ist das er aus seiner Kernel-Initialisierung gleich noch einen Boot-Loader gemacht hat, vielleicht wäre es ein besserer Weg wenn er die Boot-Loader-Funktionalität (laden aller Dateien von HDD usw.) von GRUB o.ä. erledigen lässt und sich darauf konzentriert seinen Kernel passend zur vorhandenen Hardware zu initialisieren/zusammenzusetzen.

Das könnte ich auch immernoch machen, aber mich hat es halt auch interessiert wie sowas funktioniert, wie man ein allgemeines Interface anbietet (einmal um eine Datei zu laden und einmal um einen Sektor zu laden) und damit hatte ich dann GRUB ersetzt

Ist es eigentlich möglich GRUB zur Laufzeit (von GRUB) zu konfigurieren? Ich habe bei mir ein Bootmenü mit drin, wo ich im Moment nur die Auflösung für VBE wählen kann, aber da könnte ich auch so Sachen wie den Scheduler auswählen lassen. Was dann wieder gegen GRUB sprechen würde, weil ich nach der Auswahl im Menü z.B. auch ganz andere Module laden würde (wahrscheinlich).

Klar, ich würde vermutlich auch einen Fallback einbauen, aber hat nicht auch FlashBurn recht wenn er dagegen hält dass das unnütze Speicherverschwendung ist?

Warum würdest du einen Fallback einbauen? Mir geht es dabei nicht mal um die "Speicherverschwendung".

Ich sehe es so, der Kernel bietet eine API an und an die hat man sich zu halten (ist doch unter Linux und allen andern OS´en nicht anders) und diese sieht vor, dass man nur in den Kernel kommt, indem man eine bestimmte Funktion aufruft.
Durch diese Abstraktion stelle ich sicher, dass immer die best mögliche Variante genutzt wird, egal wie alt das Programm ist und ohne das sich das Programm darum kümmern muss (ich nehme dem Programmierer Arbeit ab).
Dazu kommt noch, stell dir vor du müsstest Grafikhardware direkt und nicht über DirectX/OpenGL programmieren. Dann müsstest du für jede Graka nen eigenen Treiber schreiben und würdest nie alle Unterstützen können und deine Software würde irgendwann nicht mehr funktionieren. Durch solch ein Interface ist sichergestellt das der Programmierer solche Details nicht kennen muss.
Zumal man eigentlich auch nicht Direkt mit dem Kernel zu tun haben sollte, sondern sowas immer über eine Library abstrahiert sein sollte. Alleine schon, falls sich das Interface zum Kernel mal ändern sollte.
Ich sehe darin keine Nachteile, sondern nur Vorteile.

Vermutlich nicht, aber zum einen könnte man das sicher einbauen und zum anderen kann ein HW-Gerät ja mehrere IRQs haben die dann fest unterschiedliche Prioritäten haben und es wird für jeden Job ein passender IRQ ausgewählt.

Wenn die Hardware in der Lage ist mehrere verschiedene IRQs zu produzieren, dann stimme ich dem zu.

Das Ändern einer IRQ-Priorität sollte bei den APICs auf einen einzigen Schreibzugriff hinaus laufen.

Nope, du liest einmal um den INT-Vektor (und genau der repräsentiert die Priorität/legt sie fest) auszulesen, diesen freizugeben und dir nen neuen zu holen (das wäre das Schreiben).

Wieso willst Du neue INT-Vektoren zuweisen? Das ist doch Quatsch und sicher auch gar nicht so einfach machbar zur Laufzeit, es müsste ja auch atomar durchgeführt werden und da dürften die üblichen HW-Geräte nicht so einfach mitspielen bzw. man bräuchte entsprechende Unterstützung durch die Treiber.

Da der INT-Vektor aber die Priorität festlegt, weißt du jetzt warum das nicht dynamisch gemacht wird

Doch, I/O-Port sind extrem langsam, im Verhältnis zum Speicher. Deswegen unterstützt ja auch kaum eine andere Plattform I/O-Ports, die meisten kennen nur Speicher.

Hieße das auch, dass ein USB-RS232-Adapter viel besser ist als eine native Schnittstelle?

Viele ältere ISDN-Anlagen werden per RS232 konfiguriert und das ist meistens nicht so wichtig wie der MP3-Player im Hintergrund (ist doch egal ob die Konfiguration 2,0 Sekunden oder 2,1 Sekunden benötigt). Auch gibt es immer noch recht viele managed Ethernet-Switches mit ner RS232-Konsole (da muss der Admin zwar persönlich und mit Laptop vor Ort sein aber dafür funktioniert die wenigstens immer, selbst wenn das LAN mal komplett tot oder kaputt-konfiguriert ist), dem Admin dürfte der MP3-Player im Hintergrund auch wichtig genug sein das dieser eine höhere Priorität bekommt als das Terminal-Programm (wenn der Admin ne hundertstel Sekunde länger braucht ist das schließlich immer noch bezahlte Arbeitszeit).

Naja, das man die Priorität nicht dynamisch zur Laufzeit ändern kann, sollte dir inzwischen klar sein

RS232 wird ja auch noch viel in der Industrie eingesetzt. Dass der IRQ-Handler aber immer ne höhere Priorität als der MP3-Player hat, lässt sich wohl nicht so wirklich vermeiden. Ich wollte eigentlich keine ganzen Programme in die Real-Time-Priorität reinlassen, sondern nur die IRQ-Handler oder spricht da was dagegen?

Ja, ich weiß, meine Antworten sind auch nicht immer sehr hilfreich.

Hast dich aber gebessert.

Was ich dazu noch sagen kann, in der Uni bekommt man ganz bestimmte Aufgaben und wenn da mal jemand ein Problem hat und andere immer nur ankommen und sagen, ne das ist doof, nimm doch lieber das und das. Dann hilft dem das gar nicht weiter. Der soll das nehmen und gut ist. Ist ja leider in der reallen Welt genauso (da wo man jemanden über sich hat).

52

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 07. November 2011, 22:49 »

Dann hast du in dieser Diskussion genau garnichts gewonnen. Du zielst nämlich nicht auf das Problem, sondern auf das Symptom ab.

Wir waren uns doch aber einig, dass auf den meisten MikroKontrollern eine solche Firmware nix verloren hat. Das ist dann halt ne andere Plattform. Problem wird sein es den Herstellern schmackhaft zu machen und MS ist da mMn der richtige für (ob das nun gut ist oder nicht, ist ja erstmal egal). Die haben einfach genug Marktmacht um sowas auch mal durchzudrücken.

Ja. Und je nach Mainboard, CPU oder BIOS-Implementation sind manche Timer funktionsfähig oder eben auch nicht. Deswegen halte ich den Kernel für die richtige Stelle, den entsprechenden Timer auszusuchen.

Naja, aber den Code will ich ja gerade nicht im Kernel haben.

Andere Frage: Du hast ein Modul für den zu verwendenden Syscall-Mechanismus. Du unterstützt also mehrere davon. Gibt es ein Fallback, d.h. funktioniert "int 0x80" immer oder nur, wenn die CPU weder SYSENTER noch SYSCALL kann?

Ich gehe (den deiner Meinung nach falschen) radikalen Weg und es wird dir vorgeschrieben wie du in den Kernel kommst. Es muss immer eine Funktion aufgerufen werden (was hinter Library-Calls versteckt wird) und die hat immer den Code für die optimalste Variante. So ist sicher gestellt das alle Programme auf allen CPUs laufen ohne dass das Programm sowas vorher kontrollieren müsste.

Wenn du trotzdem auf eigene Faust in den Kernel willst, wird es dann vermutlich nach dem Zurückspringen in den UserMode krachen.

Auf jeder Plattform existiert ein Bootloader, der eine (oder mehrere, notfalls als Archiv) Dateien in den Speicher laden und reinspringen kann. Aber ein Bootloader, der speziell dein Konfigurationsdateiformat und deine Modulstrukturen unterstützt, ist eher selten. Besonders, wenn er zusätzlich noch die Hardware initialisieren muss (was RedBoot und U-Boot können, dein Bootloader muss für jedes einzelne Board angepasst werden; außerdem gibt es sog. Hardware-Quirks je nach Board-Revision).

Wenn jedes Betriebssystem auf dem Rechner von z.B. GRUB geladen werden kann, erhöht das die Interoperabilität verschiedener Betriebssysteme auf einem Rechner ungemein. Sieht man vor allem daran, wenn man Windows neu installiert. Alternative Bootloader sind dann weg. Das ist dein Wunschweg?

GRUB kann doch meinen BootloaderBootsektor laden. Zumal ich ja auf anderen Architekturen (wenn es zu umständlich wird, was ohne eine vernünftige Plattform der Fall ist) einfach den Weg der 3.-Stage gehen kann.
Auch Windows kann von GRUB geladen werden, also da sehe ich kein Problem. Das Windows den vorhandenen Bootloader rauskickt ist nen ganz anderes Thema und durchaus ein Problem.

In meinem Konzept ist der IRQ-Handler vollständig im Kernel, wenn ein IRQ auftritt, wird ein Event an den für diesen IRQ registrierten Treiber geschickt und der schnellstmöglich scheduled. Treiber laufen niemals im IRQ-Kontext.

Ich möchte meinen das einige den "kurzen" IRQ-Handler direkt ausführen (ist dort ein Modul des Treibers). Den Weg hatte ich auch mal ganz am Anfang geplant, aber ich habe mich dann dazu entschieden jeden zur Laufzeit hinzufügbaren Code rauszuschmeißen.

Du möchtest aber ein System programmieren, was den Benutzer prinzipiell zum Idioten erklärt, denn er kann ja nichts daran ändern.

Sagen wir mal, am Kernel möchte ich den User nicht rumspielen lassen. Was den UserSpace betrifft (und damit ja eigentlich alle Services), ist das schon wieder was anderes.

Wenn man mit Settop-Boxen zu tun hat (Firmware-Updates oder Streamen des Fernsehsignals - also normale Benutzung), dann gibt es einige Tweaks, die diese Funktionalität erst ermöglichen, weil der Netzwerkstack in den normalen Einstellungen (und den Endnutzer-Windows-Versionen) für diese Lasten nicht ausreichend performt.

Da sehe ich jetzt wieder nicht so das Problem, da der Netzwerkstack erstmal nicht so wichtig ist um das System zum Reagieren zu bringen.

Machen wir es kurz, auf den Kernel wirst du bei meinem OS keinen Einfluss nehmen können, schon gar nicht zur Laufzeit.

Damit betrachte ich die Diskussion für beendet. Implementiere eine Whitelist für Anwendungen. Ach so, und bitte führe die Diktatur wieder ein. Freiheit ist überbewertet.

Wow, der Mensch hat sich in seiner ganzen Lebensgeschichte nicht geändert, sieht immernoch nur schwarz oder weiß Ich bin durchaus der Meinung das der Otto-Normal-Benutzer vor sich selbst beschützt werden sollte. Wozu sonst z.B. irgendwelche Sicherheitsaspekte in das System einbauen, ist ja auch ne Art der Bevormundung.

Und nur mal am Rande, Diktatur hat auch so seine Vorteile, auch wenn man sowas gerade in Deutschland nicht hören will.

53

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 07. November 2011, 21:48 »

Obwohl ich mir sicher bin das Linux (und andere OSe die MSI(-X) anständig unterstützen) z.B. bei den AHCI-SATA-Controllern mehrere IRQs nutzen können und zumindest theoretisch diesen auch unterschiedliche Prioritäten geben können, üblicherweise wird das aber benutzt um jeden dieser IRQs fest einer bestimmten CPU zuzuordnen damit dann der IRQ-Handler auch möglichst auf der CPU läuft von welcher auch der Job kam dessen Commit der IRQ signalisiert.

Es mag ja sein, dass sie den verschiedenen IRQs verschiedene Prioritäten geben, aber ich denke nicht dass sie sie zur Laufzeit dynamisch ändern.

Wie Aufwändig das ist hängt natürlich vom IRQ-Controller ab aber die modernen APICs der x86-Plattform sollten das eigentlich recht einfach können.

Ich habe keine Ahnung an welchem Takt so ein IO-APIC hängt, wären pro IRQ 4 32bit Zugriffe (2x lesen und dann 2x schreiben). Ich denke aber mal fast das aufwendigste wäre sich nen neuen INT-Vektor zu holen und den alten gegebenenfalls (wenn man denn nen neuen bekommen hat) freizugeben.

Das trifft nur auf 16550 kompatible UARTs zu, bei den 16750 sind es schon 64 Bytes und beim 16950 sind es 256 Bytes (beide mit individuell frei konfigurierbaren Schwellen für Senden und Empfangen). Nebst dessen das dort immer nur ein Byte nach dem anderen mit elend langsamen I/O-Port-Zugriffen transferiert werden kann, ich schätze in der Zeit wo auch nur 10 Bytes aus so einem UART (der am Ende hinter 2 PCI-Bussen und dann noch an einem LPC hängt, also wo schon allein der Weg eine lange Latenz hat) geholt werden können könnte ein moderner Core-i? oder Bulldozzer mindestens 100kB Daten im RAM kopieren.

Das ist doch mal nen Wort, hätte nicht gedacht dass das so langsam ist.

Wobei ich denke, dass RS232 vllt nen schlechtes Bsp ist. Denn mir fällt gerade nix ein, wo man das nutzt und dann nicht gerade die Anwendung die wichtigste ist (dir doch bestimmt ).

Naja, ich hätte jetzt schon erwartet das Du Dich als OS-Entwickler mit sowas mal beschäftigst.

Ich weiß du siehst das anders, aber ich muss erstmal dahin kommen und um das zu schaffen, muss ich auch motiviert sein und Spaß dabei haben und das ist nicht der Fall wenn ich ganz viele technische Dokumentationen lese, die ich wahrscheinlich eh nicht verstehe, weil mir einfach die Zusammenhänge fehlen. Das kommt dann (leider) erst wenn es soweit ist, dass ich dafür konkreten Code schreibe.

Außerdem bin ich der Meinung das Svenska und taljeth nun genug auf Deiner Idee rumgehackt haben. Klar ist das mit dem Linken zur Boot-Zeit ein wenig strange aber eine bessere Lösung gibt es IMHO nicht wenn man keine unnütze Indirektion haben will.

Mit dem rumhacken habe ich erstmal kein Problem. Es ist halt nur so, dass ich mir gewisse Features in den Kopf gesetzt habe und da hilft es nix, wenn man ständig die Antwort auf ein Problem bekommt, nutz halt was anderes (was du übrigens auch oft mit deinen Segmenten gemacht hast ).

Jedes Design hat so seine Schwächen und damit muss man leben, wenn man ganz bestimmte Sachen will/braucht.

Wie groß der Performance-Gewinn wirklich ist kann ich nur schwer abschätzen, die Funktions-Pointer dürften (zumindest bei den häufig benutzen Kernel-Komponenten, ich benutze extra nicht Module weil es IMHO keine Module sind) auch alle im Cache sein so das der Overhead wohl nicht allzu groß ist.

Wenn dem so ist, dann macht es aber auch keinen Sinn, sich über den Cacheinhalt im Zusammenhang mit Threads nen Kopf zu machen. Entweder es ist wichtig oder es ist nicht wichtig. Wie intelligent sind denn die Verdrängungsstrategien? Zumal man einfach nix dagegen machen kann, wenn der User Cache-Trashing betreibt.

Zumal ich finde, so sieht der Code auch schöner aus und ist lesbarer, hat ja auch Auswirkungen auf die Wartbarkeit (leider ).

Ein ähnliches Problem haben ja auch virtuelle Methoden in C++-Klassen, auch dort kostet das etwas Performance aber das ist wohl in den meisten Fällen sehr wenig.

Was übrigens ein sehr interessantes Thema ist. Normalerweise wird ja zu jedem Objekt noch nen Pointer mitgeführt über den man rausbekommt was für ein Typ das ist. Da ich aber keine RTTI nutze, müsste der Compiler es relativ gut optimieren können und nur da wo die entsprechende Methode genutzt werden nen Pointer mitgeben. Es gab da auch mal nen Paper zu wie gut bestimmte Compiler sowas optimieren können.

54

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 07. November 2011, 19:00 »

Also da ist dann das Design fehlerhaft! Warum sollte man die Priorität von IRQs nicht auch zur Laufzeit ändern können? Ich sehe da keinen echten Hinderungsgrund.

Also sind meines Wissens nach alle "wichtigen" OS´e vom Design her fehlerhaft? Mir wäre nämlich nicht bewusst, dass die IRQ-Prioritäten zur Laufzeit dynamisch geändert werden. Das ist auch ein "wenig" aufwendig. (Mir dämmert, gleich kommt jemand und sagt mir mit meinem Boottime-linken ist es genauso  )

Wenn man damit leben kann, dass das nicht immer funktioniert, wäre es mit ein "wenig" Aufwand möglich. Es kann nicht immer funktionieren, weil ich ja bei nem PIC die Prioritäten gar nicht ändern kann und bei nem IO-APIC geht das zwar, aber es kann ja sein, dass ich keinen INT-Vektor mehr für diese Priorität frei habe.
Ansonsten besteht der Aufwand darin, dass ich nen freien INT-Vektor suchen muss und ich muss diesen dann im IO-APIC wechseln. Bei exklusiven Geräte wäre das wahrscheinlich noch in Ordnung, aber bei gesharten Geräten, weiß ich ersten nicht für welchen Prozess die Daten sind (ist doch bei USB so oder?) und der Aufwand für das ständige Umstellen des Vektors dürfte auch nicht so toll sein.

Um dein Bsp. mit der RS232 Schnittstelle zu nehmen. Wir reden da von vllt 16bytes die aus dem FIFO Buffer gelesen werden. Wieso sollte das so schlimm sein?

Außerdem können viele moderne HW-Geräte mehrere IRQs nutzen und die einzelnen Jobs können individuell einen dieser IRQs bekommen wenn sie fertig sind (bei besseren Ethernet-Controllern kann man z.B. einer bestimmten TCP-Verbindung, exakt definiert über beide Sockets, einen extra IRQ zuweisen). Da geht schon so einiges, man muss es nur wollen.

Bzw. wissen, mir war das bisher nicht bekannt.

Trotzdem kann es dann passieren das wichtige Dinge nicht schnell genug fertig werden weil Sie sich die CPU immer wieder mit weniger wichtigen Dingen teilen müssen, deswegen gibt es ja eigentlich Prioritäten.

Da hast du schon recht, aber ich bin bisher immernoch der Meinung, dass ein IRQ-Handler doch nicht wirklich viel macht oder? Wie lange kann sowas schon dauern? (ich weiß es nicht, ob da nicht Sachen dabei sind, die wirklich "lange" dauern)

Du hast also im Bootloader etwas Code der entscheidet welcher Scheduler per Default der richtige ist, dann lege doch jeweils noch eine Liste dazu welche Scheduler in der gegebenen Situation überhaupt möglich sind (klar kann ein Single-CPU-Scheduler nicht auf einem SMP-System arbeiten) und wenn der User eine Vorgabe machen will dann lass den Boot-Loader gegen diese Liste vergleichen und wenn der Wunsch des Users nicht auf der Liste steht dann nimm einfach das Default und gib eine aussagekräftige Fehlermeldung aus. Sorry, aber ich sehe auch da kein Problem.

Das ist die erste Lösung die mir gefällt bzw. auf mein konkretes Problem eingeht

Ich frage mich nur ob dieser (sicher recht kleine) Performance-Vorteil diesen ganzen Aufwand den Du da treibst wirklich wert ist.

Svenska meinte doch das Cache-Misses heutzutage verdammt teuer sind. Also entweder die sind teuer und es lohnt sich diese zu vermeiden oder nicht. Was für nen Aufwand meinst du konkret? Die Überprüfung welche Hardware vorhanden ist und welcher Code genommen wird, den habe ich so oder so. Der "Linker" den müsste ich nicht unbedingt haben, aber ganz ehrlich, das ist gar nicht so viel Code. Ne Symboltabelle erzeuge ich auch so oder so (die benutze ich für Stack-Traces). Was aber stimmt, ist dass das Linken relativ "zeitaufwendig" ist. Allerdings relativert sich diese Zeit mit der Laufzeit des OS.

55

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 07. November 2011, 17:42 »

Hä? Ein UMP-Scheduler sollte nur eine CPU benutzen. Also statt den vorhandenen 4 Kernen wird halt nur einer benutzt. Dann braucht es auch kein SMP-fähiges Locking...

Der Scheduler entscheidet aber nicht auf welcher oder wie vielen CPUs er läuft. Der Timer-IRQ-Handler ruft einfach den Scheduler auf, egal welcher vom Bootloader reingelinkt wurde.

Und es ist größer, aufwändiger und teurer, weil eine allgemeingültige Plattform immer auch Dinge unterstützen muss, die das reale System dann nicht braucht. Beim PC wäre das beispielsweise ein Tastaturcontroller, der auf einem legacy-freien System umständlich emuliert werden muss. Und darum wollen die Hersteller das nicht.

Das läuft auf etwas ähnliches hinaus wie eine andere Diskussion zu ARM. Wir reden also von einer allgemeinen Plattform, nur wer auf Consumer (in Form von Tablets, Desktops, Notebooks und was weiß ich nicht noch alles) abzielt, implementiert diese Plattform, alle anderen halt nicht. Da sehe ich absolut kein Problem. Zumal ich auch nicht soweit gehen würde zu sagen, es soll wie auf dem PC sein. Reicht es nicht, wenn man eine Schnittstelle zur Firmware hat, wo man bestimmte grundlegende Dinge (z.B. ist nen PCI-Bus vorhanden, wenn ja wo ist der gemappt usw.) nachfragen kann. Da sollte es doch auch keine Probleme mit legacy-freien Systemen geben.

"Alles, was kein Netbook ist, ist ein Desktop"

Naja, so habe ich es ja nun nicht formuliert. Ich sehe aber z.B. keinen Unterschied zw einem Terminal und einem Desktop. Denn dann wäre ein und der selbe Rechner, einmal ein Terminal, weil Benutzer A Sachen macht die da reinfallen und einmal ein Desktop, weil Benutzer B Sachen macht die da reinfallen und das am besten noch ohne nen Neustart machen zu müssen.
Sind dann nicht eigentlich alle Geräte wo ChromeOS drauf läuft per Definition Terminals?

Ja - nur warum?

Es macht den Kernel einfacher, genauso wie es den Bootloader komplexer macht. Anders herum ist der Kernel komplexer (und größer) und der Bootloader einfacher. Ist das nicht eigentlich Wumpe?

m Ende muss jeder Treiber vorher gucken, ob die Hardware da ist. Bei dir macht das der Bootloader, d.h. du hast unglaubliche Schwierigkeiten, später mal auf was anderes umzustellen und du bist auf das festgenagelt, was dein Bootloader kann.

Da hast du was falsch verstanden, ich rede nicht von Treibern! Ich rede nur von Modulen die der Kernel benötigt um überhaupt lauffähig zu sein. Treiber laufen ja in ihrem eigenen Prozess.
Es gibt ja nunmal Geräte die sollten (es geht bestimmt auch anders) einfach im Kernel sein und dazu zählt z.B. der Timer. Ich habe im Moment Module für die CPU (UMP oder SMP), die FPU, den IRQ-Chip, Syscall-Mechanismus, Scheduler und den Timer-Chip.

Nix saubere Trennung zwischen Bootloader und Kernel, nix Portabilität und vor allem nix gute Interoperabilität mit anderen Betriebssystemen.

Wieso sollte ich eine saubere Trennung zw Bootloader und Kernel wollen? Zwecks Portabilität? Was wenn auf der Ziel-Plattform eh kein Bootloader mit den nötigen Eigenschaften existiert?
Mit dem letzten kann ich gar nix anfangen.

Es bietet aber Vorteile, es bietet Flexibilität. Bei einem Mikrokernel ist das normalerweise schon per Design unnötig, weil die gleiche Funktionalität an anderer Stelle schon bereitgestellt wird.

Naja, zwecks Vorteile mache ich das doch. Auch bei einem MikroKernel (laut deiner Definition) gibt es Situationen wo dynamisch ladbare Module zur Laufzeit sinnvoll sein kann. Das wären z.B. IRQ-Handler, wenn man die im Kernel haben will oder aber FS-Module, wenn man das VFS im Kernel haben will (was dann mMn kein MikroKernel mehr wäre, aber das ist wieder Geschmackssache).

Weil ich Systeme, die mich zum Idioten erklären, nicht leiden kann. Das ist meine Natur, so bin ich, und das kann ich nicht leiden, weil ich mich nicht für einen Idioten halte.

Dann hast du wirklich ein Problem Also ich lasse mir von einem System nicht sagen, ob ich ein Idiot bin oder nicht

War OS/2 auch. Beide Systeme sind tot.

Soll heißen?

Wie gesagt: Nichtmal Windows kann auf Stellschrauben verzichten, sie werden nur besser versteckt.

Ist ja richtig, aber wie viele Benutzer müssen da wirklich ran? Und was sind das dann für Benutzer? Ich bin halt der Meinung, mit der Zielgruppe die ich habe, das sowas unnötig ist und nur mehr Code und Komplexität für Flexibilität bedeutet.

Ich bin mir aber auch darüber im Klaren, dass das auch nicht weit von dem entfernt ist was Apple mit iOS macht, sprich totale Bevormundung des Benutzers. Allerdings bin ich auch der Meinung, dass die meisten Benutzer bevormundet werden sollten, im Sinne aller Wir Freaks machen nunmal den geringeren Teil aus.

56

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 07. November 2011, 16:57 »

Du hast dich auf die Position "ich will das aber so" zurückgezogen, und das ist okay. Gerade in einem Hobby-OS kann man Dinge auch mal anders machen, weil man eben was ausprobieren will. Du solltest dann nur aufhören, zu glauben, dass dein Modell das einzig wahre ist, vor allem wenn du keine Begründung dafür hast.

Ich habe doch 2 Gründe genannt, einmal "spare" (es ist nicht viel, ich weiß) ich Speicher und ich spare mir ein paar Cache-Misses, da ich eine indirektion weniger bei den Calls habe.
Ich glaube auch nicht das mein Modell das einzige wahre ist, es gibt immer viele Lösungen für ein Problem.

Objektiv gesehen ist genau das passiert, wovor die Wiki-Seite eben warnt: Dein Bootloader schränkt das Design deines Kernels ein.

Das verstehe ich wiederrum nicht. Wieso schränkt mein Bootloader das Design meines Kernels ein? Ich habe doch das was ich will. Um es mal so zu sagen, ihr wollt mir ja einreden, dass die Möglichkeit, dass der User wählen kann verdammt wichtig ist, aber wieso ist sie das? Wieso muss ich das drin haben?

Ich sags mal so, so wie svenska von Linux und BSD geprägt ist, so bin ich besonders von einem OS geprägt (BeOS) und meines Wissens nach, gibt es dort auch nicht wirklich viele Stellschrauben (wenn überhaupt welche, die mit dem vergleichbar sind, was ihr meint) und es hat trotzdem funktioniert und war mMn seiner Zeit voraus!

Ich glaube, dass es vernünftig funktionierende Alternativen gibt, die das erlauben würden, habe ich gezeigt. Dass du sie nicht haben willst, ist eine andere Sache.

Deine Alternative, wie oben geschrieben, verbietet mir aber ein anderes Feature was ich haben will.

init in tyndur ist eine Binary, um das noch zu beantworten. Ein Skript bräuchte ja wieder einen Interpreter und das wird für den allerersten Prozess im System schwierig.

Du sagst also euer Design schränkt euch da ein. Ich würde sagen es ist kaputt

57

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 07. November 2011, 16:28 »

Prozessverwaltung ist für mich ein elementarer Teil des Kernels, also kann der Kernel auch (vom Bootloader in den Speicher gelegte) Tasks starten.

Das passiert in meinem momentanen Konzept nur für den VFS-Server, der bekommt die ganzen Module (also den Speicher) und startet dann den Device-Server usw.

Wenn du deinen Kernel zur Initialisierungszeit aus Einzelteilen zusammenlinkst, ist es ein Makrokernel, kein Mikrokernel mehr. Darum ist Linux, trotz aller Module, ein modularisierter Monolith.

Jetzt bin ich verwirrt. Der fertige Linux-Kernel mit dynamischen Modulen bleibt trotzdem ein Monolith, aber mein Kernel, der aus Einzelteilen zusammengelinkt wird (und dann ein MikroKernel wäre), ist ein MarkoKernel?
Ist ja eigentlich auch egal. Reicht es nicht wenn man zw. MikroKernel und Monolith (und eventuell noch NanoKernel) unterscheidet?

Kaputte Architektur?

Ist Linux für mich auch Liegt also wieder im Auge des Betrachters.

Aber warum sollte ein UMP-Scheduler auf einem SMP-System einen Panic werfen?

Aus einem ganz ganz einfachen Grund, kein Locking! Zumal mir gerade noch einfällt, dass der SMP-Scheduler auf einigen UMP-Systemen sogar ne Exception auslösen wird (der greift nämlich direkt auf den APIC zu).

Wie wird denn vom Bootloader entschieden, ob jetzt der (SMP-fähige) Scheduler A oder der (SMP-fähige) Scheduler B verwendet wird? Anhand der vom Benutzer vorgegebenen Konfigurationsdatei?

Nein, das sagte ich doch schon, das ist fest im Code drin. Alles was den Kernel betrifft ist fest gecodet. Im Moment unterscheide ich nur zw. UMP und SMP, will später aber noch nen Scheduler für viele CPUs (keine Ahnung, vllt ab 16 oder so) und wollte mal gucken wie man das mit Hyperthreading umsetzen kann (aber das hat erstmal Zeit).

Wenn der Kernel nach der Initialisierung aller Module feststellt, dass irgendwas elementares fehlt (z.B. das Root-Dateisystem), dann gibt es einen Panic. Machst du sicherlich ähnlich, wenn die Konfigurationsdatei kaputt ist.

Das ist der Punkt, aus der Sicht des Kernel läuft einfach alles Ich wollte genau diesen ganzen Schmarrn aus dem Kernel haben. Die ganzen wirklich groben Fehler fängt bei mir schon der Bootloader ab, macht den Kernel einfacher.

Der Kernel und die Treiber sind zwingend hardwarespezifisch. Solange du die Treiber nicht in die Firmware stopfen möchtest (was das Betriebssystem erst recht festnagelt, vgl. DOS setzt BIOS voraus), muss der Kernel auf die Hardware zugeschnitten sein.

Ich rede davon das im Prinzip jedes Board seine eigene Platform ist und Linux und Co müssen an jede Platform angepasst werden. Genau darauf wollte ich mit einer allgemeinen Firmware hinaus, dass es eine Platform gibt die man unterstützen muss. Das wäre halt wesentlich angenehmer und auch einfacher für Linux und Co.

Terminals sind nicht oder nur sekundär auf lokale Arbeiten ausgelegt, im Gegensatz zu Desktops. Das heißt meist: Schnelles Netzwerk, langsame CPU, wenig RAM, einfache GPU. Trimslice kannte ich übrigens noch nicht, würde ich aber auch nicht als Desktop bezeichnen.

Wo wir wieder dabei wären, liegt im Auge des Betrachters Ich würde Trimslice schon als Desktop (da es definitiv kein Netbook ist) einstufen. Was du als Terminal bezeichnest, bezeichnet Intel als Nettop.

Wenn du einen Linker im Mikrokernel brauchst, machst du was falsch. Mein Vorschlag war, beim Bauen alle Module in den Kernel zu linken und die nicht benötigten zur Laufzeit freizugeben. Dafür sparst du dir den kompletten Linker, sowohl im Bootloader als auch im Kernel.

Ich wollte aber das Feature haben, dass sich der Kernel erstens um so wenig Initialisationsarbeit wie nötig kümmern muss und vorallem wollte ich den ganzen Nachgucken-Was-Für-Hardware-Vorhanden-Ist Schmarrn aus dem Kernel raus haben.
Wenn ich es mir recht überlege, wenn erik ne lebend-Geburt machen will, muss er das ja auch schon alles im Bootloader machen (mal davon abgesehen, dass er ja nicht unterschiedliche Hardware unterstützen möchte).

Damit brauchst du auch keine bestimmten Funktionen in den Modules als PIC und mit eingeschränkter Lib oder in einer Skriptsprache schreiben, sondern kannst bei der Initialisierung den Code von allen Modulen ganz normal benutzen. Wenn der Benutzer etwas ungünstiges verlangt, kannst du sogar einen sicheren Fallback wählen anstatt einen Panic zu machen. Weniger Komplexität, mehr Funktionalität - für mich klingt das überzeugend.

Problem ist hier der Auftraggeber (also ich  ) und der will bestimmte Features haben und damit muss man leben. Anderes Bsp. ist dass ich 4MB Pages unterstützen will, was wiederrum einige Anforderungen an den PMM stellt, da kannst du noch so lange kommen und sagen, dann lass doch einfach die 4MB Pages weg

Warum in aller Welt sollte ein Mikrokernel dynamisch ladbare Module brauchen? Das ist vollkommen overengineert.

Warum sollte ein Monolith das brauchen oder Programme? Wieso ist das da nicht overengineert? Man "spart" auf der einen Seite Speicher und der Kernel wird einfacher.
Zumal ich eher sagen würde, statisch ladbare Module, weil das passier nur einmal und man kann sie nicht mehr entladen.

Ein Bootloader läuft selber nicht mehr weiter, nachdem er den Kernel gestartet hat, während ein OS die Kontrolle behält, wenn es ein Programm startet.

Wenn ein OS also als Bootloader für ein anderes OS missbraucht werden würde, wäre es kein OS mehr? Ich mein wenn ich mir GRUB2 so angucke, dann sehe ich sehr viel gleichen Code, ich würde sogar so weit gehen und behaupten das GRUB2 komplexer und umfangreicher als die meisten Hobby-OS´e ist.

Warum muss das im Bootloader passieren? Das ist genau mein Browser-Beispiel von oben (schade dass du nicht drauf eingegangen bist).

Weil ich das so will Ansonsten siehe oben.

Bei tyndur läuft das so: Der Kernel startet init (das ist per Definition das erste Multiboot-Modul)

Interessant, so kann man es natürlich auch machen, aber meins ist dafür flexibler Jeder entscheidet sich halt anders. Ihr habt euch für diesen Weg entschieden und konntet euch so die "Arbeit" (ich habe dabei viel gelernt und es hat auch Spaß gemacht) einen Bootloader schreiben zu müssen sparen.
Aber warum muss ich mich an irgendwelche Gegebenheiten anpassen, die ich auch relativ einfach (einfacher als ne neue Architektur umzusetzen) ändern kann, wenn diese Gegebenheiten nicht ganz meinem Design entsprechen?
Bitte komm mir jetzt nicht mit Rad neu erfinden, das hatten wir schon und den Spruch darf keiner bringen, der ein OS entwickelt

init startet dann den Rest der Multiboot-Module, die sich wiederum bei init anmelden, sobald sie initialisiert sind, und wenn sie Abhängigkeiten haben, informieren sie sich bei init, ob die Abhängigkeit schon da ist.

Ihr habt also einfach das Überprüfen der Abhängigkeiten in eure Module/Programme verlagert (was es so bei mir nicht geben wird, da dass durch die festgelegte Reihenfolge abgefangen wird). Ist init eigentlich ein Programm oder nur ein Skript?

Ich will das dann so lösen, dass ich nur ein Skript und kein Programm habe (was ich wieder flexibler finde).

58

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 07. November 2011, 14:31 »

Und warum kann der Kernel das nicht alles selber nachschauen? Wenn du Speicher sparen willst (ob sich das lohnt...?) link die einzelnen Module page-alignt rein, dann kannst du die nicht benötigten zur Laufzeit freigeben, wenn die Initialisierung fertig ist.

Warum sollte er? Zumal ich dann ja den Linker in den Kernel packen müsste und da will ich den ja nicht haben. Im Endeffekt "spare" ich mir dabei eine indirektion bei den Function-Calls.

Ich glaube, dieser Bootloader ist mal wieder dein Hang zur möglichst komplizierten Lösung...

Wieso? So wie der Linux-Kernel Module nachladen kann, lasse ich das vom Bootloader machen, weil ich im Kernel keinen Linker habe und auch nicht haben will.

Ja, GRUB 2 ist im Prinzip ein OS, nur fehlt leider ein gescheiter Bootloader.

Kann ich nicht beurteilen, habe ich mir noch nicht angeguckt. Die Frage wäre, was unterscheidet eigentlich nen Bootloader von einem OS?

Wenn eine bestimmte ELF-Sektion vorhanden ist, parst du die, und da steht dann sowas drin wie "ich habe eine Abhängigkeit auf 'vfs'".

Wer parst die? Der Runtime-Loader? Für den findet eine lebend-Geburt statt, genauso für den Device-Server. Der VFS-Server hat ein wenig Init-Code, da er die ganzen Module startet.

Ich verlagere damit eine gewisse Komplexität bzw. Funktionalität aus dem OS in den Bootloader um eine halbe lebend-Geburt zu machen.

Naja, also, da steht ja explizit drin, was was ist. Ist konzeptionell nichts anderes als wenn du die Multiboot-Kommandozeile hernimmst.

Die dann meine 3.-Stage parsen müsste, um die komme ich halt bei meiner Architektur nicht drumrum.

Ich sagte nicht, der Kernel soll hart auf die Schnauze fliegen, wenn er auf ein Gerät zugreift, das es gar nicht gibt.

Wenn ich sage, dass ich ein bestimmtes Modul haben will, dann wird es geladen, ohne irgendwas zu prüfen, und wenn es nicht funktionieren kann, krieg ich halt einen Panic.

Wenn ich jetzt den Scheduler nehme den der User vorgibt (1-CPU Scheduler) und dann das System starte (mehrere CPUs), dann wird es nen Panic geben, aber der wird nicht auf den ersten Blick nach dem Scheduler aussehen.
Will ich dieses Problem umgehen, muss ich vorher prüfen ob die Angabe des Users Sinn macht und das müsste dann im Bootloader passieren. Dazu müsste jedes Modul ne Funktion haben, die überprüft ob das Modul auf dieser Hardware überhaupt laufen kann.

Wie sieht denn der Bootvorgang bei tyndur aus? Zumal die meisten MikroKernel haben einen eigenen Bootloader (in irgendeiner Form), weil es halt einfach bestimmte Sachen im Bootvorgang und einer gewissen Reihenfolge gibt, auf die man setzt.

Nö, du hättest nur von vornherein ein einfaches (KISS) Design entwickeln müssen.

Ich wollte ein gewisses Feature haben und daraus resultiert das halt.

Also doch nicht so einfach.

Das hinzufügen ist einfach, aber dann funktioniert es nicht so wie ich es mir wünsche. Ich kann immer irgendwas zusammen hacken, was zwar einfach wäre, aber es ist halt nicht das was ich will.

Coreboot initialisiert die notwendige Hardware und startet dann einen Payload.

Wo bekommt es diesen Payload her? Dieser Payload müsste dann ja nen gewisse Art von Firmware sein, die es ermöglich das Bootloader geladen werden können. Sicher man könnte als Payload auch gleich nen Bootloader haben, aber sollte solch eine Firmware nicht einfach sein und nicht schon so speziell wie nen Bootloader?

Vergiss es. Guck dir ein Android-Gerät deiner Wahl an, da ist weder Platz noch Geld für sowas vorhanden. Gleiches gilt für Notebooks. Desktops auf ARM-Basis hab ich, abgesehen von Terminals, noch nicht gesehen.

Du meinst die Hersteller wollen das nicht, aber es wäre besser und einfacher für alle. Entweder man will nur Linux drauf laufen lassen oder es muss halt sowas wie ne Firmware geben. Ein Problem ist doch das man genau deswegen jedes Mal Linux und Co (wo Windows mit eingeschlossen ist) auf jedes Board angepasst werden müssen.
Bei Notebooks und Desktops sollte das Geld da sein. Wieviel soll das denn ausmachen?
Was ist denn der Unterschied zw. nem Terminal und nem Desktop? Mir fällt spontan Trimslice ein.

Wenn der Kernel selbstständig die bereits vorgeladenen Module starten kann, dann kann er auch die Reihenfolge festlegen, in der er sie startet.

Mein Kernel kann das aber nicht Das ist eine Design-Entscheidung gewesen, genauso wie ich mich für einen MikroKernel entschieden habe.

59

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 07. November 2011, 11:51 »

KISS wäre GRUB zu benutzen.

Dann müsste ich ne 3. Stage programmieren, diese als Kernel laden lassen, dann den Kernel linken und an die richtige Stelle laden, die ganze Hardware-Abfage müsste auch (nochmal) gemacht werden. Also im Endeffekt das meiste was meinen Bootloader ausmacht.

Wenn es einfach zu ändern wäre, würdest du es tun. Das Problem wegerklären heißt, dass es eben nicht einfach ist.

Es ist wirklich einfach, wäre nur ne zusätzliche Option in meiner Config-Datei, die ich dem Parser hinzufügen müsste, aber das macht an einer anderen Stelle Probleme.

Stellschrauben sind blöd, äh, weil, naja, Linux hat sowas und Linux will ich nicht. Ich will Windows, das kann alles, aber nichts richtig. Nichtmal Audio.

Nein, das Problem was ich habe, ist dass du immer mit irgendwelchen Sachen ankommst, die halt Linux kann. Oft sind das Features die ich brauche wenn ich nen Server betreiben will oder nen System für Freaks schreiben will oder es auf einem Toaster laufen soll

Alle Geräte, die mit Windows CE ausgeliefert werden. Dazu gehört so ziemlich jedes Navigationssystem außer TomTom, einige Settop-Boxen und viel mehr. Die Welt besteht aus mehr als Computern und computerähnlichen Geräten, besonders bei ARM und MIPS.

Genau das gleiche wie oben. Ich möchte ein Desktop-Betriebssystem schreiben, da interessieren mich andere geräte wie z.B. Settop-Boxen fürs erste nicht, sondern Computer und computerähnliche Geräte.

Das Konzept "BIOS" ist kaputt. Also gibt es auch kein "BIOS in richtig". Denk lieber an z.B. coreboot, das wäre doch mal was.

Ist coreboot nicht ein BIOS Ersatz?

Wenn du das verhindern willst, brauchst du etwas, was jeder PC hat: Einen eigenen Flash-Baustein für das Rescue-System (beim PC auch BIOS genannt). Den wird es aus Platz- und Kostengründen nie überall geben können.

Das ist klar, aber wenn man in den Consumer-Bereich will (Desktop/Laptop und Co) dann sollte man dort sowas haben. Auf nem Mikrokontroller finde ich auch hat ne Firmware nix zu suchen.

Moment... Das heißt, dein Bootloader erkennt automatisch die Hardware, damit er weiß, was er laden soll? Das heißt für das Minimum an Funktionalität, das man erwarten kann, dass er PCI kann (okay, das mag noch vertretbar sein) und dass er einen kompletten USB-Stack hat. Wahrscheinlich muss er für einige Treiber zusätzliches Probing machen, d.h. einfach nur einen zusätzlichen Treiber installieren reicht nicht, sondern man muss den Bootloader ergänzen. Wenn es mehrere Treiber für eine Hardware gibt (vgl. vesa/nv/nvidia), dann muss sich der Bootloader irgendwie automatisch entscheiden, welche er nehmen will.

Nein. Er erkennt alles was für den Kernel wichtig ist, also eine CPU oder mehrere, kann der Kernel den APIC nutzen oder muss er den PIT nutzen, wie kann man den FPU State sichern und was für Syscall-Methoden werden unterstützt. Auch die CPU Features werden abgefragt (für z.B. Paging-Flags) und für den Scheduler wäre es dann noch interessant zu wissen, was für eine CPU-Topologie vorliegt (mehrere Sockel, Hyperthreading usw.).

Außerdem halte ich es für genauso fragwürdig, in den Bootloader einen Linker einzubauen. Alles, was im Bootloader ist, wird nur während dem Booten benutzt und kann zur Laufzeit nicht wiederverwendet werden. Im Prinzip müsstest du in deinen Bootloader nur noch einen Scheduler einbauen und schon hättest du ein komplettes OS mitsamt Treibern...

Ist das nicht bei GRUB und uboot der Fall (Treiber und sowas und eigentlich schon mehr OS als Bootloader)?

Was sagst du dann erst zu erik´s Bootloader, er will ja eine lebend Geburt seines Kernels vornehmen, da dürfte also auch mehr drin sein, als dir lieb ist

Also die richtige Vorgehensweise wäre es, dass die Binaries die Information selber mitbringen, welche Abhängigkeiten sie haben.

Es gibt einfach eine feste Reihenfolge in welche das System bzw. bestimmte Komponenten gestarten werden müssen, da es dort Abhängigkeiten gibt. Das ist halt bei einem MikroKernel so. Wie soll ich das in die Binaries packen?

Wenn du nicht auf Dateinamen prüfen willst, wird es ja auch bei deinem eigenen Bootloader in der Config stehen müssen, oder?

Nicht ganz. Meine Config sieht ungefähr so aus:

Code: [Auswählen]

kernel="/system/kernel"
vfs-server="/system/server/vfs-server"
device-server="/system/server/device-server"
runtime-loader="/system/runtime-loader"
module="/system/driver/foo"
...
Das ganze wird dann in einem gewissen Format an den Kernel bzw. Device- und VFS-Server weitergeleitet und entsprechend gestartet.

Hä? Wieso muss der Code PIC sein und darf nichts anderes benutzen? Wenn ich sage, dass ich ein bestimmtes Modul haben will, dann wird es geladen, ohne irgendwas zu prüfen, und wenn es nicht funktionieren kann, krieg ich halt einen Panic. Selber schuld, wenn ich explizit eine nichtfunktionierende Konfiguration angebe.

Ich möchte diese Einstellung aber nicht bei mir. Du überprüfst die Eingabe von einem User in deinem Programm doch auch? Oder soll jedes Programm abschmieren, weil nicht überprüft wurde, ob es eine Zahl war oder nicht?

60

OS-Design / Re: Threads blockieren und wieder aufwecken

« am: 06. November 2011, 22:40 »

Ist ja kein Zufall, dass die meisten ihren Kernel x-mal neuschreiben.

Es kommt halt drauf an, ob man basteln will oder ob man ein Ergebis benutzen will. Ich bin eher der bastel-Typ

Was kann dein Bootloader denn, was GRUB nicht kann?

Ich linke meinen Kernel erst zur Bootzeit fertig zusammen. Das geht so unter GRUB nicht (??). Man kann zwar Module laden lassen, aber man kann nicht anhand vorhandener Hardware einen Kernel zusammenlinken lassen.
Ich kann bei GRUB nicht so wirklich beeinflussen wo die Module hinkommen und ich kann zu einem Modul nicht noch einen festen String dazuschreiben. Meine Config-Datei soll nen Kernel, nen VFS-Server, nen Device-Server und Module laden können und ich muss dann ganz genau wissen welches Modul was ist. Erst dadurch kann ich dann den VFS-Server und den Device-Server starten. Die anderen Server brauchen mind. diese beiden und deswegen ist das so wichtig. Zumal ich ja flexibel sein will und die Dateinamen für die Server sollen nicht fest gecodet sein.

Und was man bräuchte, um den Benutzer eine Option für den Scheduler übergeben zu lassen?

Das Übergeben der Option ist kein wirkliches Problem. Das Problem besteht darin zu entscheiden ob ein Scheduler wirklich für die vorhandene Hardware geeignet ist. Das mache ich im Moment statisch im Code, sprich ich gucke ist nur eine CPU vorhanden, dann nimm /scheduler/smp.ko, sind mehrere CPUs vorhanden dann nimm /scheduler/smp.ko.
Willst du den Benutzer entscheiden lassen, müsste ich in den einzelnen Modulen Code einbauen, die überprüfen ob die entsprechende Hardware vorhanden ist. Dieser Code müsste PIC sein und dürfte keine weiteren Funktionen nutzen (würde die Sache nur noch komplizierter machen). Extra für sowas ne Skriptsprache zu verwenden/einzubauen halte ich für richtig Overkill.