Thema: Was macht eigentlich (m)ein kernel?

[NoeTrimm]

Ws macht eigentlich (m)ein kernel? ist eine Frage die mir nun zum ersten mal in den Kopf schießt.
Als ich Anfing mit OS-Dev dachte ich es wäre klar. Er reagiert auf interrupts, bietet eine shell zum interaggieren(dazu muss gesagt sein das ich noch lange nicht an graka-modi denke, dahe rnur shell mit farbe ).
Mittlerweile hat sich mein Bild vom kernel geändert (gott sei dank)...
Aber vieles ist mir noch unklar:

Ich beziehe mcih hierbei auf Tee-Jays Tutorial zum c-Kernel.

Also ich möchte meinen Kernel wo es eben möglich ist mit C schreiben.
Daher habe ich nun den Bootloader von tee-Jay genommen, der meine Kernel.bin in den Arbeitspeicher läd.
Nun beginnt die tolle Fragestunde: What can I do for you?

Der Kernel hat nach meinem Verständnis die Aufgabe:

a. in den PM zu schalten (ja. Stichwort Grub. aber nein.)
b. GDT, IDT zu erstellen und zu laden
c. Treiber zu laden (in meinem Fall lediglich für die Tastatur)
d. Tasks zu verwalten (hab noch keine ahnung wie das geht, aber tutorial ist schon gefunden)
e. printk()
f. Fehlerroutinen bereitstellen auf die die diskriptoren Zeigen (ich hoffe das ich das nun richtig kapiert habe)
g. mein programm shell laden und damit den Benutzer mit einbinden.

Soweit korrekt?

Was muss noch alles rein? Ich mein das kann ja bei weitem nicht alles sein, auch wenn mich mindestens die hälfte derzeit noch überfordert.

Auch die logische Vorgehensweise beim Programmieren. Hab mir zwar die kleine einleitung für den Os-Dev-Newbie durchgelesen, aber besonders eindeutig finde ich sie nicht. Oben wird zwar von einem C-Kernel gesprochen aber weiter unten ist  das garnicht mehr zu wort gekommen.
Egal.
Stell ich mich jetzt einfach zu blöd an im Verständnis? Ich mein, ich hab dank dem low level Magazin meine ersten schritte im realmode gehen können. bootloader schreiben, kernel laden und zack stand die message aufm bildschirm. Dann kam die Frage wie weiter?!
Ich hab jetzt das Protected Mode tut, das c-kernel tut, Bootloader tut, PIC tut, ect. schon durch (mehr als einmal) und kann aber einfahc keinen Anfang finden. Hab keine Struktur.

Anders ausgedrückt ich brauch Hilfe, sonst platzt mein kopf noch von dem ganzen hinundher.

[blitzmaster]

Der Kernel hat nach meinem Verständnis die Aufgabe:

a. in den PM zu schalten (ja. Stichwort Grub. aber nein.)

Ich würde das eher in den Bootloader geben. Denn solltest du deinen Kernel einmal Multiboot-fähig machen (um z.B. Grub zu verwenden  ) dann wird im Bootloader schon in den PM geschalten.

b. GDT, IDT zu erstellen und zu laden
c. Treiber zu laden (in meinem Fall lediglich für die Tastatur)

Das ist die Startroutine des Kernels. Hier werden die Kernelfunktionen initialisiert.

d. Tasks zu verwalten (hab noch keine ahnung wie das geht, aber tutorial ist schon gefunden)

Und da wären wir schon bei den (meiner Meinung nach) Grundaufgaben eines Kernels:

• Multitasking
• Speicherverwaltung: Jeder Prozess möchte seinen eigenen Speicherbereich haben, wo nur er zugriff hat. Ich empfehle auch den Kernelspeicher dynamisch zu verwalten. Das Stichwort hier ist Paging.
• Hardware verwalten: Nicht jedes Programm braucht vollen Zugriff auf die ganze Hardware, den soll es auch nicht haben. Also hat nur der Kernel absolute Herrschaft über die HW und die Treiber müssen sich halt um Zugriff zu erlangen i-wie beim Kernel registrieren.
• IPC: Interprozesskommunikation: Die Programme wollen untereinander reden, das tun sie über Kernel-Funktionen. (siehe weiter unten, Shell)

