From owner-svn-src-head@FreeBSD.ORG Tue Feb 10 15:06:04 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 67289B0B; Tue, 10 Feb 2015 15:06:04 +0000 (UTC) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32920A17; Tue, 10 Feb 2015 15:06:04 +0000 (UTC) Received: by iecvy18 with SMTP id vy18so5849836iec.13; Tue, 10 Feb 2015 07:06:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ENAtZJ01tzIe+iDxlg2fuOO17ZJ77u3WuNchV3mF88M=; b=RtcDGtclkSu5MZ3Oflv81crJGIF7Y4tAQZs97iIi2xzVm1jGPMEL3GvozgV/78jEFk xv1L9Vdo8GMI03Z6RCsXTSkp35NkESbSoC8YPl7Vr3Ryh6t5mZBStu3B/ga+lf7EDHUk BazrEPIo+ibIdsvjCaxZEWXY52bTrBnuCnFMVywkpdUZl+FR59d8nGeu7nC1yXsv/WRw emzBCITG89bboJ2+I4gcXlgTqVskl2yBu1n+YeIASoP6WmnSH/D1zCQeHqk0uEEuNcBp eWTGlWfrEQ/no+EhxNLJ/f1HO9b5Fzcw1v9nrUfNKQGfeca+i+afFgHpVDltmx2Il5yG AZ+w== MIME-Version: 1.0 X-Received: by 10.50.93.70 with SMTP id cs6mr23380250igb.6.1423580763416; Tue, 10 Feb 2015 07:06:03 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.17.7 with HTTP; Tue, 10 Feb 2015 07:06:03 -0800 (PST) In-Reply-To: <1516483.e0EXgdk9ur@ralph.baldwin.cx> References: <201502092313.t19NDpoS083043@svn.freebsd.org> <1516483.e0EXgdk9ur@ralph.baldwin.cx> Date: Tue, 10 Feb 2015 07:06:03 -0800 X-Google-Sender-Auth: RLjUcxn0r4as2h-RCd1KabAsj_4 Message-ID: Subject: Re: svn commit: r278479 - in head: etc sys/kern From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" , Rui Paulo 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 15:06:04 -0000 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 ? I think devd grows these things because it's easier than teaching the devctl interface to support multiple listeners. -adrian