

D-Bus in the kernel, faster - IgorPartola
http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/

======
sqrt17
That's the downside of having VM-based system emulation easily available:
People who think that userland scripting is too complex take this complex
functionality that occurs in semi-critical areas into C code, possibly into
the kernel. Because _they_ can debug it just fine when they're trying it out
in the VM.

Fast forward: the thing gets deployed by default on Ubuntu (or SuSE, or Fedora
... whatever), and people start getting hard-to-debug crashes. Someone,
somewhere, will run into an ugly corner case. Or some app that has been
quietly chugging along in the corner suddenly causes serious breakage.

That's the moment when you get all those bugs closed with WORKSFORME, INVALID
or other non-solutions, because users can't get the debugging info on their
production system, and the enthusiastic developers can't reproduce it on their
system and are not as enthusiastic about figuring out which obscure corner
case caused the sytem to misbehave.

As an example, see here:
[https://bugs.launchpad.net/ubuntu/+source/ureadahead/+bug/48...](https://bugs.launchpad.net/ubuntu/+source/ureadahead/+bug/484677)
Under various conditions, the boot process just gets stuck (e.g., when
something has juggled the hard drive letters and what used to be /dev/sda is
now /dev/sdb and vice versa, or you have a routine fdisk check, or something
else), and when you switch off the splash screen (or don't have it switched on
at all, for obvious reasons), all you see is the (spurious) message from
ureadahead-other. Net result: this kind of spurious hangs on boot, which were
reasonably easy to diagnose in the time of SysVinit, are now a serious PITA
and the developers which are responsible for the boot process don't give a
fart because people don't have the knowledge that's needed to debug the subtle
interplay of dbus, upstart, plymouth (it's obvious that "plymouth" is the
splash screen software and not a device driver for a CRT-based face tanning,
isn't it?), and possibly others. (Full disclosure: I twice or thrice spent a
whole morning figuring out a random boot problem without getting anywhere.
After several hours, I found out that part of the problem was caused by
mountall not finding something, then asking whether you want to continue
booting without actually displaying a prompt that says so. Back then, I
managed to find the corresponding bug on launchpad among the 5+ bugs about
weird, hard-to-diagnose boot problems where all you see is the ureadahead-
other message).

TL/DR: if you consider moving X into the kernel, please imagine yourself in a
situation where X breaks in production and you have to guide a user through
the debugging of X and various assorted components that talk to X in order to
find out whether it's X or Y or ABC and what exactly is breaking. If that
thought would give you a bad dream, please refrain from putting X into the
kernel. Thank you.

~~~
swolchok
"X" is a really bad variable to use, seeing as how it's the windowing system.

~~~
xentronium
I think you got it the other way round.

X is a really bad name for the windowing system, considering they used it for
generic variable name for centuries.

~~~
IgorPartola
UNIX has a history of names that don't make sense to an outsider. The first
time I came across bitchx I was very confused.

------
nuxi7
+5 for realizing that dbus-daemon is stupid because IPC is the kernel's job

-10 for fixing it by putting dbus-daemon into the kernel

To redeem yourself please try again with the following requirements:

* No dbus-daemon

* No changing or adding kernel interfaces

Hint: put all the brains inside of libdbus

~~~
FooBarWidget
How do you want to implement broadcasting without a daemon or some other
intermediary? It's called, you know, d _bus_.

~~~
sandGorgon
I have a question - with systemd
[<http://www.freedesktop.org/wiki/Software/systemd>], do you still need a
daemonized message bus ?

OSX's launchd, creates listening sockets and when it receives a connection, it
starts the service and hands over the socket to the service.

Given such a scenario, can you not simply work with plain-jane IPC ?

~~~
FooBarWidget
I don't see how that can be compared with a message bus. They do different
things.

------
wnoise
This really seems like something that shouldn't belong in the kernel. The
D-Bus protocol is a bit more complex than other IPC, and it makes sense to me
to keep that level of complexity in userspace. (Of course if it were a simpler
model -- just a bunch of multicast channels, rather than all this filtering,
it might make sense to put bits in the kernel).

------
someone_here
I'm surprised it has such an impact on an N900 signing on to Jabber. I had no
idea it was so reliant on d-bus.

------
jey
Mach messages sneaking into Linux? </sarcasm>

------
nodata
D-Bus in kernel, kernel slightly slower?

