Thema: Delta Nanocore

[clemensoft]

Hat irgendwer Lust, dabei mitzumachen? Ich habe schon einen ftp-Server aufgesetzt, und ein Forum kommt auch bald, ebenso eine Webseite. Die Planung des Projekts wird von mir durchgeführt, an meinem Linux-Rechner, an dem regelmäßig (Immer Sonntag Vormittags) Builds durchgeführt werden.
Hier mal der Designtext

Delta Nanocore ist ein sehr sicheres Betriebssystem, obwohl es kooperatives Multitasking benutzt. Wenn Prozesse nicht kooperieren, merkt sich der Nanocore dies und killt den Prozess nach einer Bestimmten Zeit. Der Benutzer wird sofort informiert. Das Ziel ist, den Kernel möglichst klein zu halten, und alle unnötigen Funktionen in Module zu verpacken. Diese Reduzierung erfolgt bis zu einer Ebene, wo Software vollkommen Betriebssystemunabhängig laufen kann. Für diesen Nanocore werden dann Module programmiert, wie zum Beispiel Grafiktreiber oder Diskettentreiber.
Basierend auf diesem Prinzip wird eine Grafische Benutzeroberfläche programmiert, die auf bestimmte Module zurückgreift.
Der Nanocore wird von einem in zwei Stufen geteilten Loader geladen. Die erste Stufe (Stage-B) wechselt in den Protected Mode und lädt die zweite Stufe (Stage-M), einen monolithischen Kernel, der den Prozessor und andere Geräte auf Delta vorbereitet und auf Kompatibilität prüft. Ist alles ok, wird der Nanocore von Diskette oder Festplatte oder Netzwerk geladen. Er wird anhand zweier Prüfsummen analysiert (zum Beispiel auf Infektion durch Viren). Wurden Fehler festgestellt, wird der Benutzer informiert. Falls Stage-M Zugriff aufs Internet oder Netzwerk hat, wird ein aktueller Nanocore heruntergeladen und installiert. Dann werden noch die Module überprüft, die geladen werden sollen. Wird hier kein Fehler oder Inkompatibilität festgestellt, werden die Module in eigene Adressräume geladen. Jedes Modul wird initialisiert. Danach wird der Nanocore an eine bestimmte Speicheradresse geladen. Dann werden dem Nanocore an einer anderen Speicheradresse Parameter übergeben, also welches Modul (in diesem Fall das GUI) nach dem Start aufzurufen ist usw.Dann wird der Nanocore aufgerufen. Er zerstört per Speicherüberschreibung alles vom Loader. Dann schaut er in seiner Parameterliste nach, welches Modul er zuerst aufrufen soll. Dieses Modul wird dann in einen geschützten Speicherbereich geladen und ausgeführt. Dieses Sicherheitsprinzip setzt sich im ganzen System durch, alles ist isoliert, Kommunikation zwischen Objekten nur durch Pipes und System Calls.

Ich bin schon beim Coden und grade dabei, ein VESA-Modul zu schreiben.

[TeeJay]

Ohne dir den Mut nehmen zu wollen....aber...

Ein OS mit kooperativem Multitasking ist keinesfalls sicher und auch veraltet.
Es gibt einen guten Grund warum heutige OS alle preemptives Mutlitasking benutzen.

Zum einen kann so das OS darüber entscheiden welcher Prozess wie viel CPU Zeit bekommt (was mitunter auch vom User eingestellt werden kann), zum zweiten läuft das OS weiter, auch wenn ein Task hängt und zu guter letzt erspart man dem Anwendungsprogrammierer viel Arbeit.
Denn so müsste er immer abschätzen an welcher Stelle im Code er das Kommando wieder zurück ans OS gibt und das ist mühsam und fehlerträchtig.

Daher rate ich dir dein Design nochmal etwas zu überarbeiten.

[clemensoft]

Ich meine mit kooperativ lediglich, dass die Anwenderprogramme dem Kernel mitteilen, wann der nächste Taskswitch erfolgen soll. Dafür kriegen Programme eine bestimmte Zeitspanne, die sie nicht überschreiten dürfen, sonst werden sie halt beendet.

[TeeJay]

Aber dann hat trotzdem der Anwendungsentwickler das Problem das er das dem OS mitteilen muss.

Warum denn so umständlich machen? Einfach preemptives Mutlitasking machen und dann muss sich der Anwendungsentwickler um nix mehr kümmern. Was für einen Sinn würde es denn haben wenn das Programm mitteilen kann wann der nächste Wechsel stattfinden soll?

[Roshl]

Zudem wäre das  unfair^^
Einige Programme könnten die Zeit dann voll nutzen bis sie beendet werden. Andere dann nicht, obwohl se gerne mehr hätten.
Vielleicht hat man abschnitte in denen viele Berechnungen gemacht werden müssen, was lange dauert. Wer Unterbricht da schon gern freiwillig?

[Jidder]

Aber dann hat trotzdem der Anwendungsentwickler das Problem das er das dem OS mitteilen muss.

