From owner-svn-src-head@FreeBSD.ORG Tue Feb 10 14:18:53 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 137A3B53; Tue, 10 Feb 2015 14:18:53 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DF1D633D; Tue, 10 Feb 2015 14:18:52 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C43F4B91F; Tue, 10 Feb 2015 09:18:51 -0500 (EST) From: John Baldwin To: Rui Paulo Subject: Re: svn commit: r278479 - in head: etc sys/kern Date: Tue, 10 Feb 2015 09:16:55 -0500 Message-ID: <1516483.e0EXgdk9ur@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <201502092313.t19NDpoS083043@svn.freebsd.org> References: <201502092313.t19NDpoS083043@svn.freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 10 Feb 2015 09:18:51 -0500 (EST) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 14:18:53 -0000 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. -- John Baldwin