Off-topic: D-Bus in the kernel

Ray Strode halfline at
Fri Sep 17 11:07:26 PDT 2010


> So I could test a full GNOME session (and also N900) with AF_DBUS
> without implementing the bus driver in the kernel.
So this puts the session bus in the kernel?

To me, putting the /system/ bus in the kernel makes some sense because
the lifetime of the system bus is the lifetime of the system.  Just
like the kernel.  But I guess for me this solves more interesting
political problems than performance problems:

1) Put an end to the tired debate on whether or not it's okay to
restart the system bus on upgrades
2) Put an end to the auditd controversy involving audit trails
3) Put an end to the (albeit mostly fizzled out in the last couple
years) vitriolic and ignorant ideas that d-bus is "just more desktop
bloat needed for NotworkManager and *Kits"

To me, the context switch minimization and slightly better performance
should just be incidental.  d-bus is designed for low-frequency
control messaging anyway.  When its peformance is a measurable
bottleneck, it's a sign it's not being used for what it's intended

How do you handle more than one session bus?  Tie it to kernel
keyring?  generate random string in the userspace half like with
AF_UNIX sockets?


More information about the dbus mailing list