e. printk()

Das gehört nicht in den Kernel. Die direkte Grafikausgabe gehört in einen Grafik-Treiber.

f. Fehlerroutinen bereitstellen auf die die diskriptoren Zeigen (ich hoffe das ich das nun richtig kapiert habe)

Du meinst exceptions? Ja, das gehört auf jeden Fall auch in den Kernel.

g. mein programm shell laden und damit den Benutzer mit einbinden.

Am Anfang muss der Kenel natürlich ein Programm laden. Ob das jetzt direkt die Shell ist oder ein Init-Prozess der vl. noch weitere aufgaben hat ist denke ich Design-Sache. Auf jeden Fall soll die Shell nur durch IPC mit dem Tastatur- und Grafiktreiber kommunizieren, also nicht direkt auf die HW zugreiffen. (darf sie, wenn alles richtig geht auch nicht)

[NoeTrimm]

Ich würde das eher in den Bootloader geben. Denn solltest du deinen Kernel einmal Multiboot-fähig machen (um z.B. Grub zu verwenden  ) dann wird im Bootloader schon in den PM geschalten.

Das Thema Multiboot-fähig schieb ich wegen relevanz nach hinten

Das ist die Startroutine des Kernels. Hier werden die Kernelfunktionen initialisiert.

Meinst du damit die, die du als Grundaufgaben deklariert hast oder was für Funktionen?

Und da wären wir schon bei den (meiner Meinung nach) Grundaufgaben eines Kernels:

• Multitasking
• Speicherverwaltung: Jeder Prozess möchte seinen eigenen Speicherbereich haben, wo nur er zugriff hat. Ich empfehle auch den Kernelspeicher dynamisch zu verwalten. Das Stichwort hier ist Paging.
• Hardware verwalten: Nicht jedes Programm braucht vollen Zugriff auf die ganze Hardware, den soll es auch nicht haben. Also hat nur der Kernel absolute Herrschaft über die HW und die Treiber müssen sich halt um Zugriff zu erlangen i-wie beim Kernel registrieren.
• IPC: Interprozesskommunikation: Die Programme wollen untereinander reden, das tun sie über Kernel-Funktionen. (siehe weiter unten, Shell)

Inwiefern müssen sich treiber registrieren? Sie fangen doch lediglich interrupts auf und weisen den kernel darauf hin. oder wie, oder was?
And what the f*** is a IPC? Hab ich´bisher noch garnix von gehört, aber gut zu wissen das man es braucht. was es tun soll is auch klar, aber nicht wie?!

Das gehört nicht in den Kernel. Die direkte Grafikausgabe gehört in einen Grafik-Treiber.

