Eigenes OS?

Erhard Henkes

@Bitsy: Danke für den Hinweis. Momentan kämpfe ich dermaßen mit Prozessen (Multitasking/Privilegien/Syscall/Interrupts), dass ich gar keine Zeit für das Speichermanagement habe.

Du meinst, wenn ständig irgendein Prozess 4 KB Stack anfordert und anschließend wieder frei gibt? Wir betreiben das Spiel mit den Stacks auf dem Heap. Ich muss mal schauen, wie man diese geordenete Liste aller "freien Löcher" bzw. "belegten Blocks" (Heap Code von James Molloy, Kernel Tutorial, Kap. 7, übernommen) visualisieren kann. Dann könnten wir den Algo testweise stressen.
Vielleicht hat jemand Zeit/Lust für so eine Sonderaufgabe?

Erhard Henkes

Zum Thema Multitasking/UserMode/Syscalls:

Wenn man früher aus einer Task ausbrechen will, als die Timeslice dauert, lässt sich das leicht über einen Software-Interrupt realisieren:

void exit_task() //exit to next task
{
  asm volatile("int $0x21"); // <== welchen INT würdet ihr verwenden?
}

void f2()
{
    while(TRUE)
    {
      settextcolor(getpid(),0);
      putch(getpid()+'@');
      exit_task();
    }
}

void f3() //user mode at ring 3 requires syscall_...
{
    while(TRUE)
    {
      syscall_settextcolor(syscall_getpid(),0);
      syscall_putch(syscall_getpid()+'@');
      syscall_exit_task();
    }
}

int main()
{
    //...

    // create two additional tasks
    task_t* task2 = create_task (f2,0); // kernel mode (ring 0)
    task_t* task3 = create_task (f3,3); // user mode   (ring 3)

    pODA->ts_flag = 1; // enable task_switching

    while(TRUE)
    {
        settextcolor(getpid(),0);
        putch(getpid()+'@');
        exit_task();
    }
    return 0;
}

ABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCAB
CABCABCABABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCAB
CABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCACABCABCABCAB
CABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCA
BCABCACABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCA
BCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABABCABCABCABCABCABCA
BCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABABCABCABCABCABCABCA
BCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABABCABCABCABCABCABCA
BCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABC
ABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCBCABCABCABCABCABCABCABC
ABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCAB

Syscalls (Überbrückung Ring3 ==> Ring0):

#define DECL_SYSCALL0(fn)   int syscall_##fn(); //etc.

#define DEFN_SYSCALL0(fn, num) \
int syscall_##fn() \
{ \
  int a; \
  asm volatile("int $0x7F" : "=a" (a) : "0" (num)); \
  return a; \
}
//etc.

DECL_SYSCALL1(puts,  UCHAR*)
DECL_SYSCALL1(putch, UCHAR)
DECL_SYSCALL2(settextcolor, UCHAR, UCHAR)
DECL_SYSCALL0(getpid)
DECL_SYSCALL0(f3)
DECL_SYSCALL0(nop)
DECL_SYSCALL0(exit_task)

DEFN_SYSCALL1( puts,         0, UCHAR*       )
DEFN_SYSCALL1( putch,        1, UCHAR        )
DEFN_SYSCALL2( settextcolor, 2, UCHAR, UCHAR )
DEFN_SYSCALL0( getpid,       3               )
DEFN_SYSCALL0( f3,           4               )
DEFN_SYSCALL0( nop,          5               )
DEFN_SYSCALL0( exit_task,    6               )

#define NUM_SYSCALLS 7

static void* syscalls[NUM_SYSCALLS] =
{
    &puts,
    &putch,
    &settextcolor,
    &getpid,
    &f3,
    &nop,
    &exit_task
};

Das ist wohl eher ein task_yield(), da der Prozess wieder auftaucht und nicht aus der Liste der lauffaehigen Prozesse ausgetragen wird. Prozesse geben normalerweise nicht freiwillig auf, und wenn, dann mit exit endgueltig.

Erhard Henkes

zosxc63Tr schrieb:

Das ist wohl eher ein task_yield(), da der Prozess wieder auftaucht und nicht aus der Liste der lauffaehigen Prozesse ausgetragen wird. Prozesse geben normalerweise nicht freiwillig auf, und wenn, dann mit exit endgueltig.

Ja, alles richtig, werde dies auf ein exit() umbauen. Obiger Mechanismus koennte evtl. fuer ein thread_yield verwendet werden.

Wie geht es weiter mit dem OS Skript? Wann wird nach GRUB und Linux Tools umgestellt wie sonst ueblich?

