Thema: Planung der Kernelentwicklung

[ChristianF]

Hallo Leute,
ich bin ja momentan damit beschäftigt, ein kleines Betriebssystem in Assembler zu schreiben, das von GRUB geladen wird. Das Laden passt und auch Text wird ausgegeben, was sicherlich noch verbessert werden muss.
Nun möchte ich allerdings nicht wieder den Fehler begehen und einfach drauf los zu schreiben, da ich deswegen immer wieder etliche Parts neu schreiben musste.
 
Ich frage mich nun, in wie weit ich dieses Projekt planen kann. Meine ersten Vorgabe sind einfach nur, dass es auf einem 32Bit Prozessor (i386-kompatibel) laufen muss und dass es ein Mikrokernel werden soll. Wie habt ihr die Projekte geplant? Überhaupt nicht, etwas, ...
Habt ihr da, falls geplant wurde, das ganze als normalen Text einfach geschrieben, wo die ganzen Vorgaben drinne standen/stehen (z.B. i386, Paging, Hardware Multitasking, ...) oder wie wurde das gemacht?
 
Gruß Christian
 
PS: Ich bin für jede Antwort dankbar.

[rizor]

Überhaupt nicht, etwas, ...

Ich habe mir vorher überlegt was mein Kernel alles können muss.
Das habe ich mir nur grob überlegt und noch keine Methoden benannt oder so (wie man es in UML machen würde).
Beim programmieren fällt mir dann auf, auf was geachtet werden muss.
Wenn ich das noch nicht implementiert habe, dann gibt es einfach ein TODO und das wars.
Wenn ich dann wieder einen Part abgearbeitet habe, werden halt die TODOs durchgeschaut.
Habe zum Teil bis zu 50 TODOs.

Habt ihr da, falls geplant wurde, das ganze als normalen Text einfach geschrieben, wo die ganzen Vorgaben drinne standen/stehen (z.B. i386, Paging, Hardware Multitasking, ...) oder wie wurde das gemacht?

Wenn ich einen Teil entwickel, überlege ich mir vorher was alles rein muss und was ich reinmachen möchte.
Das wird einfach stichpunktartig aufgeschrieben.
Wenn ich dann die Methoden selbst entwickel skizziere ich mir die Situation und schreibe mir eine art Ablaufdiagramm.
Dadurch lassen sich Fehler recht gut vermeiden.

Hoffe, dass ich dir einen Überblick geben konnte.

Gruß
rizor

PS: Wenn du alles durchplanen willst und weißt was alles rein soll, würde ich dir UML empfehlen.
Dadurch hast du die Möglichkeit alles nötige zu definieren.
Dann brauchst du im Prinzip nur och runter-coden.
Ist halt ein extremer Aufwand ein ganzes Projekt durchzuplanen.
Dafür sollte es aber keine Probleme geben

[DerHartmut]

Ich hab mir erstmal überlegt, welche Architektur (war für mich relativ klar...), dann das welche Art Kernel und was alles in den Kernel kommt usw..

Dann habe ich, so doof es klingen mag, mir überlegt, was in welche Datei kommt und wie sie bennant wird. Halte ich für mich persönlich wichtig, damit ich genau weiß, wo was drin ist.

Dann hab ich mir aufgeschrieben, was gemacht werden muss, dann nen kleines Diagramm, was in welcher Reihenfolge geschehen muss und "drauflos" geschrieben.

[ChristianF]

Ich denke UML wäre Overkill. Allerdings sollte ich mich so langsam doch mal damit beschäftigen, da man so was ja für die Abschlussprüfung braucht...
 
Was mich interessieren würde, ist, wie das in Tyndur gemacht wurde/wird.

[kevin]

Ich glaube, die einzige Vorüberlegung, die es tatsächlich in die Praxis geschafft hat, war, dass es einen Mikrokernel gibt und nur Speicherverwaltung, Prozessverwaltung und IPC im Kernel sein sollen (das ist natürlich nicht vollkommen wahr, aber als grobe Orientierung stimmt das).

Der Rest der Entwicklung ist eigentlich evolutionär passiert, d.h. wie etwas implemeniert wird, wurde genau dann festgelegt, wenn man es gebraucht hat. So läuft das im Prinzip nach wie vor - jemand überlegt sich, was man tolles brauchen könnte, und dann wird das auf die vorhandene Basis aufgesetzt.

[ChristianF]

Ich habe mal angefangen eine Roadmap zu schreiben.
Hier schreibe ich die einzelnen Versionen rein, und was dann neues in den Kernel rein soll. Die Schritte an sich sind sehr klein:
 
Version 00.00.00

• Multiboot kompatibler Kernel

Version 00.00.01

• Text ausgeben
• Bildschirm löschen

Version 00.00.02

• GDT Initialisieren
• GDT laden

...
 
Bei der Implementierung mache ich mir dann Gedanken, wie ich das am besten einbaue und prüfe mit Hilfe der Roadmap, ob diese Funktion eventuell später nochmal irgendwo gebraucht werden könnte...

[ehenkes]

Ich finde die Planung der API, also des syscall-Interfaces, am schwierigsten, weil ich hier bisher nirgends eine klare Strategie erkennen kann, lediglich Standards wie POSIX. 

[erik.vikinger]

Hallo,


plane nicht zu viel, die meisten Pläne erweisen sich während der eigentlichen Ausführung als unrealistisch (sagt nicht nur meine Berufspraxis).

