Thema: Threads blockieren und wieder aufwecken

[FlashBurn]

Nein, sowas! Wie konnte das nur passieren? Ein selbstentwickelter Bootloader mit kaputtem Design, der die Flexibilität einschränkt. Also damit konnte ja wirklich niemand rechnen!!11elf! (Hier steht es im Wiki)

Wie soll ich es nur sagen ... das was GRUB mir bieten kann funktioniert Das was mir GRUB nicht bieten kann, ist halt nicht so flexibel wie es sein könnte. Ich habe mich für einen eigenen Bootloader entschieden, weil ich da alles kontrollieren kann, Erfahrung sammle, es spaß macht daran rumzubasteln (du weißt schon, das viele alleine die Bastelei als das fertige Ergebnis interessiert?) und weil ich mir so die 3.-Stage im Bootvorgang sparen konnte.

Interessant finde ich aber folgendes:

Falls man allerdings von Anfang an intensiv seinen Bootloader plant – was einem Anfänger aufgrund mangelnder Erfahrung verwehrt bleibt

Soll heißen, eigentlich sollte man auch kein OS programmieren (oder planen). Denn das kann ja ein Anfänger nicht aufgrund mangelnder Erfahrung. Henne-Ei-Problem (vorallem was den Bootloader betrifft, da man heutzutage ja nix mehr im Real-Mode macht).

[kevin]

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

Was kann dein Bootloader denn, was GRUB nicht kann? Und was man bräuchte, um den Benutzer eine Option für den Scheduler übergeben zu lassen?

[FlashBurn]

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.

[Svenska]

Allerdings wären wir da wieder bei KISS Im Mom brauche ich keine speziellen Sachen für meine Kernel-"Module" und so wollte ich es eigentlich lassen. Sowas kann man immernoch ändern, ohne das es Probleme gibt (außer das mit dem Wechseln zur Laufzeit).

(a) KISS wäre GRUB zu benutzen.
(b) Wenn es einfach zu ändern wäre, würdest du es tun. Das Problem wegerklären heißt, dass es eben nicht einfach ist.

Aber wenn du der Meinung bist, dass dein System besser ist als jedes andere, dann musst du es nicht einstellbar machen. Die Praxis zeigt, dass Stellschrauben immer gut sind.

Ich will kein zweites Linux machen!

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.

Was ich mir wünsche ist erstmal ein DAU-kompatibles System (und ich denke das ist schwieriger als nen System für Freaks) und da muss man keine Scheduler per Hand wechseln können.

Das Argument, dass Stellschrauben ein System DAU-unfreundlich machen, ist Blödsinn. Das weißt du so gut wie ich.
Nicht umsonst geistern elendig viele Registry-Hacks rum, die Windows in bestimmten Bereichen verbessern (eben weil der Default doof ist).

Aber gut, leb in deiner eigenen Welt. Du kannst offensichtlich jedes Problem in jedem Zusammenhang optimal lösen.
(PS: Stellschrauben sind auch gut geeignet, um gute Default-Werte zu finden.)

Reg dich lieber drüber auf, dass man einen WindowsCE-Bootloader in der Regel nicht dazu überreden kann, etwas anderes zu booten, einen üblichen Linux-Bootloader (RedBoot, U-Boot) dagegen schon eher.

Welche Geräte gibt es heute die nur WindowsCE laden können (gut gibt ein paar billig Netbooks aus Fernost)?

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.

Ich möchte meinen der Fastboot-Bootloader von Android ist auch nicht so das wahre, aber ich würde mir viel lieber eine allgemeine Firmware wünschen, wo ich nicht schon im Bootloader alles mögliche an Treiber haben muss (ein BIOS nur in besser ).

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.

Das Konzept "BIOS" ist langsam, weil sich das BIOS per se erstmal um alle Geräte kümmern können muss und später für das Betriebssystem auch noch Funktionen bereithält; bei EFI sogar noch Hardwaretreiber. Normalerweise sollte die Firmware das OS starten können, vielleicht ne minimale Konsole bieten (Bootgerät) und nicht mehr.

Dafür bräuchte man an der richtigen Stelle nen dislike-Button

Ich hab was gegen Facebook, danke.

außerdem wollen die Hersteller oft genug keine anderen Betriebssysteme, im Gegensatz zum PC, vergleiche hierbei die Diskussion von TomTom damals.

