Thema: Grundsätzliche Frage die geklärt werden sollte ;)

[Thinker]

Also morgen erstmal,

so ich bin nun wieder angefangen an meine Betriebssystem zu arbeiten, das ich vor 2 Jahren begonnen habe. War ein simples OS ähnlich wie Linux in den ersten Versionen mit Monolitischen Kernel. (Habe das vor ca. 2 Monaten gelöscht)
So daher bin ich jetzt erstmal dabei Brainstorming zu betreiben wie die neue Version davon aussehen sollte. Also im moment schwanke ich noch zwischen 3 Kernelarten: Mikrokernel, Nanokernel oder Exokernel. Ich tendiere bisher eigentlich mehr zum Exokernel, auch nachdem ich mir XoK mal angesehen habe. Was meint ihr?

Generell die Rahmeneigenschaften sind eigentlich die, die ich schon vor 2 Jahren gemacht habe: vorerst Shell-Only, schwerpunkt auf Netzwerkbetrieb (also Server)
Daraus ergibt sich dann auch eine große anforderung an die Sicherheit des Systems. Das aber nun erstmal nur so als nebeninformation.

[GhostCoder]

Hi,

ich finde den Exokernel sehr interessant, vorallem da solch ein System extrem schnell ist.
Das Problem ist nur, dass du sehr viel Speicher brauchst, wenn z.B. der ganze POSIX Layer in jedem Addressraum eines Programmes liegt. Selbst mit COW und shared pages ist das beträchtlich...

Wenn du Sicherheit willst, ist der Mikrokernel wohl der beste Ansatz für dich, aber hier hast du ein Problem mit Geschwindigkeit!

Habe das bei mir so gemacht, das ich (jetzt) ein Mikrokernel ähnliches System habe, aber Abstriche mache. D.h. es gibt nurnoch einen virtuellen Addressraum und die Prozesse werden durch Segmentierung getrennt. Das macht Messaging(Das Kernproblem des Mikrokernels) zu einer simplen Addition, beschränkt aber bei vielen Prozessen den privaten Addressraum( und ist außerdem nicht mehr POSIX konform).

Gruß GhostCoder

[Thinker]

Ja über das Problem mit der menge an Speicher bei dem Exokernel hab ich mir auch schon viele Gedanken gemacht.

Am besten ist es ja immernoch wenn ich die gute mitte zwischen den Vorteilen des Exokernels und des Microkernels finde. Das könnte aber schon etwas schwieriger werden.

Nunja, hat sich schon jemand mal mit dem Nanokernel auseinandergesetzt?

[n3Ro]

Also mit dem Nanokernel ist das so eine Sache. Im Prinzip bezeichnet ma damit auch nur Microkernel, aber die der 2. Generation, die wirklich klein und schnell sind (also nicht wie MACH sondern eher wie L4). Aber eigentlich gibt es diesen Begriff nicht wirklich.

[Legend]

Also ich weiss nicht, wenn ich nen Exokernel sehe, denke ich mir auch immer das ich (fast) auch gleich DOS benutzen kann. Zwar wird noch versucht sicher zu trennen (das heisst z.B. das ich im Exokernel doch nen halben IP-Stack brauche?), aber der Vorteil des hardware-unabhängigen Programmieren geht wohl verloren - dafür ist wohl dann so eine OS Bibliothek da, die alle dann entwickelt werden wollen.

Im Endeffekt durfte das bestenfalls darauf hinauslaufen das 99% der Programme die selbe Lib benutzen, und vielleicht Web- und Datenbankserver etwas direkter auf Netzwerk und Festplatten zugreifen.

[GhostCoder]

Im Endeffekt durfte das bestenfalls darauf hinauslaufen das 99% der Programme die selbe Lib benutzen, und vielleicht Web- und Datenbankserver etwas direkter auf Netzwerk und Festplatten zugreifen.

Und genau das ist der Vorteil! Du kannst über die OS libs Unix und Windows (Wenn du die Sourcen hast) Anwendungen auf deinem System laufen lassen. Wenn du aber eine Andwendung laufen lassen willst, die auf Gewschwindigkeit aus ist, nimmst du eine angepasste libos.
Für ein(en) Spiel(er) sind wichtige Faktoren...

Gruß GhostCoder

[Legend]

Na ja, abgesehen davon das ich manche Benchmark's zu diesen Kernel einfach nicht glaube. Bei einem Dokument hatte ich gesehen das sie "cp" gebenchmarkt haben und das es angeblich 3x mal so schnell war als unter Linux. Vielleicht hätten sie auch unter Linux mal DMA anmachen sollen (oder sowas)?

[GhostCoder]

Das kann schon sein,

sagen wir "cp" kopiert mittels read/write eine 8MB große Datei mit nem 1024 Byte Buffer, das macht alleine 8192 Syscalls, die beim Exokernel entfallen. Wobei die wahrscheinlich direkt auf Disk geschrieben haben. Linux muss sich ja noch um's VFS kümmern, die Verwaltung vom Disk Treiber,FS, usw.