selbst für die ausgabe eines einfachen Strings, von mir aus lademessage brauch ich nen grafik-Treiber? Na holla. Also ich habs bisher zwar immer im kernel gelassen, aber kann mir schon vorstellen das sich das besser anbietet über nen treiber zu machen.
Aber da tuen sich bei mir schon wieder ein schwall von fragen auf. in welchem dateiformat muss ich treiber abspeichern.? wie lad ich sie? was muss drin stehen? wie funzt die kommunikation zwischen kernel und treiber? (Jetzt auf alles ne antwort zu verlangen wäre ein wenig dreist, aber das sind fragen die mir dann kommen.

Du meinst exceptions? Ja, das gehört auf jeden Fall auch in den Kernel.

Jupp. Die meinte ich. Auch eines der wenigen dinge die ich glaube ich bisher verstanden habe.

Am Anfang muss der Kenel natürlich ein Programm laden. Ob das jetzt direkt die Shell ist oder ein Init-Prozess der vl. noch weitere aufgaben hat ist denke ich Design-Sache. Auf jeden Fall soll die Shell nur durch IPC mit dem Tastatur- und Grafiktreiber kommunizieren, also nicht direkt auf die HW zugreiffen. (darf sie, wenn alles richtig geht auch nicht)

Ab satz zwei komm ich nciht mit. also ich versteh schon was da steht, aber das mit der kommunikation versteh ich nich, wie oben schon erwähnt...
Fragen kommen dann zur treiber geschichte hinzu: Wie kommunizieren die Progs mit den treibern? sagen die den treibern mach das und sie tuns? wenn ja wo bleibt die kontrolle durch die Kernel?...usw.


Ja ich weiß. Viele, viele Fragen und wenig klarheit. Ich versuchs ja. Lese dokumentationen, die tutorials rauf und runter, aber mir fehlen einfach noch enorm viele bindeglieder um den gesamten apperat von treiber, kernel und progs zu vertsehen... 

Aber aufgeben kommt nicht in Frage...schließlich ist jetzt we. und damit viel zeit dafür...

[blitzmaster]

Die meisten deiner Fragen laufen wohl auf das Thema IPC (Inter process communication) also der Interprozesskommunikation. Wie gesagt und von dir gefragt müssen die Programme eben mit den Treibern kommunizieren. Das könnte z.B. so ähnlich sein wie E-Mails: es gibt z.b. eine funktion SendMessage(). Dort wird die Nachricht (pointer zur Nachricht) übergeben und die Prozess-Nummer (PID, eindeutige Nummer die jeden Prozess identifiziert). Die funktione SendMessage() springt dann in den Kernel der dann die Nachricht an den richtigen Prozess weiterleitet.
Nützliche Links hierzu:

• http://lowlevel.brainsware.org/wiki/index.php/IPC
• http://lowlevel.brainsware.org/wiki/index.php/Protected_Mode#Call_Gates - Wie SendMessage() in den Kernel springt

So.

Meinst du damit die, die du als Grundaufgaben deklariert hast oder was für Funktionen?

Ja. Hier wird z.B. die IDT, die GDT initialisiert, hier werden die Treiber geladen (oder auch nur der Init-Prozess),...

Inwiefern müssen sich treiber registrieren? Sie fangen doch lediglich interrupts auf und weisen den kernel darauf hin. oder wie, oder was?

Naja ich habe es so gemeint: Mit der HW kommuniziert man über die Ports. Die sollten aber nicht für jedes Programm frei zugänglich sein, sondern nur für Treiber. Und ein Treiber braucht auch nicht Zugriff auf jeden Port. Beispiel:
Ein Treiber braucht zugriff auf den Port 0x34. Also fordert er dies vom Kernel:

Code: [Auswählen]

ReservePort(0x34);
// Dann kann er darauf zugreifen
data = ReadPort(0x34); // heißt üblicherweise InB();
WritePort(0x34, data); // heißt üblicherweise OutB();
Der Kernel kann so dafür sorgen dass immer nur ein Treiber auf einen Port zugreift und dass nicht jedes Programm auf alles Zugreifen kann.

selbst für die ausgabe eines einfachen Strings, von mir aus lademessage brauch ich nen grafik-Treiber? Na holla. Also ich habs bisher zwar immer im kernel gelassen, aber kann mir schon vorstellen das sich das besser anbietet über nen treiber zu machen.
Aber da tuen sich bei mir schon wieder ein schwall von fragen auf. in welchem dateiformat muss ich treiber abspeichern.? wie lad ich sie? was muss drin stehen? wie funzt die kommunikation zwischen kernel und treiber? (Jetzt auf alles ne antwort zu verlangen wäre ein wenig dreist, aber das sind fragen die mir dann kommen.

Kommunikation: IPC, wie oben beschrieben. Dateiformat: Egal, wie du willst. Drinnen muss sein was der Treiber halt mahct, also meistens verschiedene Funktionen.

Aber für den Anfang empfehle ich dir noch nicht Sorgen zu machen wie du z.B. deine Treiber lädst. Ich würde die ersten Schritte so angehen(Reihenfolge)

• Startroutine des Kernels (also grundlegende HW initalisieren)
• Speicherverwaltung Kernel
• Speicherverwaltung User bzw. Multitasking
• IPC

Natürlich ist das ganze komplex, aber ich glaube jeder weiß, dass OS-Programmierung halt nicht was ist, was man an einem Nachmittag erlernt sonder ein andauernder Prozess vieler Jahre und viel Erfahrungssammeln ist. 

[NoeTrimm]

Vielen Dank für deine ausführliche erklärung.

Vorallem die IPC ist recht interessant und das du mir gleich die verbindung über die call gates audgezeigt hast, denn die hab ich im protected mode tutorial kennengelernt. jetzt macht das ganze langsam sinn, bzw. erschließt sich so langsam.

Werd mich mal an den kleinen fahrplan von dir halten. wobei eine Frage dabei aufkommt:
 Du sagt Startroutine des kernels (HW initialisieren)
---> sind das nicht die Treiber die geladen werden oder was meinst du damit?

[bluecode]

Du sagt Startroutine des kernels (HW initialisieren)
---> sind das nicht die Treiber die geladen werden oder was meinst du damit?

Ich nehme mal an er meint da eine Art main()-Funktion, welche nacheinander die verschiedenen Kernelteile initialisiert, da manche Sachen eben darauf aufbauen, dass andere bereits initialisiert sind. Deshalb fängt man am besten bei den "lowlevel Prozessorsachen" an, wie: GDT, IDT, Paging. Darauf aufbauend kann man dann zB virtuelle & physische Speicherverwaltung initialisieren. Dann könnte man
a) [Microkernel]: die Treiber (die zB als Grub-Module geladen wurden) & init als elf/PE (oä. Dateiformat) laden und in einem eigenen Prozess (Ring 3) ausführen. Die Treiber holen sich beötigte I/O Ports und physische Speicherbereiche beim Kernel, d.h. der Kernel erlaubt den Treibern Zugriff auf bestimmte I/O- bzw. Speicherbereiche. Init kümmert sich dann über IPC daram, dass zB der ext2-Dateisystemtreiber auf den Datenträger zugreift und beim VFS eingehängt wird.
b) [Monolithischer Kernel]: die Treiber welche in den Kernel gelinkt wurden werden initialisiert. Die haben direkt Zugriff auf Speicherbereiche & I/O Ports, da sie in Ring 0 laufen. Treiber können direkt Funktionen von anderen Treibern aufrufen (ohne IPC).

