KDBUS Is Taking A Lot Of Heat, Might Be Delayed From Mainline Linux Kernel

[Ericg]

but ... shouldn't be the protocol be the same as "regular" dbus? I.e. act as a drop-in-replacement? Which in turn means the protocol is not up for debate ...

That is one of the arguments yes. Greg and others are proposing that its not up for debate because when they decided to write kdbus they said they were not going to break the dbus API and that it would be a drop in replacement. Hence why the name is "kDBUS" and not "LinuxIPC" or "kIPC." This is a -K-ernel level implementation of -DBUS-, nothing more and nothing less.

Opponents are saying that the DBUS API has fundamental flaws and that if they are going to go down the road of putting IPC into the kernel that they should do it right and if they have to break compatibility then so be it, in the end everyone will get a better system and if apps have to be updated then so be it.

Someone did ask, though they havent been responded to yet, on whether or not a shim-layer could be added that would allow existing DBUS programs to continue working even though kdbus did break compatibility with the DBUS API behind the scenes.

[Akka]

After reading the complete thread so are my impression lkml has almost as substanceless discussion as the phoronix forum. I get the impression the only one (besides the involved developers) concerned himself with reading the code is Lutomirski all the other only speak a lot.

[interested]

Yeah, I don't understand the technical issues here either, but I don't buy in to Greg's arguments that we're stuck with the existing design and that it can't be cleaned up ( http://lkml.iu.edu/hypermail/linux/k...4.1/04662.html ).

If the kernel needs a new style of IPC that isn't served by existing mechanisms, fine, but add something which will be broadly useful, well designed, and fixes the design mistakes of all it's predecessors.

Ramming through a bad design isn't a good long term strategy. Let's have nice clean flexible and maintainable kernel API's for the long haul (write "kGENERICIPC").

Either kdbus is accepted in such a way that legacy dbus1 works without modification, or the alternative is to rewrite the entire Linux/BSD user land to support a brand new, unproven kernel IPC. We are talking about millions of lines of code that needs to be changed.
The kernel developers that propose the "lets rewrite everything from scratch" don't seem to understand that user land wants more than just a IPC, they want something that can replace the dbus daemon too, which does more than just IPC.

So the "rewrite everything from scratch" solution needs to replace a decades worth of dbus experience and code that works for DE's like KDE, daemons, init-systems and Linux plumbing code. It will take years to even develops such a IPC and all necessary user land support libraries.

One huge advantage with kdbus is that user space programs can support both systemd and non-systemd Linux distros and BSD variants with the same code (dbus1). If the systemd developers drops kdbus, they are much more likely to develop their own systemd-only solution. Since systemd-distros represents something close to 100% of all commercial Linux distros, such a systemd-only solution will simply wipe out any remaining non-systemd distros. It will be tough for BSD too if Linux user land drops the common dbus standard in favour of a systemd-only solution.

[Brane215]

So the "rewrite everything from scratch" solution needs to replace a decades worth of dbus experience and code that works for DE's like KDE, daemons, init-systems and Linux plumbing code. It will take years to even develops such a IPC and all necessary user land support libraries.

Yes, when time comes for next step, it is no of use to bumble around. This is also how dbus has been done, after all.

DBUS crowd already has dbus. And kdbus, for those that want to have kernel version at all costs.

But before baking such solution into kernel globally, maybe it is time for taking the next step after summarizing accumulated experience with dbus and other approaches.

Also, not discrepancy between criteria for systemd and kdbus projects. Main force behind kdbus is systemd crowd. But when it comes to systemd, you don't hear often compatibility and existing code change argument.
Which changes the moment kdbus is mentioned.

If code change cost is always your main argument, then what is the point of having open source as it is ? Main strength of it is that code can be inspected, changed, and when needed, thrown out and rewritten.

[MoonMoon]

Can somebody enlighten me why those people that stand against it come up with their arguments after all the work is done and it is ready to be incorporated into the kernel, and not at one of the previous reviews or even when it was proposed? I mean, it was clear from the beginning that this will be DBUS in the kernel, so all those flaws they talk about have been known from the beginning, why didn't they come up with their arguments before someone wrote those 34K lines of code/documentation/tests, before man-years of work were put into it?

[Delgarde]

Either kdbus is accepted in such a way that legacy dbus1 works without modification, or the alternative is to rewrite the entire Linux/BSD user land to support a brand new, unproven kernel IPC. We are talking about millions of lines of code that needs to be changed.

Not quite. Major design changes would have that effect, but some changes can be adopted without affecting userspace. None of those millions of lines of code are currently talking to kdbus - they all use various userspace libraries, and it's the libraries that talk to the server (either kdbus or the current userspace daemon). So depending on the scale of changes required, a lot of the impact may be hidden in the libraries and language bindings.

[varikonniemi]

Can somebody enlighten me why those people that stand against it come up with their arguments after all the work is done and it is ready to be incorporated into the kernel, and not at one of the previous reviews or even when it was proposed? I mean, it was clear from the beginning that this will be DBUS in the kernel, so all those flaws they talk about have been known from the beginning, why didn't they come up with their arguments before someone wrote those 34K lines of code/documentation/tests, before man-years of work were put into it?

This is the primary question also i have about this situation.

[geearf]

My understanding is that many of these complaints have been raised before, and are being raised again.

[interested]

Also, not discrepancy between criteria for systemd and kdbus projects. Main force behind kdbus is systemd crowd. But when it comes to systemd, you don't hear often compatibility and existing code change argument.
Which changes the moment kdbus is mentioned.

I think you are completely wrong about this; a major, major design point with systemd is exactly that is a drop in replacement for SysVinit etc. with extensive backwards code compatibility for everything; hence systemd can work with SysVinit scripts and daemons and legacy setups that require syslog text files etc.

systemd provides alternative and better ways to implement certain things, but it also support almost all legacy ways of doing stuff. This allowed distros to gradually phase in systemd features; There was never a "flag day" where all of user space suddenly had to support a new daemon or logging interface or they wouldn't work.

If systemd had required that the entire Linux user space had to be rewritten in order to work with it, it would never have gained traction. It is exactly because systemd didn't require user space rewrites, and at the same time showed a path away from the SysVinit quagmire that it succeeded.

If code change cost is always your main argument, then what is the point of having open source as it is ? Main strength of it is that code can be inspected, changed, and when needed, thrown out and rewritten.

There is a huge difference between changing ones own code and forcing the entire Linux user space to be rewritten.
The proposals about making a clean slate IPC from scratch will require an insane amount of work that no one has volunteered to do either in the kernel nor in user space.

This 15 year old blog post about how rewriting everything from scratch is wrong and why programmers tend to react to any code they see with this wish, is still so very valid:

http://www.joelonsoftware.com/articles/fog0000000069.html

[crymsonpheonix]

There is a huge difference between changing ones own code and forcing the entire Linux user space to be rewritten.
The proposals about making a clean slate IPC from scratch will require an insane amount of work that no one has volunteered to do either in the kernel nor in user space.

This 15 year old blog post about how rewriting everything from scratch is wrong and why programmers tend to react to any code they see with this wish, is still so very valid:
http://www.joelonsoftware.com/articl...000000069.html

You're not wrong, but there are times that things need to be replaced even though it's painful.

One of those times is when there are major design flaws that *cannot* be incrementally fixed. This is the argument that the NAKers of kDBUS have (I don't know enough about DBUS or kDBUS to know the validity of their arguments). This is especially true of the kernel, where these interfaces will have to be maintained for 20+ years at least, if there are design flaws in kDBUS (especially security concerns) then they need to be addressed *now*, before the code lands.