From my perspective, the D-Bus daemon has three main tasks:
- deciding where messages should be delivered (routing)
- actually delivering messages
- starting delivery sources on-demand
Third point is already intercepted by
start on dbus-activation), so we are left with message delivery and routing.
D-Bus messages have source and destination, sometimes multiple destinations. Just like TCP/IP packets, which sometimes have multicast destinations. For TCP/IP, we already have world-class delivery stack in Linux. And we have clear separation between mechanism — kernel TCP/IP stack using routing table to forward packet — and policy — routing deamons like
bird. Routing daemons manipulate routing table in kernel, but are not needed to actually move the packets.
That's how I see D-Bus—in—kernel. The kernel moves the message. D-Bus daemon should only modify kernel routing table putting “deny” and “allow” where appropriate. D-Bus daemon will no longer deliver messages, leaving message juggling to kernel. This separation will fix long-standing problems with D-Bus deamon early start and restarts. Message passing will be available all the time, D-Bus routing daemon won't need to run uninterruptably. Or at all.
Just like basic networking works right now without routing daemons.
mh 2012-06-20 14:41:31
Yay! Do you know if/how will be implemented sniffing?
Currently there is dbus-dump which uses strace (sic!) attached to dbus-monitor process.
If message passing will be in kernel, we can't use strace ;/
z 2012-06-20 14:59:02
I guess pcap interface will be extended, so tcpdump will work with it. Just like it allows sniffing USB & Bluetooth traffic now (see "tcpdump -D").
Khorne 2012-06-20 16:39:28
Nice! I love the idea, esp. for embedded Linux systems. Very useful.
Rich 2012-06-21 09:47:25
Oh dear, we need less dbus not more.
Khorne 2012-06-21 09:58:39
@Rich: why do you think that?
I've seen a lot of devs reinventing the RPC wheel with shm, sockets, pipes and whatnot. Dbus is a good solution to that problem.