svn commit: r278479 - in head: etc sys/kern

[Ian Lepore]

On Mon, 2015-02-09 at 18:29 -0500, Benjamin Kaduk wrote:
> On Mon, Feb 9, 2015 at 6:22 PM, Rui Paulo <rpaulo at me.com> wrote:
> 
> > On Feb 09, 2015, at 03:16 PM, Benjamin Kaduk <bjkfbsd at gmail.com> wrote:
> >
> >
> > What advantage does putting this in devd have over a standalone daemon for
> > crash reporting?  Is it just the ease of implementation to leverage the
> > existing infrastructure?
> >
> >
> > Well, I want to automatically inspect all the programs that crashed in a
> > given system.  I don't see how you can do that with a standalone daemon.
> > Or maybe I didn't understand what you meant.
> >
> 
> I think you have misunderstood what I was trying to ask.
> 
> We could in principle write a new daemon, call it crash-reporterd for now,
> and have the kernel notify that daemon whenever any program on the system
> crashes.  But writing the infrastructure to support that would be a bunch
> of work, and we already have devd set up to get notifications from the
> kernel, so it is much faster to implement crash reporting in devd, even
> though crashes in software have nothing to do with device changes.
> 
> The question boils down to: is the time saved by implementing it this way
> worth the tradeoff of architectural purity.
> 
> I don't have an opinion myself, I just want to make sure the question is
> considered.
> 
> -Ben

Truth be told, it kind of bugs me.  I think adding this to devctl and
devd is inappropriate without also renaming those components to reflect
their new role, and rewriting the manpages to reflect what they actually
do now.

If you ponder for a moment what the new role seems to be (generic
notification to userland of events happening in the kernel), you end up
with names like "keventd" and that makes you wonder whether a new type
of knote for kevent, listened for by a new crashd app, would be better.

-- Ian