Versuche ein grobes Konzept-Papier (das darf ruhig auf echtem Papier, A3 oder größer, sein) und verfeinere das ganze Etappenweise währen der Umsetzung.
Nützlich ist auch eine hierarchische Dokumentation :
- grobes Konzept-Papier (muss nicht alle Details enthalten)
- einzelne Module sollten sicher noch mal einzeln und etwas detaillierter dargestellt werden
- in jeden Verzeichnis eine "Info.txt" welche grob umreißt worum es geht und welche Funktionalität sich in welcher Datei befindet, hier sollten auch Zusammenhänge erklärt werden die nicht im Quell-Code offensichtlich sind
- saubere Dokumentation im Quell-Code, die sollte immer den tatsächlichen Ist-Stand möglichst genau beschreiben. Offene Baustellen sollten als solche zu erkennen sein.
- Ideen und andere TODOs können in eine "TODO.txt".

Was APIs angeht sollten die Erfordernisse im Vordergrund stehen, implementiert werden muss das was gebraucht wird. Meistens kristallisiert sich während der Umsetzung erst heraus was Sinnvoll ist und was nicht.

Habe vor allem auch den Mut die Dinge die sich als Blöd erwiesen haben umzuwerfen und es noch mal ordentlich zu machen. Dumme Krücken durch ein Projekt zu schleifen kosten immer mehr Kraft als es noch mal neu aufzusetzen.


Grüße
Erik

[kevin]

Ich finde die Planung der API, also des syscall-Interfaces, am schwierigsten, weil ich hier bisher nirgends eine klare Strategie erkennen kann, lediglich Standards wie POSIX. 

Das muss auch so sein. In der API spiegelt sich schließlich wieder, was dein OS am Ende ist. Hardware ansteuern wird jedes OS mehr oder weniger gleich, weil die Hardware eben auf eine bestimmte Weise programmiert werden muss. Wenn du nicht ein vorhandenes System nachbauen willst, ist die API der Platz, an dem du dich austoben kannst und bei der du wirklich deine eigenen Vorstellungen unterbringen kannst.

[bluecode]

Ich finde die Planung der API, also des syscall-Interfaces, am schwierigsten, weil ich hier bisher nirgends eine klare Strategie erkennen kann, lediglich Standards wie POSIX.

Ich würde POSIX nicht als Standard auf der Syscall-Ebene bezeichnen. Man kann natürlich (einige) POSIX-Funktionen als Syscalls implementieren, man kann aber auch POSIX komplett über eigene APIs mit eigenen Konzepten "emulieren". Es gibt ja schließlich auch Microkernel die in der libc dann POSIX unterstützen (zB MINIX, oä).
Ansonsten gebe ich taljeth natürlich Recht. Die API ist das Feld in dem man eigene Konzepte verwirklichen/probieren kann. Erfahrungsgemäß scheitert das teilweise (zB. ist meiner Einschätzung nach RPC bei tyndur eher ein Fehlschlag), aber so lernt man natürlich auch was.
edit: Man kann natürlich gewisse Standards (C und POSIX) nicht komplett unberücksichtigt lassen, zumindest wenn man irgendwann mal einen Assembler oder C-Compiler oder ähnliche Software portieren möchte. Es hat schließlich nicht jeder genug Lebenszeit um all das selbst zu schreiben.

Zur Planung allgemein würde ich sagen, dass das einfach keinen Sinn macht, wenn man zu wenig Wissen in dem Bereich den man durchplanen möchte hat. Es gibt dann einfach zu viele "unknown unknowns" die man sicherlich nicht einplanen kann. Außerdem ist der Aufwand den man dann in der Planungphase betreiben müsste (zB diverse Spezifikationen durchlesen um korrekt planen zu können) unglaublich groß.

[ehenkes]

Wenn du nicht ein vorhandenes System nachbauen willst, ist die API der Platz, an dem du dich austoben kannst und bei der du wirklich deine eigenen Vorstellungen unterbringen kannst.

Diese Aussage beruhigt mich, denn genauso habe ich es gesehen, war mir aber nicht sicher, ob das mit der Kreativität so richtig ist. 

Es gibt ... zu viele "unknown unknowns" die man sicherlich nicht einplanen kann.

Starker Satz! 

[kevin]

Wenn du nicht ein vorhandenes System nachbauen willst, ist die API der Platz, an dem du dich austoben kannst und bei der du wirklich deine eigenen Vorstellungen unterbringen kannst.

Diese Aussage beruhigt mich, denn genauso habe ich es gesehen, war mir aber nicht sicher, ob das mit der Kreativität so richtig ist. 

Naja, je kreativer man wird, umso höher wird die Wahrscheinlichkeit, dass man später an manchen Stellen merkt, dass es wohl gute Gründe gibt, warum das kein anderer so macht.

Aber andererseits, je weniger kreativ man ist, umso langweiliger wird das OS, weil es nichts ungewöhnliches bietet. Vermutlich macht es mal wieder die richtige Mischung.

[DaCodaaa]

Ich glaube ein Betriebssystem ist alleine doch nicht wirklich für den Benutzer Interresant. Interressant ist eher was man damit anfangen kann: also letztenendlich Programme und Spiele, und es wäre nicht machbar das alles selber zu machen.

aber ich glaube wir gehen hier langsam Offtopic...