Ich denke das würde sich mit einer allgemeinen Firmware auch lösen lassen.

Nein. Du kannst soziale Probleme nicht technisch lösen.

Problem außerhalb des PCs ist doch das man das System relativ einfach zerschießen kann, aber es relativ schwer wieder in Ordnung bekommt.

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.

Gruß,
Svenska

[kevin]

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.

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.

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...

tl;dr: Bist du des Wahnsinns?

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.

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

Wenn du es einfacher machen willst, kannst du ja in die Modul-Kommandozeile irgendwelche Flags packen wie "das hier vor dem ganzen Rest laden". Wenn du nicht auf Dateinamen prüfen willst, wird es ja auch bei deinem eigenen Bootloader in der Config stehen müssen, oder? Spricht also nichts dagegen, das auch bei Multiboot so zu machen.

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.

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.

[FlashBurn]

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?

[kevin]

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.).

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.

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

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

Ja, GRUB 2 ist im Prinzip ein OS, nur fehlt leider ein gescheiter 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

Ich hoffe, dass er seinen Kernel nicht im Bootloader zusammenlinken will... Ansonsten gebe ich dafür gern ein k-Attribut raus.

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 eine bestimmte ELF-Sektion vorhanden ist, parst du die, und da steht dann sowas drin wie "ich habe eine Abhängigkeit auf 'vfs'".

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

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

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?

Ich sagte nicht, der Kernel soll hart auf die Schnauze fliegen, wenn er auf ein Gerät zugreift, das es gar nicht gibt. Sondern dass der Kernel gestartet werden soll und dann ganz ohne PIC und mit so vielen Funktionsaufrufen wie er will feststellt, ob die Hardware da ist oder nicht. Wenn nein, gibt es eine Fehlermeldung.

Was du willst, ist nicht, dass es eine Fehlermeldung gibt, sondern dass (nehmen wir mal einen Browser als Beispiel) der Browser gar nicht erst startet, um mir einen 404 anzuzeigen. Stattdessen prüft eine als PIC geschriebene Funktion, die das OS aus dem Browser extrahiert, ob es die Webseite überhaupt gibt. Und wenn nicht, dann wird der eigentliche Browser gar nicht erst gestartet.

Klingt bescheuert? Ja, schon irgendwie...

[Svenska]

KISS wäre GRUB zu benutzen.

Dann müsste ich ne 3. Stage programmieren, [...]

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

aber das macht an einer anderen Stelle Probleme.

Also doch nicht so einfach.

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.

(a) Tut mir Leid, dass ich mich mit Windows seit längerem nicht mehr tiefgehend befasse und daher lieber mit Systemen vergleiche, die mir persönlich wesentlich besser gefallen. Das ist neben Linux gelegentlich auch mal ein BSD.
(b) Halte ich Benutzer entweder für kompetent oder für inkompetent. Inkompetent heißt, es gibt überall gut funktionierende Standardwerte. Kompetent heißt, wer es besser weiß, darf sein Wissen auch benutzen. Das unterscheidet ein Betriebssystem von Spielzeug...
(c) "Einstellbar" heißt nicht "kompliziert". Wenn du explizit ein debugfs mounten musst, dann sieht das ein inkompetenter Nutzer die Stellschrauben nichtmal...

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.

Darum ging es an der Stelle aber nicht... ich wollte dir nur zeigen, dass der Horizont auch weiter weg sein kann... und dass es dort Probleme gibt, ist offensichtlich. Solange diese aber ignoriert werden (weil ist für mich ja nicht relevant), ändert sich nichts.

PS: Eine Settop-Box mit USB-Anschluss und eingebauter Festplatte ist potentiell ein vollwertiger Computer.

Ist coreboot nicht ein BIOS Ersatz?

Ja, es ist aber kein BIOS. Coreboot initialisiert die notwendige Hardware und startet dann einen Payload. Das kann ein BIOS sein (dann wird SeaBIOS verwendet), muss es aber nicht.

Einen eigenen Flash-Baustein für das Rescue-System (beim PC auch BIOS genannt).

Das ist klar, aber wenn man in den Consumer-Bereich will (Desktop/Laptop und Co) dann sollte man dort sowas haben.

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.

Auf nem Mikrokontroller finde ich auch hat ne Firmware nix zu suchen.

