| Zeile 118: | Zeile 118: | ||
Im Umkehrschluss gehören eine [[Shell]], [[GUI]] oder sonstige Anwendungsprogramme '''nicht''' in den Kernel! Eine Shell im Kernel ist vielleicht akzeptabel für eine frühe Testphase, um überhaupt einmal etwas laufen zu sehen, aber es ist auf Dauer kein tragfähiges Konzept. (Einer der Gründe dafür: Erinnerst Du Dich an den Absatz über die Ringe oben? Was im Kernel liegt, hat Kernel-Mode-Privilegien, und ein Grundsatz für sichere Software ist, nie Privilegien zu haben, die man nicht braucht) | Im Umkehrschluss gehören eine [[Shell]], [[GUI]] oder sonstige Anwendungsprogramme '''nicht''' in den Kernel! Eine Shell im Kernel ist vielleicht akzeptabel für eine frühe Testphase, um überhaupt einmal etwas laufen zu sehen, aber es ist auf Dauer kein tragfähiges Konzept. (Einer der Gründe dafür: Erinnerst Du Dich an den Absatz über die Ringe oben? Was im Kernel liegt, hat Kernel-Mode-Privilegien, und ein Grundsatz für sichere Software ist, nie Privilegien zu haben, die man nicht braucht) | ||
| + | |||
| + | ===Schnittstelle zum Userspace=== | ||
| + | Auch der tollste Kernel mit [[Multitasking]]-Unterstützung bringt Dir natürlich herzlich wenig, wenn die laufenden Programme nicht mit dem Benutzer interagieren können. Um den Programmen, die ja in einem eigenen Adressraum laufen und meist keinen direkten Zugriff auf die Hardware haben, diese Möglichkeit zu bieten, muss der Kernel eine entsprechende Schnittstelle, üblicherweise in Form von [[Syscall|Syscalls]], anbieten. Wie diese Schnittstelle genau aussieht, hängt von Deiner gewählten Architektur ab. Bei einem Monolithen wird die Schnittstelle eher breit ausfallen, und beispielsweise Funktionen für das Arbeiten mit Dateien mitbringen, während bei einem Mikrokernel vor allem die Funktionen für die [[Interprozesskommunikation]] im Zentrum stehen werden. | ||
[[Category:Tutorials]] | [[Category:Tutorials]] | ||