Off-topic: D-Bus in the kernel

[Alban Crequy]

Le Fri, 17 Sep 2010 14:07:26 -0400,
Ray Strode <halfline at gmail.com> a écrit :

> Hi,
> 
> > 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?

It depends what is in /etc/dbus-1/{session,system}.conf. If there is:
  <listen>unix:tmpdir=/tmp</listen>
it uses the usual AF_UNIX sockets. If I change it to:
  <listen>dbus:path=/tmp/kdbus</listen>
then it use AF_DBUS sockets with kdbus.

I tested changing both session.conf and system.conf in order test kdbus
on both the session and system bus. For the system bus, I also needed
to change the default bus address in libdbus/configure.in because the
environment variable $DBUS_SYSTEM_BUS_ADDRESS is not set.

> 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 the bus system should not be started as early as the kernel boot,
at least not before some userspace application read the policy in the
configuration file and set up the bus correctly. It makes sense that
the system bus is created and configured by userspace.

In the prototype, a bus is created when an application bind() and
listen() on an AF_DBUS socket. kdbus doesn't know about the 2 kinds of
bus (system or session). There is several buses when several AF_DBUS
sockets are bound with a different name.

> 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
> for.
> 
> 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?

I didn't really tested several session buses, but different bound names
would create different buses. At least it works for 2 buses (1 system
and 1 session).

-- 
Alban