Natürlich sind alle Möglichkeiten zwischen Microkernel & monolithischer Kernel möglich (und auch noch andere extremere: zB Exokernel). Soll heißen, es könnten teilweise Treiber im Kernel sein (zB. für die Basishardware, zB PIC, PIT, CMOS, ...), teilweise als Prozess. Oder auch ladbare Module (-> Linux)...
Außerdem ist das eher eine Möglichkeit wie man das machen kann, OSDev zeichnet sich ja dadurch aus, dass es extrem viele Freiheiten bietet, was das Design angeht

Ich hoffe, dass ich helfen konnte

btw. Herzlich willkommen, schön das du den Weg hierher gefunden hast

[kevin]

Das Thema Multiboot-fähig schieb ich wegen relevanz nach hinten

Naja, für den Benutzer ist es natürlich auch relevant, einen Bootloader für alle Systeme zu haben.

Aber in erster Linie ist es für dich selbst relevant! Wenn ich mich recht erinnere, möchtest du einen Microkernel schreiben. Das heißt vor allem, daß dein Kernel weder einen Plattentreiber haben noch mit Dateisystemen umgehen können wird. Und das wiederum heißt, daß dein Bootloader schonmal ein paar für den Bootvorgang wichtige Programme/Treiber (bei einem Microkernel ist das vom Konzept her dasselbe) laden muß.

