Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: gismo2004 am 05. May 2004, 14:54
-
hi leute langsam glaub ich ich verblöde anstatt schlauer zu werden.
Kann mir mal jemand bitte bitte erklären was allen in den kernel gehört?
nein ich bitte niemanden hier nen koppletten kernel aufzuzeigen wenn jemand so net wäre mir kurz in stichworten zu schreiben was ich in den kernel einbauen sollte würde es mir schon ausreichen. Achja ich hab mir schon den linux kernel 1.0 angeschaut aber irgendwie klappt es alles nicht. Um es kurz zu sagen ich brauche ein paar stichworte.
Schon mal vielen dank (ein verblödener) gismo :-)
-
1) Willkommensschrift
2) Funktion zum speichern/lesen von Dateien
3) Spionagefunktion ;-)
4) Hilfe
5) Credits
6) ein Compiler
7) Verabschiedungsschrift
Zusätzlich:
1) Benutzeroberfläche
2) Speichern beim ausschalten des Rechners (ich meine wenn man auf den Knopf drückt, dass der nicht gleich ausschaltet, sondern dass er erst alles abspeichert)
Joa, das sind die Grundlegenden sachen
-
naja, nen compiler würd ich net gerade innen kernel einbauen...
-
hey super danke für eure antworten man das ging ja super schnell.
@ DaniilKharlamov
heiß ich microsoft???
naja ich mach mich dann mal an die arbeit
und nochmals danke!
gismo
-
"3) Spionagefunktion ;-)"
Wieso spionage? Das sind sicherheits routinen, die es verhindern, dass der user ausversehen etwas falsch macht. Daher wird jede aktivität sofort an microsoft gesendet und ausgewertet ^^
-
@DaniilKharlamov
find deine Beschreibung etwas unzureichend. Erst mal kommts drauf an ob du nen RMode oder PMode Kernel schreiben willst. bei RMode kannst du auf Bios Funktionen aufsetzen. Ansonsten kommt es drauf an was du für eine Kernel Struktur haben möchtest (siehe Lowlevel 1 oder 2?). Ich würd sagen grundsätzlich gehört z.B. das Memory Management, Tasks, usw. is aufjedenfall so einiges.
-
Naja es gibt ja mehrere Möglichkeiten einen Kernel zu bauen.
Grundsätzlich muss der Kernel eigentlich nur Schnittstellen bereitstellen über die dann andere Module (Treiber etc) miteinander kommunizieren können.
Windows 2000 ist so aufgebaut. Da ist der eigentliche Kernel sehr klein. Er regelt nur den Datenaustausch zwischen Modulen die zwar ebenfalls in der Kernelebene arbeiten, aber eigentlich nicht direkt selbst zum Kernel gehören.
-
>>> 1) Willkommensschrift
Kann auch der Bootloader machen, außer es ist z:b. GRUB der Bootloader, dann vielleicht schon. Linux macht was nettes. Das zeigt mit nem bestimmten Modul dem Benutzer beim Start einen Pinguin pro CPU.
>>> 2) Funktion zum speichern/lesen von Dateien
Nicht ganz unsinnig, komm ich gleich aber noch mal drauf zurück.
>>> 3) Spionagefunktion ;-)
Sehr, sehr wichtig für die Monopolbildung.
>>> 4) Hilfe
Hat wirklich nichts im Kernel verloren.
>>> 5) Credits
Höchstens in den Quellcodes.
>>> 6) ein Compiler
Ein Compiler mit Super User Rechten. Das ist was feines. Schlag das doch mal Linus Torvalds vor.
>>> 7) Verabschiedungsschrift
Ist halt ein reines Goody.
>>> Zusätzlich:
>>> 1) Benutzeroberfläche
Würd ich nie in den Kernel reinpacken. Viel zu große Sicherheitslücke.
>>> 2) Speichern beim ausschalten des Rechners (ich meine wenn man auf den Knopf drückt, dass der nicht gleich ausschaltet, sondern dass er erst alles abspeichert)
Ja vielleicht.
Also in der ersten oder zweiten Ausgabe stand mal was über Kernelarten: Monolithischer Kernel, Micro-Kernel oder Exo-Kernel. Da musst Dich halt entscheiden. Linux ist ein Monolithischer, wogegen BSD z.B. ein Micro-Kernel ist. Hat beides vor und Nachteile. Ich würde ein Zwischending bevorzugen.
Also der Compiler im Kernel ist wirklich unsinnig. Lass das lieber gleich sein.
Die Schreibe und Lesefunktionen wären bei einem Microkernel und nem Exo-Kernel wohl eher auf Server aufgeteilt. Musst Du halt wissen.
-
Aprops Memorymanagement, kennt einer von euch da 'n gutes tutorial oder so?
-
Sicher das BSD ein Microkernel ist? ich hatte es nur ca. 2 Tage installiert aber es kahm mir so...monolithisch vor...
-
Also ich bin mir sicher, dass wenigstens eins der BSD-Systeme ein Micro-Kernel ist.
Aber nehmen wir ein sicheres Beispiel:
GNU HURD ist auf jeden Fall ein Micro-Kernel.
Und HydrixOS ist etwas in der Art. Es gibt ein paar Ausnahmen, dabei, die nicht Micro-Kernel like sind, aber das meiste ist schon Micro-Kernel.
Micro-Kernel heißt aber halt von Anfang an, dass die Systemserver, die die Aufgaben des Monoliths übernehmen sehr zentral sind.
Ein weiteres Beispiel war der ursprüngliche Win NT Kernel.
Und ich glaube auch Longhorn soll wieder Micro-Kernel sein. Bin mir aber da nicht sicher.
-
WinNT, XP und 2000 basieren auf Microkernel.
Linux ist das beste Beispiel für einen Monolithischen Kernel.
Das wird auch irgendwann mal nen Gau geben wenn die so weiter machen und alle Treiber in den Kernel packen *g*.
-
Monolithische Kernel haben aber auch einige Vorteile. Die Performace ist z.B. besser. Mir würde kein (wirklicher) Grund einfallen einen Micro Kernel zu benutzen.
-
Der größte Vorteil ist, sofern du den Microkernel ordentlich gemacht hast, jederzeit einzelne Module auszutauschen ohne das System umbedingt neu starten zu müssen, geschweige denn zu compilieren.
Programmierfehler werden wohl eher vermieden, da der Kernel recht klein bleibt.
Die Performance muss nicht unweigerlich schneller sein bei einem Monokernel.
KOmmt halt drauf wie man das ganze umsetzt.
Jedenfalls ist der Microkernel die modernere Technik und das wird seinen Grund haben :)
Für uns ist jedoch vollkommen unrelevant, da wir noch lange nicht so weit sind uns darüber gedanken zu machen.
Wer es mal soweit geschafft hat, das er Virtuellen Speicher, Paging und Tasks in seinem System hat, der hat dann sozusagen ein kleines OS.
Alles andere ist halt nur Spielerei oder halt Lernstoff :)
-
eigenlich reicht ja auch das:
Funktion zum Ausführen von Sektoren
alles andere kann man in module einbauen...
-
@TeeJay: Man muss doch mindestens genau so viel programmieren, wie beim mono. Kernel, also sind auch wahrscheinlich genau so viele Fehler drin. Wenn der einzigste Vorteil die Module sind, das kann Linux auch! (Und das ist ja mono.)
Und wer sagt, dass alles moderne (neue) gut und besser ist??? (Man muss nur mal an die neuen Benzinpreise denken ;) )
-
Also
1. Ist der Monokernel meiner Meinung nach der größte nachteil von Linux.
2. Ein Microkernel ist einfach weniger fehleranfällig da, wie im Lowlevel Magazin beschrieben, nur ein einzelnes Modul abstürzt nicht aber der ganze Kernel. Zudem ist ein Microkernel im normalfall SEHR viel übersichtlicher was sowohl das Programmieren als auch das debuggen natürlich erheblich erleichtert.
3. Um auf chr15s OT Bemerkung zu Antworten: Es ist sicherlich nicht alles gut was neu ist aber da der großteil der Bevölkerung ohnehin zuviel mit dem Auto unterwegs ist kann man auch die Benzinpreise positiv sehen :)
-
Der Vorteil eines Microkernels ist aber, dass Du weniger Code hat der mit Kernel-Rechten läuft. Wichtig ist aber, dass die Server meist trotzdem noch sehr viele Rechte haben, aber die dann differenzierter sein können. Das ist beim Monolithischen anders. Da läuft alles mit Kernelrechten, auch die Module.
-
Also einen monolithischen Kernel kann man genauso übersichtlich gestalten. Wenn das mit der Stabilität so ist, dann wunderts mich, warum Windows bei mir öfters abstürzt als Linux, obwohl ich es viel seltener benutze. Mit den rechten kann man wieder geteilter Meinung sein, es kann ein Vorteil sein, aber wieso sollte nicht jeder Hardware-Treiber auch zugriff auf diese haben???
@Another Stupid Coder: Dann nehme ich halt das Bsp. Softwarepatente ;)
-
Also MIcrokernel haben den Vorteil, das man ihn so bauen kann, das nur ein möglichst kleiner Teil im RIng0 Modus läuft.
Der Rest (Speichermanager, Zugriffsrechteverwaltungt etc.) KÃNNEN (müssen aber nicht) im User Mode laufen.
Und wie schon gesagt sinkt die Fehlerrate, weil das ganze über ein einfaches austauschen von Messages kommuniziert und nicht so eng miteinander verwebt ist.
Klar ist es alles auch eine Sache der Implementierung, aber ich persöhnlich halte es nicht für sehr produktiv es zu handhaben wie Linux und alle möglichen Treiber direkt in den Kernel zu packen. Die gehören da einfach net hin *G*
PS zu WIndows: Ab WIndows 2000/XP/2003 muss man windows schon wirklich einen Stock in FOrm von defekter Hardware oder fehlergaftem Treiber zwischen die Beine schieben, damit es abstürzt. Und in so einem Fall hält auch Linux nicht durch. Ich persöhnlich hab XP nun schon seit MOnaten laufen und mein Rechner läuft meist auch wochenlang durch OHNE auch nur einen Absturz. EIn Bluescreen hatte ich schon eeeeewig nichtmehr.
-
Also prinzipiell muss man natürlich um Module umsetzen zu können, erstmal ELF oder des von Microsoft umsetzen, sonst ist nicht viel mit Modulen.
Übersichtlich kann man den monolithischen Kernel schon gestalten, das stimmt schon.
Du darfst nicht direkt von einer Umsetzung aufs ganze Konzept schließen. Microsoft verwendete auch lange die RC4-Verschlüsslung und sah die als sicher an, aber man kann die ganz leicht knacken. Ist deswegen Kryptographi gleich schlecht?
Und warum sollten nicht alle Treiber Root-Rechte haben. Ganz einfach, weil das mehr Möglichkeiten bietet, unerlaubt durch Programmierfehler an Root-Rechte zu kommen. Und wofür soll ein Treiber, der nicht anderes macht als z.B. Signale an ein paar LEDs zu leiten Zugriff auf die Speichertabellen oder die tiefsten Kernelfunktionen haben. Das schafft nur die Möglichkeit für Sicherheitslücken und die gibt es meist schon genug.
-
@Teejay: ja, das ist der Unterschied zwischen mir und den anderen Menschen: Wenn ein System abstürtz, dann bei mir; wenn es ein fehler gibt, dann tritt er bei mir auf.
Aber lass uns nicht streiten, jeder macht das, was er für besser hält (Hängt ja auch immer von dem Fall ab; was man proggen will...)
@kleiner: Was soll den das jetzt mir RC4????(ist sowieso nicht so gut wie mein Algorithmus; Aber den muss ich erst noch weiter überprüfen ;) ) Ich habe doch garnicht behauptet, das Verschlüsselung schlecht ist. worauf beziehst du das jetzt??? Aber bei dem Microkernel haben die Programme ja auch alle (wenn auch indirekt) vollen zugriff auf die Hardware, sonst könnten die Treiber ja auch nicht die Hardware treiben...
-
Das Beispiel mit der Veschlüsselung war ein Vergleich, weil Du von der Instabilität eines Redmonder MIcro-Kernel-Systems auf alle Micro-Kernels geschlossen hast. Ich wollte damit zeigen, dass jene Firma nicht unbedingt herangezogen werden sollte, wenn es um Rückschlüsse auf die jeweils zugrunde liegende Philosophie geht, wie hier eben Micro-Kernel und Verschlüsselung.
Ja, klar die einzelnen Treiber haben Zugriff auf die Hardware, das stimmt schon, aber es geht um Rechteverteilung: In einem Monolith hat jeder Treiber volle Kernelrechte, weil es sich ja um ein Programm handelt. Wenn Du nun einen einfachen FS-Treiber bastelst und dort einen Programmierfehler reinbaust, der etwas schwerwiegender ist, wirst Du damit die Möglichkeit bieten, volle Root-Rechte zu bekommen.
Wenn Du dagegen einfach einem Server diese Arbeit überlässt, der dann nicht als Root laufen muss, wird ein solcher Fehler nicht dazu führen, dass der Angreifer Root-Rechte erhält. Und ein FS-Server braucht keinerlei Zugriff auf die Graphikkarte oder die Eingabe. Für den FS-Server reicht Zugriffsrechte auf die Festplattenserver, um die Daten auslesen zu können.
-
kleiner postete
[...]... unerlaubt durch Programmierfehler an Root-Rechte zu kommen. [...]
<--- Siehe Buffer-Overflow ... Man sollte zumindest davon absehen GUI und Console (root-konsole bildet eine Ausnahme) in den Kernel zu integrieren.
-
@Kleiner: Ich habe nie behauptet, dass ein Monilithischer Kernel stabieler ist als ein Microkernel!!!!! Ich habe nur gesagt, das es auch nicht abders herum sein muss!!!!!!!!!
Wegen der Sicherheit: Gleiches Beispiel!
Meiner Meinung nach haben beide Systeme Vorteile und Nachteile. Man sollte am besten etwas gemischtes nehmen! (Und in dem Maße, dass man die Vorteile von beiden hat, aber nicht die nachteile!)
-
Wenn das ganze so einfach wäre hätten wir schon lange das perfekte Betriebssystem;)
-
Wollte nur kurz anmerken, dass es sehr viel schwieriger ist, ein gut durchdachtes Micro-Kernel-System zu entwerfen, also ein einfaches monolithisches System zu entwerfen. Der Grund ist vor allem die Kommunikation zwischen den Servern/Treibern. Benutzt man Ports? Pipes? Messages? Lässt man alles über ein virtuelles Netzwerk laufen, damit man später eventuell Anwendungen über LAN starten kann?
Ihr seht schon, die Theorie ist einfach, aber Microkernels sind kompliziert...
-
Ja, schon aber da ein Betriebsystem sowieso schon kompliziert ist und es genug gute Beispiele für einen Microkernel gibt (siehe spoon) finde ich das sich die arbeit auszahlt.
-
Tja eine interessante Anwendung für einen Micro-, wenn nicht gar Exo-Kernel, wäre sicher Clustering oder gar Griding. Wenn man wirklich alles, bis auf die Ausführung auf Server verteilt und die über Sockets kommunizieren lässt, könnte man vielleicht sogar ein komplettes Netzwerk mit einer OS-Instanz betreiben. Das würde natürlich vorraussetzen, dass auch der Scheduler, oder wenigstens ein Hauptscheduler, als Server implementiert ist. Das wäre dann wirklich ein delokalisiertes OS.
-
Schon mal was von Mosix gehört? Clustering ist auch mit einem monolithischen Kernel kein Problem!
-
Klar ist Clustering auch mit Monolithen kein Problem. Linux lässt sich auch gut clustern, aber meine Idee würde halt einen einzigen "PC" auf x Rechner verteilen, wobei die Performance, sehr gutes Netzwerk vorrausgesetzt, durch die verteilung der Server für gro skalierende Netzwerke steigen würde.
-
Ein OS über Sockets klingt interessant gibts sowas schon Ansatzweise irgendwo im Netz??
-
@kleiner: Was ist denn Mosix. Das kann man auch bedienen, wie EINEN PC. Also keine wirklich neue Erfindung ;)
-
Ok, kenn Mosix nicht.
OK, aber selber erdacht.
Wenigstens etwas.
-
Sicher das BSD ein Microkernel ist? ich hatte es nur ca. 2 Tage installiert aber es kahm mir so...monolithisch vor...
Dazu http://www.freebsd.org/doc/de_DE.ISO8859-1/books/handbook/kernelconfig-custom-kernel.html
"Traditionell besaß FreeBSD einen monolithischen Kernel."
-
Was soll es denn bringen, die alten Threads von 2004 aus der Versenkung hervor zu holen?
-
Tjaja und nochmal das Thema aufwärmen... :roll:
Ich möchte einen Mikrokernel schreiben.
Folgendes habe ich aufgeschrieben, was in den Kernel soll:
# Multiboot kompatibler 32-Bit Protected Mode Kernel
## GDT
## IDT
## ISRs
## IRQs and the PICs
## PIT (Programmable Interval Timer)
# Einfacher Video-Treiber zur Textausgabe (vllt. auch nicht)
# Memory Manager
# Multitasking
# System Calls
# Interprozesskommunikation
# Modul Interface
# Prozessorspezifischer Kram
## FPU-Support
# Treiberinterface
Aber irgendwie denke ich die ganze Zeit, dass da doch irgendwas fehlt oder nicht?
Gruß Christian
-
Ich nehme das "oder nicht". Einige Begriffe da drin sind so breit gefaßt (z.B. "System Calls"), daß du damit eigentlich alles abdeckst. Ansonsten: Wenn du das alles abgearbeitet hast, hast du sicher mehr Gefühl für die Sache und weißt, was als nächstes kommen muß. Für einen Mikrokernel wird sich das aber höchstwahrscheinlich im Userspace abspielen.
-
Gut das war alles was ich wissen wollte.
Danke.
Gruß Christian
-
Und nocheinmal eine Frage, da ich ja keinen neuen Thread deswegen aufmachen will.
Wie habt ihr Prozessorspezifische Features, wie z.B. PAE, implementiert? Die Idee, die mir kam, war eine Art "Systemtreiber", der abhängig von der CPU kompiliert wird und in der initrd liegt. Ist das sinnvoll?
Ich würde dann nämlich als minimale Vorgabe einen i386 kompatiblen Prozessor angeben, und wenn man irgendwas spezielles haben will (PAE), wird das über den Systemtreiber gemacht.
Der Nachteil an der Geschichte ist halt, dass man diesen nicht mitliefern kann, sondern vor Ort kompilieren und linken muss.
Ich möchte halt nicht zig verschiedene Versionen von meinem Kernel. Ich würde gerne "nur" unterscheiden zwischen z.B. Intel und AMD...
Beispiel: Pentium 1 unterstützt ja bekanntlich kein PAE, dafür aber der Pentium Pro. Und damit der Kernel nicht vollmüllt (meine Ansicht), kann der Nutzer mit dem Pentium Pro sich dann diesen Systemtreiber bauen. Oder man baut dies während der Installation, falls ich irgendwann mal soweit kommen sollte *träum*.
Das ganze ist begrenzt auf 32Bit. Es gibt ja nicht die Möglichkeit, einen Kernel zu bauen, der 32Bit und 64Bit in einem vereint...
-
Prozessorspezifische Dinge sind eigentich nichts, was man gut in einem Treiber verpacken könnte. Es gehört ja mehr dazu als nur das Feature zu aktivieren.
Ein Treiber stellt ja normalerweise irgendwelche Funktionen bereit um ein Gerät zu lesen, zu beschreiben, bunte Pixel auf den Bildschirm zu kopieren oder krasse Gitarrenriffs aus den Boxen erschallen zu lassen. Das heißt ein Programm hat dann auch irgendwo einen Aufruf der Funktion FileOpen, DrawPixel oder PlaySound.
Im Fall von prozessorspezifischem Zeug wären die Treiberaufrufe hauptsächlich im Kernel, weil es ja um sehr sensible Geschichten wie Speicherverwaltung (PAE, PSE, ...), Ausführungsprivilegien (NX-Bit), Virtualisierung, und so weiter geht. Das heißt jedes unterstützte Feature benötigt zwingend auch Modifikationen im Kernel. Diese Sachen sind aber auch alle so speziell, dass diese in sehr vielen Bereichen hineinspielen. Du müsstest deswegen quer über den Kernel verteilt diese Treiberfunktionen aufrufen. Und da hast du dann immer das Problem, dass du wieder if-Abfragen in dieser Form hast: if (pae_enabled()) {
pae_treiber_do_something();
} else {
default_do_something();
}Das bläst deine Kernelfunktionen genauso auf, als hättest du alles gleich im Kernel gelassen. Nur die Performance ist schlechter ;)
Wenn du deine Kernel mehr oder weniger minimalistisch halten willst, kannst du deinen Kernel möglichst weit modularisieren (ähnlich wie du es beim Treiber gemacht hättest), dann aber trotzdem den Code direkt in den Kernel zu linken. Wenn du zum Beispiel Prozessoren mit und ohne PAE optimal unterstützen willst, kannst du zwei Kernel aus den selben Sourcen kompilieren, und PAE- und nicht-PAE-spezifische Teile mittels #define und #ifdef trennen.
-
Wenn du deine Kernel mehr oder weniger minimalistisch halten willst, kannst du deinen Kernel möglichst weit modularisieren (ähnlich wie du es beim Treiber gemacht hättest), dann aber trotzdem den Code direkt in den Kernel zu linken. Wenn du zum Beispiel Prozessoren mit und ohne PAE optimal unterstützen willst, kannst du zwei Kernel aus den selben Sourcen kompilieren, und PAE- und nicht-PAE-spezifische Teile mittels #define und #ifdef trennen.
Das wäre dann natürlich auch eine Option.
Im Fall von prozessorspezifischem Zeug wären die Treiberaufrufe hauptsächlich im Kernel, weil es ja um sehr sensible Geschichten wie Speicherverwaltung (PAE, PSE, ...), Ausführungsprivilegien (NX-Bit), Virtualisierung, und so weiter geht. Das heißt jedes unterstützte Feature benötigt zwingend auch Modifikationen im Kernel. Diese Sachen sind aber auch alle so speziell, dass diese in sehr vielen Bereichen hineinspielen. Du müsstest deswegen quer über den Kernel verteilt diese Treiberfunktionen aufrufen. Und da hast du dann immer das Problem, dass du wieder if-Abfragen in dieser Form hast: if (pae_enabled()) {
pae_treiber_do_something();
} else {
default_do_something();
}Das bläst deine Kernelfunktionen genauso auf, als hättest du alles gleich im Kernel gelassen. Nur die Performance ist schlechter ;)
Das nicht unbedingt. Gedacht hatte ich das so, dass Paging und so zeug auf Basis i386 implementiert werden. Sobald dann der Systemtreiber geladen wurde (falls vorhanden) wird die Speicherverwaltung im Kernel abgeschaltet. Das würde dann aber auch wieder einige if-Abfragen benötigen...
Dann werde ich das ganze wohl über Module machen...