Eigenes OS?

Erhard Henkes

Ein ganz wichtiger Punkt ist nun der Einsatz eines Cross-Compilers/-Linkers, der vor allem auch das ELF-Format erlaubt, das man für andere Hobby-OS und später für User-Programme benötigt. Man benötigt allerdings auch ein brauchbares make-Tool, das alle Anforderungen erfüllt, findet man nun alles hier, natürlich alles einfach und übersichtlich nachzuvollziehen:
http://www.henkessoft.de/OS_Dev/OS_Dev2.htm#mozTocId42018

Wichtig ist, dass man nun aus Assembler-Quellcode leicht elf-object- und mittels des linkers der cross-compiler-tools daraus elf-executable-Dateien herstellen kann. Es ist nun die nächste Aufgabe diese elf-Programme seitens Pretty-OS im "user space" zum Laufen zu bringen. Dann kann man zur Zeit mittels incbin und Einbinden in die RAM Disk Programme im VFS "loadable" zur Verfügung stellen.
Dort sollte z.B. später die Programme

init,
vielleicht noch einge Treiber
und eine shell

stehen. Das wäre dann eine interessante Aufgabe für das Assembler-Forum, solche kleinen Programme in Assembler zu erstellen.

nasm(w) -felf -o file.o file.asm
i586-elf-ld -T user.ld -nostdinc -o program.elf file.o

user.ld:

ENTRY(_start)
OUTPUT_FORMAT(elf32-i386)

SECTIONS
{
    . = 0x400100;

    .text :
    {
      *(.text*)
    }
    .data :
    {
      *(.data*)
      *(.rodata*)
    }
    .bss :
    {
      *(.bss*)
    }
}

Setzt man kein Linkerscript ein

i586-elf-ld -nostdinc -o program.elf file.o

so ergibt sich die default Adresse: 0x08048000 + program_offset
http://www.henkessoft.de/OS_Dev/OS_Dev2.htm#mozTocId95189

Kann jemand erklären, warum gerade diese Adresse verwendet wird?

Mit Einsatz der Cross-Tools ist das Thema Linux und GRUB damit vorerst vom Tisch, wie gewünscht.

