Moin Moin liebe Leute willkommen zum nächsten Video zur Vorlesung Betriebssysteme. Jetzt Kapitel

2 erster Teil worum soll es da gehen? Es soll darum gehen wie übersetzt man ein Betriebssystem

für ein gegebenes Rechensystem. Typischerweise in unserem Fall ein PC. Also was wir uns angucken

wollen ist jetzt gar nicht so das innere des eigentlichen Betriebssystems, sondern mehr das

was außenrum noch zu bedenken ist. Also wie entwickelt man so ein System, wie kompiliert

man, wie linked man ist, wie debuggt man ist und so weiter. Ja also unsere Agenda wird sein, wir

gucken uns mal an wie das ganze Wort einzuordnen ist. Wir gucken uns an wie ein Betriebssystem zu

übersetzen zu linken ist, wie man es booten kann, wie man es debuggen kann. Ja, ordnen wir das

Problem zunächst einmal ein. Ihr werdet merken, Betriebssystementwicklung ist viel, viel komplizierter,

also das außenrum, um das eigentliche Betriebssystem zu entwickeln, ist komplizierter als ein normales

Anwenderprogramm zu entwickeln. Wo liegen die Schwierigkeiten? Ja es fängt schon an beim

Übersetzen. Übersetzen ist schon anders als bei einem normalen Anwenderprogramm. Alle Leute

wollen Anwenderprogramme entwickeln, deshalb ist alles für Anwendungsprogrammierung passend

eingestellt. Da funktioniert alles out of the box. In unserem Fall überhaupt nicht. Gucken wir uns

gleich an. Auch das Starten eines Betriebssystems, in unserem Fall dann ein Bootvorgang, ist natürlich

was ganz anderes als ein beispielsweise Starten eines normalen Anwenderprogramms aus einer

Shell nach Haus. Und das letzte auch testen und debuggen ist sehr viel anders als das Debuggen

eines normalen Anwendungsprogramms. Gehen wir ein paar Punkte schon mal kurz an. Das erste was da im

einfällt beim Debuggen ist das sogenannte Printf-Debugging. Kennt ihr alle aus SP. Was heißt

Printf-Debugging? Printf heißt ich baue in mein zu testendes System einfach viele Ausgaben mit ein,

lasse es dann laufen und anhand der Ausgaben sehe ich dann hoffentlich was mein Programm so tut oder

eben auch nicht tut oder falsch tut. Klingt erstmal gut in der Praxis, aber gar nicht so einfach.

Es gibt verschiedene Probleme. Erstes Problem ist ja vielleicht entwickeln wir ja ein Betriebssystem

für eine kleine Waschmaschine. Waschmaschine hat vielleicht aber gar kein Display und Printf ohne

Display. Wie soll das funktionieren? Nächster Punkt der vielleicht schwierig ist für die Ausgabe.

Selbst wenn wir einen Bildschirm haben brauchen wir irgendeine Art von Ausgabetreiber. Ihr braucht

Unterprogramme namens Printf, die dann irgendwie auf dem Bildschirm was ausgeben. Diese Unterprogramme

muss man erstmal schreiben, die muss man Debuggen und wie debuggt man dann dieses Printf ohne

Debugger zu haben. Gucken wir uns noch genauer an. Nächstes was einem vielleicht einfällt sind

Emulatoren. Ihr kennt so KVM, QEMU, die Variante die es unter Linux so gerne gibt, aber im Prinzip

natürlich auch die kommerziellen wie VMWare oder so. Auf diesen Emulatoren kann man natürlich sein

Betriebssystem laufen lassen. Heißt das booten ist dann natürlich schon mal ein bisschen einfacher.

Man muss nicht sein echten Rechner hoch und runter fahren. Man kann dann virtuell Rechner nutzen.

Was es da zu beachten gibt gucken wir uns in diesen Testen und Debuggen Kapitel nochmal genauer an.

Nächster Punkt der einem vielleicht einfällt wenn es ums Debuggen geht sind die Debugger.

Also ihr kennt in der Linux Welt typischerweise den GDB oder GDB mit irgendwelchen verschiedenen

Frontends. Der funktioniert wunderbar allerdings auch nur für Benutzerprogramme. Warum? Er benutzt

die Schnittstelle des Betriebssystems die Debugger Schnittstelle um beispielsweise User Programme zu

starten, zu stoppen, in den Speicher und so reingucken zu können. Diese Schnittstelle des

Betriebssystems haben wir nicht. Dementsprechend läuft der GDB auch nicht. Was eventuell geht, etwas

einfacher geht aber auch da muss man erstmal handanlegen dass das funktioniert sind sogenannte

Remote Debugger. Das ist so ein sogenanntes Stop auf dem zu untersuchenden Rechner. Das ist so ein

Mini Hilfsprogramm das von außen typischerweise über diese Schnittstelle Kommandos entgegennimmt.

Dann die entsprechende Untersuchung auf dem Rechner durchführt und die Antwort dann an einen

Debugger der von außen diese Kommandos absetzt zurückschickt. Heißt dann eben der Remote Debugger

der auf einem anderen Rechner läuft. Der schickt über diese Schnittstelle lieber stopp guckt auch

mal was in Speicherzelle 25 steht und dieser stopp guckt dann in Speicherzelle 25 und schickt das

Ergebnis über diese realischen Stelle zurück an den Debugger auf dem anderen Rechner. Dieses

kleine Untersuchungssoftware Stückchen das kann man eventuell schreiben muss man aber auch erstmal

schreiben vorher geht auch Remote Debugging nicht. Was am einfachsten ist, ist natürlich wenn der