was soll dieses os überhaupt bringen? es gibt doch schon minix für genau diesen zweck. und das ist auch x86. tut es wirklich not?

Hobby Programmierer

Ich denke mal, es soll dazu dienen, zu verstehen, wie ein OS funktioniert. Deswegen wird es von Grund auf programmiert. Und da so etas nicht einfach ist, muss man etwas geduld mitbringen.

_matze

upperleft schrieb:

was soll dieses os überhaupt bringen? es gibt doch schon minix für genau diesen zweck. und das ist auch x86. tut es wirklich not?

Genau! Und warum progammieren Anfänger immer diese Hello World Programme? Die gibts doch schon! Ich verstehe wirklich nicht, was das bringen soll...

sothis_

so ist das nun. bildungsresitenz breitet sich hierzulande immer mehr aus

_matze

sothis_ schrieb:

bildungsresitenz

Vorsicht! Bildungsresistenz falsch zu schreiben, ist ähnlich gefährlich wie bei Intelligenz...

freaky

I _matze

upperleft schrieb:

was soll dieses os überhaupt bringen? es gibt doch schon minix für genau diesen zweck. und das ist auch x86. tut es wirklich not?

Wie matze schon meinte, es dient zur Übung und ein OS ist eine gute Herausforderung. Hätte ich das Wissen und die Zeit dazu, würde ich mich auch dran versuchen. Wer kann schon von sich sagen, er habe alleine sein eigenes OS gebaut?

sothis_

_matze schrieb:

sothis_ schrieb:

bildungsresitenz

Vorsicht! Bildungsresistenz falsch zu schreiben, ist ähnlich gefährlich wie bei Intelligenz...

ich habe nicht behauptet, dass ich mich davon selbst ausschließe

nein, ihr habt mein posting nicht verstanden. es gibt schon minix, wsa genau für diesen zweck geschrieben wurde und in einem umfangreichen buch schritt für schritt, sowohl in der theorie als auch in der praxis (anhand des quellcodes) erläutert wie ein OS funktioniert. also wozu genau das gleiche hier nochmal?

sothis_

upperleft schrieb:

also wozu genau das gleiche hier nochmal?

weil es menschen gibt, die besser lernen wenn sie es selbst von grund auf durcharbeiten. wenn sie andere an der arbeit teilhaben lassen kommt dies dem eigenen lernprozess und dem der anderen zu gute. deswegen existieren unzählige halbfertige betriebssystem-kernel, und das ist auch gut so.

abc.w

sothis_ schrieb:

deswegen existieren unzählige halbfertige betriebssystem-kernel, und das ist auch gut so.

Ab wann ist denn ein Stück Software fertig... Heisst es nicht, ist Software fertig, dann wohl veraltet

und all dies für dieses frickelicke baumhaus mit zig anbauten namens x86. naja wers sich gern unnötig schwermacht

wenn ich mal zeit habe schreibe ich auch mal ein buch über ein kleines betriebssystem, aber das läuft dann auf einem schönen MIPS oder ARM oder so, damit der leser sich aufs wesentliche konzentrieren kann und ned auf x86 frickelei.

^^das statement hätte von mir sein können (bis auf das bücher schreiben). aber naja, es war nunmal erhards entscheidung.

Erhard Henkes

Melde mich aus dem Urlaub zurück.

Schaut man sich die in Tanenbaum "Modern OS" konkret untersuchten OS an, so findet man Unix/Linux, MS Vista und Symbian OS. Die meisten Hobby-OS sind wohl Linux/Unix-Clones.

Ich wollte zunächst mit dem starten, was viele als Teenager - in diesem Alter versuchen einige begabte und ehrgeizige jungen Leute ein erstes eigenes OS zu basteln, um die Grundlagen besser zu verstehen - zur Verfügung haben, nämlich einen 80x86 Rechner mit MS Windows. Daher schreibe ich das Tutorial in deutsch und starte von diesem Bezugspunkt.

Das Design-Thema habe ich auf Teil 3 verschoben. Teil 2 ist zunächst noch dem spielerischen Kennenlernen weiterer notwendiger Techniken wie Speichermanagement (Paging, Heap, Virtual File System, Ram Disk) und Prozessmanagement (Multitasking) gewidmet. Das Thema User-Lib und -Programme gehört dort auch noch dazu.