Mit GRUB bekommst du das geschenkt. Wenn du es selbst machen willst, viel Spaß. So ein Bootloader ist ein halbes OS für sich.

(Ach, und noch ein Rat: Schlag unsere Empfehlungen nicht ohne echten Grund in den Wind. In den meisten Fällen wissen wir, warum wir etwas so und nicht anders vorschlagen. Du könntest es dir sonst an einigen Stellen deutlich schwerer machen als nötig.)

Das [printk] gehört nicht in den Kernel. Die direkte Grafikausgabe gehört in einen Grafik-Treiber.

Wohin soll ein printk denn sonst gehören? Die einzgie Alternative wäre, im Kernel auf Textausgaben komplett zu verzichten. Allerdings wäre es doch ganz nett, im Fall eines Panic o.ä. eine Meldung auf den Bildschirm zu schreiben, bevor man sich verabschiedet...

Aber da tuen sich bei mir schon wieder ein schwall von fragen auf. in welchem dateiformat muss ich treiber abspeichern.? wie lad ich sie? was muss drin stehen?

Letztendlich ist es alles nur Maschinencode. Den mußt du vereinfacht gesagt irgendwoher in den Speicher laden (oder vom Bootloader laden lassen) und anschließend dorthin springen. Es bietet sich an, ein Binärformat wie ELF dafür zu nehmen, aber theoretisch kannst du machen, was du willst. (Belasse es bei der Theorie und nimm ELF )

