Thema: HAL

[ChristianF]

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:

Code: [Auswählen]

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

[Termite]

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.

[kevin]

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

[Korona]

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.

[ChristianF]

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:

Code: [Auswählen]

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

[Korona]

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]

[bluecode]

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

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

[Termite]

* Portzugriffe

Manche Architekturen haben keinen gesonderten I/O Portbereich, sondern bei denen wird I/O über den "normalen" physischen Adressraum gehandhabt.

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

[bluecode]

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 auch kennt, bevor man meckert.

[bluecode]

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?

[kevin]

Manche sind eben bei 16-Bit-Prozessoren stehengeblieben.

[Termite]

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

[Korona]

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.

[Termite]

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.

[bluecode]

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.

[Korona]

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.

[ChristianF]

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

• Modulinterface

(Mehr fällt mir Momentan nicht ein)
 
Gruß Christian

[bluecode]

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

[ChristianF]

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, ...) 
Genau das wollte ich ja eigentlich vermeiden...
 
Gruß Christian

[bluecode]

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.