Wie ich GRUB und Cross-Compiler einbeziehen werde, weiß ich noch nicht sicher. Zunächst werde ich das Community-OS tyndur näher unter die Lupe nehmen, um handwerklich dazu zu lernen. Hier existiert ein "noch" lebendiges deutsches Forum zum Thema OS Development, das eine Unterstützung/Belebung verdient und arbeitsteilig seit einigen Jahren ein interessantes Hobby-OS entwickelt:
http://lowlevel.brainsware.org/wiki/index.php/Tyndur

Das Kernproblem für den Einsteiger ist nicht die komplexe x86-Technik, die in den Intel Manuals gut beschrieben ist, sondern die Herausforderung, mit den notwendigen Tools (Intel- und AT&T Assembler-Syntax, Linker-Skripte, Cross Compiler, GRUB Image, Bochs Debugger, ...) und Informationsquellen (Intel Manuals, Foren, Tutorials, Bücher, Sourcecode einiger Vorbild-OS, Wechselspiel C und Assembler, ...) umfassend und tiefschürfend klar zu kommen.

Minix3 http://www.minix3.org/ spielt hierbei nach wie vor nur eine akademische Rolle als Beispiel für einen "Mikrokernel", was nichts über seine Bedeutung für die Zukunft aussagt. Es wurde historisch schlicht und einfach von Linux besiegt. Hier hat der mutige Student über den sturen Professor gesiegt.

In der Praxis findet man momentan bevorzugt monolithische Systeme.

Erhard Henkes schrieb:

Das Kernproblem für den Einsteiger ist nicht die komplexe x86-Technik, die in den Intel Manuals gut beschrieben ist...

x86 prozessoren sind schon übel genug. protected/real-mode, descriptortabellen, segmentregister usw. kommen doch nur daher, dass eine uralt-cpu mit immer mehr funktionalität versehen wurde, aber trotzdem kompatibel zur ursprungsversion bleiben sollte. hinzu kommt noch die hürde der verfrickelten PC-architektur (boot-loader, bussysteme, video-ram, bios, usw). alles in allem eine suboptimale konstruktion, so als hätte jemand einen formel-1 wagen aus 'nem trabbi zusammengezimmert.

Erhard Henkes schrieb:

sondern die Herausforderung, mit den notwendigen Tools (Intel- und AT&T Assembler-Syntax, Linker-Skripte, Cross Compiler, GRUB Image, Bochs Debugger...

hier bietet sich vielleicht an (als unterprojekt z.b.) eine toolchain zusammenzustellen, die ein benutzer leicht installieren (oder im idealfall einfach auf seinen rechner kopieren) kann, um dein OS zu bauen, zu testen und damit zu experimentieren.

Erhard Henkes schrieb:

"Mikrokernel", was nichts über seine Bedeutung für die Zukunft aussagt. Es wurde historisch schlicht und einfach von Linux besiegt.
...
In der Praxis findet man momentan bevorzugt monolithische Systeme.

auch hier, würde ich sagen, hat nicht das bessere gesiegt. ein modularer kernel ist doch wartbarer und leichter erweiterbar, als ein monolithischer klotz. ein system, in dem alle komponenten über wohldefinierte schnittstellen verbunden sind, ist im endeffekt auch weniger komplex.

Erhard Henkes

x86 prozessoren sind schon übel genug. protected/real-mode, descriptortabellen, segmentregister

Wenn man die Beiträge zu der "üblen" Situation der x86 Architektur liest, fragt man sich, warum diese komplizierte Struktur - bedingt durch Abwärtskompatibiltät - nicht schon längst durch eine überlegene einfachere Struktur überholt wurde?

toolchain

Ja, das ist richtig. Langfristig bleibt aber einem "OSDever", der in einer OS-Entwickler-Community (Deutschland: lost/tyndur; lowlevel.brainsware.org) eingebettet sein will, nur der Weg über Linux als Hostsystem und GRUB als luxuriöser Bootloader. Das gilt neben Bochs als Emulator und Debugger als Quasi-Standard im PC-Bereich. Linux ist insgesamt ein übermächtiges Vorbild für die gesamte Szene, die alles andere an die Wand drückt. Das ist schade und sollte durchbrochen werden. Vielleicht schaffen wir das noch, sind ja erst ganz am Anfang. Eine OS benötigt Jahre bis ein halbwegs stabiles Team mit Freude daran arbeiten kann. Redesigns und Neuanfänge inbegriffen.

auch hier, würde ich sagen, hat nicht das bessere gesiegt. ein modularer kernel ist doch wartbarer und leichter erweiterbar, als ein monolithischer klotz. ein system, in dem alle komponenten über wohldefinierte schnittstellen verbunden sind, ist im endeffekt auch weniger komplex.

Akzeptiert. Welches Vorbild schwebt Dir hier vor? Minix3?