Gruß GhostCoder

[GhostCoder]

Quatsch,

8192*2 Syscalls, einen für read, einen für write...

[Legend]

Linux muss sich ja noch um's VFS kümmern, die Verwaltung vom Disk Treiber,FS, usw.

Gruß GhostCoder

a) Das entfällt auch beim Exokernel nicht komplett. (Oder willst du gar kein Dateisystem mehr benutzen). Das einzige was du dir ersparst sind die Ring Transisitions, und vielleicht noch das VFS (wenn du schon eine sehr spezielle, für eine allgemeine, ZU spezielle Lib hast).
b) Da war die Platte eigentlich der begrenzende Faktor, da auch Linux die komplett ausnutzt. Und die wird wohl kaum schneller durch einen Exokernel.

Du verlierst an diesen Stellen bei weitem nicht die Zeit die da angeblich eingespart wird.

[GhostCoder]

Ob das jetzt Sinnvoll ist oder nicht, eine Lib zu haben, die direkt raw auf Platte schreibt sie dahingestellt...aber schneller ist es in jedem Fall!

Gruß GhostCoder

[Legend]

Dafuer brauch ich aber keinen Exokernel,
ich kann unter Linux z.B. auch direkt auf Disketten oder Partitionen schreiben, solange sie nicht gemountet sind.

[GhostCoder]

Ja,
aber unter Linux sind und bleiben das Systemcalls...

[Legend]

Und unter einem Exokernel nicht wenn ich eine Partition uebergebe? Das waere mal ein interressanter Punkt. Zugriff auf den Plattencontroller darf man ja der Anwendung ja nicht geben, solange die nicht alle Platten die an dem haengen haben darf. Deswegen muss ich ja irgendwie von Festplattencontroller auf eine einzelne Partition kommen, wohl in Software. Und die muss vor der Anwendung geschuetzt sein.

Abgesehen davon das ein reines Kernelprojekt wohl am besten alle drei Arten koennen sollte (je nach compilezeit optionen ...)

[SSJ7Gohan]

Ich verstehe nicht wirklich, wie der Exokernel funktionieren soll.
Was für Aufgaben hat der Kernel und wie greifen die Programme auf die Hardware zu? Irgentwie muss ja sichergestellt werden, das die Programme sich nicht gegenseitig belästigen, z.b. 2 Programme auf den FDC zugreifen.
Direkt können die Programme also nicht auf die Hardware zugreifen, ohne das die Sicherheit vernachlässigt wird, also sind doch weiterhin Ringchanges und Systemcalls nötig, oder?

[Legend]

Also wenn ich einem Programm z.B. direkt eine ganze Floppy gebe (und nur ein Laufwerk habe), koennte ich mir ueberlegen, dem Programm Zugriff auf die FDC Ports usw. zu geben und IRQs direkt durchzureichen. DMA brauch noch eine Extrabehandlung, da ich ja nicht andere DMA Kanaele manipulierbar machen will.
Dann koennte ich praktisch wie in einem Mikrokernel das Programm als Treiber benutzen, nur das ich dann Treiber und das eigentlich Programm in einem Addressraum wieder haette.

Aber das waere noch nicht genug um einen eigenen Namen fuer so ein Konzept abzugeben.

[SSJ7Gohan]

Aber wenn ein anderes Programm gleichzeitig auf den FDC zugreifen würde, würde er nicht richtig arbeiten, es muss da also irgenteinen Schutz geben. Die einzige Möglichkeit die mir einfallen würde, ist, die Portzugriffe über Systemcalls zu machen und so zu kontrolieren. Aber das wäre dann wieder ein Geschwindigkeitsverlust.

[Legend]

Dafuer haette man wohl ein Konzept wie der Exclusive Mode von DirectX. Dann oeffnet die Anwendung die Floppy eben exklusiv. Wuerde in sofern nicht "richtig" arbeiten, als das die 2. Anwendung nicht zugreifen koennte.

[SSJ7Gohan]

Aber wie sorgt man dafür, das die andere Anwendung sich daran, dass die erste Anwendung exklusive Rechte hat, hält und nicht zugreift?

[Legend]

Die Kontrolle wer welche Zugriffsrechte bekommt MUSS immer noch beim Kernel liegen (wie bei einem Microkernel). Dieser wird dann auch wissen, wer welche Hardware belegt, und die noetigen Resourcen nicht herausgeben.

Selbstverstaendlich wird auch bei einem Exokernel wohl kaum jede Anwendung einfach so auf die Hardware zugreifen koennen, ohne Kontrolle. Der Sinn sollte ja sein, soweit direkten Hardwarezugriff zu ermoeglichen, solang man die Hardware sicher teilen kann. Und genau da faengt fuer mich das Problem mit dem Konzept an, den bei wohl 90% der Hardware ist das nicht gerade einfach (und besonders ohne eine Art Treiber) zu bewerkstelligen.