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

[John Baldwin]

On Tuesday, February 10, 2015 07:06:03 AM 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 ?

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