DBUS: Was in-kernel messaging (was Re: brasero requires gvfs)
On Wed, 3 Sep 2014 21:38:47 +0100
Jonathan Dowland <jmtd@debian.org> wrote:
> On Wed, Sep 03, 2014 at 03:54:06AM +0200, Bzzzz wrote:
> > Hehe, because it sinks his claws deep and everywhere (it also
> > plans to implant dbus _into_ the kernel (WTF? A kernel is
> > here to kernelling and nothing else AFAIK),
>
> Plans to move bits of dbus into the kernel predate systemd. The first
> serious effort I am aware of was patches by Vince Sanders (and
> possibly others) to add a DBUS socket type, but they were nixed by
> the network maintainer. It now looks like it might happen with KDBUS.
> Other than having Lennart's involvement, I don't think this has
> anything much to do with systemd.
>
> kernel support is pretty much essential to improve the performance of
> dbus. Lots of data is being passed over dbus by apps nowadays, and
> because it's an entirely userspace solution that means data is being
> copied from process to process. These needless copies can be avoided
> with some kind of help from the kernel, but none of the existing IPC
> mechanisms are good enough.
Hi Jonathan,
Maybe you or someone else can explain the need for dbus. First, I
should say that as an ex Kmail user, I was constantly afflicted with
runaway, 95% CPU consuming dbus-daemon instances, and so I have a bad
attitude toward DBUS, KDE, and the whole "programs communicate with
each other" thing.
To me, programs not knowing each others' business is a *good* thing. To
me, having something like DBUS is sort of like using global variables
in programming, in that you can quickly lose track of who said what to
whom. The only time I've consciously used is for notifications, and
notifications could have been done just as easily with a socket, with
all programs writing to the socket and the actual notifications printed
and handled by the socket's server. Unless different "client" programs
need to know what other "client" programs are doing, and why would
anyone construct a system that way?
The few times I needed two programs to communicate, there were always
relatively easy ways. One obvious example is mplayer's fifo API, so I
can control a running instance of mplayer from my own program. Another
is the Nullmailer program, which receives email files in a queue
directory, and when the client sends an interrupt (SIGUSR1 if I
remember correctly), Nullmailer breaks its normal sleep and processes
the queue directory. My vinyl record digitation scripts communicate
through a fifo, and are shown on slide 19 of this file:
http://www.troubleshooters.com/linux/presentations/leap_digitizing/leap_digitizing.pdf
The main advantage I see of things like signals, fifos, sockets,
intermediate file and the like, as opposed to DBUS, is that when
troubleshooting the former, you have a much smaller suspect pool than
if they'd used DBUS, in which case your suspect pool would be every
DBUS aware program running on your system.
Was DBUS created just for crazy entangled suites like KDE, or does it
have a more basic use within Linux?
Thanks,
SteveT
Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance
Reply to: