Das mit deinem geschätzten 20x schneller halte ich für ein Gerücht. Je nach Architektur und Optimierung des C Codes wird doch ein differenzierter Maschinencode generiert.
Es ist ein Unterschied, ob ich einen (Am Beispiel von 680x0 Code) 'mulu' Befehl benutzt, welches 70+ Taktzyklen verwendet oder das Ganze mit einem 'swap' und zwei 'lsl' Befehlen substituiere.
Gut das ist unerheblich für dieses Beispiel. Es ist jedoch ein gewaltiger Unterschied, wenn alle Subprozesse des Kernels an den KDBUS kommunizieren und sich in der Gesamtsumme die Zyklen der ausgeführten Opcodes kumulieren.
Es gibt durchaus Systeme bzw. Programme die kein DBUS einsetzen.
Für mich sieht das eher aus, als wenn man Linus Torvalds und alle andere Kernelentwickler mit einer Mistforke von Hinten durchs Auge, durch 2 Türen und einem Kopf das KDBUS in die Aufnahme des Kernels "erpressen" will.
Wenn man es in Red Hat per Patches (und vollkommen ungetestet) aufschwatzt, die Entwickler (vornehmlich Gnome (Red Hat)) und andere das "gezwungenermaßen" nutzen, man eine ähnliche Situation schafft, wie es mit udev und systemd geschah.
Damit isoliert man andere unixoide Systeme noch mehr ins Abseits.
Stellt sich die Frage, was Linux noch mit Linux zu tun haben wird in 5-10 Jahren.
Es könnte aber so (Kernel - Userspace) verwendet werden, und daher ist es nicht auszuschließen dass das irgendwann mal vorkommen wird. Aber selbst dann wird es vermutlich eher eine Seltenheit irgend eines Hardwareexoten sein und gegenüber den vielen Clients aus dem Userspace kaum auffallen..
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 31. Jul 2015 um 14:29.
Wieviel Prozent der CPU-Zeit benötigt D-Bus auf einem normalen System? Es ist nicht mal messbar. KDBus ist noch mal schätzungsweise 20-mal schneller.
Das mit deinem geschätzten 20x schneller halte ich für ein Gerücht. Je nach Architektur und Optimierung des C Codes wird doch ein differenzierter Maschinencode generiert.
Es ist ein Unterschied, ob ich einen (Am Beispiel von 680x0 Code) 'mulu' Befehl benutzt, welches 70+ Taktzyklen verwendet oder das Ganze mit einem 'swap' und zwei 'lsl' Befehlen substituiere.
Gut das ist unerheblich für dieses Beispiel. Es ist jedoch ein gewaltiger Unterschied, wenn alle Subprozesse des Kernels an den KDBUS kommunizieren und sich in der Gesamtsumme die Zyklen der ausgeführten Opcodes kumulieren.
Es gibt durchaus Systeme bzw. Programme die kein DBUS einsetzen.
Für mich sieht das eher aus, als wenn man Linus Torvalds und alle andere Kernelentwickler mit einer Mistforke von Hinten durchs Auge, durch 2 Türen und einem Kopf das KDBUS in die Aufnahme des Kernels "erpressen" will.
Wenn man es in Red Hat per Patches (und vollkommen ungetestet) aufschwatzt, die Entwickler (vornehmlich Gnome (Red Hat)) und andere das "gezwungenermaßen" nutzen, man eine ähnliche Situation schafft, wie es mit udev und systemd geschah.
Damit isoliert man andere unixoide Systeme noch mehr ins Abseits.
Stellt sich die Frage, was Linux noch mit Linux zu tun haben wird in 5-10 Jahren.
Naja diese Teilaussage ist ja richtig und sicherlich unstrittig.
Schon möglich, aber warum sollten die das auf einmal tun?
KDBUS ist ja nicht für Kommunikation im Kernel oder zwischen Kernel und Userspace.
Es ist doch nur der kernelseitiger Teil für Userspace-Userspace Kommunikation
Es könnte aber so (Kernel - Userspace) verwendet werden, und daher ist es nicht auszuschließen dass das irgendwann mal vorkommen wird. Aber selbst dann wird es vermutlich eher eine Seltenheit irgend eines Hardwareexoten sein und gegenüber den vielen Clients aus dem Userspace kaum auffallen..
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 31. Jul 2015 um 14:29.