Thema: YourOS

[OsDevNewbie]

Hallo liebe Community,
ich möchte hier mal mein OS vorstellen mit dem Namen "YourOS".
Mein Ziel ist ein Monolithischer Kernel im 64-bit Mode.
Es besteht eigentlich aus drei Teilen. Dem Bootloader, der den Übergang zwischen GRUB und Kernel darstellt und auch in den Long Mode wechselt. Dann der eigentliche Kernel und schliesslich noch Programme und eine dazugehörige Lib, die momentan aber nur Grundfunktionen beinhaltet.
Ich möchte mal eure Meinung dazu hören. Ich bin für jegliche Kritik oder Lösungsvorschläge offen.

Hier der Link: https://github.com/Gurgel100

P.S.: Ja ich weiss mein Codestil ist nicht gerade der Beste aber er verbessert sich nach und nach.

[Jidder]

Cool, mein OS. Hahaha ...

Ich seh da CDI. Funktioniert das schon?

[OsDevNewbie]

CDI funktioniert insoweit, wie es für die aktuell implementierten Treiber nötig ist. Wird aber sicherlich noch erweitert.

[OsDevNewbie]

UPDATE
Hier ein kleines update zum  Entwicklungsstatus von YourOS. Beim booten wird jetzt der Cache der CPU aktiviert. Zudem wird ein Initialisierungsprozess gestartet, der später alle anderen Prozesse Starten wird.
es weißen auch einige Verbesserungen in der Speicherverwaltung gemacht die (hoffentlich) die Performance auch ein bisschen erhöhen.
Würde mich freuen wenn einige von euch mein OS bei sich testen würden.

[kevin]

Würde mich freuen wenn einige von euch mein OS bei sich testen würden.

Aus dem kernel-Repository oder braucht man von lib/bootloader auch was? Und muss man sich die Makefile selber bauen oder wie ist das gedacht? Eclipse werde ich mir dafür nicht installieren.

[Svenska]

Blöde Frage, aber sind die CPU-Caches nicht sowieso immer aktiviert?

[OsDevNewbie]

Hallo,
hier findet ihr ein ISO zum ausprobieren (müsst einfach das .txt entfernen).

Blöde Frage, aber sind die CPU-Caches nicht sowieso immer aktiviert?

Laut meinen Analysen nicht. Vielleicht werden sie auch vom GRUB ausgeschaltet. Ich habe übrigens mal bei tyndur geschaut, dort ist der Cache auch deaktiviert.
Aber irgendwie bringt bei mir der Cache keinen Geschwindigkeitsvorteil.

[Jidder]

Meinst du mit "Cache aktivieren" diesen Abschnitt? https://github.com/Gurgel100/Kernel/blob/develop/cpu.c#L202

Was du da tust ist den Cache Deaktivieren. Ich habe, während ich deine ISO gebootet habe, einfach mal im Bootmenü die Register im QEMU Monitor anzeigen lassen, und er sagt mir CR0=00000011. Sobald dein OS geladen ist, ist CR0=e0000013. Also sind nun die Bits für Cache Disable und No Write-Through gesetzt.

Das Manual sagt in Volume 3, Abschnitt 11.5.1: "For highest processor performance, both the CD and the NW flags in control register CR0 should be cleared." Außerdem siehst du vermutlich keine positive oder negative Geschwindigkeitsänderung, weil du den Cache nicht geflusht hast. Auch mit dem deaktivierten Cache werden existierende Einträge weiterhin genutzt. (In Tabelle 11-5, in der Zeile für CD=1, NW=1: "Read hits access the cache; read misses do not cause replacement.")

Außerdem finde ich die Verwendung der BTC-Instruktion etwas seltsam. Das kehrt ja nur das Bit um. Ein Bit setzen kannst du damit nicht, wenn es vorher schon gesetzt war.

[OsDevNewbie]

Meinst du mit "Cache aktivieren" diesen Abschnitt? https://github.com/Gurgel100/Kernel/blob/develop/cpu.c#L202

Ja

Was du da tust ist den Cache Deaktivieren. Ich habe, während ich deine ISO gebootet habe, einfach mal im Bootmenü die Register im QEMU Monitor anzeigen lassen, und er sagt mir CR0=00000011. Sobald dein OS geladen ist, ist CR0=e0000013. Also sind nun die Bits für Cache Disable und No Write-Through gesetzt.

Also bei mir steht nach dem Booten CR0=80000013. Also sind bei mir die Bits für Cache disable und No Write-Through gelöscht.
Das heisst bei mir wird der Cache aktiviert.

Das Manual sagt in Volume 3, Abschnitt 11.5.1: "For highest processor performance, both the CD and the NW flags in control register CR0 should be cleared." Außerdem siehst du vermutlich keine positive oder negative Geschwindigkeitsänderung, weil du den Cache nicht geflusht hast. Auch mit dem deaktivierten Cache werden existierende Einträge weiterhin genutzt. (In Tabelle 11-5, in der Zeile für CD=1, NW=1: "Read hits access the cache; read misses do not cause replacement.")

Wieso muss ich den Cache flushen, wenn die Instruktionen sowieso erst später ausgeführt werden (also nachdem ich den Cache deaktiviert habe)?

Außerdem finde ich die Verwendung der BTC-Instruktion etwas seltsam. Das kehrt ja nur das Bit um. Ein Bit setzen kannst du damit nicht, wenn es vorher schon gesetzt war.

Oh, da habe ich wohl die falsche Instruktion erwischt. Das sollte natürlich btr heissen.

Danke fürs Ausprobieren . Gab es irgendwelche Fehler?
Mit welchen Spezifikationen hast du mein OS getestet? Danke auch für deinen "Fehlerreport" (das mit dem btc).

