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

[Ian Lepore]

On Tue, 2015-02-10 at 07:06 -0800, Adrian Chadd wrote:
> On 10 February 2015 at 06:16, John Baldwin <jhb at freebsd.org> wrote:
> > On Monday, February 09, 2015 11:13:51 PM Rui Paulo wrote:
> >> Author: rpaulo
> >> Date: Mon Feb  9 23:13:50 2015
> >> New Revision: 278479
> >> URL: https://svnweb.freebsd.org/changeset/base/278479
> >>
> >> Log:
> >>   Notify devd(8) when a process crashed.
> >>
> >>   This change implements a notification (via devctl) to userland when
> >>   the kernel produces coredumps after a process has crashed.
> >>   devd can then run a specific command to produce a human readable crash
> >>   report.  The command is most usually a helper that runs gdb/lldb
> >>   commands on the file/coredump pair.  It's possible to use this
> >>   functionality for implementing automatic generation of crash reports.
> >>
> >>   devd(8) will be notified of the full path of the binary that crashed and
> >>   the full path of the coredump file.
> >
> > I think this is a very useful feature and I think this is fine to be in the
> > tree as-is for now.  My only note is that this is a bit of feature creep for
> > devd (this isn't a device notification, this is a system event notification).
> > As such, I think it might be worth thinking if we (collectively) want to think
> > about having a separate framework at all for system event notification.  You
> > could possibly publish other interesting events this way.  For example, Isilon
> > currently has a patch to log(9) Witness LORs.  I personally think it's a bit
> > hackish and potentially unreliable.  A much nicer interface if you want to
> > capture such things would be to publish an event for each logged LOR instead.
> > Machine checks are another example of something that might be nice to publish
> > (though you could possibly make the case that those would not be inappropriate
> > to publish via devd since actual hardware is involved).  Disk and PCI errors
> > are another class of thing that it would be nice to publish in an easier to
> > programmaticaly parse manner.
> 
> Cool, so someone's going to add multi-subscriber support to /dev/devctl ?
> 

I don't see how you get that from the foregoing at all.  Doing fan-out
in the kernel is hard, and doing it in userland is easier, so the
existing devd model could be an appropriate one to follow for a general
"kernel events which are not hardware events" system.

> I think devd grows these things because it's easier than teaching the
> devctl interface to support multiple listeners.

Until recently, devd only grew additional support for things which are
device-related, modulo the zfs stuff that I don't know much about.  I
was under the impression that that also was device-related in some way,
such as zfs reporting on device errors or attach/remove and things
related to that (like health of the pool(s) affected by the device
change).  Maybe the zfs stuff was the beginning of the mission creep and
still had enough of a device-related fig leaf to not look like creep.

But there's no disguising the fact that post-processing core dumps has
absolutely nothing to do with devices.

-- Ian