Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › IPC: Linux-Kernel soll D-Bus…

Und was soll das bringen?

  1. Thema

Neues Thema Ansicht wechseln


  1. Und was soll das bringen?

    Autor: fratze123 11.02.13 - 12:44

    Beschleunigung? Habe noch nie davon gehört, dass D-Bus ein Geschwindigkeitsproblem haben soll. Dürfte auch keine Rolle spielen, ob das nun als Dienst oder direkt im Kernel gemacht wird. Was das mit 'ner Sandbox zu tun haben sollte, kann ich auch nicht erkennen.

    Na ja. Wird schon Gründe haben, warum der bisher gescheitert ist...

  2. Re: Und was soll das bringen?

    Autor: birdy 11.02.13 - 13:11

    Also ich habe schon laufend von Performanc-Problemen mit DBUS "gehört". Aber nicht unbedingt am Desktop...

    Warum das schneller ist, ist klar, weil dann kein separater Daemon mehr laufen würde. Und damit der eine oder andere User-space / Kernel-space Switches entfallen würden.

    Wobei die Performance-Probleme oft an der falschen Nutzung von DBUS liegen.

  3. Re: Und was soll das bringen?

    Autor: BRDiger 11.02.13 - 13:24

    > Die Verlegung des IPC-Systems in den Kernel sorge für eine notwendige
    > Standardisierung.

    Gute Absicht!

    > Dürfte auch keine Rolle spielen, ob das nun als Dienst oder direkt im Kernel gemacht
    > wird.

    Schon mal davon gehört, dass Programme im Kernel-Space eine viel höhere Priorität haben als andere?

    Aber das mit der Sandbox verstehe ich auch nicht! Sandbox???
    Programme die im Kernel-Space laufen, können so ziemlich alles zerstören was sie wollen. Das ist bei Treibern ebenso. So funktioniert ein monolithischer Kernel nun mal.

    Außerdem hat man den Nachteil, dass der Kernel dadurch noch komplizierter wird und mehr Angriffsfläche bietet. Man darf nicht vergessen, dass der Kernel komplett im RAM liegt mit allen Treibern (Modulen) und dementsprechend mehr Quelltext zu mehr Angriffsfläche führt.

    Andererseits ist es vielleicht der einzige Weg die Distributoren zu zwingen ein einheitliches System umzusetzen. Denn der Kernel wird ja von den Distributionen übernommen und dementsprechend wäre es gut, wenn die Distributoren sich an eine Schnittstelle des Kernels wenden könnten anstatt ihren eigenen Mist zu basteln, der es fast nie schafft zum Standard zu werden.

    Im Großen und Ganzen spricht mehr *gegen* dieses IPC-System im Kernel.
    Man muss auch bedenken: Für Kommunikation innerhalb des Kernels hat man andere schnellere Wege. Also braucht *der Kernel* dieses IPC-Zeug nicht. Die Kernel-Entwickler wollen natürlich nichts umsetzen, was mehr Arbeit als Erfolg bringt, denn zur Kernel-internen Kommunikation gibt es wie gesagt andere schnellere Wege und der Kernel sollte nicht dafür zuständig sein anderen Kernel-externen Programmen eine Kommunikationsschnittstelle zu bieten.
    Ansonsten sollte man Greg Kroah-Hartman nicht unbedingt Inkompetenz vorwerfen. Wenn man sieht für was der Mann Maintainer ist...nicht übel.

  4. Re: Und was soll das bringen?

    Autor: birdy 11.02.13 - 13:37

    BRDiger schrieb:
    --------------------------------------------------------------------------------
    > Aber das mit der Sandbox verstehe ich auch nicht! Sandbox???

    Prinzipiell - der Kernel muss über die Sandbox sowieso Bescheid wissen. Sonst funktioniert das nicht, Das einem externem Daemon (sicher) klar zu machen ist schon deutlich schwieriger.

    > Außerdem hat man den Nachteil, dass der Kernel dadurch noch komplizierter
    > wird und mehr Angriffsfläche bietet. Man darf nicht vergessen, dass der
    > Kernel komplett im RAM liegt mit allen Treibern (Modulen) und
    > dementsprechend mehr Quelltext zu mehr Angriffsfläche führt.

    "Dementsprechend" ?!? Du verwürfelst hier in paar Dinge. Aber im Grunde gebe ich recht. Sicherheit ist einer der größten Punkte gegen dieses Projekt.

    > Andererseits ist es vielleicht der einzige Weg die Distributoren zu zwingen
    > ein einheitliches System umzusetzen. Denn der Kernel wird ja von den
    > Distributionen übernommen und dementsprechend wäre es gut, wenn die
    > Distributoren sich an eine Schnittstelle des Kernels wenden könnten anstatt
    > ihren eigenen Mist zu basteln, der es fast nie schafft zum Standard zu
    > werden.

    Hast du da ein paar Beispiele?
    Ich kenne nur Binder und KDbus. Wobei zweiteres meines Wissens nach nie verwendet wurde. Viel mehr ist _mir_ aktuell nicht geläufig.

    > Im Großen und Ganzen spricht mehr *gegen* dieses IPC-System im Kernel.

    Kommst auf den Standpunkt an.
    Ich z.B. wäre ganz klar dafür.

    > Die Kernel-Entwickler wollen natürlich nichts umsetzen, was mehr Arbeit als
    > Erfolg bringt, denn zur Kernel-internen Kommunikation gibt es wie gesagt
    > andere schnellere Wege und der Kernel sollte nicht dafür zuständig sein
    > anderen Kernel-externen Programmen eine Kommunikationsschnittstelle zu
    > bieten.

    Andererseits gibt es z.B. DRM, dass es schon jetzt erweiterte Schnittstellen für die Kommunikation des Kernels zum Userspace gibt.

  5. Re: Und was soll das bringen?

    Autor: Rainer Tsuphal 11.02.13 - 14:06

    birdy schrieb:
    --------------------------------------------------------------------------------
    > Also ich habe schon laufend von Performanc-Problemen mit DBUS "gehört".

    D-Bus ist kein D-Zug. Eher ein ICE!

  6. Re: Und was soll das bringen?

    Autor: BRDiger 11.02.13 - 16:36

    @birdy

    " Ich z.B. wäre ganz klar dafür. "

    Wieso? Also, welche Vorteile siehst du?

    > "Dementsprechend" ?!? Du verwürfelst hier in paar Dinge."

    Wieso? Meine Aussage war: Kernel liegt in RAM. Wenn Kernel noch größer und komplizierter wird liegt noch mehr im RAM (genauer "Kernel-Space") und wenn dort etwas korrumpiert wird, dann hat man ein Problem....das ist doch das gleiche also ob man Treiber unter Linux nutzt. Die Treiber können sich doch nahezu "frei bewegen", laufen ständig mit root-Rechten und im Kernel-Space.

  7. Re: Und was soll das bringen?

    Autor: birdy 11.02.13 - 17:06

    BRDiger schrieb:
    --------------------------------------------------------------------------------
    > Wieso? Also, welche Vorteile siehst du?

    1.) Performance

    2.) Hilft es der Sicherheit. Denn DBUS muss nicht mehr umständlich via AppAmor oder ähnlichem abgedichtet werden. Das macht dann der Kernel selber.
    Das ist der Teil der die Sandbox betrifft.

    3.) Performance

  8. Re: Und was soll das bringen?

    Autor: taschenorakel 11.02.13 - 22:42

    Architektur: Der D-Bus-Daemon ist ein Message-Dispatcher und dupliziert damit die im Netzwerk-Stack implementierte Funktionalität.

    Zero-Copy: Speicher-Busse, CPU-Caches freuen sich, wenn Informationen herumgereicht werden, ohne dass sie explizit über Prozessgrenzen kopiert werden müssen. Der Kernel kann hier mit netten Features namens Zero-Copy und Copy-On-Write aufwarten: Sobald eine D-Bus-Message aufbereitet und die Empfänger bekannt sind, wird die verwandte Speicherseite aus dem Kernel-Pool entfernt und in den Adressraum der Empfänger eingeblendet. Erfordert nur ein paar kleine Bit-Tricks. Funktioniert hervorragend bei Festplattentreibern, Netzwerktreibern, Memory-Mapped-Files usw.

    Doch am wichtigsten ist das Vermeiden von CPU-Wakeups!

    Solange die D-Bus-Nachrichten durch einen Userspace-Prozess verteilt werden, werden für jede Nachricht wenigstens vier Prozesse aktiv: Sender, D-Bus-Daemon, die 1 bis n Empfänger und in der Mitte der Kernel welcher den dummen Dienstbote für verschickten Socket-Nachrichten spielt. Wenn der Kernel hingegen die Nachrichten verteilt, fällt erstmal der D-Bus-Daemon als aufwachender Prozess weg und noch viel besser: Da der Kernel nun die auf den Nachrichten aufgeklebten Adressaufkleber so halbwegs versteht, kann er mit dem Weiterleiten warten, bis der empfangende Prozess turnusmässig aufzuwecken wäre. Solange die Reihenfolge der Nachrichten erhalten bleibt[*] und die Verzögerung akzeptable ist, bekommt keiner der Userspace-Prozesse was vom Zauber mit, die CPU kann aber, da seltener panisch aufgeweckt wird in tiefere Träume versinken und die Batterie besser schonen.

    [*] Als ich das letzte mal aufs Thema blickt, war man sich gerade uneinig, ob Nachrichten umsortiert werden dürfen.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Apollo-Optik Holding GmbH & Co. KG, Schwabach / Metropolregion Nürnberg
  2. Auswärtiges Amt, Bonn, Berlin
  3. Energiedienst Holding AG, Rheinfelden (Baden)
  4. OMICRON electronics GmbH, Klaus (Österreich)

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 529,00€ (zzgl. Versand)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Faire IT: Die grüne Challenge
Faire IT
Die grüne Challenge

