http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193...
DBUS implementation aside (which seems to leave a lot of room for optimization), my initial reaction was that the gain was rather minimal compared to the claims of the systemd folks.
However, the real issue is how slow overall DBus seems to be according to those numbers. As Linus says earlier in the thread: "No way should it take 4+ seconds to send a 1000b message to back and forth 20k times." This is indeed rather shocking.
I will put it another way: if it can't be more performant than a simple HTTP client/server it doesn't deserve to be included into mainline kernel especially when the costs are so high.
My understanding of this whole thing was that most of the car companies thought they should try using linux for their console / entertainment / etc systems. Electrical and mechanical engineers seem to all only use windows and not know anything about linux, so they asked themselves "what's the bus on linux?" and found D-bus, the desktop bus used by desktop environments and utilities, for a handful of messages a minute.
They used it to send frequent sensor data to all sorts of services that might be interested, like digital gauges, sound distribution, etc. They didn't realize that there are lots of good low-level IPC mechanisms available on linux, and they should have probably used 0mq, or a scheme based on unix sockets with filesystem permissions based access control, etc.
Anyway, they realized that D-bus had way too much overhead, and instead of porting to some other IPC, got to work accelerating D-bus with additional kernel functionality, such as the AF_BUS which was rejected by the linux networking maintainers. (Though that was probably a better idea than kdbus.)
How exactly GregKH got into this project, I'm not entirely sure. He is relatively friendly with the systemd developers. He's paid by the Linux Foundation, and many of those car companies are members of the Linux Consortium, or something like that, I think. I dunno. Apparently a lot of people used D-bus accidentally, and now the thing to do is make the kernel make it faster.
"Wayland does not currently provide network transparency, but it may in the future. It was attempted as a Google Summer of Code project in 2011, but was not successful. Adam Jackson has envisioned providing remote access to a Wayland application by either 'pixel-scraping' (like VNC) or getting it to send a "rendering command stream" across the network (as in RDP, SPICE or X11). As of early 2013, Høgsberg is experimenting with network transparency using a proxy Wayland server which sends compressed images to the real compositor."
[1] https://en.wikipedia.org/wiki/Wayland_%28display_server_prot...
Remote access can be achieved by running a special Wayland server on the remote side that connects to a Wayland client on the local side and exchanges framebuffer and event data with that client. In this setup, apps can talk Wayland and not even be aware that their display is being networked; they are also completely decoupled from the remoting protocol which can be anything. RDP and streaming h.264 would be good choices, certainly better than legacy X protocol.
Wayland is objectively a huge win.
I know some hardware (eg. nvidia optimus) have tearing but these are driver bugs and not a property of X (or freedesktop's implementation thereof).
The XPresent extension may ameliorate this, but adding yet another extension to a protocol already lousy with them, such that they have to be tested for at runtime, is pretty much polishing a turd at this point. Starting from scratch is the correct approach and even the X.Org foundation advocates Wayland as X's replacement.
People keep telling me that.
Greg KH has given a few talks/blogs about the design goals of kdbus. https://lwn.net/Articles/551969/
Another one?
If the existing solutions were sufficient, why would the 'new' way ever get merged into mainline?
I really still don't see a good-enough scenario for this.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
But not many people are aware of that; since neither systemd nor Lennart Poettering have anything to do with it, the usual armchair architects did not paste their, uhm, well considered opinions about how much it sucks and is the end of the UNIX philosophy all over the comment threads when it happened.
It does in fact use a SLAB, based on early kernel versions with per-thread allocation caching.
As for avoiding utf8 validation, that would require being able to trust the sender/receiver. That, I believe, is a major bullet point of both memfd (sealing) and kdbus.