Login
Newsletter
Werbung

Thema: L4 Microkernel Fiasco aktualisiert

28 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von M:ke am Do, 29. September 2005 um 13:46 #
Wiese arbeiten die nicht stattdessen lieber mit an Hurd?
[
| Versenden | Drucken ]
  • 0
    Von mein Name am Do, 29. September 2005 um 14:00 #
    Was spricht dagegen diese L4-Implementation für Hurd zu verwenden?
    [
    | Versenden | Drucken ]
    • 0
      Von mein Name am Do, 29. September 2005 um 14:02 #
      Die wirklich große Frage dabei ist allerdings eher: heißt es nicht eher Implementierung? keine Ahnung..
      [
      | Versenden | Drucken ]
      • 0
        Von Andi am Do, 29. September 2005 um 14:05 #
        Schaust Du im Artikel nach :) Implementation ist englisch. Implementierung Deutsch.
        [
        | Versenden | Drucken ]
      0
      Von wj am Do, 29. September 2005 um 18:15 #
      > Was spricht dagegen diese L4-Implementation für Hurd zu verwenden?

      Weil das Design von Hurd-auf-L4 Fähigkeiten des Kernels voraussetzt, über die Fiasco weder jetzt verfügt noch auf absehbare Zeit verfügen wird (während bei L4Ka entsprechendes fest geplant ist).

      Siehe auch:
      New capability protocol implementation

      [
      | Versenden | Drucken ]
      0
      Von Bla am Do, 29. September 2005 um 23:57 #
      Es ist ein Realtimekernel... Abgesehen davon fehlt eine "benutzbare" Treiberinfrastruktur. Ich denk mal, dass der L4::Pistachio ohnehin mehr Zukunft hat - siehe auch Debian Hurd/L4-Projekt...
      [
      | Versenden | Drucken ]
    0
    Von Jen am Do, 29. September 2005 um 14:02 #
    Weil GNU Hurd kein Microkernel ist, sondern drauf basiert, also z.B. auf L4. Bisher wurde noch GNU Mach benutzt, aber schon seit einer ganzen Weile läuft das Porten auf L4.
    [
    | Versenden | Drucken ]
    • 0
      Von mein Name am Do, 29. September 2005 um 14:04 #
      Hä? Also ich weiß, dass Hurd kein Microkernel ist -- aber einen solchen braucht, nicht wahr? Daher wäre diese L4-Imple.. doch durchaus dafür nutzbar.. odää?
      [
      | Versenden | Drucken ]
      • 0
        Von Gert am Do, 29. September 2005 um 14:43 #
        Das schreibt er doch: Hurd wird L4 benutzen!?
        [
        | Versenden | Drucken ]
        • 0
          Von mein Name am Do, 29. September 2005 um 14:55 #
          L4 ist glaub eher ein Konzept für das es verschiedene Implement[ierung|ation]en gibt, oder habe ich das falsch verstanden?? Wär schön, wenn uns(?) hier jemand richtig aufklären würde..

          Wann kommt eigentlich mal wieder ein Beitrag über HURD hier bei pl? Würd mich freuen..

          [
          | Versenden | Drucken ]
          • 0
            Von anon am Do, 29. September 2005 um 15:47 #
            Fände ich auch ganz spannend. Ich dachte, HURD wäre als Alternative zu Linux einsetzbar (wobei HURD Microkernel und Linux Monolitisch).

            Inwieweit braucht man bei HURD einen (weiteren?) monolitischen Kernel? Und in welchem Zusammenhang ist da Mach oder L4 zu deuten?

            [
            | Versenden | Drucken ]
            • 0
              Von Jörg W Mittag am Do, 29. September 2005 um 16:39 #
              > Ich dachte, HURD wäre als Alternative zu Linux einsetzbar

              Ist es doch auch. Also, konzeptionell meine ich. Natürlich ist der HURD noch bei weitem nicht so ausgereift wie Linux (obwohl die Entwicklung deutlich vor Linux begonnen hat), aber konzeptionell sitzt er auf der selben Abstraktionsebene.

              > (wobei HURD Microkernel und Linux Monolitisch)

              Letzteres ist grundsätzlich richtig (auch wenn Dinge wie Early Userspace, Userspace-Dateisysteme, Gerätedateiverwaltung und Hotplug im Userspace (udev), Partitioneserkennung im Userspace, USB-Treiber im Userspace (libusb), Grafiktreiber im Userspace (DRM+DRI+X.Org) u.s.w. nicht gerade typisch für monolithische Kernel sind), ersteres ist aber falsch.

              Dass der HURD kein Microkernel ist, sagt doch sogar der Name: "HIRD of Unix-Replacing Daemons", wobei HIRD für "HURD of Interfaces Representing Depth" steht. Das heißt, der HURD ist eine Sammlung (oder "Herde", deswegen auch das Wortspiel HURD und HIRD, die beide wie "herd" (Herde) ausgesprochen werden) von Servern, die auf einem Microkernel laufen.

              > Inwieweit braucht man bei HURD einen (weiteren?) monolitischen Kernel?

              Man braucht nicht einen weiteren Kernel sondern man braucht überhaupt erstmal einen Kernel. Man könnte auch einen monolithischen nehmen, das würde aber keinen Sinn ergeben, denn die ganze Funktionalität, die HURD bereitstellt, wäre dann ja bereits im Kernel vorhanden. Man kann auch keinen Exokernel nehmen, weil dieser wiederum zuwenig Funktionalität bereitstellt, als dass HURD darauf laufen könnte.

              Also nimmt man einen Microkernel, weil das nunmal auch das ist, wofür der HURD entworfen wurde.

              > Und in welchem Zusammenhang ist da Mach oder L4 zu deuten?

              Mach ist der Microkernel, für den der HURD ursprünglich entwickelt wurde. Es gibt ein Projekt, um den HURD auf L4 zu portieren und L4 wird wohl möglicherweise in Zukunft der Microkernel für HURD werden.

              jwm

              [
              | Versenden | Drucken ]
              • 0
                Von anon am Do, 29. September 2005 um 17:27 #
                Bei GNU/Linux ist doch so: der Kernel verwaltet Hardwareressourcen (CPU/RAM/IDE/SCSI/...) über Scheduler und sorgt dafür dass der initiale Prozess gestartet wird (z.B. /sbin/init bei System V). Gleichzeitig sind Filesysteme direkt im Kernel implementiert (monolithischer Kernel), so dass man als normaler "nicht-root" User keine Dateisysteme mounten kann, weil man dafür auf privilegierte Bereiche im Kernel zugreifen müsste.

                Wie sieht das jetzt bei einem Microkernel aus? Soweit ich weiß, sind Filesysteme in den User-Space ausgelagert, damit man z.B. auch als normaler User Filesysteme mounten kann (ich erinner mich da an die Möglichkeit, ein FTP-Verzeichnis zu mounten). Ist es so, dass das Scheduling von dem "richtigen" Kernel übernommen wird (also Mach/L4) und die Informationen bezüglich des Filesystems in Hurd (also im Userspace) liegen?

                Und wie sieht es bei einem Microkernel mit der Übergabe an den Userspace aus? Bei Linux gibt es die Möglichkeit über den init-Parameter dem Kernel mitzuteilen, welches der initiale Prozess sein soll. Bei Mach/Hurd müsste das ja viel früher passieren, damit über HURD z.B. das root-Verzeichnis eingebunden werden kann?

                Und wenn Hurd eigentlich aus zwei Teilen besteht (Mach, bzw. L4 und HURD), wie sehen die Spezifikationen aus, nach denen Hurd mit Mach (bzw. L4) kommuniziert?
                Kann ich dann als nicht-root einen HURD-Teil mit Mach/L4 verbinden? Wenn ja: wer hindert mich daran, über HURD alle Tastatur-Eingaben auf dem Rechner zu protokollieren?

                [
                | Versenden | Drucken ]
                • 0
                  Von Linuxoid am Fr, 30. September 2005 um 19:58 #
                  Du bringst hier einiges durcheinander. Die Hardware-Ressourcen verwaltet Linux über dedizierte Subsysteme, die man sich als eine Sammlung von Unterprogrammen innerhalb des Kernels vorstellen kann. Der Scheduler hingegen verwaltet weder RAM noch irgendwelche Massenspeicher-Protokolle, sondern ist allein für die Taskwechsel zuständig, sprich, alles was er verwaltet ist die Zuteilung von Rechenzeit einer oder mehrerer CPUs an Prozesse bzw. Threads.
                  Auch hat ein root-User keinen Zugriff auf privilegierte Bereiche des Kernels. Er muss genauso wie ein 0815-User per System Calls mit dem Kernel kommunizieren. Er hat dabei Zugriff auf weitere Calls, die einem normalen User nicht zur Verfügung stehen. Merke: root-Rechte nicht mit Kernelspace verwechseln. Wenn ein Programm mit root-Rechten im Kernelspace herumwurschteln will, wird es genauso mit einem SEGFAULT aus dem Speicher gekickt wie jedes andere Programm auch. Ein Unterprogramm innerhalb des Kernels (z.B. als Bestandteil eines NIC-Treibers oder eines Dateisystems) kann hingegen wirklich machen, was es will. Spinnt so ein Subsystem rum, ist es mit der Stabilität vorbei, da es alles ins Nirvana reißen kann. Ein klitzekleiner Fehler hat also im Kernelspace u.U. eien verheerende Wirkung. Ein Userspaceprogramm hingegen stürzt einfach mit einem SEGFAULT ab, ohne andere Programme oder gar den Kernel zu beeinflussen. Und hier setzt das Konzept des Microkernels an.

                  Microkernel sind in ihren Fähigkeiten gegenüber monolithischen Kerneln arg beschränkt. Vereinfacht gesagt kümmert sich ein Microkernel fast nur um Scheduling und Interprozesskommunikation und bringt gerade mal so viel Ressourcenverwaltung mit, dass er sich selbst und die Userspace-Daemons starten kann. Sämtliche Ressourcenverwaltung wie Dateisysteme wird auf Userspace-Programme ausgelagert. Prozesse im Userspace können nur auf ihre eigenen Ressourcen zugreifen und müssen sich mit anderen Prozessen oder dem Kernel nachrichtenbasiert unterhalten. Wenn ein solcher Prozess Amok läuft, kann er so nur sich selbst, aber nicht die anderen Prozesse oder gar den Kernel abschießen, so zumindest die Theorie. Die Möglichkeit der nachrichtenbasierten Kommunikation stellt dann der Microkernel zur Verfügung. Beispiel: Wenn ein Treiber absemmelt, bleiben die anderen Prozesse wie Speicherverwaltung und Dateisysteme intakt und der betreffende Treiber z.B. kann neu gestartet werden. Ziel des ganzen ist also ein robusteres System und eine Vereinfachung der Entwicklung. Allerdings hat sich herausgestellt, dass die korrekte Kommunikation der einzelnen Daemons eine ganz eigene Komplextität mitbringt, bei monolithischen Kerneln viel einfacher zu bewerksteligen ist.

                  [
                  | Versenden | Drucken ]
                0
                Von micha am Do, 29. September 2005 um 18:10 #
                Der Exokernel ist ein (konkreter) Mikrokernel, der von seiner Funktionalität her ähnlich wie L4 einzuordnen ist.
                [
                | Versenden | Drucken ]
                0
                Von pinky am Do, 29. September 2005 um 19:55 #
                >Natürlich ist der HURD noch bei weitem nicht so ausgereift wie Linux (obwohl die Entwicklung deutlich vor Linux begonnen hat)

                naja, 2 Monate würde ich nicht als "deutlich vor Linux bezeichnen"...

                [
                | Versenden | Drucken ]
            0
            Von Brezel am Do, 29. September 2005 um 18:35 #
            Ich will ja nicht klugscheißen (na ok, etwas schon... :-) ), aber laut Backus und Naur ist "Implement[ierung|ation]en" nicht korrekt. Denn die eckigen Klammern stehen für eine Option, aus deiner Regel könnte man also "Implementen" folgern... sorry für den Klugschiß, ich konnte es mir aber nicht verkneifen... ;-)
            [
            | Versenden | Drucken ]
            • 0
              Von mein Name am Do, 29. September 2005 um 20:52 #
              *hehe* Die Vorlesung "Allgemeine Informatik" ist bei mir eben schon wieder ein Weilchen her ;-) sorry für den Fehler..
              [
              | Versenden | Drucken ]
          0
          Von mein Name am Do, 29. September 2005 um 15:00 #
          schon wieder ich - sorry ;)

          laut gnu.org wird HURD auf "L4Ka::Pistachio microkernel" portiert, welcher soweit ich mich erinnern kann an der Uni Karlsruhe entwickelt wird. Ist es nun so, dass der oben genannte und "Fiasko" einfach verschiedene Variationen von L4 sind? Scheint jedenfalls so.. egal - nen schönen Tag wünsch ich noch!

          [
          | Versenden | Drucken ]
          • 0
            Von Jörg W Mittag am Do, 29. September 2005 um 16:57 #
            Mit "L4" ist das ungefähr so wie mit "Unix": man meint damit ganz unterschiedliche Sachen. Wenn jemand "Unix" sagt, dann meint er meistens "ein Betriebssystem, das sich anfühlt wie eine Modernisierung von Unix" (also z.B. GNU/Linux), er könnte aber auch meinen "das Betriebssystem namens Unix, welches in den 70ern an den Bell Labs entwickelt wurde" oder "ein Betriebssystem, dessen Quelltexte vom originalen Unix abstammen" (z.B. die *BSDs, Solaris, SCO u.s.w.) oder "ein Betriebssystem, dessen Konzepte und Ideen von Unix abstammen" (z.B. GNU/Linux, MacOS X (teilweise)) oder "ein Betriebssystem, das für die Benutzung der eingetragenen Marke 'UNIX' zertifiziert wurde" (z.B. OS/390) oder auch alles auf einmal.

            Ähnlich ist das wohl mit "L4": Ursprünglich war L4 ein Microkernel der Uni Karlsruhe. Inzwischen ist L4 eine Familie von Microkerneln. Außerdem ist L4 auch eine Familie von Schnittstellenstandards für L4-Microkernel. Wenn man heute "L4" sagt, meint man meistens die Schnittstelle, stabil sind derzeit die Versionen V2 und V4, es gibt noch die Zwischenversionen X.0, X.1 und X.2.

            Sowohl in Karlsruhe als auch in Dresden werden L4-Microkernel entwickelt, die Karlsruher heißen L4Ka::irgendeine-Nuss (L4Ka::Hazelnut und L4Ka::Pistachio), der Dresdner heißt eben Fiasco.

            BTW: die deutsche und englische Wikipedia-Seite zu L4 zusammen ergeben einen guten Überblick.

            jwm

            [
            | Versenden | Drucken ]
    0
    Von brum am Do, 29. September 2005 um 14:37 #
    zeitdruck - sie wollten es in 2 jahren schaffen ;-)
    [
    | Versenden | Drucken ]