ARM-Bausteine sind Mikrocontroller... die werden auch dann nicht zu Mikroprozessoren, wenn man sie in Netbooks einbaut...

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

U-Boot enthält nur Treiber für CPU, RAM, Flash (evtl. HDD) und Splash-Screen und kann Dateisysteme recht ineffizient lesen. Mehr kannst du einkompilieren, wenn du willst, genug Platz und (Boot-)Zeit hast und die entsprechende Unterstützung überhaupt existiert.

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.

Nö. Wenn der Kernel selbstständig die bereits vorgeladenen Module starten kann, dann kann er auch die Reihenfolge festlegen, in der er sie startet. Und normalerweise macht man eine Abhängigkeitsverwaltung in der Form "ich brauch dies, du brauchst das" usw. Ist flexibler und wird bei Erweiterungen wichtig...

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?

Darum sollte jemand, der keine Ahnung hat, ja auch nicht am Bootloader rumspielen... geht ja auch nicht jeder Windows-Nutzer an die Registry und pfuscht da wahllos rum. Das tun die, die genug Ahnung haben - und für die ist sowas da.

Gruß,
Svenska

[FlashBurn]

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.

[Svenska]

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.

Bei einem Mikrokernel sind die Module üblicherweise Tasks. Prozessverwaltung ist für mich ein elementarer Teil des Kernels, also kann der Kernel auch (vom Bootloader in den Speicher gelegte) Tasks starten. Wenn ein Task einfach blockiert, weil seine Vorbedingung noch nicht erfüllt ist (z.B. ein Socket oder ein bestimmter IPC-Dienst), dann spielt auch die Ladereihenfolge keine Rolle mehr.

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.

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.

Kaputte Architektur?

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.

Dann ist dein System nicht in der Lage, vernünftig mit Fehlern umzugehen. Ein Kernel ohne Scheduler ist nicht lauffähig, soweit richtig. Aber warum sollte ein UMP-Scheduler auf einem SMP-System einen Panic werfen? Reicht eine Warnung nicht? Warum sollte ein SMP-Scheduler auf einem UMP-System einen Panic werfen? 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? Dann kann der Benutzer auch den Scheduler vorgeben und wenn der nicht geladen werden kann, wird der Standardscheduler als Fallback geladen...

Dazu müsste jedes Modul ne Funktion haben, die überprüft ob das Modul auf dieser Hardware überhaupt laufen kann.

Ja, ein USB-Modul sollte auf einem USB-freien PC einen Fehler werfen... und ein PAE-Modul sollte das auf einem i586 ebenfalls tun. 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.

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?

Payloads sind im Baustein mit drin und können alles mögliche sein, z.B. ein Linux-Kernel mit Initrd (als Rescue-System), ein BIOS, ein DOS, ein GRUB-artiger Bootloader, was immer du möchtest.

Flexibilität ist das Zauberwort. In einem festplattenlosen Terminal braucht die Firmware keine Festplattenunterstützung haben, die kostet nur Zeit, Platz und damit Geld. In einer eierlegenden Wollmilchsau kommt ein full-featured sonstwas zum Einsatz, auf einem Tablet ein Kernelloader.

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.

Eine Firmware brauchst du immer, ob du nun Linux drauf haben willst oder was anderes. Und nein, die Hersteller wollen das nicht. Das ist Aufwand, Aufwand ist teuer und Geld ist ein Problem. Und man könnte ja auf Bastler treffen, die dann ihre eigene Software drauf laufen lassen wollen.

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.

Das ist falsch. 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.

Bei Notebooks und Desktops sollte das Geld da sein. Wieviel soll das denn ausmachen?

Das Geld ist nicht da, das nennt man nämlich Gewinnspanne. Die ist im Consumerbereich ohnehin schon sehr klein.

Was ist denn der Unterschied zw. nem Terminal und nem Desktop? Mir fällt spontan Trimslice ein.

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.

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.

Tja, dann ist das eben schlechtes Design. Aber wenn du den Kernel zusammenlinkst, ist es eher ein Makrokernel als ein Mikrokernel.

Gruß,
Svenska

[kevin]

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.

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.

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.

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.