wie funzt die kommunikation zwischen kernel und treiber? (Jetzt auf alles ne antwort zu verlangen wäre ein wenig dreist, aber das sind fragen die mir dann kommen.

Im allgemeinen über die ganz normale Syscall-Schnittstelle.

Wie kommunizieren die Progs mit den treibern? sagen die den treibern mach das und sie tuns? wenn ja wo bleibt die kontrolle durch die Kernel?...usw.

Was sollte der Kernel denn kontrollieren? Die Treiber haben bestimmte Rechte bekommen und daß sie die einhalten, dafür sorgt der Prozessor (Stichwort sind z.B. Speicherschutz oder IO-Bitmap). Der Kernel ist nur dafür zuständig, diese Rechte zu vergeben.

Lese dokumentationen, die tutorials rauf und runter, aber mir fehlen einfach noch enorm viele bindeglieder um den gesamten apperat von treiber, kernel und progs zu vertsehen... 

Fang einfach an, Code zu schreiben. Mit der Zeit und wahrscheinlich auch nach der einen oder anderen Sackgasse ergibt das alles Sinn.

[NoeTrimm]

Vielen Dank für die Ausgiebige Antwort.

Also, Stichwort Bootloader:

GRUB wird ja fast überall empfohlen, das stimmt schon. Was ich jedoch nicht verstehe wieso bei einem Microkernel der Bootloader die wichtigsten Treiber und Progs starten muss. Warum kann ich dieses nicht er initialisierungsphase des Kernels überlasses. Soweit ich das Microkernelsystem verstanden habe macht es doch keinen Unterschied, oder? Die treiber liegen ausgelagert und ich lad sie über funktionen im kernel in den Arbeitsspeicher.
Was mir bei GRUB auch noch sorgen macht ist die sache das dort gdt und idt schon erstellt sind. Ich bin froh das ich langsam durch das Protected Mode tut verstehe wie man hinein kommt und die tables läd. Wenn ich jetzt überlege diese ändern zu müssen, bringt mich das ein wenig durcheinander.

Nochmal zu kprint():
Nehmen wir an ich bin im protected Mode und mein c-Kernel ist im speicher geladen und der sprung zur main() hat stattgefunden. Ich würde dann ne Funktion schreiben, der man einen string übergibt und welche dann diesen in den Videospeicher schreibt. Nehme an das ich sie dann noch inne Header  stecke, aber im Prinzip als teil des Kernels. Wäre das dann diese besagte kprint()? Wenn ja, wozu dann ein Grafiktreiber, wenn ich in meiner Kwernel eine Funktion dafür schon fertig habe? kann ja ein Call gate für Prog PL 3 einrichten die dann dadurch darauf zugreifen können?!

Zu ELF:
Hab mir schon mal die englische Doku zu ELF durchgelesen, aber ganz ehrlich, hab nur bahnhof verstanden. Reichen im prinzip auch einfach *.bin dateien aus? Und was mir dazu auch noch einfällt: unterscheide ich zwischen treibern und programmen, indem ich ihnen einen anderen header gebe?

Zur kommunikation:
Vieles steht ja im protected Mode Tutorial. einträge gdt, idt. denke mal das du das damit meinst und auf die privileglevel anspielst?!

Einfach anfangen Code zu schreiben?
Na aber logisch  bin schon dabei. Wie gesagt, hab ja den bootloader(vorerst, wenn ich das mit dem microkernel modulen, ect. verstehe wirds sicher grub) von tee-jay und mein kernel springt innen protected mode, jedoch war das bis dahin nur scriptkiddy like. kurz gesagt: nicht sehr befriedigend für mich. aber da ich bis gestern nacht die erstellung von gdt, idt, ldt, tss, gates, task usw nicht verstanden habe musste das sein um ne grundlage zu schaffen. Von da an hab ich erstmal meinen c-kernel mit ner ausgabe funktion ausgestattet, wie oben erwähnt. Gerade versuche ich mich daran im init-prozess einfach mal mit ein paar funktionen rumzuspielen. Dafür gibts ja nette sachen im resource center, wie speichergröße ermitteln und co. Einziges Prob: alles in Assembler. Und da ist noch eines meiner größten probleme. Als ich damals c schrieb habe ich wenig mit pointern und co arbeiten müssen, jetzt ist es die grundlage  Aber genau diese Funktionen in c zu schreiben sehe ich als erste herausforderung. Bloß diese ganze addressierung, naja. muss ich durch...

[MNemo]

GRUB wird ja fast überall empfohlen, das stimmt schon. Was ich jedoch nicht verstehe wieso bei einem Microkernel der Bootloader die wichtigsten Treiber und Progs starten muss. Warum kann ich dieses nicht er initialisierungsphase des Kernels überlasses. Soweit ich das Microkernelsystem verstanden habe macht es doch keinen Unterschied, oder? Die treiber liegen ausgelagert und ich lad sie über funktionen im kernel in den Arbeitsspeicher.

Es ist so, dass ein Microkernel für gewöhnlich keine Funktionen hat, mit denen es z.B. auf die Festplatte zugreifen kann.  Es ist also darauf angewiesen, dass zumindest der Festplatten-Treiber schon vom Bootloader in den RAM geladen wird, damit es wenigstens die restlichen Treiber "selbständig" laden kann.

[NoeTrimm]

und woher weiß dann GRUB wie meine Treiber heißen, wo sie auf der platte liegen und wohin er die im speicher laden soll?

[bluecode]

Wenn ja, wozu dann ein Grafiktreiber, wenn ich in meiner Kwernel eine Funktion dafür schon fertig habe?

Das war mehr oder weniger mit Grafiktreiber (bzw. Treiber für die Textausgabe) gemeint, denke ich.

kann ja ein Call gate für Prog PL 3 einrichten die dann dadurch darauf zugreifen können?!

Ich glaube nicht wirklich viele Leute benutzten wirklich Callgates. Die meisten nehmen Interrupts.

Reichen im prinzip auch einfach *.bin dateien aus?

Das klingt jetzt d00f, aber: Es reicht das, was du meinst das reicht. Es ist dein OS schließlich.
Aber reine .bins werden nicht reichen, da du wissen solltest wo der Startpunkt deiner Applikation ist, wo groß das BSS (uninitialisiertes Datensegment), wo/wie groß Daten-/Codesegment sind (um die Rechte beim Paging richtig zu setzten) sind, etc... Aber elf ist garnicht so schwer, wenn man den ganzen Mist den man noch nicht braucht erstmal rauslässt. Primär musst du um eine ausführbare Datei zu laden nur die ELF Header durchgehen, überprüfen, dass die Felder dort korrekt sind und anschließend durch die Programmsegmente (nicht die Sections!) durchgehen und diese an die dort angegebene Stelle in den Adressraum des zu erstellenden Prozesses mappen (d.h. dort in den Adressraum einblenden, siehe auch Paging, falls dir das jetzt noch nicht wirklich was sagt). Danach kannst du eigentlich schon beginnen den Code am Einsprungpunkt (steht auch in der ELF Header) auszuführen.
Ich hab jetzt nicht in den ELF docs nachgeschaut, aber wenn da konkrete Probleme auftauchen einfach einen neuen Thread erstellen und dann konkret nachfragen.

Und was mir dazu auch noch einfällt: unterscheide ich zwischen treibern und programmen, indem ich ihnen einen anderen header gebe?

Das kannst du machen wie du willst Ich habs in lightOS so gemacht, dass der der das die Datei startet angeben muss ob es ein Treiber oder Programm ist (Die von Grub geladenen Module wurden automatisch als Treiber gestartet). Das ist vielleicht nicht glorreich, aber es reicht für den Anfang. Man könnte auch init eine Liste von Treibernamen in den Kernel laden lassen und den Kernel dann immer überprüfen lassen, ob das nun ein Treiber sein soll oder ein Programm (anhand des Dateinamens). Man könnte da auch noch feiner festlegen welche Treiber zugriff auf welche Ressourcen haben sollen, ohne den Aufwand zu betreiben bei jedem Linken die ELF/PE sections manuell zu verändern.

Vieles steht ja im protected Mode Tutorial. einträge gdt, idt. denke mal das du das damit meinst und auf die privileglevel anspielst?!

Nicht nur. Abgesehen vom CPL kann man noch in der I/O Bitmap des TSS angeben, auf welche I/O Ports ein Prozess zugriff hat. Außerdem kann man über Paging bestimmte Speicherseiten als Read-only, read-write, non-executable (und noch ein paar weitere Flags) markieren und damit den Zugriff weiter einschränken. Noch ein Wort zu Paging: Dabei wird ein komplett neuer Adressraum eingeführt: Der virtuelle Adressraum. Alles was ein Programm macht bezieht sich dann immer auf den virtuellen Adressraum. Der Kernel ist dann dafür zuständig den richtigen physischen Speicher (mit den entsprechenden Zugriffsrechten) in den virtuellen Speicher "einzublenden"/mappen.

Dafür gibts ja nette sachen im resource center, wie speichergröße ermitteln und co.

Tipp: Schau dir an was Grub für dich machen kann. Du kriegst über grub einen Zeiger auf eine Struktur die schon einiges an Informationen für dich hat, siehe auch Multiboot Specification (Kapitel 3.3 Boot information format)
Das manuelle Testen der Speichergröße in dem man Werte in den Speicher schreibt und wieder zurückliest ist nämlich nicht sehr zuverlässt, da:
* Löcher im physischen Adressraum sein können (meisten zwischen 15-16MB und ~3-4GB)
* Man nicht unbedingt in den physischen Speicher gemappte Geräte (PCI/ISA) durcheinanderbringen möchte
* Man nicht unbedingt wichtige Systemtabellen (SMP/ACPI/APM/SMBIOS, etc.. Tabellen) überschreiben möchte

[bluecode]

und woher weiß dann GRUB wie meine Treiber heißen, wo sie auf der platte liegen und wohin er die im speicher laden soll?

Das sagst du grub in deinem Eintrag in der menu.lst (Der Liste der bootbaren Betriebssystem). Die kann zB so aussehen.

[NoeTrimm]

Ein kleiner Abriss:

Ich habe mich zur Einführung die ganze Zeit an TeeJays Tutorials geklammert, aber mittlerweile scheint es so als bringe mir das garnix.
Ich sollte GRUB benutzen? Ok. dann mach ich das. Hab auch verstanden wieso das besser...A20 gate ist aktiviert, Protected Mode ist aktiviert, multiboot, ect.

So. Schön. Aber ich nun hab ich keinen Ansatz mehr. 
Was aber nciht heißt das ich aufgebe 

Ich aber keine Ahnug wie und wo ich nun anfangen soll. Wie mein Kernel gestrickt sein muss, wie ich die gdt, idt ändere und so weiter.
Zu Paging hab ich was gelesen, aber nur Bahnhof verstanden. und das schlimmste ist (so empfinde ich es), ist das ich nicht weiß welche Fragen ich stellen kann, da nicht mal weiß wie ich nun beginne. Und ohne Fragen keine Antworten.

Ich hoffe ihr versteht mein dilemmer!?

[kevin]

Ich aber keine Ahnug wie und wo ich nun anfangen soll. Wie mein Kernel gestrickt sein muss, wie ich die gdt, idt ändere und so weiter.

Dein Kernel sieht vom Konzept her genauso aus, wie er bisher auch ausgesehen hätte, nur eben ohne deinen eigenen Bootloader. In Sachen GDT und IDT ändert sich überhaupt nichts.

[NoeTrimm]

Das heißt ich habe also weiterhin meinen c-kernel, der sagen wir mal ganz einfach nur aus der void main() besteht, die zb. eine Message ausgibt, indem sie diese in den videospeicher schreibt?


EDIT: Manchmal glaub ich, bin ich einfach blind, blöd und durcheinander zur gleichen Zeit.

Steht ja alles im Wiki unter C- Kernel mit grub...

Schmerz lass nach! Ich probiere das mal aus gucke mein Monitor mich mit ner message begrüßt. wenn ja, dann freu ich mich und frage mal wieder nervig was zur gdt und idt 
oder falls nicht, probier ichs nochmal

[NoeTrimm]

Da bin ich wieder  (klingt wie ne Drohung oder?)


Ähm ja. Also ich hab mal alles abgetippt ausm wiki c-kernel mir grub ums zu testen obs klappt. Naja was soll ich sagen: gcc meckert.

also Quelltext sieht genauso wie der im wiki aus.

aber gcc meint:

Code: [Auswählen]

kanasaru@gabriella:~/Desktop/Sempra$  gcc -ffreestanding -o kernel_c.o -c kernel_c.c -Wall -Werror -nostdlib -nostartfiles -nodefaultlibs
kernel_c.c: In Funktion »main«:
kernel_c.c:18: Fehler: »true« nicht deklariert (erste Benutzung in dieser Funktion)
kernel_c.c:18: Fehler: (Jeder nicht deklarierte Bezeichner wird nur einmal aufgeführt
kernel_c.c:18: Fehler: für jede Funktion in der er auftritt.)
kernel_c.c:20:2: Fehler: Kein Newline am Dateiende

Aber der Quelltext scheint mir fehlerfrei. Ich denke soviel versteh ich dann schon vonc 

[bluecode]

Ein

Code: [Auswählen]

#define true 1
#define false 0
am Anfang sollte das Problem beheben. Und natürlich eine Leerzeile am Ende der Sourcecodedatein

[NoeTrimm]

*lol* ich bin so doof. aber schön wenn man über seine eigene blödheit noch lachen kann.

die newline hatte ich zwar auch schon eingefügt, aber an #define hab ich garnicht gedacht. war so auf die BOOL werte getrimmt, das mir das garnicht aufgefallen ist. Keine ahnung was ich gedacht habe...

naja. thanks for stupping me in the haufen mist i've verzapfing

[kevin]

Im Tut steht dort doch gar kein true.

[bluecode]

*lol* ich bin so doof. aber schön wenn man über seine eigene blödheit noch lachen kann.

Es ist noch kein Meister vom Himmel gefallen.

*rofl* taljeth