Eigenes OS?

Tobiking2

Die technischen Besonderheiten, gerade bei 80x86, sind aber genau der Clou! Grau, grau ist alle Theorie.

Man braucht aber zum verstehen von Paging nicht zu wissen, welches Bit in welchem Register gesetzt werden muss, um es beim x86 zu aktivieren. Es ist natürlich in einem Tutorial wie deinem wichtig zu erwähnen, aber wer selber ein Betriebsystem schreibt und nicht auf ein Tutorial aufbaut, kann sich das auch aus dem Intel Manual oder aus einem der recht guten Wikis zu dem Thema raussuchen. Das sehe ich noch nicht als spannend an. Zu dem Wechsel in den PM dürften sich auch schon genug negativ geäußert haben.

Ich find dann erst wieder interessant, wie die verschiedenen Techniken dann in der Praxis wirklich genutzt werden. Das steht dann aber auch oft im Tanenbaum. Ich denke zudem schon das man mit soliden Assembler/C Kenntnissen, dem Tanenbaum und dem Intel Manual ein Betriebsystem schreiben könnte. Es kann ja nicht jeder irgendwo abgucken, irgendwer muss angefangen haben.

Die Zielgruppe 13-15 find ich etwas niedrig. Den meisten dürfte es selbst mit dem Tutorial an Vorwissen fehlen und es endet mit stumpfen copy and paste.

Daher schreibe ich das Tutorial auch in Deutsch und nicht in Englisch.

Und wieso kommentierst du den Code (vor allem die Codebeispiele) auf Englisch und nicht auf Deutsch?

ach das wär zu schön. schätzungsweise 90% der dozenten, die diese dinge lehren, haben ihr skript, was sie ca. 1983 kompiliert haben, worin sie die studenten mit gelaber über uralten x86 kram wie real mode, protected mode, xms, x86 isa und co nerven die meisten dozenten sind leider vor 20 jahren in der zeit stehen geblieben, als sie selbst das letzte mal irgendwas programmiert haben

Wir haben teilweise Glück gehabt. Die Hardware Grundlagen kamen von einem Dozenten der am Lehrstuhl Eingebettete Systeme tätig ist. Das ist warscheinlich der Grund dafür gewesen, dass wir jedes mal MIPS als Referenzarchitektur genommen haben wenn etwas konkret behandelt wurde.

Die Betriebsystem Vorlesung war dafür dann das Tanenbaum Buch in Kurzform. Sogar die Folien waren original von Tanenbaum auf Englisch und zwischendurch mal ein Deutscher Satz als Zusatz drunter gesetzt.

So etwas ist eine Schande für unser Ausbildungssystem!
Für was zahle ich denn Unmengen von Steuern? Diesen Damen und Herren müsst ihr mal richtig Bescheid stoßen.

Ich zahl sogar noch 500 Euro pro Semester an Studiengebühren...

es endet mit stumpfen copy and paste

Das ist erstmal nicht schlimm. Man will sehen, dass etwas geht, bevor man sich tiefer beschäftigt. RM->PM ist blöd, dass BIOS weg ist. Gibt es da keinen Weg, das doch noch zu nutzen? Einschalten A20 kopiert man einfach, basta. Interessant ist Einsatz von FAT12, hoffentlich bald USB, wäre toll.

Tutorial ist bisher glaube ich bestes, was es gibt in deutsch, oder?

Tobiking2: ja dan hattest du wohl Glück. Ich verstehe auch nicht, warum nicht mehr Dozenten einfach auf die wirklich gute Literatur wie Tanenbaum, Silberschatz und Co. zurückgreifen, die es zu diesem Thema ja zur Genüge gibt. Viele Dozenten haben stattdessen ihr didaktisch absolut miserabel gestaltetes Skript, was zusätzlich halt veraltet ist. Schade, daß die Dozenten so ziemlich in jeder Hinsicht tun und lassen können, was sie wollen. Da sollte es mal mehr Vorgaben geben oder so :o

Mich würde interessieren, welches Skript zum Thema OS Development das beste an der Hochschule ist.

Erhard Henkes schrieb:

Die Abwehr gegen den "x86 Kram" finde ich prinzipiell unberechtigt, denn diese CPUs beherrschen heute immer noch den PC-Markt, nun in 64-Bit-Qualität, was die ganze Sache noch mehr verkompliziert. Ich fände eine vergleichende konkrete Darstellung der Pros und Cons sinnvoll mit Blick auf Windows, Linux, Symbian OS und einem Roboter-Betriebssystem.

der 'x86-kram' stellt aber eine äusserst miserabel zusammengeflickte architektur dar (im vergleich z.b. zu ARM-systemen). das design der ersten X86-CPUs war nun mal nicht darauf ausgelegt, immer neue derivate (bis in die heutige zeit) hervorzubringen. dementsprechenden haben wir heute übelsten pfusch in unserern PCs.

