FAT32 und ELF

Hallo,
Wie kann man ein FAT32 Laufwerk auslesen und eine ELF Datei starten ohne gleich eine Libray runter zuladen?

Jonas OSDever

Aeh einfach die FAT-Strukturen lesen und parsen, dann die Datei laden (ggf. Unreal Mode), ELF-Header parsen und dann den Entry anspringen (fuer ein PM-OS ist natuerlich noch etwas mehr noetig mit Ring3-Code-Segment, ggf. eigenes Page-Directory usw.)? Die Formate sind offen dokumentiert. Du kannst ja trotzdem Libraries oder den PrettyOS-Code angucken, der Bootloader kann FAT lesen und die User-Programme sind auch ELFs.

Im PrettyOS-Code findest Du hier beispielhaft den kompletten Vorgang.

Mal eine Frage, warum gibts es überhaupt die .multiboot-Sektion? Warum reicht keine ganz normale executable-Datei?

Ob die Sektion, die den Code enthält, jetzt .text oder .multiboot heißt, ist doch egal?

mal ne frage schrieb:

Mal eine Frage, warum gibts es überhaupt die .multiboot-Sektion? Warum reicht keine ganz normale executable-Datei?

Ob die Sektion, die den Code enthält, jetzt .text oder .multiboot heißt, ist doch egal?

Mir ist grade noch eine Frage eingefallen:
Braucht die Kernel-Datei überhaupt die anderen Sektions (.data,.text... usw.)?
Braucht Grub nur die .multiboot-Sektion?

.multiboot im Kernel benötigt man nur für Multiboot, also z.B. für GRUB.

helper007 schrieb:

.multiboot im Kernel benötigt man nur für Multiboot, also z.B. für GRUB.

Ja, das weiß ich ja, die Frage ist ja eben: wenn ich .multiboot bei GRUB brauche, warum brauche ich dann auch die anderen, "normalen" sections (.data, .text usw.).

Ich mein: Wenn grub doch sowieso nur die .multiboot-section sucht, dann kann ich doch die anderen sections, die der gcc meistens mit in die Datei packt, mit objcopy entfernen, oder? (Ich meine: .bss, .comment usw.)

Was ist denn los? Ich weiß ganz genau, dass es hier Leute gibt, die mir diese Frage beantworten können.

Jonas OSDever

Geduld, Geduld. Auch wir muessen in der Vorweihnachtszeit mal aus unseren Kellerloechern kriechen und uns soziale Interaktion antun.

Jedenfalls ist, sofern ich die Multiboot-Spec nicht missinterpretiere, der Name der Sektion erstmal egal. Der Bootloader sucht im wesentlichen nach dem MB-Header, in welchem optional mit einem Flag festgelegt werden kann, dass er eine ELF-Datei vor sich hat und diese interpretieren und auf den Sections basierend laden soll, anstatt die Informationen aus dem Header zu benutzen.
Der Grund, dass man den MB-Header idR in eine eigene Sektion packt ist einfach der, dass es eine Restriktion des Bereichs gibt, in dem nach dem Header vom Dateianfang aus gesucht wird, naemlich 0-8KiB von Beginn des Images.
Wenn du den in eine eigene Section packst, kannst du im Linkerskript leicht explizit klar machen, dass er an den Anfang gehoert; packst du ihn dagegen in eine andere Section, die viele Daten enthaelt, kannst du nur schwer sichergehen, dass es sich auch dort befindet.
Dementsprechend ist es, wenn du nicht den kompletten Kernel-Stuff, spricht Code, Daten, RO-Daten, unitialisierte Daten/BSS, in die .multiboot-Section verschiebst, was selber wiederum eine dumme Idee waere, weil dann der Compiler entscheidet, was wohin gepackt wird, keine gute Idee, die Sections zu entfernen.
Nimm einfach .multiboot fuer den Header, .text ganz normal fuer den Code und .data, .rdata sowie .bss fuer ihren normalen Bestimmungszweck.

Ok, danke für die Erklärung.

Wo wir schonmal dabei sind, welche Sections sind notwendig, welche kann ich entfernen?

Der gcc packt, soweit ich das mitbekommen habe, z.B. standardmäßig eine .comment-Section ein, in der nur die Version und der verwendete Compiler, bzw. das verwendete Betriebssystem steht. Diese Section ist doch nicht notwendig für die Ausführung des Programms, oder?

Mr X

Der gcc packt, soweit ich das mitbekommen habe, z.B. standardmäßig eine .comment-Section ein, in der nur die Version und der verwendete Compiler, bzw. das verwendete Betriebssystem steht. Diese Section ist doch nicht notwendig für die Ausführung des Programms, oder?

Deinen Angaben zufolge nein. Du könntest es doch einfach mal ausprobieren, oder?

Warum hat man eigentlich kein eigens, völlig neues Kernel-Format entwickelt?
Eins, das 100%ig auf die Bedürfnisse von Kernel-Entwicklern ausgelegt ist?

Ich mein, das müssten halt dann die Compiler-Entwickler implementieren, und dafür hätten alle anderen ihre Ruhe.
Nun hat man einfach das Bestehende erweitert, zugunsten der Compiler-Entwicklern, die müssen jetzt nichts neues implementieren, dafür haben jetzt halt die Kernel-Entwickler das Problem. Jedes einzelne unnötige Byte im Kernel ist zu viel... vor allem, wenn man nur einen sehr begrenzten Speicherplatz hat.

Tobiking2

nächste Frage... schrieb:

Warum hat man eigentlich kein eigens, völlig neues Kernel-Format entwickelt?
Eins, das 100%ig auf die Bedürfnisse von Kernel-Entwicklern ausgelegt ist?

Die Bedürfnisse von Kernel-Entwicklern unterscheiden sich auch. Das Ergebnis wäre ein Format mit Sektionen, die man ein- und ausschalten kann. Praktisch also wie ELF. Warum also ein neues Format schreiben wenn ein Linkerscript ausreicht?

Ansonsten kannst du dir mal das a.out Format angucken. Das enthält wirklich nur das Nötigste.

Tobiking2 schrieb:

Ansonsten kannst du dir mal das a.out Format angucken. Das enthält wirklich nur das Nötigste.

wird das überhaupt noch vom gcc als output-format unterstützt?

Das ist Sache des Linkers ld. Ältere Versionen können das noch.
http://stackoverflow.com/questions/8303536/generating-a-out-file-format-with-gcc