Nächstes kapitel wird richtiger user mode, denn bisher wurde der kernel als user mode / read-only eingesetzt (ein Erbe von JM's Tut.)

Erhard Henkes

User-Land macht Fortschritte. User-Programme werden momentan noch via incbin in die RAM Disk geladen, dort mit VFS gefunden und in den User-Page-Bereich geschoben. Dort greifen sie via syscalls (int 0x7F) auf die in syscall.h/.c freigegebenen Kernel-Funktionen zu.

Linkerscript user.ld:

ENTRY(_start)
OUTPUT_FORMAT(elf32-i386)
SECTIONS
{
    . = 0x400100;
	.text : { *(.text*)             }
    .data : { *(.data*) *(.rodata*) }
    .bss :  { *(.bss*)              }
}

makefile:

ASFLAGSBIN= -O32 -f bin
ASFLAGSOBJ= -O32 -f elf
NASM = nasmw

CFLAGS=	-O -ffreestanding -fleading-underscore    
CC= i586-elf-gcc

LDFLAGS= -T user.ld -Map kernel.map -nostdinc
LD= i586-elf-ld

all: program.bin program.elf

program.bin: program.asm
	$(NASM) $(ASFLAGSBIN) $< -o $@

program.o: program.asm
	$(NASM) $(ASFLAGSOBJ) $< -o $@

program.elf: program.o
	$(LD) $(LDFLAGS) $+ -o $@ 

#    $<		Erste Abhängigkeit
#    $+		Liste aller Abhängigkeiten	
#    $@		Name des Targets

Erste kleine User-Beispiel-Programme:

[BITS 32]
start:
   mov [0x000b8000], byte 'T'
   mov [0x000b8002], byte 'e'
   mov [0x000b8004], byte 's'
   mov [0x000b8006], byte 't'
   mov [0x000b8008], byte ' '
   mov eax, 4
   int 0x7F
   jmp start

[BITS 32]
start:
   mov ebx, 0x4  ; 1. Argument
   mov ecx, 0x0  ; 2. Argument
   mov eax, 2    ; settextcolor
   int 0x7F

   mov ebx, 0x54 ; 'T' 
   mov eax, 1    ; putch
   int 0x7F

   jmp start

Output: http://www.henkessoft.de/OS_Dev/Bilder/userprogram001.PNG

http://www.henkessoft.de/OS_Dev/OS_Dev2.htm#mozTocId710871 (wird noch ausgebaut)
http://www.henkessoft.de/OS_Dev/Downloads/20090703_61.zip (Download)

Nun gäbe es z.B. folgende Aufgaben:
- elf-exec-Parser
- syscalls systematisch aufbauen
- user-Programme schreiben
- user-lib entwickeln
- user-Programme init und shell schreiben
- Treiber

Hat jemand gute Ideen, was man auf dem jetzigen Stand alles so machen könnte mit kleinen Assembler-Programmen (passt zum Unter-Forum) und dazu passenden Syscalls?

Eine Frage ist auch, wie man das Arrangement der Syscalls sinnvoll aufbaut. Vielleicht hat hier jemand eine klare Meinung?

Auf jeden Fall kann man Teil 2 des Tutorials so langsam beenden, denn wesentliche Elemente eines durch einen eigenen Bootloader hochgefahrenen OS auf dem 80x86 wurden bisher konkret gezeigt.

Nun stellt sich die Frage, was man in Teil 3 sinnvoll angehen könnte:
Es kommt bei der Weiterentwicklung von PrettyOS z.B. darauf an, welchen Kernel-Typ man anstrebt. Bei einem monolithischer Kernel umfassen die Syscalls z.B. die POSIX-Funktionen, Win32API bzw. irgendeine eigene API. Dies verlagert die komplette Funktionalität eines Betriebssystems in den Kernel. Beim Mikrokernel-Typ sind die Syscalls vor allem IPC, Speichermanagement und etwas Prozessmanagement. Die IPC stellt die Kommunikation zwischen den Prozessen sicher, um die jeweils benötigtge Funktionalität zu triggern. Der Kernel brennt dann inhaltlich eher auf Sparflamme.
Darüber hinaus könnte man verschiedene Treiber anbieten. Bisher haben wir die Hardware des PC geschont, so dass Ladevorgänge via Emulator oder in einem Rutsch beim Booten von Floppy Disk abliefen.

Falls jemand konkret Lust hat, mich bei (Re-)Design des Kernels, Definition der syscalls und Aufbau der User-Applikations-Landschaft (NASM-Assembler oder nach Aufbau einer API-Lib für die syscalls auch in C) zu unterstützen, da wäre ich nicht abgeneigt. Kein Zeitdruck. Ich denke nicht, dass man das konkrete Development im Forum machen kann. Mein persönliches Ziel (gute Co-Autoren werden akzeptiert): Buch "Betriebssystementwicklung - leicht gemacht"

ICQ: 76194616
http://www.henkessoft.de/OS_Dev/OS_Dev3.htm (development ongoing)

Erhard Henkes

Wichtiger Meilenstein:
User-Programme in C mit userlib.h/.c anstelle Assembler-User-Programme. Echt gutes Gefühl, wenn so etwas endlich läuft.
Hier sollte sogar C++ möglich sein.

http://www.henkessoft.de/OS_Dev/Downloads/20090705_66.zip

// userlib.h

#ifndef USERLIB_H
#define USERLIB_H

void settextcolor(unsigned int foreground, unsigned int background);
void putch(unsigned char val);

#endif

// userlib.c

#include "userlib.h"

void settextcolor(unsigned int foreground, unsigned int background)
{
    asm volatile( "int $0x7F" : : "a"(2), "b"(foreground), "c"(background) );
}

void putch(unsigned char val)
{
    asm volatile( "int $0x7F" : : "a"(1), "b"(val) );
}

// program.c

#include "userlib.h"

int main()
{
  settextcolor(14,1);
  putch('T');
  putch('e');
  putch('s');
  putch('t');
  return 0;
}

killerkirsche

Mit was für einem Dateisystem arbeitest du?
bzw. hast du schon eins?

Hobby Programmierer

Wenn du dur mal das Tut zum OS ansehen würdest, oder dir das OS ansiehst, würdest du feststellen, dass dort noch gar kein Festplattenzugriff ist.

killerkirsche

Ich meine gar keinen Festplatten sondern Diskettenzugriff.
Außerdem kann es ja sein, dass schon etwas ins Auge gefasst wurde.

Erhard Henkes

Mit was für einem Dateisystem arbeitest du? bzw. hast du schon eins?

Bei User-Programmen wird mit dem ELF-executable-Format gearbeitet. In der RAM disk wird ein von James Molloy selbst gestricktes Format eingesetzt (Quellcode für Erzeuger-Programm liegt bei). Bezüglich der "Datenträger" weiß ich noch nicht wie ich vorgehen soll. Diskettenlaufwerke sind sicher nicht mehr der Hit und an vielen PCs nicht mehr vorhanden. Alle Programme werden bisher via "incbin" innerhalb initrd.img in den Kernel transportiert und dort über das VFS und selbst gestrickte Dateisystem gefunden und "geladen".

killerkirsche

Ah ok.
Das hilft mir doch schonmal weiter.
Da ich nicht denke, das Diskettenlaufwerke untergehen sollten und da mein OS die Massen nicht interessieren wird, habe ich ein ext2-System auf der Floppy mit dem OS.
Ich hab gehofft du benutzt das auch und wüsstest einen Treiber dafür.
Aber scheint ja nicht der Fall zu sein.

Erhard Henkes

Da ich nicht denke, das Diskettenlaufwerke untergehen sollten

Da stehst Du wohl nicht völlig alleine da mit dieser Meinung, aber aufhalten kann den Niedergang niemand mehr. Das Ende der drehenden Scheiben ist nahe.

ext2-System auf der Floppy mit dem OS

Da ich MS Windows als Host-System mit Cross-Compiler/-Linker für die OS-Entwicklung verwende, wollte ich mich - wenn überhaupt - eher auf ELF und FAT konzentrieren.

Erhard Henkes

Die bisherige Begrenzung für den Kernel im Bootloader ist endlich gefallen:
http://www.henkessoft.de/OS_Dev/OS_Dev3.htm#mozTocId882541

Der Bootloader und zugehörige Aufgaben vor dem Start der C-Datei ist bisher noch ein gehöriger Schwachpunkt. Die Ratschläge, endlich GRUB einzusetzen, verstummen nicht.

Musste allerdings noch die bss section nullen, das hat noch gefehlt.
Ich könnte echt einen BIOS / Bootloader / ... -Spezialisten brauchen.

Instabiler Code, der auf mehreren PCs getestet wurde und in einigen Fällen zu "Datenverlusten" in der RAM Disk führte, was dann teilweise #PF oder fehlendes User-Programm zur Folge hatte.
http://www.henkessoft.de/OS_Dev/Downloads/20090720_83.zip
(Fehler in fs.h/fs.c muss noch exakt lokalisiert und behoben/abgefangen werden)

Da das Problem eindeutig in dem verwendeten Code von James Molloy für VFS/RAM Disk liegt, wurde das in nachfoglendem Code einfach umgangen:
Hier ist ein stabiler Code, der VFS umgeht, solange der Fehler nicht exakt lokalisiert und behoben wurde: http://www.henkessoft.de/OS_Dev/Downloads/85.zip

Erhard Henkes

Ich möchte auf eine hervorragende, bisher 20-teilige Serie (BrokenThorn Entertainment, "Mike") aufmerksam machen: http://www.brokenthorn.com/Resources/OSDev1.html
(didaktisch wirklich gut, da von Grund auf mit eigenem Bootloader und FAT12 System gearbeitet wird; leider noch einige kleine Fehler enthalten, Author wurde von mir über diese informiert)

Ich hab gehofft du benutzt das auch und wüsstest einen Treiber dafür.

Vielleicht sind die ersten Teile des obigen Tutorials für Dich das richtige, verwendet allerdings FAT12 anstelle ext2.

Erhard Henkes

Das Thema Analyse des physikalischen Speichers wurde nun auch erfolgreich umgesetzt: http://www.henkessoft.de/OS_Dev/OS_Dev3.htm#mozTocId584885
Allerdings haben wir mit int 15h eax = 820h die 80er verlassen und sind auf neuere Zeiten (spätestens ab 2002, funktioniert aber vielfach bereits bei früheren PCs) umgestiegen.

Der Bootloader ist nun allerdings voll gestopft. Platz für FAT12 ist dort nun nicht. Wir verwenden ja noch "raw format". Die Frage ist, ob man sich überhaupt noch Gedanken über Floppy Disk machen soll.

supertux

Erhard Henkes schrieb:

Mich würde mal interessieren, wer alleine oder mit anderen an einem eigenen OS entwickelt, zu welchem Zweck und in welcher Sprache (ASS, C oder C++)? Links?

Für meine Studienarbeit habe ich einen Echtzeit-fähigen Mikrokernel entwickelt mit einem EDF Scheduler. Während der Diplomarbeit erweitere ich den um energieeffiziente Schedulingalgorithmen. Das ganze läuft auf einem gumstix connex400 mit einem Intel PXA255 (ARMvt5). Code darf ich noch nicht veröffentlichen

Erhard Henkes

@supertux: Klingt echt toll! Davon musst Du hier berichten, sobald Du dies darfst. Aber vielleicht kannst Du mit Deinen Erkenntnissen hier einige wichtige Weichenstellungen kommentieren und beeinflussen. PrettyOS soll ja vor allem ein Experimentier-OS werden und Einsteiger in diese Materie ansprechen und ermuntern.

Das Bild von einem OS, das man vor Augen hat, wird entscheidend geprägt durch das Interface. Daher habe ich nun auch begonnen die "Shell" (in Ring 3) zu entwickeln:
http://www.henkessoft.de/OS_Dev/OS_Dev3.htm#mozTocId29082

Ich stelle mir momentan vor allem die Frage: Was gehört in die syscall-API (teuer) und was in die user-API (bläht User-Programm auf)?

supertux

Erhard Henkes schrieb:

@supertux: Klingt echt toll! Davon musst Du hier berichten, sobald Du dies darfst. Aber vielleicht kannst Du mit Deinen Erkenntnissen hier einige wichtige Weichenstellungen kommentieren und beeinflussen. PrettyOS soll ja vor allem ein Experimentier-OS werden und Einsteiger in diese Materie ansprechen und ermuntern.

das hörst sich sehr interessant an, hab ein bisschem im Code nachgeschaut. Leider kenne ich mich mit x86 überhaupt nicht aus, also verstehe ich den Code und viele (für x86) Notwendige Sache gar nicht.

Ich muss meine Ausarbeitung in ca. 2 1/2 Wochen abgeben, dann Vortrag halten und so. Also erst danach werde ich wahrscheinlich meine Sachen (plus Sources) veröffentlichen können.

Erhard Henkes

ARM ist für einige interessant. Vielleicht kannst Du auch einen passenden Emulator verlinken.

Erhard Henkes

Ich habe PrettyOS nun auch unabhängiger und stabiler gemacht. Da hatten sich nach dem Umstieg von DJGPP nach Cross-Tools doch einige unbehobene Schwachpunkte angesammelt. Nun kann man Kernel und User-Programme mit CFLAGS= -Werror -Wall -O -ffreestanding -fleading-underscore -nostdlib -nostdinc -fno-builtin kompilieren.
Physikalischer Speicher wird nun auch automatisch bestimmt und für das Paging (Anzahl der Frames = Phys. Memory / Pagesize) übernommen.

Das ist die bisher stabilste und beste Version: http://www.henkessoft.de/OS_Dev/Downloads/88.zip (läuft inzwischen mit -Werror und -Wall und benötigt keine Header der Cross-Tools)

Hier habe ich wieder initrd und VFS verwendet, um die shell zu finden/laden:
http://www.henkessoft.de/OS_Dev/Downloads/90.zip
(dabei gibt es aber auf bestimmten PC noch Probleme, die ich bisher nicht lokalisieren und beheben kann):
Die Shell wurde als ELF-Programm via incbin (data.asm) über die Paarung RAM Disk / VFS lokalisiert und gestartet. Der visuelle Eindruck beginnt sich zu entwickeln.

Ich stelle mir für die Zukunft die Fragen:
- wie sollen die syscalls aussehen?
- was gehört in die user-lib?
- Sollte man Standards einsetzen? (POSIX, standardisierte C-userlib)
- Sollte man letztendlich doch GRUB einsetzen oder stur den eigenen Bootloader ausbauen? (niemand hetzt mich)

Wenn du mich fragst, ich würde auf jeden Fall einmal das Thema GRUB anschneiden.
Es soll immerhin ein OS- und kein Bootloader-Tutorial bleiben / werden.

Hobby Programmierer

Ich würde Standards einsetzen, weil es dann einfacher ist Programme zu entwickeln bzw. zu portieren.

Als erstes vorweg: ich beobachte die Entwicklung des Tutorials jetzt schon einige Zeit und bin echt begeistert! Mach auf jeden Fall weiter.

Zum Thema GRUB: Ich fände es schade um die viele Arbeit, die jetzt schon in den eigenen Bootloader investiert wurde. Außerdem find ich es gut, dass man so von Anfang an gut erklärt bekommt, wie so ein Betriebssystem von Grund auf aufgebaut ist. Wenn man den Anfang jetzt GRUB machen lässt, werden wieder Fragen wie "Wie läuft das denn eigentlich mit GRUB ab?" aufgeworfen. Es ist zwar viel Arbeit, doch ist der Lerneffekt zumindest für mich größer, wenn mit dem jetzigen Bootloader weitergearbeitet wird.

Übrigens habe ich festgestellt, dass der Bootloader sich im Bochs-Emulator bei folgenden IPS folgendermaßen verhält (Näherungswerte):

400.000 -> Bootloader wird garnicht erst geladen
400.050 -> Bootloader startet verzögert (ca. 7 Sekunden)
400.100 -> Bootloader startet verzögert (ca. 5 Sekunden)
400.500 -> Bootloader startet verzögert (ca. 1 Sekunde)
402.000 -> Bootloader startet vollkommen normal

Getestet wurde übrigens mit jeweils 8 MB RAM (das Niedrigste, ohne eine Fehlermeldung von alloc_frame() zu bekommen, dass es keine freien Frames mehr gebe, um anschließend (außer bei 7MB RAM) im "Page Fault >>> Exception. System Halted! <<<" zu enden ;))

Woran liegt das genau, warum sind so kleine Werte hierbei so entscheidend?