1. Foren
  2. Kommentare
  3. OpenSource-Forum
  4. Alle Kommentare zum Artikel
  5. › Lennart Poettering: Systemd…

"Wir stopfen einfach alles in den Kernel"

  1. Thema

Neues Thema


  1. "Wir stopfen einfach alles in den Kernel"

    Autor: zilti 22.06.15 - 16:09

    Was genau ist denn der Vorteil, nun auch das noch in den Kernel zu verlagern? Das führt doch komplette Sicherheitsmechanismen ad absurdum und öffnet Tür und Tor für neue Lücken?

  2. Re: "Wir stopfen einfach alles in den Kernel"

    Autor: bstea 22.06.15 - 16:11

    Die Antwort: Es ist Linux.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  3. Re: "Wir stopfen einfach alles in den Kernel"

    Autor: pfanne 22.06.15 - 17:48

    Es bietet mehr Performance als D-Bus, einen Interprozesskommunikationsstandard für Linux, sowie Interprozesskommunikation sehr früh im Bootvorgang des Systems, was systemD zugute kommt.

  4. Re: "Wir stopfen einfach alles in den Kernel"

    Autor: RipClaw 22.06.15 - 18:30

    pfanne schrieb:
    --------------------------------------------------------------------------------
    > Es bietet mehr Performance als D-Bus, einen
    > Interprozesskommunikationsstandard für Linux, sowie
    > Interprozesskommunikation sehr früh im Bootvorgang des Systems, was systemD
    > zugute kommt.

    Ich glaube die Geschwindigkeit ist eher nebensächlich da man auch im Userspace mit entsprechender Optimierung das ganze sicher flotter hinbekommt als das klassische D-Bus.

    Was vor allem das wichtigste sein dürfte ist das bereits sehr früh im Bootvorgang Kdbus zur Verfügung steht.

  5. Re: "Wir stopfen einfach alles in den Kernel"

    Autor: felix.schwarz 22.06.15 - 22:10

    RipClaw schrieb:
    > Ich glaube die Geschwindigkeit ist eher nebensächlich

    nein, z.B. zero-copy für große Daten

  6. Re: "Wir stopfen einfach alles in den Kernel"

    Autor: erzgebirgszorro 23.06.15 - 07:08

    Nein, gerade die Geschwindigkeit ist hier großer Treiber der Umsetzung. Sonst bräuchte man es nicht im Kernel. Ich halte Mr. Poettering und seine Kumpane im Übrigen für ziemlich intelligent was die Umsetzung moderner Systemkonzepte angeht. Die Integration von D-BUS in den Kernel allerdings wird schon seit langer Zeit angedacht, ich erinnere mich da an einen Blog-Beitrag von Alexander Larsson (GNOME-Projekt) vor einigen Jahren, wo das Thema eine Rolle spielte.

  7. Re: "Wir stopfen einfach alles in den Kernel"

    Autor: bstea 23.06.15 - 08:24

    D-Bus mit Geschwindigkeit in Beziehung zu setzen zeugt nicht gerade davon, dass du viel Ahnung hast. Das einzige Ziel dieser Maßnahme ist es bereits früh Bus-Semantik zu ermöglichen.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  8. Linus will einfach nicht zugeben, dass Tannenbaum recht hatte ;-)

    Autor: taschenorakel 23.06.15 - 08:32

    DBus ist ein Mechanismus der die Kommunikation über Prozessgrenzen hinweg erlaubt.

    Um dies sicher zu erledigen benötigt man Zugriff auf die Datenstrukturen des Kernels. Triviale Dinge wie "Darf dieser Nutzer diesen Service benutzen?" lassen sich noch halbwegs sicher im Userspace erledigen. Interessantere Fragen, wie "Wie kommt dieser Prozess überhaupt in das System?", "Ist das Binary signiert?" lassen sich eigentlich nur innerhalb des Kernels zuverlässig beantworten.

    Noch wichtiger ist Effizienz. Hier rede ich nicht von großen Datenmengen, denn dafür war DBus nie gedacht: Alles was es erledigen soll, ist Aktionen anstoßen und Statusmeldungen liefern. Trotzdem lassen sich große Mengen bereits heute effizient per File-Descriptor versenden. Die wesentliche Effizienz um die es geht, ist Power-Management. Fragen wie: "Prozess X wurde gerade schlafen gelegt. Muss ich ihn für Nachricht Y jetzt sofort aufwegen? Oder darf ich bis zur nächsten Zeitscheibe warten? Oder kann das sogar warten, bis die CPU wieder aus dem Sleep-Modus ausgeweckt wird?" Um diese Power-Management-Aspekte geht es primär!

    Letztendlich empfinde ich Torvald's Haltung zu KDBus als scheinheilig: DBus gehört genauso in den Kernel, wie der IP-Stack, Unix-Sockets oder Netlink. Der Kernel enthält bereits wesentlich unsinnigere Sachen, die viel eher in den Userspace gehören, wie z.B. Netzwerkdateisysteme (SMB, NFS, ...). Mein gehe persönlicher, absolut unfundierter Verdacht ist ja, dass Linus einfach nicht zugeben will, dass Tannenbaum recht hatte: Sobald KDBus im Kernel landet, hat diese plötzlich einen effizienten IPC und man könnte das Ding in 'nen Micro-Kernel umbauen... :)



    1 mal bearbeitet, zuletzt am 23.06.15 08:33 durch taschenorakel.

  9. Re: "Wir stopfen einfach alles in den Kernel"

    Autor: erzgebirgszorro 23.06.15 - 08:33

    Nur weil man etwas nicht versteht dem anderen Ahnunglosigkeit zu unterstellen ist Diskussionskultur in Höchstform, Bravo! Informiere dich doch bitte vorher über die Hintergründe zu K-DBUS, bevor du mir Ahnungslosigkeit unterstellst. Die jetzigen sinnvollen Features wie erhöhte Sicherheit und ein frühes Messaging sind erst später dazu gekommen, als systemd dies nutzen und erweitern konnte. Die Idee und erste Implementierungen zu K-DBUS waren aber schon vorher da, aus Geschwindigkeitsüberlegungen heraus.

  10. Re: "Wir stopfen einfach alles in den Kernel"

    Autor: YoungManKlaus 23.06.15 - 12:38

    1) Performance da man sich mehr als die Hälfte der Context-switches spart, oder auch da man nicht Speicherbereiche kopieren muss sondern die einfach weitergeben kann (zero-copy)
    2) angeblich tatsächlich _bessere_ Sicherheit da man Sicherheits-Features des Kernels direkt verwenden kann (aber da kenn ich mich auch nicht so gut aus)
    3) es ergibt einfach tatsächlich Sinn einen guten IPC-Mechanismus im Kernel zu haben (da gibts viel unnötigere Systeme die man vorher auslagern könnte).

    EDIT: hier eine (englische) Zusammenfassung: https://en.wikipedia.org/wiki/User:ScotXW/kdbus



    1 mal bearbeitet, zuletzt am 23.06.15 12:40 durch YoungManKlaus.

  11. Re: "Wir stopfen einfach alles in den Kernel"

    Autor: bstea 23.06.15 - 21:48

    Achso und ich dachte die Entwickler hätten das gesagt, dann müssen deren Präsentationen im nachhinein gefälscht wurden sein und nur du hast Recht.
    Ob KD-Bus wirklich so viel ausmacht sei mal dahingestellt. Derzeit scheinen viele Performanceprobleme beim Daemon und dem Client zu liegen. Und verglichen mit anderen IPC ist es nicht performant, eher eine langsame Krücke. Es ist keine Kunst D-Bus Implementierung abzuhängen, die scheint ja außerdem auf mehr als einer Plattform zu funktionieren.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  12. Re: "Wir stopfen einfach alles in den Kernel"

    Autor: erzgebirgszorro 26.06.15 - 08:04

    Anscheinend hast du noch nicht verstanden was K-DBUS bewirkt. Denn mit K-DBUS würde der Daemon wegfallen können bzw. nur eine untergeordnete Rolle spielen. Ergo kann er auch nicht mehr für Performance-Probleme verantwortlich sein. Aber hauptsache mal rumgebrüllt dass andere keine Ahnung hätten ...

  1. Thema

Neues Thema


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. Forecasting Data Scientist (m/w/d)
    ALDI SÜD Dienstleistungs-SE & Co. oHG, Mülheim an der Ruhr
  2. IT-System-Administrator*in (m/w/d) im Storage / Fileservice-Bereich
    Humboldt-Universität zu Berlin, Berlin-Adlershof
  3. Anwendungsbetreuer*in Campus Management System (m/w/d)
    Humboldt-Universität zu Berlin, Berlin
  4. Leitung IT (m/w/d)
    Steinco Paul vom Stein GmbH - Wermelskirchen, Wermelskirchen

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. mit 20% auf Logitech und Razer, 3 Games für 49€ und vielen weiteren Angeboten. Extra-Punkte für...
  2. u. a. Gigabyte B550 Gaming Mainboard für 107,90€ statt 145,90€
  3. (bis 17.01.2024)


Haben wir etwas übersehen?

E-Mail an news@golem.de