Bei Linuxmodulen geht es darum, zur Laufzeit nachzuladen, bei dir geht es darum, zur Bootzeit auszuwählen. Aber lassen wir das einmal außer Acht: Warum in aller Welt sollte ein Mikrokernel dynamisch ladbare Module brauchen? Das ist vollkommen overengineert.

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

Ich glaube, diese Frage zu beantworten hilft uns nicht so richtig weiter, aber mein Versuch wäre: 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.

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

Die stage3 wäre aber Teil des Kernels und würde wesentlich einfacher werden als ein kompletter Bootloader mit integriertem Linker.

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.

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

Aus dem Zufallspanic einen Panic zu machen, der nach Scheduler aussieht, ist einfach. Dazu musst du prüfen, ob die Angabe des Users sinnvoll ist, ja. Das kannst du bei der Initialisierung des Schedulers machen. Wenn du magst, kannst du statt dem aussagekräftigen Panic sogar einen sicheren Falback auswählen und damit weitermachen.

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.

GRUB ist ursprünglich der Bootloader eines Mikrokernels (Hurd).

Bei tyndur läuft das so: Der Kernel startet init (das ist per Definition das erste Multiboot-Modul) und mappt alle anderen Module in den Adressraum von init. 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.

An dieser Stelle sind in der Regel pci und jeweils ein Block- und Dateisystemtreiber geladen, plus servmgr. servmgr liest eine Konfiguration vom Rootdateisystem und lädt alle übrigen Module, die darin angegeben sind (inklusive weiteren Abhängigkeiten usw.).

[FlashBurn]

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).

[kevin]

Eine Antwort auf einzelne Absätze spare ich mir. 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.

Objektiv gesehen ist genau das passiert, wovor die Wiki-Seite eben warnt: Dein Bootloader schränkt das Design deines Kernels ein. Du kannst oder willst ein Feature (Stellschrauben für den Benutzer) nicht implementieren, weil es mit deinem Bootloader-Design zu umständlich wäre. 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.

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.

[FlashBurn]

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

[Svenska]

Reicht es nicht wenn man zw. MikroKernel und Monolith (und eventuell noch NanoKernel) unterscheidet?

Reicht es nicht auch, wenn man den Begriff "Kernel" komplett weglässt und von "Computer" spricht?

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

Aus einem ganz ganz einfachen Grund, kein Locking!

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...

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.

Ja. 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.

Ich würde Trimslice schon als Desktop (da es definitiv kein Netbook ist) einstufen. Was du als Terminal bezeichnest, bezeichnet Intel als Nettop.

"Alles, was kein Netbook ist, ist ein Desktop". Naja, wie du willst. Der Begriff "Terminal" stammt übrigens aus dem letzten Jahrhundert, neue Buzzwords für alte Dinge bringen meistens wenig.

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.

Ja - nur warum? Am 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. Nix saubere Trennung zwischen Bootloader und Kernel, nix Portabilität und vor allem nix gute Interoperabilität mit anderen Betriebssystemen. Das sind natürlich auch Designziele, aber in jedem Fall sind es Folgen von Designentscheidungen.

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).

Will er auch. Bei einer einzigen Hardwareplattform ist das durchaus möglich, danach zerbricht das System. Siehe die Diskussion zu ARM.

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

Warum sollte ein Monolith das brauchen oder Programme?

Der klassische Monolith kann das genausowenig wie das klassische Programm. 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. Zwei Lösungen für fast gleiche Probleme an verschiedenen Stellen ist Overengineering.

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).

Treiber in einem Mikrokernel-Design werden auch Abhängigkeiten voneinander haben (z.B. ein USB-Tastaturtreiber vom USB-Stack, der USB-Stack vom USB-Hosttreiber, der von PCI oder alternativ der TCP-Treiber von IP, der IP-Treiber von einer Netzwerkkarte/localhost). Wenn du das an einer Stelle ohnehin implementieren musst, dann kannst du diese Lösung auch allgemein an jeder ähnlichen Stelle nutzen.

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?

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.

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!

War OS/2 auch. Beide Systeme sind tot. Wie gesagt: Nichtmal Windows kann auf Stellschrauben verzichten, sie werden nur besser versteckt. (Und bei den Nicht-Serverversionen werden teilweise auch Stellschrauben schlechter eingestellt.)

Gruß,
Svenska

[FlashBurn]

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.

[erik.vikinger]

Hallo,

Bei mir laufen (bisher) alle IRQ-Handler mit der selben Real-Time-Priorität.