Erhard Henkes schrieb:

Mit "abstrakter" Software kann man zunächst wenig bewegen. Zum Schluss müssen immer auch die "Basics" bedient werden, und diese sind zumeist komplex, weil diese wirtschaftlich und nicht didaktisch getrieben sind, eben Bit-Gefrickel.

deshalb sollte man auch besser 'hardware abstraction layer' einsetzen, im einfachsten fall I/O-bitgefummel über makros machen und für komplexere komponenten (z.b. die RTC, RS232, speichermedien usw.) treiber mit 'nem einheitlichen interface schreiben. sowas wie scheduling-algorithmus, exception und interrupt-handling z.b. kann man in portablem C coden, wobei nur sehr wenig plattformabhängiger assembler-code verwendet werden muss (den man hinter funktionen verstecken kann, z.b. switch_context()). wenn ich z.b. so'n tutorial wie deins (bis jetzt) machen würde, dann würde ich es nicht 'betriebssystementwicklung' sondern eher 'programmierung unter nackten x86 systemen' o.ä. nennen.

Erhard Henkes

der 'x86-kram' stellt aber eine äusserst miserabel zusammengeflickte architektur dar (im vergleich z.b. zu ARM-systemen). das design der ersten X86-CPUs war nun mal nicht darauf ausgelegt, immer neue derivate (bis in die heutige zeit) hervorzubringen. dementsprechenden haben wir heute übelsten pfusch in unserern PCs.

Du kennst die ARM-Systeme in 20 Jahren noch nicht, kann genau so enden wie bei x86. Nennt sich Abwärtskompatibilität.

programmierung unter nackten x86 systemen

Schöner Titel.

Erhard Henkes schrieb:

Du kennst die ARM-Systeme in 20 Jahren noch nicht, kann genau so enden wie bei x86. Nennt sich Abwärtskompatibilität.

naja, wenn die ARMs nicht mehr mit zusätzlichen befehlen und macrocells erweitert werden können (z.b. die normalen register R0...R15 auf 64 bits aufgebläht werden o.ä. x86-krankheiten), dann ist's wohl auch damit vorbei. *heul*

Erhard Henkes

..

Nobuo T

;fricky schrieb:

Erhard Henkes schrieb:

Du kennst die ARM-Systeme in 20 Jahren noch nicht, kann genau so enden wie bei x86. Nennt sich Abwärtskompatibilität.

naja, wenn die ARMs nicht mehr mit zusätzlichen befehlen und macrocells erweitert werden können (z.b. die normalen register R0...R15 auf 64 bits aufgebläht werden o.ä. x86-krankheiten), dann ist's wohl auch damit vorbei. *heul*

Tja, keine Architektur lebt ewig. Dann lieber einmal komplett from scratch ueberholen.
Richtig schlimm wird es doch erst, wenn tausend neue obskure Register, krumme OpCodes und irgendwelche (Kompatibilitaets)Modi eingefuehrt werden.

Erhard Henkes

Ich bin noch nicht lange dabei beim OSDEV (genau genommen ernsthaft seit dem 13.03.2009, siehe Beginn dieses Threads), mache es auch nur aus grundlegendem Interesse, spielerischer Neugier und basierend auf dem Wunsch, die Dinge möglichst knapp, bildhaft und vor allem praktisch umsetzbar zu erklären. Denn ich denke, dass die Einstiegshürde relativ hoch ist. Da gehören beim x86 das A20-Gate und der Umstieg von RM nach PM dazu. Mir persönlich ist z.B. das Multitasking schwer gefallen, bis ich eine brauchbare Vorgehensweise bei tyndur fand. Auch das Paging bei x86 hat mich oft durcheinander gebracht. Das Wichtigste beim OSDEV ist, dass man "dran" bleibt. Das ist kein Thema für ein Wochenende, sondern ein mehrjähriges Projekt, also nur etwas für Leute, die sich in etwas "hinein bohren" können und wollen und dann auch nicht los lassen, wenn es zäh und holprig wird.

Wenn man aber über diese Einstiegshürde hinweg ist, dann ist es wie beim Tanzen: Man hat Lust dem eigenen Repertoire ab und zu eine neue Figurabfolge hinzu zu fügen.

Hier z.B. das Lesen von Sektoren von Floppy Disk im Kernel:
http://www.henkessoft.de/OS_Dev/OS_Dev3.htm#mozTocId967150
Diesbezüglich ist mir wichtig, dass ich solche externen Module möglichst einfach an PrettyOS anflanschen kann. Bezüglich IRQ-Interface ist unser Aufbau hier einfacher und damit eleganter, so dass man einiges einfach weglassen konnte.

Ich kann nur hoffen, dass ich mit meinem Tutorial im deutschen Sprachraum etwas dazu beitrage, dass Einsteiger in diese absolut empfehlenswerte Materie schnell praktische Erfolgserlebnisse haben. Das würde mich freuen.

