so the kernel can send d-bus messages
elanthis at awesomeplay.com
Sat Jul 24 13:07:05 PDT 2004
On Sat, 2004-07-24 at 15:39 -0400, Robert Love wrote:
> On Sat, 2004-07-24 at 15:16 -0400, Sean Middleditch wrote:
> > 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
Hmm. Assuming that we can't make a really good guarantee that D-BUS
will always stay running, that sounds like a point in favor of a kdbusd.
It's very easy to keep a very small and simple daemon like that running
and holding a small queue of events. It could also just log the events
if it can't deliver them to D-BUS, giving servers that absolutely
require the information to be able to monitor the system logs in
addition to D-BUS signals.
> We need to start dbus at early boot, like we do now, and work hard to
> ensure that it keeps running.
Hmm. Doesn't D-BUS need to be restarted whenever the settings change,
like adding a new bus configuration? If we have D-BUS able to reload
these without shutting down, that'll be a lot better.
I'd actually like to see D-BUS be able to do that independent of the
kernel events layer, since all the other D-BUS using apps shouldn't need
to have a bunch of duplicative code added for handling D-BUS connection
> Robert Love
More information about the dbus