so the kernel can send d-bus messages

Sean Middleditch elanthis at awesomeplay.com
Sat Jul 24 12:16:46 PDT 2004


On Sat, 2004-07-24 at 14:31 -0400, Robert Love wrote:
> Yo,
> 
> FYI.  I finally proposed the Kernel Events Layer patch at last week's
> Kernel Summit.  If you were at OLS, I also gave a talk on it.

You are my hero.  ;-)

> Mr. Kay Sievers has a lot of test code and examples available at
> 
> 	http://vrfy.org/projects/kdbusd/
> 
> kdbusd.c is a simple daemon to push the kernel events onto the system
> message bus.  This can also be done directly in the D-BUS daemon (my
> personal preference).

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).

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?



More information about the dbus mailing list