Ja, genau so hatte ich das auch verstanden. Und genau das ist es was ich kritisiere, Prioritäten gibt es nicht umsonst, eben weil manche Dinge wichtiger sind als andere. Der entscheidende Punkt ist dass das nicht schon zum Compile-Zeitpunkt festgelegt werden kann sondern sich erst dynamisch aus der tatsächlichen Nutzung (durch den User) ergibt.

dass immer die Threads mit höchster Priorität laufen und am Ende ihrer Zeitscheibe wieder hinten an die Ready-Liste gepackt werden, wird der MP3-Player entweder nie oder nur zu sporadisch drankommen.

Wenn Dein MP3 Player verhungert dann musst Du ihm eine höhere Priorität geben. Wenn Du im Vordergrund normal arbeiten möchtest (inklusive längerem Compilerlauf) aber die Hintergrundberieselung trotzdem ohne Aussetzer laufen soll dann braucht die Hintergrundberieselung eben eine höhere Priorität, das ist der Grund warum überhaupt Prioritäten eingeführt wurden. Wenn Dein Scheduler anders arbeitet dann musst Du eben andere Stellschrauben verwenden. Du hast doch bestimmt welche vorgesehen, oder?

Der Treiberprogrammierer weiß schon wie wichtig was ist

Woher?

schließlich legt er auch fest welche Priorität der IRQ bekommt.

Nur weil er das für gewöhnlich tut heißt das nicht das der Treiberprogrammierer im Voraus meinen Workload kennt (den kenne ja noch nicht einmal ich selber im Voraus).

Problem auf Empfangsseite ist, dass du die Priorität des direkten IRQ-Handlers nur einmal festlegen kannst (da wo der Treiber sich registriert) und dann kannst du eigentlich keinen Einfluss mehr darauf nehmen.

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. 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.

Denn du weißt ja auch nicht wer die Daten dann haben möchte und wie wichtig die nun sind.

Das ist sicher bei vielen Geräten ersteinmal richtig, aber bei einer RS232-Schnittstelle ist es ziemlich eindeutig wer die Daten bekommt und wie wichtig die sind und auch bei den HW-Geräten die für mehrere Programme parallel arbeiten können (wie z.B. ein Ethernet-Controller oder auch ein AHCI-SATA-Controller) gibt es Mittel und Wege dem nachzuhelfen.

Das mit dem kleinen Prioritäts-Boost für Vordergrund-Prozesse ist zwar nützlich aber nicht das was ich meine, dieser Boost ist auf jeden Fall kleiner als wenn der User seinen Programmen bewusst unterschiedliche Prioritäten gibt eben weil er ganz klar definieren will was ihm wichtig ist.

Das die anderen Treiber nicht verhungern, soll ja durch eine entsprechend "kurze" Zeitscheibe gesichert werden.

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.

So kann es also passieren das der User den Scheduler für Single-CPU Systeme ausgewählt hat, aber auf einem SMP-System funktioniert das nicht und das OS wird crashen. Das finde ich eher nicht so toll.

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.

Zur Laufzeit umstellen will ich mir nicht antun.

Das verlangt doch auch keiner.

Das Du Deinen Kernel erst zur Boot-Zeit zusammenlinken möchtest finde ich gar nicht mal so schlecht (ich bestreite auch nicht das Dein Kernel immer noch ein Micro-Kernel ist weil Du ja nur die wirklich elementaren Dinge in den Kernel linkst und der Rest trotzdem normale User-Mode-Prozesse sind), das spart Dir immerhin indirekte Calls. Ich frage mich nur ob dieser (sicher recht kleine) Performance-Vorteil diesen ganzen Aufwand den Du da treibst wirklich wert ist.