Kann man IT-Produkte nachhaltig gestalten? Drei Startups zeigen, dass es nicht so einfach ist, die grüne Maus oder das faire Smartphone auf den Markt zu bringen.
Von Christiane Schulzki-Haddouti

  1. Smartphones Samsung und Xiaomi profitieren in Europa von Huawei-Boykott
  2. Smartphones Xiaomi ist kurz davor, Apple zu überholen
  3. Niederlande Notrufnummer fällt für mehrere Stunden aus

Nachhaltigkeit: Jute im Plastik
Nachhaltigkeit
Jute im Plastik

Baustoff- und Autohersteller nutzen sie zunehmend, doch etabliert sind Verbundwerkstoffe mit Naturfasern noch lange nicht. Dabei gibt es gute Gründe, sie einzusetzen, Umweltschutz ist nur einer von vielen.
Ein Bericht von Werner Pluta

  1. Nachhaltigkeit Bauen fürs Klima
  2. Autos Elektro, Brennstoffzelle oder Diesel?
  3. Energie Wo die Wasserstoffqualität getestet wird

Noise Cancelling Headphones 700 im Test: Boses bester ANC-Kopfhörer sticht Sony vielfach aus
Noise Cancelling Headphones 700 im Test
Boses bester ANC-Kopfhörer sticht Sony vielfach aus

