So what's the use case for sending large packets of data over dbus where the performance gains warrant integrating the dbus server to the kernel? Are they planning to migrate the X server to dbus?
Large packets, I'm not sure. For a long time, you've been able to attach a file descriptor (e.g. one end of a pipe) to a message, and then send bulk data over the file descriptor.
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.
X is going to be migrated into the recycling bin. Lennart wants to migrate PA to dbus, and the possibility exists for doing the same for some future version of Wayland.
Ah, Wayland. Yet another example of the successor to a system being less capable than the system it replaces.
"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."
It turns out that in this day and age, desktop users much prefer pixel-perfect tear-free rendering to network transparency. Wayland is X11 without the legacy cruft -- and it turns out that the only thing left in X11 that's not legacy cruft -- like seriously, bleeding-edge tech for 1986 -- is a centralized way to hand out direct-rendering frame buffers to user processes and composite them together for the final image. Which is exactly the extent to which modern apps use X11.
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.
It's historically been basically impossible to guarantee a tear- or glitch-free display under X because it was impossible in the protocol to sync display updates to vblank.
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.
I don't get the use case, why can't the programs use DBus to negotiate the streaming over some low-overhead transport? Why are people so insistent on ramming a square peg into a round hole?
I'm not terribly convinced by this point, since it's relatively easily solved by the "transparent direct connection" idea that's been suggested in LKML. That is, rather than making the application set up its own Unix socket connection for the media, the DBus library would have a simple call to switch to a direct socket connection as a transport for a given DBus connection. This wouldn't work for multicast, but who needs to multicast raw media data to whatever local process feels like receiving it?
KDBus was designed with sandboxed applications in mind. So use-case wise think android-style "use the camera app to take a picture/video", where the camera app transfers the media to another app over kdbus, thus without leaking information about the system.
You don't fling uncompressed video between apps like that, it goes straight to the hardware-accelerated h.264 (or whatever) encoder and then a low bandwidth stream comes out. Local AF_UNIX sockets (aka userspace dbus) provide ample bandwidth for that use case.
Yes, that's what I was talking about. Current dbus is is using local AF_UNIX sockets for transport -> the current transport is plenty fast enough to push encoded video over.
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.
As far As I can remember in mailling list one of kernel developer mention "android IPC (Its name I think is binder) is completely broken" , He didn't mention any evidence for his claim.
I don't know. I'm not advocating kdbus for multimedia, I'm just repeating what I've heard. I think one of the driving forces behind kdbus is Samsung who are interested in kdbus for Tizen.
