so the kernel can send d-bus messages

Robert Love rml at
Sat Jul 24 12:39:15 PDT 2004

On Sat, 2004-07-24 at 15:16 -0400, Sean Middleditch wrote:

> Assuming kdbusd is kept around (do we really want _that_ much Linux
> specific code in D-BUS?  What if the kernel events layer interface
> changes - that shouldn't require the user to upgrade D-BUS, as it should
> be neutral to its producers and consumers, right?) it should probably be
> made more fault-tolerant if the D-BUS daemon dies (or more likely, is
> restarted).

All good points.

First, I would expect that the kernel event layer code be an optional
compile feature.  We could try to abstract it fairly well and put it in
system-dependent code.

I could also write a spec ;-)

If the kernel events layer did change, something would have to be
upgraded either way.  Once we get the design hashed out for the kernel,
though, I really don't want it to ever change.  I do not even want the
signals to change.  I want to consider it ABI.

> Not only should it try to reconnect instead of bailing out, and complain
> very noticeably in syslog if it can't, but it should be important that
> it doesn't loose any potentially vital signals (like processor over-
> heating) that get sent to it while D-BUS is the middle of restarting.
> Actually, not being that knowledgeable on netlink (which means I should
> probably just shut the hell up, right?), what happens if D-BUS *is*
> responsible for reading kernel events, and is restarting right when a
> vital event comes through?  Does netlink throw away events if there are
> no listeners, or queue them?  How many messages stay in the queue?
> Should there be a priority setting for each event so that, if events
> need to be chucked out, it can make sure the vital ones like CPU over-
> heating errors are kept instead of less important events?

Messages not read at time of transmission are lost.  This is the only
negative item on the list of pros and cons for and against using

We need to start dbus at early boot, like we do now, and work hard to
ensure that it keeps running.

	Robert Love

More information about the dbus mailing list