Lowlevel
Lowlevel => OS-Design => Thema gestartet von: ChristianF am 14. May 2008, 18:39
-
Hi
Ich bin gerade am restrukturieren meines Quellcodes.
Da drängt sich mir nun die Frage auf, was wenn der Kernel auch auf einem Mac laufen soll (ist nicht geplant, kann aber durchaus sein).
Daher habe ich mir das Tutorial über die HAL durchgelesen und bin zu folgendem Ergebnis gekommen:
HAL - Hardware Abstraction Layer
* Portzugriffe
* typedef Variablen und Definitionen
# Größe einer Page
# Größe word, dword, qword, ...
* Global Descriptor Table (GDT)
* Interrupt Description Table (IDT)
* Interrupt Service Routines (ISRs)
* Interrupt Requests (IRQs)
* Programmable Interval Timer (PIT) /*wurde allerdings vorerst aus dem Kernel entfernt*/
GDT, IDT, ISRs, IRQs und die PIT habe ich deswegen bei der HAL dazugeschrieben, weil die sich ja je nach CPU unterscheiden (vllt. habe ich auch was falsch verstanden)
Ist das so komplett? Muss noch was dazu, oder ist da was überflüssig?
Gruß Christian
-
Moin
kleine gemeinheit am rande, was für einen Mac meinst du? die neuen oder etwa die alten? (G5 und G4 Modelle sind nicht von intel die neuen schon somit würden sie laufen, wenn die sache mit dem nichvorhandensein eines BIOS nicht währe. Glaub EFL heist das ding)
Als ergänzung
Alles was in ASM geschrieben ist.
-
(G5 und G4 Modelle sind nicht von intel die neuen schon somit würden sie laufen, wenn die sache mit dem nichvorhandensein eines BIOS nicht währe. Glaub EFL heist das ding)
EFI heißt es.
-
Einige Funktionen für die virtuelle Speicherverwaltung (Page mappen, Page unmappen, Zugriffsrechte setzen) sind auch stark platformabhängig. Eventuell möchtest du auch ACPI etc. direkt im Kernel implementieren, wobei man das durchaus als Treiber auslagern könnte.
-
Mein Ziel ist es ein Microkernel.
Wo ja alles als Treiber geladen wird.
@Termite
ich meine nicht Intel basierte Macs, also die mit einem PowerPC Prozessor.
@Korona
Da ich ja versuche einen Microkernel zu entwickeln, werde ich in den Kernel nur Grundlegendes einbauen und so Sachen wie ACPI oder z.B. Disketten-/Festplattenzugriff in Treiber auslagern.
Ich habe nun die Liste um den Paging Code wie folgt erweitert:
HAL - Hardware Abstraction Layer
* Portzugriffe
* typedef Variablen und Definitionen
# Größe einer Page
# Größe word, dword, qword
* Global Descriptor Table (GDT)
* Interrupt Description Table (IDT)
* Interrupt Service Routines (ISRs)
* Interrupt Requests (IRQs)
* Programmable Interval Timer (PIT) /*wurde allerdings vorerst aus dem Kernel entfernt*/
* Paging Code
Multitasking denke ich gehört da nicht rein, da ich Softwarebasiertes Multitasking einsetzen möchte.
Was die Interprozesskommunikation (IPC) angeht, kann ich noch nichts dazu sagen, da ich mich damit bis jetzt noch nicht beschäftigt habe.
Gruß Christian
-
Multitasking (auch Software Multitasking) basiert natürlich schon auf platformspezifischen Funktionen (schließlich müssen die Register ja direkt manipuliert werden), du könntest daher Funktionen wie createThread(pointer entry) oder switchThread(struct thread *nextone) auch in das HAL einbauen.
Was die IPC betrifft sind Funktionen zur Syncronisation von Threads notwending, nützlich wären etwa atomicCompareAndSwap(pointer dest, pointer source, uint value) [für die Implementation von Spinlocks und Semaphores] oder yield() . [eine hlt Instruktion damit der Scheduler die CPU anhalten kann, wärend alle Threads blocken]
-
[...] nützlich wären etwa atomicCompareAndSwap(pointer dest, pointer source, uint value) [für die Implementation von Spinlocks und Semaphores] oder yield().
Nur um das mal gesagt zu haben, gcc bietet tolle builtin Funktionen für atomic ops, siehe gcc manual (http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Atomic-Builtins.html#Atomic-Builtins).
* Portzugriffe
Manche Architekturen haben keinen gesonderten I/O Portbereich, sondern bei denen wird I/O über den "normalen" physischen Adressraum gehandhabt.
# Größe word, dword, qword
1. Was ein {d,q}word ist, ist imho nie wirklich festgelegt worden und jeder versteht was anderes darunter, insofern evtl. unsinnvoll in einem Kernel.
2. Der C standard definiert bereits Typen fester Größe, es ist mitunter sinnvoll (für andere die den Code lesen, aber auch für dich) diese zu verwenden (zumindest den Namen, muss ja nicht in der gleichen Header sein)
* Global Descriptor Table (GDT)
Segmentation hat afaik auch nur der x86. Das ist schon im long-mode praktisch nicht mehr vorhanden. Insofern macht es nicht viel sinn Segmentation extensiv zu benutzen, deshalb würde ich da auch keine Funktionalität zur Veränderung der GDT nach außen präsentieren.
-
* Portzugriffe
Manche Architekturen haben keinen gesonderten I/O Portbereich, sondern bei denen wird I/O über den "normalen" physischen Adressraum gehandhabt.
:-D damit hab ich die letzten 9 monate beruflich zu tun gehabt. Ein ARM ist halt doch ein lustiges spielzeug.
# Größe word, dword, qword
1. Was ein {d,q}word ist, ist imho nie wirklich festgelegt worden und jeder versteht was anderes darunter, insofern evtl. unsinnvoll in einem Kernel.
2. Der C standard definiert bereits Typen fester Größe, es ist mitunter sinnvoll (für andere die den Code lesen, aber auch für dich) diese zu verwenden (zumindest den Namen, muss ja nicht in der gleichen Header sein)
Da muss ich wiedersprechen. es mag zwar definiert sein was ein int, ein short int und ein long int ist, nur hält sich nicht jeder compiler auch wirklich daran. bzw ist es bei int sogar platform abhängig. es gibt in der MISRA nicht umsonst eine Vorschrift, alle typen zu redefinieren. Daher sollten wenn der Code partabel sein soll alle basistypen redefiniert werden. eine anpassung an die platformgegebenheiten ist dann durch änderungen an einer zentralen stelle möglich.
und zu word dword und qword. ein word ist 16 bit gross. und was dann dWord und qWord sind sollte dann klar sein. es gibt sicher geschicktere type definitionen. z.B.
U8 I8 U16 I16 U32 I32
uint8 sint8 uint16 sint16 uint32 sint32
gruss
-
Da muss ich wiedersprechen. es mag zwar definiert sein was ein int, ein short int und ein long int ist, nur hält sich nicht jeder compiler auch wirklich daran. bzw ist es bei int sogar platform abhängig. es gibt in der MISRA nicht umsonst eine Vorschrift, alle typen zu redefinieren. Daher sollten wenn der Code partabel sein soll alle basistypen redefiniert werden. eine anpassung an die platformgegebenheiten ist dann durch änderungen an einer zentralen stelle möglich.
Habt ich dem in irgendeiner Weise widersprochen? Es wär halt manchmal nicht schlecht, wenn man den C Standard (http://en.wikipedia.org/wiki/Stdint.h) auch kennt, bevor man meckert. :mrgreen:
-
Hab doch glatt die andere Hälfte vergessen zu beantworten:
und zu word dword und qword. ein word ist 16 bit gross.
Ach, ist das so? (http://en.wikipedia.org/wiki/Word_(computing))
-
Manche sind eben bei 16-Bit-Prozessoren stehengeblieben. ;)
-
entschuldigung sollte ich dich angegriffen haben.
Ich kenn WORD eigentlich nur aus pascal zeiten. und aus der MSDN und da war es meist 16 bit gross. (wobei MS sicher nicht das mass aller dinge sein sollte)
aus gründen der Portabilität sollten Variablen typen selber definiert werden. Nicht jeder compiler muss sich entsprechend standard verhalten. somit kann da viel stehen, nur wenn es nicht so implementiert ist bringt das recht wenig.
Die von mir erwähnte MISRA regeln schreiben das nicht ohne grund vor.
und die im Standard beschriebenen int32_t setzen wir hier auch ein. nur definieren wir diese selber, damit wir wissen, wie gross die auch wirklich sind.
gruss
-
Das Problem ist ja gerade, dass du nicht weißt wie lang sie "in echt" sind.
int, long etc. können unterschiedlich lang sein. Also kannst du auch über die Länge der von dir neu definierten Typen nichts sicheres aussagen. int32_t, int16_t haben immer die geforderte feste Größe, ansonsten entspricht der verwendete Compiler nicht dem ANSI C Standard.
Woher möchstest du wissen, das dein selbst definierter int32_t auch 32 Bit lang ist? Das kannst du nur mit Sicherheit auf allen Platformen garantieren, wenn du die Typen aus der stdint.h benutzt.
-
Genau ich weiss nicht wie lang sie sind. daher definier ich sie ja selber. Dies ist ein part, der bei der Portierung auf eine andere plattform angepasst werden muss. Wenn meine selbst definierten typen ohne kontrolle auf eine neue platform übernehme, kann ich probleme bekommen. Da sie aber an einer zentralen stelle definiert sind, kann ich recht einfach anpassungen vornehmen.
Ich geb ja zu das dies problem eher auf exotische plattformen zu finden ist. Das beispiel ist sicher nicht representative, aber für den 8051 gibt es zumindest keinen mir bekanten ANSI C Compiler. es ist auch ein MCU und keine CPU, aber quasi industrie standard.
-
entschuldigung sollte ich dich angegriffen haben.
Ach Blödsinn, ich schreib das eher aus Spaß in dem Ton :-)
Ansonsten stimme ich Termite zu, die Typen muss man sich schon selbst definieren und bei einer Portierung auf eine neue Architektur (oder auch auf einen anderen Compiler) anpassen. Zumindest hat ein gcc crosscompiler keine vorgefertigte stdint.h und Header vom Host sollte man sowieso nicht nehmen, also sehe ich nicht ganz wie Korona zu deiner stdint.h kommst ohne die selbst zu definieren.
-
Ja, in einer solchen Situation muss man sich die Typen der stdint.h natürlich selbst definieren. Wenn wir die Typen aus der libc benutzen wollen geht das natürlich nur, wenn wir überhaupt eine libc haben. (Sprich: Nicht im Kernel)
In dem Fall, das der Compiler keine libc bereitstellt (im Kernel oder eben auch bei Microcontrollern) stimme ich euch natürlich zu. ;D
-
Mmmhhhh....
Es sieht so aus, als ob ich die start.asm für GRUB auch mit in die HAL nehmen muss, da der Kernel an die virtuelle Adresse 0xC0000000 geladen wird.
Denn soweit ich informiert bin, ist das Paging beim 386er anders als z.B. bei einem PowerPC-Prozessor.
Oder irre ich mich da? :?
Nur ist dann so eigentlich fast der ganze Kernel im HAL außer folgenden Punkten (nicht vollständig):
(Mehr fällt mir Momentan nicht ein)
Gruß Christian
-
Denn soweit ich informiert bin, ist das Paging beim 386er anders als z.B. bei einem PowerPC-Prozessor.
Jo, natürlich.
Nur ist dann so eigentlich fast der ganze Kernel im HAL [...]
Naja, es sind halt viele Sachen teilweise Architekturabhängig, teilweise nicht. z.B. ist das Konzept von Prozessen/Thread architekturunabhängig, aber die Struktur in der dann die Register etc... gespeichert werden, ist natürlich abhängig von der Architektur. Scheduling ist auch sehr gut abstrahierbar, wobei das Task-Switching an sich wieder abhängig von der Architektur ist.
Man muss halt versuchen die architekturunabhängigen Teile eines Subsystems von den anderen zu trennen. Das ist natürlich nicht von vorneherein klar und deswegen eher ein Prozess, d.h. du wirst wahrscheinlich immer wieder feststellen, dass manche Funktionen eines Subsystems eben doch nicht architekturunabhängig sind und sie deswegen woanders hinschieben (analog gilt natürlich der umgekehrte Fall).
-
Gut dann ist das soweit denke ich klar.
Aber das würde ja bedeuten, dass ich für jeden Prozessor-Typ einen extra Kernel brauche (z.B. 386, x86_64, PowerPC, ...) :-o
Genau das wollte ich ja eigentlich vermeiden...
Gruß Christian
-
Wenn du damit den compilierten Code meinst, dann ja. Aber das sollte auch klar sein, der Assembler/Maschinencode sieht ja schonmal ganz anders aus.
Ansonsten sehe ich nicht ganz was genau du meinst.
-
Ich dachte an so was, wie erst schauen, welche CPU vorhanden ist und dann den jeweiligen code ausführen, z.B. für 386 initialise_kernel_386(mbt).
Allerdings muss beim HigherHalf Kernel das Paging zuerst aktiviert werden, bevor irgendwas anderes gemacht werden kann, oder ich habe da was falsch verstanden.
Ich werde dass dan so lösen, dass ich bei GRUB die Auswahl lasse, was geladen werden soll.
- Kernel x86
- Kernel x86_64
- Kernel PowerPC
usw.
Gruß Christian
-
Ich dachte an so was, wie erst schauen, welche CPU vorhanden ist und dann den jeweiligen code ausführen, z.B. für 386 initialise_kernel_386(mbt).
Wie gesagt, der Maschinencode sieht schon komplett anders aus, auch die ELF Datei sieht anders aus. Da kann nur Mist rauskommen, wenn du die auch nur versuchst zu laden. Und wenn du das dann auch noch auf einer anderen Arch ausführen willst wird da nur Mist rauskommen.
Allerdings muss beim HigherHalf Kernel das Paging zuerst aktiviert werden, bevor irgendwas anderes gemacht werden kann, oder ich habe da was falsch verstanden.
Das ist falsch. Du kannst in einem Assemblerstub soviel machen wie du willst, wenn du beachtest, dass die Labels eben auf die falsche Adresse zeigen.
Ich werde dass dan so lösen, dass ich bei GRUB die Auswahl lasse, was geladen werden soll.
Grub legacy kann afaik nur x86 (und nur mit Patch x64). Soll sich aber mit grub2 afaik ändern.
-
Ja, um verschiedene Kernels kommst du auch mit HAL nicht herum. Wenn du ein HAL benutzt ist aber der Anteil des Codes den du für jede Architektur neu schreiben musst geringer als ohne ;D.
Wie bluecode gesagt hat würde ein Kernelimage für viele Architekturen schon allein vom Format der Instructions her nicht funktionieren.
Zum HigherHalf Kernel:
Du kannst natürlich auch solange Paging noch deaktiviert ist Teile des Systems initialisieren (z.B. lesen der GRUB Infos), nur ist das je nach verwendeter Programmiersprache schwierig zu handhaben. In C musst du alle Pointer auf globalen Addressen anpassen, in Assembly ist das ganze wsl. noch etwas übersichtlicher da du ja alle Speicherzugriffe die dein Kernel macht kennt (und somit die Gefahr geringer ist das du Zugriffe auf globale Variablen übersieht). Im Allgemeinen ist es jedoch empfehlenswert schnell Paging zu aktivieren um nicht ganz triviale Addressmanipulationen zu vermeiden :D.
-
Wie gesagt, der Maschinencode sieht schon komplett anders aus, auch die ELF Datei sieht anders aus. Da kann nur Mist rauskommen, wenn du die auch nur versuchst zu laden. Und wenn du das dann auch noch auf einer anderen Arch ausführen willst wird da nur Mist rauskommen.
Es sei denn, er hat einen genialen Hack gebastelt, der auf allen unterstützten Architekturen "zufällig" genau den passenden Sprung macht. Gibt ja auch Programme, die sich mit zig Sprachen kompilieren lassen, weil geschickt Kommentare usw. genutzt werden. Wäre mal ein lustiges Experiment. ;)
-
Okay.
Bin grad am reorganisieren des Codes. :evil:
Nun habe ich einen "Bildschirm Treiber", der Text mittels printf ausgibt.
Theoretisch müsste dieser doch auch in das HAL, zumindest solange, wie er vorhanden ist.
Denn der VideoRAM ist ja nicht überall an der Stelle 0xB8000, bzw. in meinem Fall 0xC00B8000.
Es sei denn, er hat einen genialen Hack gebastelt, der auf allen unterstützten Architekturen "zufällig" genau den passenden Sprung macht. Gibt ja auch Programme, die sich mit zig Sprachen kompilieren lassen, weil geschickt Kommentare usw. genutzt werden. Wäre mal ein lustiges Experiment. ;)
Solch einen Hack habe ich leider nicht. :roll:
* EDIT *
Ich habe da noch eine Frage bezüglich nasm und macros.
Kann ich folgendes Macro verwenden:
%macro IRQ 1
global irq%1
irq%1:
cli
push byte 0
push byte %1+32
jmp irq_common_stub
%endmacro
Es wird keine Fehlermeldung ausgegeben, ich kann es momentan allerdings auch nicht ausprobieren.
-
Denn der VideoRAM ist ja nicht überall an der Stelle 0xB8000, bzw. in meinem Fall 0xC00B8000.
Der VideoRAM ist auch nicht bei allen Architekturen gleich aufgebaut und bei einigen Dinger gibts sowieso nur Grafikmodi (afaik PDAs und irgendwie auch PowerPCs).
Es sei denn, er hat einen genialen Hack gebastelt, der auf allen unterstützten Architekturen "zufällig" genau den passenden Sprung macht. Gibt ja auch Programme, die sich mit zig Sprachen kompilieren lassen, weil geschickt Kommentare usw. genutzt werden. Wäre mal ein lustiges Experiment. ;)
Solch einen Hack habe ich leider nicht. :roll:
So einen Hack gibt es im Allgemeinen auch nicht.
Der Nasm-Code lässt sich bei mir assemblieren. Es wäre nicht schlecht deine Fehlermeldung zu sehen. Evtl. irq_common_stub als extern deklarieren?
-
So einen Hack gibt es im Allgemeinen auch nicht.
IIRC habe ich mal so einen Hack für 2 oder 3 Architekturen gesehen. Ich weiß aber nicht mehr wo das war. Aber auch mit so einem Hack macht es natürlich keinen Sinn nur ein Kernel-Image zu verwenden. Der Hack wäre ja ausserdem nicht erweiterbar auf andere Architekturen.
-
So einen Hack gibt es im Allgemeinen auch nicht.
IIRC habe ich mal so einen Hack für 2 oder 3 Architekturen gesehen. Ich weiß aber nicht mehr wo das war. Aber auch mit so einem Hack macht es natürlich keinen Sinn nur ein Kernel-Image zu verwenden. Der Hack wäre ja ausserdem nicht erweiterbar auf andere Architekturen.
Jo exakt den Hack habe ich auch gesehen, kann ihn aber nicht mehr finden. Aber wie du schon sagst, dass ist nur sehr beschränkt möglich und macht keinen Spaß zum Zusammenfrickeln.
-
Da ich sowas nicht machen will, bastel ich gerade an einer Funktion, die mir ausgibt und zurück gibt, welcher Prozessor installiert ist.
Je nachdem, ob das ein Intel 386 oder ein PowerPC o.ä. ist, wird dann die entsprechende Funktion zur Initialisierung des Kernels ausgeführt.
Gruß Christian
PS: Ich hoffe, das geht so, wie ich mir das vorstelle :-D
-
Damit diese Funktion auf allen Prozessoren läuft, müßte sie eben genau dieser Hack sein. Normal baust du einfach für jede Architektur den Kernel einmal durch und hast dann für n Architekturen eben n Binaries.
-
Das ganze wird nicht funktionieren, da die Anweisungen der Prozessoren ganz anders aussehen. Auf dem x86 wird ein jmp Befehl zum Beispiel zu der Bitsequenz 0xFF 0x12345678 assembliert. Auf einem ARM, MIPS oder PPC Prozessor stellt die gleiche Bitsequenz einen völlig anderen Befehl dar, falls diese Bytesequenz überhaupt gültig ist. (aufgrund von Alignments auf RISC Prozessoren oder einfach dadurch dass es keinen Opcode gibt der mit 0xFF beginnt)
-
Aber zu irgendwas muss der Befehl CPUID ja gut sein.
Zumindest kann ich herausfinden, ob der installierte Prozessor z.B. mehr als 4 GB RAM unterstützt (Pentium Pro, glaub ich).
Des Weiteren kann ich auch herrausfinden, ob ich einen 64 Bit Prozessor habe und ob und wenn ja, welcher AMD prozessor installiert ist.
Mal schauen, was sich damit noch so alles anstellen lässt :evil:
Gruß Christian
-
Jo, dieser x86-Befehl gibt dir genauere Informationen über den x86-Prozessor aus. Das heisst aber nicht, dass andere Architekturen diesen Befehl auch unterstützen. CPUID wird meist nur benutzt um festzustellen, ob der Prozessor ein bestimmtes Feature unterstützt, bevor man es benutzt, damit der Prozessor nicht mit Exceptions um sich wirft. ;-)
-
Und genau das habe ich nun vor.
Obwohl mir die Verwaltung von max. 64GB momentan noch ein Rätsel ist, das es zu lösen gibt. :-)
Trotzdem Vielen Dank für die Antworten auf meine Fragen, die Reorganisierung meines Kernel-Codes ist nun in vollem Gange.
Gruß Christian
PS: Ich vereinfache mal wieder meine Speicherverwaltung :-D
-
Moin
Nochmal so eine konzeptionelle Frage :-D:
Wäre es besser den PCI-BUS mit in den Kernel einzubauen, oder ihn als Treiber auszulagern?
Gruß Christian
-
Das lässt sich nicht allgemeingültig sagen, das kommt stark auf deinen Kernel an. Ich habe einen Microkernel also lagere ich den PCI Treiber aus. Monolithische Kernel möchten den PCI Bus vielleicht innerhalb des Kernels verwalten.
-
Monolithische Kernel möchten den PCI Bus vielleicht innerhalb des Kernels verwalten.
Oder auch als Kernelmodul, aber ich denke PCI ist so wichtig, dass man das in einem monolitischen Kernel wahrscheinlich direkt (also nicht über Module) unterstützen möchte.
-
Nun gut.
Dann werde ich das als Treiber auslagern, da ich mich an einem Mikrokernel versuche.
Gruß Christian