so the kernel can send d-bus messages

[Sean Middleditch]

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

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

> 
> 	Robert Love
> 
>