Linus is just being Linus. He's brusque, non-chalant. He's inflammatory to get people to listen. His thesis here is that bad DBus performance isn't due to context-switching overhead or buffer copies (which can be solved by moving the daemon into the kernel), but instead it's due to malloc-intensive / utf8-parsing-intensive marshalling.
Secondly, he's saying that if performance is being used as an argument for kdbus, then that's an invalid argument.
He's totally right by the way. In this pure message-passing benchmark, where the message-passing overhead is the majority of the work, the slowness is not in kernel-scheduling/system-call/kernel-buffer-copies. People confused a potential impossible-to-overcome bottleneck as the most relevant bottleneck.
But that doesn't mean there isn't a reason for kdbus. Kdbus allows for much better authentication than UNIX sockets do (you can authenticate with pid, pgid, uid, gid, kdbus token, etc.). Also it allows for message-passing security policies to live in the kernel which is crucial for security applications. The tangential performance benefits are nice too, even though the bottleneck wasn't in the kernel to begin with.
Responses like yours are why I enjoy to visit Hacker News.
Sorry for going meta - I'm just a bit disappointed because your tone used to be the normal thing on HN, even when there were just as many disagreements. People were able to keep it friendly. Today not as much; I find HN has become too mainstream and "reddity", and the tone in general too emotional and aggressive, about who or what is right.
This wasn't unexpected, but still, it is good to see not everyone has moved into that direction.
Secondly, he's saying that if performance is being used as an argument for kdbus, then that's an invalid argument.
He's totally right by the way. In this pure message-passing benchmark, where the message-passing overhead is the majority of the work, the slowness is not in kernel-scheduling/system-call/kernel-buffer-copies. People confused a potential impossible-to-overcome bottleneck as the most relevant bottleneck.
But that doesn't mean there isn't a reason for kdbus. Kdbus allows for much better authentication than UNIX sockets do (you can authenticate with pid, pgid, uid, gid, kdbus token, etc.). Also it allows for message-passing security policies to live in the kernel which is crucial for security applications. The tangential performance benefits are nice too, even though the bottleneck wasn't in the kernel to begin with.