Wenn ein Programmierer in einem Delta Nanocore-Programm Systembefehle nutzt wird ja bei deren Aufruf in den Kernelmodus gewechselt. Hier kann das OS entscheiden ob es dem Programm die Ausführung entzogen werden muss, weil es unkooperativ ist. Das ist z.B. bei dem Befehl sleep() sinnvoll - das programm will ja keine CPU-Zeit mehr - oder bei Dateioperationen, die u.U. eine bestimmte Zeit dauern, in dem ein anderes Programm laufen kann. Bei Windows hab ich es beobachtet, dass sogar bei einem vergleichsweise schnellen (da keine HW-I/O) Systembefehl wie CreateThread() ein Taskswitch erfolgt. Das ist also eine gängige Sache. Aber das kann daran liegen, dass Windows (IIRC) früher auf komplett kooperativem Multitasking basierte.

Ich fände es gut, wenn du das kooperative Multitasking beibehältst.

Ich finde das mit den mehreren Stages viel zu kompliziert. Wenn du Stage-M mit Netzwerk- und Internetzugriff ausstatten willst, ist Stage-M schon ein ausgewachsenes Betriebssystem. Außerdem musst du für den Kernel und für Stage-M jeweils einmal Netzwerktreiber/FS-unterstützung schreiben. Auch wenn diese Treiber sich sehr ähnlich oder sogar die gleichen sein sollten, ist das ein erheblicher Aufwand. Ich würde den Stage-M vollständig in den Kernel integrieren. Der Kernel kann sich auch selbst checken und evtl. Updates herunterladen und dann sich selbst neuladen und booten.

Von Festplatte, Netzwerk oder Diskette booten kann auch GRUB. Wenn man den Bootserver (oder wie das Ding heisst, das halt dann die Datei für einen Netzwerkboot bereitstellt) entsprechend konfiguriert kann der bestimmt auch selber das System aktuell halten.

Ich würde auf jedenfall mir das Delta Nanocore gerne mal anschauen.

PorkChicken

[TeeJay]

Es spricht ja nix dagegen, bei Systemcalls, die wohl etwas länger brauchen oder auf HW warten müssen, den Task die CPU zu entziehen.

Aber kooperatives Mutlitasking als solches ist alt und nit gut.
Man sollte die Kontrolle vollends beim OS belassen. Nur so können viele Tasks mit unterschiedlichen Bedürfnissen und Prioritäten ordentlich bedient werden.

[clemensoft]

@PorkChicken:

Was für eine Rede, aber ich stimme voll und ganz zu!

[joachim_neu]

@PorkChicken: du übersiehst eines: du gehst davon aus, das Programm sein ein gutes! Auf dem OS muss ich nurn Virus einbringen, der keine Sys-Calls benutzt, und schon ist das System platt, weil es nimmer kontrollieren kann! es hat keine kontrollinstanz mehr, weil der Virus nix macht, bei dem der Kernel kontrollieren könnte!

[clemensoft]

@joachim_neu:
Dafür gibt es einen Timer-Interrupt, der guckt, wie lange das Programm schon rumm,acht, und wenns zulange ist, dann zAcK

[TeeJay]

Was heisst denn *Zack*?
Zack der Task wird gewechselt oder Zack der Task wird gekillt?

[clemensoft]

zack heißt ja nachdem, wie sich das programm verhält
vorerst wird es gekillt.
die beste idee wäre, den user zu fragen: "Der Prozess WINWORD verhält sich wie vermutet unkooperativ. Drücken sie Beenden, um den Prozess zu beenden oder Nicht Beenden, um den Prozess trotzdem zu beenden "

[elfish_rider]

Den Benutzer würde das in den Wahnsinn treiben, 1. wüsste er nicht, was es bedeutet, 2. will er doch nur abgestürzte Programme beenden.

[joachim_neu]

außerdem ist das bei einer solchen menge von taskwechseln ziemlich schwierig... und ein virus könnte einfach die max. zeit blockieren und dann abgeben. dann crasht das system zwar net, aber es wird unbenutzbar langsam!

[Lizer]

Die Kontrolle an den Kernel abzugeben ist auch so möglich, unter Linux z.B. mit usleep(1); Wenn sich ein Prozess nämlich schlafen legt, macht der Kernel logischerweise mit dem nächsten Prozess weiter. Das Beispiel usleep(1) legt den Prozess für eine Microsekunde schlafen. D.h. wenn der Kernel sonst nichts zu tun hat (z.B. andere Prozesse ausführen), kann der Prozess nach einer Mikrosekunde weiter ausgeführt werden, was nicht wirklich ein Geschwindigkeitsverlust ist.

[clemensoft]

@joachim_neu: die max. zeit ist so ausgelegt, dass das system noch benutzbar wird

[joachim_neu]

jo, wenn es noch benutzbar ist, dann isses zu schnell für den anwender, jedes mal ne msg wegzuklicken über ein unkooperativen virus außerdem könnte der virus duplikate aufrufen, und damit den benutzer ins boxhorn jagen

[mastermesh]

@joachim_neu

Das Problem hast du aber auch beim präemptiven Multitasking.

[joachim_neu]

jo, es sei denn du machst es mit gerechtigkeit, sodass der task dann langsam auf unterste ebene wandern würde, und immer weniger ins gewicht fällt!

[clemensoft]

@joachim

Schluss mit dieser Virendiskussion, wer schreibt denn Viren für ein Betriebssystem, das von 0,00000000001% (noch hehehe...) der Menschheit benutzt wird?