Meinen Kernel linke ich nicht zur Boot-Zeit zusammen, das wäre auch nahezu unmöglich da ich noch auf Assembler-Quell-Text-Ebene linke (mein Linker ist also ne Art Text-Merger) und erst danach der Code-Generator kommt der den tatsächlichen Binär-Code für die CPU generiert und all das möchte ich nicht im Boot-Code haben (schon allein weil ich dort recht enge Platzverhältnisse habe und auch kaum eine gescheite libc anbieten kann, was alles gegen meinen in C++ geschriebenen Code-Generator im Boot-Code spricht). Die Lebendgeburt meines OS bezieht sich darauf das ich in dem Moment wo der Kernel zum Leben erwacht bereits mehrere laufende Prozesse habe, ich lege also noch vom Boot-Code aus die nötigen Datenstrukturen für den Kernel so an das er sieht das er bereits 3 Prozesse mit insgesamt X Threads (der idle-Prozess hat so viele Threads wie CPUs vorhanden sind) hat. Die ersten 3 Prozesse werden also nicht durch den CreateProzess()-Syscall erstellt nachdem der Kernel bereits läuft sondern die sind schon da wenn der Kernel zum Leben erwacht. Dazu muss der Boot-Code natürlich ganz genau wissen wie die Datenstrukturen des Kernels aussehen, ich binde also in den Boot-Code auch einige Teile des Kernel-Quell-Codes ein. Dass das von taljeth eventuell das K-Attribut bekommt nehme ich in Kauf, weil auch ich eine möglichst hohe Performance möchte und mein Kernel keinen Code enthalten soll den er nicht auch zur Laufzeit benötigt. Mein Kernel ist eigentlich nur eine Ansammlung von passiven Exception/IRQ/Syscall-Handlern und hat gar keine aktive main()-Funktion oder etwas vergleichbares, mein Kernel hat nicht mal eine init-Funktion, das muss alles durch den Boot-Code erledigt werden. Das bedeutet zwar das der Kernel und der Boot-Code immer exakt zusammen passen müssen aber da der Kernel eh als Binär-Klumpen mit in den Boot-Code integriert (quasi als rodata-Sektion mit reingelinkt) werden muss ist das auch kein Problem wenn nach dem compilieren des Kernels auch der Boot-Code neu compiliert werden muss. Mein Boot-Code richtet im übrigen keine normalen HW-Geräte ein, er fasst nicht mal den IRQ-Controller an (außer das er dort die physischen Adressen der IRQ-Handler-Funktionen vom Kernel konfiguriert), er richtet nur den physischen RAM ein und aktiviert alle CPUs (und legt auf jede CPU einen der idle-Threads), mein Boot-Code kümmert sich also nur um den absoluten Kernbereich der Plattform. Das Einrichten der restlichen HW-Geräte, also alles was PCI und dahinter ist, wird erst zur Laufzeit durch die normalen User-Mode-Prozesse gemacht.


Grüße
Erik

[FlashBurn]

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.

[erik.vikinger]

Hallo,

Also sind meines Wissens nach alle "wichtigen" OS´e vom Design her fehlerhaft?

Also wenn Du das so siehst dann eindeutig ja. 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.

Das ist auch ein "wenig" aufwendig.

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. Beim IRQ-Controller auf meiner Plattform ist das auch ganz einfach. Beim klassischen PIC geht das natürlich gar nicht aber den ziehe ich ja auch nicht als Referenz heran.

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?

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. Diese I/O-Port-Zugriffe werden nämlich immer rein sequenziell abgearbeitet (könnte ja theoretisch ein A20-Gate bei manipuliert werden) und die CPU verarbeitet auch keine anderen Befehle während dessen, das ist einer der Gründe warum die PCI-Spec fordert das neue/native PCIe-Geräte jede Ressource als Speicher anbieten müssen.

Bzw. wissen, mir war das bisher nicht bekannt.

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

Wie lange kann sowas schon dauern? (ich weiß es nicht, ob da nicht Sachen dabei sind, die wirklich "lange" dauern)

Ich weiß auch nicht wie lange ein IRQ-Handler im Worst-Case so brauchen kann aber ich denke dass das OS-Design auch mit wirklich worstigen Worst-Cases anständig umgehen können muss.

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

Gerne, dafür bin ich doch da. 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. Mir persönlich wäre das wohl zu aufwendig aber wenn Du das machen willst dann nur zu. Wie taljeth ja selber geschrieben hat, es ist Dein OS und da darfst Du natürlich auch mal neue Wege ausprobieren. 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. Wer es genau wissen will wird wohl um eine ordentliche Performance-Messung nicht umhin kommen. 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. Über die Boot-Zeit des OS würde ich mir an Deiner Stelle nicht so arg viele Sorgen machen, da dürfte ein besseres BIOS sicher mehr Potential bieten.


Grüße
Erik

[FlashBurn]

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.