1. Foren
  2. Kommentare
  3. Applikationen
  4. Alle Kommentare zum Artikel
  5. › Kernel: GNU Hurd 0.5…

Treiber im Userspace haben keine praktischen Vorteile

  1. Thema

Neues Thema Ansicht wechseln


  1. Treiber im Userspace haben keine praktischen Vorteile

    Autor: Vanger 30.09.13 - 14:11

    Wie häufig erfährt man unter Linux eine Kernel Panic?
    Wie häufig erfährt man einen BSoD unter Windows?

    Extrem selten. Unter Linux habe ich in meiner gesamten Linux-Karriere exakt eine Kernel Panic erlebt: nämlich in dem Moment in dem der Grafikchip meines Notebooks abgeraucht ist. Auch unter Windows erfährt man heute selten einen BSoD, da gab es schlimmere Zeiten. Den letzten habe ich an einem fremden Notebook vor nicht ganz zwei Wochen gesehen, an den letzten davor kann ich mich nicht erinnern, das muss lange her sein.

    Das soll nun nicht das übliche Microsoft-Gebashe sein, es geht vielmehr um die grundsätzlichen Konzepte. Sowohl Linux (monolithistisch) als auch Windows (hybrid) setzen auf Treiber im Kernelspace - mit dem wichtigen Unterschied, dass bei Linux der überwältigende Teil der Treiber auch zentral gepflegt wird. Bei Microsoft ist das anders.

    An genau diesem Punkt sehe ich den Grund warum unter Windows der BSoD doch häufiger vorkommt: Microsoft hat keine Möglichkeit die Qualität der Treiber sicherzustellen, weshalb "ein billiger Soundkartentreiber" sehr schnell zu einem Absturz führen kann. Mit einer zentralen Verwaltung wie bei Linux wird der Treiber vor Aufnahme geprüft. Grobe Schnitzer fallen dabei auf und der Treiber landet im Staging. Natürlich, bereits aufgenommene Treiber können Fehler haben und damit eine Kernel Panic verursachen - das aber wird gemeldet werden und der Treiber wird entweder innerhalb kürzester Zeit gefixt oder fliegt aus dem Kernel. In der Windows-Welt kann man sich nur an den Hersteller der "billigen Soundkarte" wenden - ob sie den Treiber dann korrigieren ist eher Glückssache. In der Tendenz werden sie es aber nicht tun - immerhin ist es ja nur eine "billige Soundkarte" bei der auf Service nicht wirklich Wert gelegt wird, solange nicht ein erheblicher Teil der Kunden betroffen ist, wird nichts geschehen.

    So ein wirklicher praktischer Vorteil ergibt sich aus dem Betrieb der Treiber im Userspace somit nicht. Ganz im Gegenteil, der zusätzliche Overhead ist gewaltig. Die Stabilitätsvorteile sind gegenüber dem Modell von Linux winzig bis nicht existent.



    1 mal bearbeitet, zuletzt am 30.09.13 14:11 durch Vanger.

  2. du vergleichst Äpfel mit Birnen

    Autor: Kaiser Ming 30.09.13 - 14:37

    Vanger schrieb:
    --------------------------------------------------------------------------------
    > Wie häufig erfährt man unter Linux eine Kernel Panic?
    > Wie häufig erfährt man einen BSoD unter Windows?

    vergleich mal lieber Linux mit einem Opensource Unix
    übrigens ist Linux kein reiner "Makrokernel" mehr, warum wohl

    nene Stallman hatte schon Recht

  3. Re: Treiber im Userspace haben keine praktischen Vorteile

    Autor: Christo 30.09.13 - 14:41

    Windows hat deswegen so wenig BSoD weil sie die Grafiktreiber mit Windows 7 in den Userspace verfrachtet haben.

    Es ist bei mir des öfteren vorgekommen, dass der Bildschirm kurz schwarz wurde. Und als alles wieder angezeigt wurde kam in der Task-bar eine Meldung, die sagte: dass der Grafiktreiber abgestürzt sei & neu gestartet wurde.

    Also die Vorteile von Treiber im Userspace!

  4. Re: Treiber im Userspace haben keine praktischen Vorteile

    Autor: muh3 30.09.13 - 16:00

    Vanger schrieb:
    --------------------------------------------------------------------------------
    > Wie häufig erfährt man unter Linux eine Kernel Panic?
    > Wie häufig erfährt man einen BSoD unter Windows?
    >
    > Extrem selten. Unter Linux habe ich in meiner gesamten Linux-Karriere exakt
    > eine Kernel Panic erlebt: nämlich in dem Moment in dem der Grafikchip
    > meines Notebooks abgeraucht ist. Auch unter Windows erfährt man heute
    > selten einen BSoD, da gab es schlimmere Zeiten. Den letzten habe ich an
    > einem fremden Notebook vor nicht ganz zwei Wochen gesehen, an den letzten
    > davor kann ich mich nicht erinnern, das muss lange her sein.
    >
    > Das soll nun nicht das übliche Microsoft-Gebashe sein, es geht vielmehr um
    > die grundsätzlichen Konzepte. Sowohl Linux (monolithistisch) als auch
    > Windows (hybrid) setzen auf Treiber im Kernelspace - mit dem wichtigen
    > Unterschied, dass bei Linux der überwältigende Teil der Treiber auch
    > zentral gepflegt wird. Bei Microsoft ist das anders.
    >
    > An genau diesem Punkt sehe ich den Grund warum unter Windows der BSoD doch
    > häufiger vorkommt: Microsoft hat keine Möglichkeit die Qualität der Treiber
    > sicherzustellen, weshalb "ein billiger Soundkartentreiber" sehr schnell zu
    > einem Absturz führen kann. Mit einer zentralen Verwaltung wie bei Linux
    > wird der Treiber vor Aufnahme geprüft. Grobe Schnitzer fallen dabei auf und
    > der Treiber landet im Staging. Natürlich, bereits aufgenommene Treiber
    > können Fehler haben und damit eine Kernel Panic verursachen - das aber wird
    > gemeldet werden und der Treiber wird entweder innerhalb kürzester Zeit
    > gefixt oder fliegt aus dem Kernel. In der Windows-Welt kann man sich nur an
    > den Hersteller der "billigen Soundkarte" wenden - ob sie den Treiber dann
    > korrigieren ist eher Glückssache. In der Tendenz werden sie es aber nicht
    > tun - immerhin ist es ja nur eine "billige Soundkarte" bei der auf Service
    > nicht wirklich Wert gelegt wird, solange nicht ein erheblicher Teil der
    > Kunden betroffen ist, wird nichts geschehen.

    das ist doch Quatsch.
    1. kommen doch die meisten "alten" Treiber eh mittlerweile von MS und sind über WindowsUpdate installierbar (also sind sie schon von MS kontrolliert) und
    2. meckert Windows schon sehr hartnäckig wenn man einen Treiber installieren will, der nicht von MS geprüft wurde

    außerdem kann man auch unter Linux jederzeit Treiber nachinstallieren, die nicht von den Kernelentwicklern durchgesehen werden.


    >
    > So ein wirklicher praktischer Vorteil ergibt sich aus dem Betrieb der
    > Treiber im Userspace somit nicht. Ganz im Gegenteil, der zusätzliche
    > Overhead ist gewaltig. Die Stabilitätsvorteile sind gegenüber dem Modell
    > von Linux winzig bis nicht existent.

  5. Re: Treiber im Userspace haben keine praktischen Vorteile

    Autor: Vanger 30.09.13 - 17:58

    > 1. kommen doch die meisten "alten" Treiber eh mittlerweile von MS und sind
    > über WindowsUpdate installierbar (also sind sie schon von MS kontrolliert)
    Also ich weiß nicht welche Erfahrungen du gemacht haben willst, wer einigermaßen aktuelle Hardware einsetzt, muss nach einer Windows-Neuinstallation dennoch händisch Treiber nachinstallieren. Microsoft liefert per Windows Update lediglich Treiber für veraltete Hardware aus.

    > 2. meckert Windows schon sehr hartnäckig wenn man einen Treiber
    > installieren will, der nicht von MS geprüft wurde
    Das ist so nicht richtig, der Code muss lediglich signiert sein - mehr nicht. Eine Codeprüfung schließt das nicht mit ein.

    > außerdem kann man auch unter Linux jederzeit Treiber nachinstallieren, die
    > nicht von den Kernelentwicklern durchgesehen werden.
    Niemand hat etwas anderes behauptet, das aber ist eine absolute Ausnahme und weit nicht die Regel.

  6. Re: du vergleichst Äpfel mit Birnen

    Autor: Vanger 30.09.13 - 18:09

    > vergleich mal lieber Linux mit einem Opensource Unix
    Wozu?

    > übrigens ist Linux kein reiner "Makrokernel" mehr, warum wohl
    Danke, dass du dich outest keine Ahnung zu haben. Linux war noch nie ein Makrokernel. Makrokernel ist nicht das Gegenteil von Mikrokernel, Makrokernel ist ein anderer Begriff für einen Hybridkernel.

    Das konzeptionelle Gegenteil eines Mikrokernel ist der monolithische Kernel - was Linux ist. Daran hat sich nie etwas geändert, das war er von Beginn an und ist es auch heute. Wie das an anderer Stelle behauptet wurde ist das Modulkonzept von Linux keine Aufweichung dieses Konzept sondern lediglich eine Flexibilisierung der gleichen Idee - auch Kernelmodule laufen im Kernelspace.

  7. Re: Treiber im Userspace haben keine praktischen Vorteile

    Autor: Vanger 30.09.13 - 18:22

    > Windows hat deswegen so wenig BSoD weil sie die Grafiktreiber mit Windows 7
    > in den Userspace verfrachtet haben.
    Halbwissen. Das mit Windows Vista (nicht Windows 7) eingeführte WDDM läuft nur teilweise im Userspace. Es versucht einige Fehlerquellen abzufangen und dadurch einen BSoD zu verhindern, vollständig kann es das aber nicht, da essentielle Teile weiterhin im Kernelspace ausgeführt werden.

    Das widerspricht im übrigen auch in keiner Weise meinen Ausführungen. Wenn du diese sorgfältig gelesen hast und weißt wovon ich spreche, dann weißt du, dass Windows einen Hybridkernel besitzt und somit durchaus Teile, die ein monolithischer Kernel im Kernelspace ausführt, im Userspace ausführt - aber eben nicht alle.

    > Es ist bei mir des öfteren vorgekommen, dass der Bildschirm kurz schwarz
    > wurde. Und als alles wieder angezeigt wurde kam in der Task-bar eine
    > Meldung, die sagte: dass der Grafiktreiber abgestürzt sei & neu gestartet
    > wurde.
    Auch unter Linux werden vom Kernel einige mögliche Fehlerquellen abgefangen um eine Kernel Panic zu verhindern. Ein Fehler führt nicht zwingend zu einer Kernel Panic. Genauso wie bei Windows... Details habe ich ja schon ausgeführt.

    > Also die Vorteile von Treiber im Userspace!
    Blöd nur, dass auch die Grafiktreiber unter Windows größtenteils im Kernelspace laufen... ;)

  8. Re: du vergleichst Äpfel mit Birnen

    Autor: Kaiser Ming 01.10.13 - 12:02

    Vanger schrieb:
    --------------------------------------------------------------------------------
    > > vergleich mal lieber Linux mit einem Opensource Unix
    > Wozu?
    wegen Äpfeln und Birnen
    Windows kann ich nicht mal eben neukomplilieren weil mir ein Treiber nicht gefällt zum Bsp
    dazu kommt dass man die Qualität des Quellcodes nicht kennt mangels Quellcode
    weshalb dein Argument mit dem BlueScreen nicht als Kriterium angeführt werden kann

    >
    > > übrigens ist Linux kein reiner "Makrokernel" mehr, warum wohl
    > Danke, dass du dich outest keine Ahnung zu haben. Linux war noch nie ein
    > Makrokernel. Makrokernel ist nicht das Gegenteil von Mikrokernel,
    > Makrokernel ist ein anderer Begriff für einen Hybridkernel.
    >
    > Das konzeptionelle Gegenteil eines Mikrokernel ist der monolithische Kernel
    > - was Linux ist. Daran hat sich nie etwas geändert, das war er von Beginn
    > an und ist es auch heute. Wie das an anderer Stelle behauptet wurde ist das
    > Modulkonzept von Linux keine Aufweichung dieses Konzept sondern lediglich
    > eine Flexibilisierung der gleichen Idee - auch Kernelmodule laufen im
    > Kernelspace.

    hier du Oberschlauer
    http://www.heise.de/open/meldung/Linux-Treiber-in-den-Userspace-153415.html

    es wäre echt mal schön wenn Leute was zum Thema sagen würden
    anstatt Wortklauberei zu betreiben, begleitet wie immer mit dem Ahnung Statement
    Makrokernel hatte ich übrigens extra in Gänsefüsschen gesetzt
    aber einen "monolithische Kernel" zu verteidigen fällt anscheinend schwer :D



    4 mal bearbeitet, zuletzt am 01.10.13 12:13 durch Kaiser Ming.

  9. Re: du vergleichst Äpfel mit Birnen

    Autor: Vanger 01.10.13 - 13:09

    > > > vergleich mal lieber Linux mit einem Opensource Unix
    > > Wozu?
    > wegen Äpfeln und Birnen
    > Windows kann ich nicht mal eben neukomplilieren weil mir ein Treiber nicht
    > gefällt zum Bsp
    > dazu kommt dass man die Qualität des Quellcodes nicht kennt mangels
    > Quellcode
    > weshalb dein Argument mit dem BlueScreen nicht als Kriterium angeführt
    > werden kann
    Wie du unter Linux Module deaktivieren kannst, kannst du unter Windows Treiber deinstallieren. Wirkung ist die gleiche: In beiden Fällen wird der Treiber nicht mehr geladen. Bleiben dann die BSoD aus, ist die wahrscheinlichste Fehlerquelle gefunden.

    > > > übrigens ist Linux kein reiner "Makrokernel" mehr, warum wohl
    > > Danke, dass du dich outest keine Ahnung zu haben. Linux war noch nie ein
    > > Makrokernel. Makrokernel ist nicht das Gegenteil von Mikrokernel,
    > > Makrokernel ist ein anderer Begriff für einen Hybridkernel.
    > >
    > > Das konzeptionelle Gegenteil eines Mikrokernel ist der monolithische
    > > Kernel - was Linux ist. Daran hat sich nie etwas geändert, das war er von
    > > Beginn an und ist es auch heute. Wie das an anderer Stelle behauptet
    > > wurde ist das Modulkonzept von Linux keine Aufweichung dieses Konzept
    > > sondern lediglich eine Flexibilisierung der gleichen Idee - auch
    > > Kernelmodule laufen im Kernelspace.
    >
    > hier du Oberschlauer
    > www.heise.de
    Gut, zugegebenermaßen hatte ich von dieser Schnittstelle noch nie gehört. Diese Tatsache schränkt das aber auch schon wieder ein, denn da stellt sich die Frage: Wie häufig hast du diese Schnittstelle schon benutzt? Vermutlich noch nie. Das hat auch einen Grund:
    > Userspace-I/O-Treiber sollen in erster Linie proprietäre Treiber aus dem Embedded-Bereich ersetzen

    Nur weil eine einzelne Schnittstelle geschaffen wird, wird der Kernel nicht zum Hybridkernel. Nur wegen einer Schnittstelle, die die Flexiblität erhöhen soll, der Fokus aber weiterhin überwältigend auf der direkten Integration in den Kernel verbleibt, ändert sich das Konzept nicht. FUSE ist auch ein gutes Beispiel für eine beim monolithischen Kernel im Kernelspace befindliche Aufgabe die in den Userspace ausgelagert wird. Dennoch ist klar, dass der Linux-Kernel nicht auf FUSE sondern auf in den Kernel integrierte Dateisystemtreiber setzt - weshalb Linux auch weiterhin ein monolithischer Kernel bleibt. Das entspricht auch exakt der in der Literatur einschlägigen Auffassung. Bedenke, dass es wie bei vielen Themen in der Praxis nicht das theoretische Maximal gibt, auch das Konzept des Mikrokernels wird in der tatsächlichen Implementierung häufig aufgeweicht.

  10. Re: du vergleichst Äpfel mit Birnen

    Autor: Kaiser Ming 01.10.13 - 13:46

    Vanger schrieb:
    --------------------------------------------------------------------------------
    > > > > vergleich mal lieber Linux mit einem Opensource Unix
    > > > Wozu?
    > > wegen Äpfeln und Birnen
    > > Windows kann ich nicht mal eben neukomplilieren weil mir ein Treiber
    > nicht
    > > gefällt zum Bsp
    > > dazu kommt dass man die Qualität des Quellcodes nicht kennt mangels
    > > Quellcode
    > > weshalb dein Argument mit dem BlueScreen nicht als Kriterium angeführt
    > > werden kann
    > Wie du unter Linux Module deaktivieren kannst, kannst du unter Windows
    > Treiber deinstallieren. Wirkung ist die gleiche: In beiden Fällen wird der
    > Treiber nicht mehr geladen. Bleiben dann die BSoD aus, ist die
    > wahrscheinlichste Fehlerquelle gefunden.

    ja
    wenn nicht hast du allerdings ein Problem

    ich wollte allerdings auf etwas anderes hinaus,
    die Konzepte open/closed und komerziell/free sind so stark unterschiedlich und spielen auch in die direkte Programmierung rein,
    dass man damit keine(sehr begrenzt) Rückschlüsse auf den Kernel ziehen kann


    > Kernelspace befindliche Aufgabe die in den Userspace ausgelagert wird.
    > Dennoch ist klar, dass der Linux-Kernel nicht auf FUSE sondern auf in den
    > Kernel integrierte Dateisystemtreiber setzt - weshalb Linux auch weiterhin
    > ein monolithischer Kernel bleibt. Das entspricht auch exakt der in der
    > Literatur einschlägigen Auffassung. Bedenke, dass es wie bei vielen Themen
    > in der Praxis nicht das theoretische Maximal gibt, auch das Konzept des
    > Mikrokernels wird in der tatsächlichen Implementierung häufig aufgeweicht.

    Konzepte werden oft aufgeweicht, das schrieb ich ja auch schon in meinem ersten Beitrag,ganz gut auch bei RISC/CISC zu sehen,
    war jetzt aber auch nicht mein Argument

    > ein monolithischer Kernel bleibt. Das entspricht auch exakt der in der

    nichtsdestotrotz bleibst du immer noch den Nachweis des Vorteils schuldig
    oder aus meiner Sicht den Nachweis des Nichtnachteils

    in der heutigen Zeit wo kaum noch einer sein Linux selbst kompiliert,
    (ja ich weiss hat nur indirekt was damit zu tun)
    selbst Experten nicht mehr, kenn da welche die früher mal Gentoo benutzten,
    verschiebt sich das Konzept imo weiter zum negativen

  11. Re: du vergleichst Äpfel mit Birnen

    Autor: Vanger 01.10.13 - 14:26

    > nichtsdestotrotz bleibst du immer noch den Nachweis des Vorteils schuldig
    > oder aus meiner Sicht den Nachweis des Nichtnachteils
    Ich habe doch nie argumentiert (wenn du das so aufgefasst hast war es zumindest nicht gewollt), dass monolithische Kernel besser als Mikrokernel sind, sondern nur, dass Mikrokernel keine Vorteile gegenüber monolithischen Kerneln aufweisen und damit ihr (unbestrittener? Jedenfalls hat das hier niemand angekreidet...) zusätzlicher Overhead unnötig ist. Diesen Nicht-Vorteil von Mikrokerneln habe ich meiner Meinung nach zu Genüge ausgeführt: Sowohl Linux als auch Windows sind (was Kernel Panics bzw. BSoD angeht - also der Bereich in dem Mikrokernel laut Theorie Vorteile entfalten können) äußerst stabil. Das bedeutet, dass dieser theoretische Vorteil in der Praxis irrelevant wird, da die monolithischen bzw. Hybridkernel bereits stabil genug sind. Es besteht im Gegenteil die Gefahr, dass durch die bei einem Mikrokernel dann naturgemäß geringere Schwere eines Fehlers diese nicht die nötige Beachtung finden. Dieser letzte Satz ist aber zugegebenermaßen reine Mutmaßung.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. über duerenhoff GmbH, Raum Saalfeld
  2. HABA Group B.V. & Co. KG, Bad Rodach bei Coburg
  3. Anstalt für Kommunale Datenverarbeitung in Bayern (AKDB), München
  4. DAW SE, Ober-Ramstadt

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 19,98€ (nach 1 Monat 9,99€/Monat für Amazon Music Unlimited - frühestens zum Ende des ersten...
  2. (aktuell u. a. LG-Fernseher günstiger (u. a. LG 49UN73906LE (Modelljahr 2020) für 449€), Eufy...
  3. (u. a. "Alles fürs Lernen zuhause!" und "Cooler Sommer, heiße Preise" und )
  4. (u. a. Mount & Blade II - Bannerlord für 28,99€, Resident Evil 3 (2020) für 24,99€, Detroit...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Mars 2020: Was ist neu am Marsrover Perseverance?
Mars 2020
Was ist neu am Marsrover Perseverance?

Er hat 2,5 Milliarden US-Dollar gekostet und sieht genauso aus wie Curiosity. Einiges ist dennoch neu, manches auch nur Spielzeug.
Von Frank Wunderlich-Pfeiffer


    Indiegames-Rundschau: Stadtbaukasten trifft Tentakelmonster
    Indiegames-Rundschau
    Stadtbaukasten trifft Tentakelmonster

    Traumstädte bauen in Townscaper, Menschen fressen in Carrion und Bilderbuchgrusel in Creaks: Die neuen Indiegames bieten viel Abwechslung.
    Von Rainer Sigl

    1. Indiegames-Rundschau Licht aus, Horror an
    2. Indiegames-Neuheiten Der Saturnmond als galaktische Baustelle
    3. Indiegames-Rundschau Dunkle Seelen im Heavy-Metal-Rausch

    Programmiersprache Go: Schlanke Syntax, schneller Compiler
    Programmiersprache Go
    Schlanke Syntax, schneller Compiler

    Die objektorientierte Programmiersprache Go eignet sich vor allem zum Schreiben von Netzwerk- und Cloud-Diensten.
    Von Tim Schürmann