I am following the discussion caused by Greg Kroah-Hartman requesting that kdbus be pulled into the next kernel release. First of all my hat of to Greg for his persistence and staying civil. There has already been quite a few posts to the thread at coming close to attempts at character assassination and a lot of emails just adding more noise, but no signal.
One point I feel is missing from the discussion here though is the question of not making the perfect the enemy of the good. A lot of the posters are saying that ‘hey, you should write something perfect here instead of what you have currently’. Which sounds reasonable on some level, but when you think of it is more a deflection strategy than a real suggestion. First of all the is no such thing as perfect. And secondly if there was how long would it take to provide the theoretical perfect thing? 2 more years, 4 years, 10 years?
Speaking as someone involved in making an operating system I can say that we would have liked to have kdbus 5 years ago and would much prefer to get kdbus in the next few Months, than getting something ‘perfect’ in 5 years from now.
So you can say ‘hey, you are creating a strawman here, nobody used the word ‘perfect” in the discussion. Sure, nobody used that word, but a lot of messages was written about how ‘something better’ should be created here instead. Yet, based on from where these people seemed to be coming the question I ask then is: Better for who? Better for the developers who are already using dbus in the applications or desktops? Better for a kernel developer who is never going to use it? Better for someone doing code review? Better for someone who doesn’t need the features of dbus, but who would want something else?
And what is ‘better’ anyway? Greg keeps calling for concrete technical feedback, but at the end of the day there is a lot of cases where the ‘best’ technical solution, to the degree you can measure that objectively, isn’t actually ‘the best’. I mean if I came up with a new format for storing multimedia on an optical disk, one which from a technical perspective is ‘better’ than the current Blu-Ray spec, that doesn’t mean it is actually better for the general public. Getting a non-standard optical disc that will not play in your home Blu-Ray player isn’t better for 99.999% of people, regardless of the technical merit of the on-disc data format.
Something can actually be ‘better’ just because it is based on something that already exists, something which have a lot of people already using it, lets people quickly extend what they already are doing with the new functionality without needing a re-write and something which is available ‘now’ as opposed to some undefined time in the future. And that is where I feel a lot of the debaters on the lkml are dropping the ball in this discussion; they just keeping asking for a ‘better solution’ to the challenges of a space they often don’t have any personal experience with developing in, because kdbus doesn’t conform to how they would implement a kernel IPC mechanism for the kind of problems they are used to trying to solve.
Also there has been a lot of arguments about the ‘design’ of kdbus and dbus. A lot of lacking concreteness to it and mostly coming from people very far removed from working on the desktop and other relevant parts of userspace. Which at the end of the day boils down to trying to make the lithmus test ‘you have to prove to me that making a better design is impossible’, and I think that anyone should be able to agree that if that was the test for adding anything to the Linux kernel or elsewhere then very little software would ever get added anywhere. In fact if we where to hold to that kind of argumentation we might as well leave software development behind and move to an online religion discussion forum tossing the good ol’ “prove to me that God doesn’t exist’ into the ring.
So in the end I hope Linus, who is the final arbiter here, doesn’t end up making the ‘perfect’ the enemy of the good.
I disagree with this post. There have been many valid criticism of the design made, especially with regards to security. I also agree with the notion that dbus does not need to be in the kernel. The kernel can provide better a better IPC system sure, but why should the design be tied to dbus? As long as a userspace implementation of dbus can be built on top of it it’s fine. A smaller design that serves more general use-cases can be used to build other IPC systems as well. Finally, it’s important to recognize a fundamental different between kernel-provided interfaces and userspace ones: a kernel interface cannot change. This means that the design (not necessarily implementation) has to be right or good enough on the first try. For things of this nature (think IPv6, HTTP2, etc) it’s normal for them to take years to develop for precisely this reason. Yes, the kernel should provide a better IPC system which speeds dbus up and provide the required functionality to meet the systemd devs requirements, but what’s the rush. Dbus is here and works and it’s better to be cautious when adding something that will be used on every Linux desktop (and many servers and embedded systems) and have potentially strange interactions with other subsystems.
What is the rush? We been waiting for this for years now, I don’t think claiming we are in a rush is a fair characterization. One could turn it around and ask what is the foot dragging about, why are you are asking us to wait for even more years hoping for some hypothetical person comes up with the better IPC mechanism.
The foot dragging is precisely because of the reason Joe stated. And it’s a very important one.
On an unrelated tangent… I’m really not sure drawing a comparison between dbus/kdbus and the patent-encumbered, licensing-fee drawing Bluray format – which won the format war only because Sony was determined to be in control and spent millions (or more?) to ensure victory thus forcing an inferior format down everyone’s throats – is really doing your cause any justice. If anything I think it’s just going to give the conspiracy theorists more fuel.
Well I am not going to digress into a Blu-Ray vs HD-DVD debate here :) And at some point one just have to live with the conspiracy theorists, if they want to read some hidden meaning into me using that as an example then they are probably a lost cause anyway, in fact I would recommend Greg renaming his patch set to ‘Area 51’ to really fire them up :)
While my quote uninformed opinion is that kdbus is good enough, I understand the concern about adding such an important new system in the kernel. It’s something we’ll have to live with “forever”. That is probably another point of differentiation between kernel and desktop developers.
The problem is that a generic approach was already attempted, it was called AF_BUS, and it was flatly rejected by David Miller (the networking subsystem maintainer), largely on the basis that it was a generic thing for a single user. So the D-Bus community went back to work and came back with a specific self-contained solution that didn’t impact the rest of the kernel. You just can’t have it both ways.
Trying to abstract something that exists (D-Bus) and other possible things that don’t exist, will end up with something that works not as well for D-Bus (because generic), and that will probably not be useful for anything not D-Bus anyway.
Ref: https://lwn.net/Articles/504970/
I think it’s best to connect this to HTTP2 and QUIC. With HTTP2, the semantics of HTTP from an application’s perspective do not change. All the developer has to do is link against a new library or upgrade their HTTP server and they are done (there is a similar goal for QUIC). However, the wire used to send the data has changed substantially in the process. This is obviously more true with QUIC, and at least there the developers are aiming to have something that works for more than just HTTP (more like a TCP replacement in that regard).
There is no reason that kdbus should be tied to DBUS’s design. Before the recent discussions I was under the impression that most/all of the dbus-specific work was being done in userspace, but based on the recent discussion this seems to be false which (in addition to the security issues) is why I have an issue with this.
“There is no reason that kdbus should be tied to DBUS’s design.”
Sure there is: it’s called KDBus not KGenericIPCTransport.
That’s the whole point of KDBus: to have a fast, race-free, secure DBus transport with the help of the kernel; this means following the DBus design, and, more importantly, that it works as a drop-in replacement for the existing DBus daemon, as far as applications are concerned. Any other concern is largely academic. Sure, we could replace every application using DBus with another IPC mechanism, if we had the infinite time and resources; by that same line of thought, we could all hold out on Linux until we get the perfect I/O scheduler, or the perfect cgroup implementation.
No. Kdbus does not need to be tied to the design of dbus to implement dbus in userspace. The kernel does not understand HTTP or websockets, but we can use it just fine. Why? Because the bits than should be in the kernels are (though even that could be reduced). This is about changing the implementation of dbus to take advantage of some future kernel ipc mechanism, and for that the kernel does not need to understand dbus. Instead, the model (which should be much simpler than dbus) should have the building blocks needed for dbus and preferably also other ipc mechanisms.
Even if this only benefits dbus, having the kernel side of things be simple helps maintainability tremendously because ipc systems are not standalone things like drivers. The design affects how you can build containers and what security mechanisms you can provide (at the very least. I’m sure there’s more).
Well the kdbus implementation is quite standalone here actually, and if people had strong objections to the way Greg was going with kdbus the time for that feedback was 2 years ago.
As another commenter has mentioned, the generic approach was already tried 2 years ago, the AF_BUS patches were sent for review and the maintainer of the kernel networking stack rejected them out of hand:
http://thread.gmane.org/gmane.linux.kernel/1320892
“We are not creating a full address family in the kernel which exists for one, and only one, specific and difficult user.”
https://lwn.net/Articles/504970/
Your opinion is certainly valid and makes sense from a technical point of view, but please read up on the history before suggesting approaches that have sadly proved to be politically impossible before.