svn commit: r278479 - in head: etc sys/kern
Slawa Olhovchenkov
slw at zxy.spb.ru
Tue Feb 10 15:13:01 UTC 2015
On Tue, Feb 10, 2015 at 07:06:03AM -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 think devd grows these things because it's easier than teaching the
> devctl interface to support multiple listeners.
/dev/eventctl and eventd? And, may be, rename /dev/devctl2 to
/dev/eventctl too.
More information about the svn-src-head
mailing list