Bose schafft mit seinen neuen Noise Cancelling Headphones 700 eine fast so gute Geräuschreduzierung wie Sony und ist in manchen Punkten sogar besser. Die Kopfhörer haben uns beim Testen aber auch mal genervt.
Ein Test von Ingo Pakalski

  1. Bose Frames im Test Sonnenbrille mit Musik
  2. Noise Cancelling Headphones 700 ANC-Kopfhörer von Bose versprechen tollen Klang
  3. Frames Boses Audio-Sonnenbrille kommt für 230 Euro nach Deutschland

  1. Spielestreaming: Cyberpunk 2077 erscheint für Stadia
    Spielestreaming
    Cyberpunk 2077 erscheint für Stadia

    Gamescom 2019 Google hat das Rollenspiel Cyberpunk 2077 für Stadia eingekauft - leider ohne zu verraten, ob die Raytracing-Version gestreamt wird. Auch der Landwirtschaft-Simulator 2019 und Borderlands 3 sollen über die neue Plattform erscheinen.

  2. Magentagaming: Auch die Telekom startet einen Cloud-Gaming-Dienst
    Magentagaming
    Auch die Telekom startet einen Cloud-Gaming-Dienst

    Google Stadia, Blade Shadow und jetzt Magentagaming: Die Deutsche Telekom macht beim derzeit viel diskutierten Cloud-Gaming-Geschäft mit. Das Angebot der Telekom umfasst zum Beginn 100 Spiele und soll in Full-HD und später in 4K funktionieren. Die Beta startet noch auf der Gamescom 2019.

  3. Streaming: Disney+ kommt zunächst nicht für Amazon-Geräte
    Streaming
    Disney+ kommt zunächst nicht für Amazon-Geräte

    Disneys Streamingdienst Disney+ wird auf einer Reihe von Geräten als App verfügbar sein - nicht jedoch auf Amazons Tablets und TV-Sticks. Außerdem hat Disney die ersten Länder bekanntgegeben, in denen der Dienst im November 2019 starten wird.


  1. 20:01

  2. 17:39

  3. 16:45

  4. 15:43

  5. 13:30

  6. 13:00

  7. 12:30

  8. 12:02