From owner-svn-src-all@FreeBSD.ORG Tue Feb 10 15:37:06 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 594F7326; Tue, 10 Feb 2015 15:37:06 +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 2D52AD2E; Tue, 10 Feb 2015 15:37:06 +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 B66CFB91E; Tue, 10 Feb 2015 10:37:04 -0500 (EST) From: John Baldwin To: Adrian Chadd Subject: Re: svn commit: r278479 - in head: etc sys/kern Date: Tue, 10 Feb 2015 10:36:51 -0500 Message-ID: <2907775.GXqUUp6Hz6@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <201502092313.t19NDpoS083043@svn.freebsd.org> <1516483.e0EXgdk9ur@ralph.baldwin.cx> 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 10:37:04 -0500 (EST) Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" , Rui Paulo X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 15:37:06 -0000 On Tuesday, February 10, 2015 07:06:03 AM Adrian Chadd wrote: > On 10 February 2015 at 06:16, John Baldwin 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 ? Eh, devd publishes /var/run/devd.pipe already which supports multiple subscribers. I think that was one of the intentional design decisions was to handle multiple subscribers in userland rather than the kernel. > I think devd grows these things because it's easier than teaching the > devctl interface to support multiple listeners. That wasn't really my question. My question was if we want distinct streams or if we want want unified stream. Having a unified stream might very well make sense (and if so we could rename devd to make that more obvious). -- John Baldwin