wirst du denn auch versuchen windows und linux konkurrenz zu machen?

Erhard Henkes

Mal eine ganz andere Diskussion: Das Blöde und vielleicht zur Zeit dennoch Gute an Computern ist, dass man sie nicht individualisieren kann. Was müsste passieren, um PrettyOS ein lernfähiges oder zumindest adaptives Interface zum User zu verpassen? Ich denke mal, das gehört in den Bereich Shell / User-Space. Gibt es da schon Beispiele?

Erhard Henkes

wirst du denn auch versuchen windows und linux konkurrenz zu machen?

http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId533656

Als Gegenleistung bekommt man in der Regel nur den Genuss der intellektuellen Herausforderung, denn gegen MS Windows, Linux oder andere etablierte OS anzutreten, hat sicher keine Einzelperson vor. Wozu sollte das auch gut sein?

MS Windows ist ein hoch-professionelles OS mit Millionen von Code-Zeilen und Heerscharen von Fulltime-Planern, -Codern, -Testern. Linux, das ich bewundere, aber ungern selbst verwende, schafft es kaum, mit diesem Giganten aus USA mitzuhalten.

Nachdem nun die Grundlagen auf Basis x86 dargestellt wurden, würde es mich reizen, auf der User-Ebene etwas Neues zu schaffen, das in Richtung KI geht. Alleine kann ich allerdings nur Impulse setzen.

Erhard Henkes schrieb:

Linux, das ich bewundere, aber ungern selbst verwende, schafft es kaum, mit diesem Giganten aus USA mitzuhalten.

http://www.top500.org/stats/list/33/osfam

u_ser-l schrieb:

Erhard Henkes schrieb:

Linux, das ich bewundere, aber ungern selbst verwende, schafft es kaum, mit diesem Giganten aus USA mitzuhalten.

http://www.top500.org/stats/list/33/osfam

Das sagt leider rein gar nichts über die Code Qualität des Linux Kernels und die nicht gerade vertrauenserweckenden Praktiken des Maintainerteams (Kindergarten!) aus. Ich bin zwar auch ein Fan von Linux, aber ob der Kernel so gut und objektorientiert ist, wie der von Wind00f, da habe ich meine Zweifel.

Erhard Henkes

Zur Zeit freue ich mich aber noch über jeden kleinen Schritt, z.B. dass es mir gelungen ist, die Floppy-Sektor-Read-Funktion mit einigen Änderungen auch zu einer zusätzlichen Sektor-Write-Funktion umzuwandeln (alles via DMA). Nun habe ich endlich einen zweiten Ausgabekanal neben dem Bildschirm, allerdings noch rein binär.

hack0r schrieb:

Das sagt leider rein gar nichts über die Code Qualität des Linux Kernels und die nicht gerade vertrauenserweckenden Praktiken des Maintainerteams (Kindergarten!) aus.

[Ironie on:]

klar - der durchschnittliche Ottonormal-User ist ja in der Wahl seines OS auch kompetenter als der Architekt von mio. $ teurer Hardware in der Spitzenforschung.

[Ironie off:]

aber ob der Kernel so gut und objektorientiert ist, wie der von Wind00f, da habe ich meine Zweifel.

Ersteres ist hoffentlich ein (schlechter) Witz, und Letzteres ist absolut nicht abzusehen, es sei denn, du verdienst deinen Lebensunterhalt bei jenem mittelständigschem Unternehmen aus Redwood...
Ach kommt, bitte kein Linux vs. Windows Geflame hier. Das Tutorial mal "Linux-kompatibel" zu machen hätte zwar was für sich, aber wenn der Autor nun einmal Windows einsetzt , dann ist das halt so.

Edit:
Sehr richtig. Deshalb werde ich auch alles Weitere in Richtung dieser "Diskussion" loeschen.

Erhard Henkes

Ich habe momentan das Problem, das zwei Sektoren anstelle von einem Sektor geschrieben wird. Wo wird die Zahl der Sektoren bezüglich DMA genau gesteuert?
http://lowlevel.brainsware.org/forum/index.php?topic=2244.0
http://www.henkessoft.de/OS_Dev/Downloads/100.zip
Vielleicht kann jemand helfen? Die Daten werden via DMA gelesen/geschrieben (0x1000 als Puffer).

Erhard Henkes schrieb:

Ich habe momentan das Problem, das zwei Sektoren anstelle von einem Sektor geschrieben wird.

teste die read/write funktionen separat. wird wirklich nur ein sektor (512 bytes) beschrieben und gelesen (benutze ein externes programm, z.b. 'nen disk-editor wie z.b. 'winhex' zur prüfung)?
falls nicht, schau im user manual des DMA-controllers nach. vielleicht transfererierst du 16-bit words anstelle von bytes oder sowas.