[Jidder]

Also bei mir steht nach dem Booten CR0=80000013. Also sind bei mir die Bits für Cache disable und No Write-Through gelöscht.
Das heisst bei mir wird der Cache aktiviert.

Mit dem BTC als Instruktion? Dann wäre das sehr seltsam, weil das ja hieße, dass vorher der Cache tatsächlich deaktiviert war. <rhetorisch>Warum sollte das jemand tun?</rhetorisch>

Wieso muss ich den Cache flushen, wenn die Instruktionen sowieso erst später ausgeführt werden (also nachdem ich den Cache deaktiviert habe)?

Ich muss zugeben, dass ich das auch erst gelesen habe, als ich mich über die Funktionsweise von CD informiert habe. Ich vermute, dass durch das setzen von CD die CPU angewiesen wird, nichts mehr in den Cache zu laden. Aber der restliche Mechanismus, der den Cache nutzt bleibt aktiv. Das heißt, die CPU versucht weiterhin den Cache zu benutzen, und wenn sie etwas drin findet, dann nutzt sie es auch. Also würden Daten, die früher einmal in den Cache geladen wurden, auch nach dem deaktivieren weiterhin darin benutzt werden.

Eine Theorie, die ich (ohne entsprechende Belege) hätte, ist, dass dieses Flag eher dafür gedacht ist, bei Multiprozessorsystemen das Verhalten der CPUs untereinander zu steuern, und nicht wirklich für den Ein-Prozessor-System-Fall gedacht ist. Das Flushen hätte dann den Sinn, dass alle Prozessoren nach dem Deaktivieren des Caches dieselbe Sicht hätten (nämlich eine, die nicht durch die eigenen Caches beeinflusst wird).

Danke fürs Ausprobieren . Gab es irgendwelche Fehler?
Mit welchen Spezifikationen hast du mein OS getestet? Danke auch für deinen "Fehlerreport" (das mit dem btc).

Ich hab da nicht viel getestet. Das war ein Qemu 1.1.2 unter Debian, dem ich einfach deine ISO mitgegeben habe.

[OsDevNewbie]

Mit dem BTC als Instruktion? Dann wäre das sehr seltsam, weil das ja hieße, dass vorher der Cache tatsächlich deaktiviert war. <rhetorisch>Warum sollte das jemand tun?</rhetorisch>

Also bei ist das halt unter Bochs so. Vielleicht macht das nur Bochs so.

Ich hab da nicht viel getestet. Das war ein Qemu 1.1.2 unter Debian, dem ich einfach deine ISO mitgegeben habe.

Und wieviel RAM hast du der virtuellen Maschine zugewiesen?

[Jidder]

Und wieviel RAM hast du der virtuellen Maschine zugewiesen?

Keine Ahnung, den Standardwert. Vermutlich 128 MB.

[kevin]

Ich habe mich gewundert, wie in aller Welt du es schaffst, deinen Kernel 1,4 MB groß zu machen, wenn das OS doch nur eine kleine Shell drin hat, die nicht viel kann. Zum Vergleich, mein Kernel hat 304k (ohne Debugsymbole 112k) und hat wahrscheinlich etwas mehr Funktionalität.

Das entscheidende Problem bei dir scheint folgendes zu sein:

Code: [Auswählen]

.section .rodata
.space 0x100000 #1MB Platz für den Kernelstack
stack:Du hast also ein MB Nullen in deiner Binary. Der Stack hat sowieso nichts in .rodata zu suchen, besonders read-only ist der ja nicht. Der initiale Stack gehört nach .bss und dann werden die Nullen auch nicht explizit in die Binary geschrieben. Ein MB ist auch wesentlich mehr als man braucht (vor allem dafür, dass der Stack vermutlich sowieso nur zu Initialisierung verwendet wird), üblich sind eher 4-16k.

[OsDevNewbie]

Ich habe mich gewundert, wie in aller Welt du es schaffst, deinen Kernel 1,4 MB groß zu machen, wenn das OS doch nur eine kleine Shell drin hat, die nicht viel kann. Zum Vergleich, mein Kernel hat 304k (ohne Debugsymbole 112k) und hat wahrscheinlich etwas mehr Funktionalität.

Also die Shell ist ein separates Programm, welches von der CD geladen wird. Mein Plan ist als erstes Programm dann so ein Init Programm auszuführen (wie bei Linux), welches dann die restlichen Programme startet (darunter unter anderem die Shell).

Ein MB ist auch wesentlich mehr als man braucht (vor allem dafür, dass der Stack vermutlich sowieso nur zu Initialisierung verwendet wird), üblich sind eher 4-16k.

Ja ich weiss, mein Stack ist ein bisschen übertrieben gross. Zu Beginn dachte ich halt lieber zu viel Stack als zu wenig. Ich wusste ja noch nicht, wieviel Stack mein Kernel benötigen würde.

Du hast also ein MB Nullen in deiner Binary. Der Stack hat sowieso nichts in .rodata zu suchen, besonders read-only ist der ja nicht. Der initiale Stack gehört nach .bss und dann werden die Nullen auch nicht explizit in die Binary geschrieben.

Achso stimmt ja in bss werden die nullen ja nicht ins Binary geschrieben. Sollte ich mal ändern.
Danke für deine Rückmeldung(en).

Noch eine Frage habe ich: Gibt es eine Möglichkeit herauszufinden, wieviel Stack maximal verwendet wird?

[Svenska]

Du kannst den Stack mit einem Bitmuster, z.B. 0x55aa füllen.
Wenn du dann irgendwann reinguckst, siehst du, bis zu welcher Stelle dieses Muster noch da ist und ab wo es überschrieben wurde.