0
Von Sizzla am Fr, 30. September 2005 um 09:57 #
Ein Mikrokernel ist ein Kernel der fast keine Funktionalitaet besitzt.
L4 ist ein Mikrokernel.
Mach ist auch ein Mikrokernel.
L4 und Mach wurden unabhaengig voneinander entwickelt.
L4 plus irgendein Name ist eine Neu-/Weiterentwicklungen vom L4-Mikrokernel.
Hurd ist kein Kernel sondern eine Ansammlung von Treibern fuer einen Mikrokernel um die Funktionalitaet zu erweitern.
Hurd alleine oder ein L4-/Mach-Mikrokernel alleine sind kein Ersatz fuer einen monolitischen Kernel.
Ein L4-/Mach-Mikrokernel + Hurd waere ein Ersatz fuer einen monolitischen Kernel.

Hab ich Muell geschrieben oder stimmt das? Waer schoen wenn man was dazu sagen wuerde :)

[
| Versenden | Drucken ]
  • 0
    Von Gert am Fr, 30. September 2005 um 10:16 #
    Liest sich korrekt. Zumindest habe ich das auch so verstanden. Lediglich die letzte Aussage ist nicht 100%ig. Ich wuerde eher schreiben:

    Ein L4-/Mach-Mikrokernel + Drumherumtreiber = Hurd. Hurd ist ein Ersatz fuer einen monolitischen Kernel.

    [
    | Versenden | Drucken ]
    • 0
      Von Sizzla am Fr, 30. September 2005 um 10:28 #
      Dankeschoen :)
      Und wie nennt man dann nur die Ansammlung von Treibern fuer einen Mikrokernel?
      [
      | Versenden | Drucken ]
      • 0
        Von Sizzla am Fr, 30. September 2005 um 10:57 #
        Eigentlich stell ich eine ziemlich bloede Frage. Das nennt sich wahrscheinlich Treiber *G*
        [
        | Versenden | Drucken ]
    0
    Von mein Name am Fr, 30. September 2005 um 10:23 #
    > L4 und Mach wurden unabhaengig voneinander entwickelt.

    stimmt - nur ist L4 glaub etwas jüngeren Datums..

    > Hurd ist kein Kernel sondern eine Ansammlung von Treibern fuer einen Mikrokernel um die Funktionalitaet zu erweitern.

    nicht nur Treiber.. Jedenfalls sehr viele (kleine) Programme, die im Userspace laufen und einen Unix-Kernel "vortäuschen"

    Der Rest stimmt meines Erachtens schon :)

    [
    | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung