News Linux: Kdbus schafft es nach über 2 Jahren in Kernel 4.1

sturme schrieb:

Was für dich wie ein Flamewar aussieht hält die Qualität auf einem hohen Niveau.

Zum Vergrößern anklicken....

Frag doch mal Lennart Poettering, ob der das genauso sieht

Ich kenne keinen lkml "Flamewar" mit Poettering, wobei der kaum an Kernelentwicklung anstreift, im Gegensatz zu Kay Sievers. Und der hatte es mit seinem Fehlverhalten auch verdient...

Ich denke, hier war eher gemeint, dass nicht nur GKH sondern auch die Systemd-Entwickler hoffen, dass Kdbus es diesmal schafft, in den Kernel einzuziehen und nicht durch diese "Diskussion", die mehr aus weissem Rauschen denn aus technischen Argumenten besteht, nochmals verschoben zu werden.

Heißt das, dass es für die vorgebrachten sicherheitsbedenken keine echte Grundlage Sibt? Das wäre echt ehrlich. Ich arbeite viel auf eingebetteten Systemen und bin für jede Funktion dankbar, die der Kernel zur Verfügung stellt.

Ob Poettering sich jemals an einem Flamewar beteiligt hat, weiß ich nicht, er war in letzter Zeit aber sehr häufig Gegenstand unzähliger systemd-Flamewars, bei denen es ganz sicher nicht immer sachlich zuging und die dann auch wenig dazu beigetragen haben, die Qualität zu sichern.

Miuwa schrieb:

Heißt das, dass es für die vorgebrachten sicherheitsbedenken keine echte Grundlage Sibt? Das wäre echt ehrlich. Ich arbeite viel auf eingebetteten Systemen und bin für jede Funktion dankbar, die der Kernel zur Verfügung stellt.

Zum Vergrößern anklicken....

Die Sicherheitsbedenken sind ernst zu nehmen und das tut GKH auch. Aber außer diesen wenigen, technisch unterfütterten Bedenken ist dort viel Rauch und wenig Substanz. Systemd hat halt auch die Kernel-Entwickler-Gemeinschaft gespalten.

Geht ja nicht um die Sicherheit des Kernels an sich, nur um das "Gerede" zwischen den Dbus-Komponenten. Der Kernel transportierts nur von A nach B, kümmert sich aber um Adressierung/Zugriffsrechte. Den Part hätte man anders lösen können. Die These einiger Kernel-Leute ist nun, dass man sich über die aktuelle Methode in nicht zu ferner Zukunft ärgern wird, die Dbus-Leuten dann mit einer besseren Idee ankommen(d.h. ein anderes Interface zum Kernel wollen) und sie dieses dann erneut in den Kernel integriert haben wollen, was dank beharren auf einem stabilen Kernel-API scheitern würde bzw. altes und neues Interface parallel supportet werden müssten.

Ergo:
Bei neuen Funktionen des Kernels, die nach außen sichtbar sind, lieber 3 mal mehr nachdenken statt einbauen und sich ggf. später ärgern. Man will keine 100 verschiedenen APIs zur Interprozesskommunikation sondern nur wenige, wirklich gut ausgetüftelte.

Das die Kernel-Leute der Freedesktop-Dbus-whatever-Bloat-Fraktion ggü. besonders kritisch+skeptisch eingestellt sind, wenns um API-Design geht, wird niemanden wundern. O-Ton dürfte da sein: "Usermode-Weicheier, denen Effizienz wurscht ist und die jeden Tag 5 neue, inkompatible Versionen von APIs erfinden und einbauen und 2 alte nicht mehr supporten und sich um Sachen wie Überlast, Speicherverbauch u.ä. nicht konzeptionell kümmern"

fethomm schrieb:

Die Sicherheitsbedenken sind ernst zu nehmen und das tut GKH auch. Aber außer diesen wenigen, technisch unterfütterten Bedenken ist dort viel Rauch und wenig Substanz. Systemd hat halt auch die Kernel-Entwickler-Gemeinschaft gespalten.

Zum Vergrößern anklicken....

Das ist allerdings eine stark vereinfachte Sicht auf die Dinge. Wenn sich erfahrene Kernelentwickler bspw. an mies bzw. gar nicht dokumentiertem Code stoßen, sollte man das etwas ernster nehmen. Auch die Diskussion um die API: Im Kernel gelten schlicht andere Standards, nicht umsonst ist er so erfolgreich. Andere, weniger kontroversielle Erweiterungen haben es erst nach vielen, vielen Jahren in den Kernel geschafft, dass die Argumentation wieso kdbus unbedingt _jetzt_ schon in den Merge Window musste schon über "sind ja bloß 13k Zeilen" hinausgehen sollte. In diesem Zusammenhang halte ich auch die Vergleiche mit Hardware für völlig fehl am Platz, gerade in der Open Source Welt.

Merge Window closed, wie erwartet ist kdbus nicht dabei. Stattdessen ist Linus in die Diskussion eingestiegen: http://lkml.iu.edu/hypermail/linux/kernel/1504.3/02040.html

Linus scheint gar nicht über den Grund, weshalb es in den Kernel soll, amüsiert zu sein: "IOW, all the people who say that it's about avoiding context switches are probably just full of shit. It's not about context switches, it's about bad user-level code."

Irgendwo finde ich es schwer zu glauben, dass die Entwickler 2 Jahre an KDBus gearbeitet haben ohne DBus mir einem vernünftigem Profiler unter die Lupe genommen zu haben. Falls doch würde ich deren Code nicht mal in die Nähe des Kernels lassen.

Meine Vermutung (nur geraten): Selbst wenn die Kontextswitches selbst nicht für die lahme Performance verantwortlich sind können mehr Switches zu mehr Arbeit im Userspace führen, die bei der Kernelvariante schlicht nicht nötig ist.

Das wars dann wohl fürs erste:

If the code spends 10x as much time in user space in "overhead" as it
actually spends in the kernel, the proper place to optimize is to get
rid of the 10x. That will make things much faster.

Once user space is lean and mean, at that point do I believe that "ok,
let's add kernel code for the last bit of performance". But as it is
right now, anybody who works on kdbus and claims that _performance_ is
the reason for their work is just looking at teh wrong piece of the
puzzle.

Now, there may be *other* reasons why kdbus is a good idea. But quite
frankly, every time somebody asks "why", performance seems to be one
of the main answers.

And quite frankly, that *stinks*.

Do proper optimizations of the actual real costs before starting to
work on kernel stuff. It's *stupid* to add a kernel driver to get 2x
improvement, when there's a 10x bloat in user space.

Zum Vergrößern anklicken....

http://article.gmane.org/gmane.linux.kernel/1940021